Strange result adding new camera

[dronevdl]

I have a dataset from a Sensefly eBee Plus drone with a Sensefly S.O.D.A. camera. I cannot share this dataset. But I can reproduce the problem with a public dataset that can be found on https://support.pix4d.com/hc/en-us/articles/360000235126-Example-projects-real-photogrammetry-data#quarry the dataset can be downloaded from: https://s3.amazonaws.com/mics.pix4d.com/example_datasets/example_quarry_2.0.zip

For the example I used ER-02-21260_0129_0028.JPG from this dataset.

I use the latest code, did git pull.

I added to drone_sensors.csv: senseFly,eBee Plus,senseFly,S.O.D.A.,5,13.2,8.8,1.0,1.0

My command line is: python3.9 Drone_Footprints.py -i /disk/data/3dmapping/soda/ -o /disk/data/3dmapping/soda-results/ -m

Above is the resulting Geojson loaded in QGIS. There is a sort of butterfly shape.

This is the resulting geotiff converted to png because github does not support tiff.

[spifftek70]

Military drone?

[spifftek70]

Well, I figured out the issue pretty fast. Most Drones metadata measure Roll, Pitch, Yaw, and altitude by an industry standards. That is, it's orientated for the camera looking DOWN. Plus most separate the Drone's Roll, Pitch, and Yaw from the Gimbals, like so:

  'XMP:FlightPitchDegree': '+0.70',
  'XMP:FlightRollDegree': '+1.60',
  'XMP:FlightYawDegree': -24.1,
  'XMP:GimbalPitchDegree': -89.9,
  'XMP:GimbalRollDegree': '+0.00',
  'XMP:GimbalYawDegree': -55.9,

The eBee Plus, senseFly is handling their metadata more like a GoPro does. That's to say, looking straight forward. Plus it only has ONE set of Roll, Pitch, and Yaw values, like so:

 'XMP:Pitch': 4.34836,
 'XMP:Roll': 0.088655,
 'XMP:Yaw': 31.640188

Also, the altitude is off, so I'm wondering if it is in Feet rather than meters.

This will take some time to figure out and it'll be a bit before I can look at it. If you'd like to take a crack, it would be on new_fov.py, probably in calculate_rads_from_angles(). probably an if/else statement for when pitch is within a certain range of 0. This will also affect Yaw by 90°.

Here a JSON showing one files metadata:

ebee_meta.json

[sbonaime]

@spifftek70 We can also check if we have some eBee Plus, senseFly data from the metada and then create the correct image attributes at this stage

[spifftek70]

@spifftek70 We can also check if we have some eBee Plus, senseFly data from the metada and then create the correct image attributes at this stage

I downloaded a dataset from the link he provided above.

[dronevdl]

Sensefly eBee series is not a military drone, it is just a professional mapping drone. Not everybody likes to have their dataset on public internet, by using the public dataset I do not have to ask (-: In my dataset, the altitude is Height above the Ellipsoid (HAE), that differs 40 meter with Mean Sea Level at the location of my Dataset. So drone is set to fly at 120 meters, HAE in metadata of photo is 160 meters.

[spifftek70]

Sensefly eBee series is not a military drone, it is just a professional mapping drone. Not everybody likes to have their dataset on public internet, by using the public dataset I do not have to ask (-: In my dataset, the altitude is Height above the Ellipsoid (HAE), that differs 40 meter with Mean Sea Level at the location of my Dataset. So drone is set to fly at 120 meters, HAE in metadata of photo is 160 meters.

Yep. I've figured out the yaw, pitch, and roll fix. Working the Altitude now. Absolute vs Relative.

[spifftek70]

Okay, the sample set is from 2019. Has the drones firmware been updated since then? @dronevdl, If you can't send me a sample image from your drone, can you send metadata?

This drone only has Absolute Altitude (above sea level). It doesn't have relative altitude (above ground level). Without accurate elevation, it's impossible to accurately calculate the relative altitude. OpenElevation is accurate within 30 meters, depending on available data in that location, so getting that to work is somewhat 'iffy' at best.

[dronevdl]

My dataset is from 2018 (-:

[spifftek70]

This drone only has Absolute Altitude (above sea level). It doesn't have relative altitude (above ground level). Without accurate elevation, it's impossible to accurately calculate the relative altitude. OpenElevation is accurate within 30 meters, depending on available data in that location, so getting that to work is somewhat 'iffy' at best. Unless you have a DSM? That would fix it.

[spifftek70]

Also, you aren't going to get a great "map" of a query. This doesn't give you a 3D interpretation like ODM. It only registers the four corners of the Field of View.

[dronevdl]

Understand. I am only interested in (rough estimate of) the four corners. Yes I have a DSM as output of photogrammetry software.

[dronevdl]

My dataset is flown with RTK in ETRS89. I assume I can convert from HAE to MSL using one of EGM96/EGM2008/etc. It seems that OpenElevation returns an elevation measure from MSL. If I provide my own DSM, I assume it should have values measured from HAE, so it is the same as the height in de exif metadata.

[dronevdl]

Yes, I checked, my DSM has HAE values. Its projection is ETRS89 UTM Zone xxN.

[dronevdl]

ERROR | Utils.new_elevation:get_altitude_at_point:72 - Point (xxx.xxxx, yyy.yyyy) is outside the elevation data bounds for file EP-xx-xxxxx_0027_0001.JPG. Switching to default elevation.

Seems it does not like UTM, probably need to convert to ETRS89 using gdal.

[spifftek70]

I have it fixed already… IF open elevation has data or if you have a DSM. Will push later today or tomorrow.

[spifftek70]

but the info from that drone isn't the best for this process as it doesn't separate the camera/gimbal data from the Drones.

[dronevdl]

Thanks a lot. Just to learn from this. Why is drone data + separate gimbal data beter than combined? Are you on discord or somewhere, so for the case that I just want to ask a question without raising an issue on github?

[spifftek70]

On Slack.

[spifftek70]

The ability is now there, but only with accurate areas of OpenElevation or good DSMs.