Hi All,
I am unable to successfully produce a map. This issue I am experiencing happens to most datasets I feed in, so I am guessing it is a procedural error on my part I am hoping to get help with identifying.
For this case, I flew 58m legs, 12 meters apart at 30m altitude. I then flew a second set of legs half way between the previous legs and parallel to them, at 40m altitude.
This by my reckoning should produce sufficient overlap as well as the images from two altitudes.
It seems to produce a 3d map fine, but the 2d image doesnt work.
However, my results are either a subset of the map has formed, or in some cases only weird sections have generated. To keep it simple, the former is the case for this dataset.
Did you fine tune any parameters? Which ones? No. All settings standard
If applicable, what browser are you using? What operating system? How did you install the software? Be precise. Firefox 87, Ubuntu 20.10 64-Bit, 16Gb RAM, WebODM from git following instructions.
Im flying a DJI Spark, and using Litchi for my flight plan if that helps. Image spacing is every 10m, cruising speed is 1m/s
I’ll try to get to this this week. Ping me if I don’t by midweek. Tomorrow I hope to not be at the computer much, so not a good day for poking at data, haha
Here’s another asset dump for a second test case. This time I went 60m altitude. 3d model generated brilliantly(I am honestly surprised at how well) but the orthophoto is a failure.
Given the small disparate clusters of images, I’m not terribly surprised your first dataset doesn’t want to stitch a contiguous surface. There simply isn’t enough coverage to join the clusters together. What did you use to flightplan this?
Might work if you processed each cluster separately and then tried to merge the resultant point clouds together, but you still won’t have a contiguous surface between them. There simply isn’t data there.
That’s consistent with my results, and that’s the thing, It doesn’t reflect my flight plan one bit.
Good to know the issue is reproducible though.
Here is the flight plan from the second data set I supplied:
Doesn’t reflect what ODM is showing at all. Im thinking this could be a GPS accuracy issue on my drones side?
I’m using a DJI Spark.
Given that the 3D model works fine, and I dont require location information. Is there any way to skip the geo-location step and just generate the ortho image?
I did some looking and it turns out the GPS accuracy on my drone is the issue:
You’re right, GPS coordinates in photos taken with the Spark are only accurate to 1 arc second resultion. That’s poor IMHO.
1 arc second means an inaccuracy of up to 44 meters (equator area). At least one extra digit would give decent accuracy.
So, I will need to figure out a way to get more accurate location date in the EXIF. But it looks like those settings will be useful to help me work around it for now. Thanks!
Wow, that’s horrific. What is DJI doing to make the images so inaccurate? There is no way the GPS on the device operates at that level… It wouldn’t be able to fly.
If it is deterministic, you can override the GPS locations with data from the flightlog using Geosetter.
Thats what I am thinking for a long term workaround, some way to replace the EXIF data. Annoying but with small data sets it should be manageable. Thankyou for all the assistance.
Interesting. Thank you for showing me this. I will definitely investigate this issue further and see if I can get a root cause. I wonder if the accuracy of GPS EXIF is tied to the number of satellites…
Will reply back if I can solve this.
Edited: So far ive done some looking into the flight logs which gives position to 6 decimal places, but then it seems like that value is clipped to 4 decimals for the EXIF information. Im assuming the loss of these two digits is what is messing everything up. Should be a simple matter to get the information from the flight log into the image before processing.
So I have made some progress but with all things its 2 steps forward, 1 step back.
I have made a simple python script to scrape the flight log and update the image EXIF accordingly.
I get a nice interesting result though:
As always, 3D generated perfectly.
Heres the data set with the fixed info and the assest dump as always:
As a bonus, heres the script for future reference:
As a bonus laugh, DJI’s response. Love the upsell at the end.
The GPS accuracy could have deviation of several meters, even more than 10 meters when GPS signal is not strong enough.
For the accuracy of the GPS coordinates in photo EXIF data, there might be deviation of about 100+ meters (mainly from satellite system deviation, satellite current orbit angle deviation, and GPS hardware deviation).
May we confirm whether you would like to use Spark to mapping? If yes, we recommend Phantom 4 RTK, Matrice 300 RTK and so on.
So even with my six year old Solo and it’s original M7N GPS Rev.A with a well-known hardware flaw, I never had issues with Arc-second level accuracy. My bad data was usually on the order of sub-10m.
It honestly feels like they’re purposefully ruining the data coming from the entry level platforms to not have them eat the lunch of their “real” stuff. Their response heavily implies this as well.
Amazing work on the script!
I hope you get something good from this. This frustrates me to see happening to someone.
As for the precision of the tags, see this incredible answer:
TLDR: 11m at four decimals. They’re doing something shady it seems.
I own a Spark and have never used it for photogrammetry. But my impression is that it´s capable of doing the job with some accuracy.
I will experiment this weekend and report if I find something useful.
