Just completed a session, almost 400 drone photos all aligned and spaced as expected.
A number of the drone photos, with what appear to be good, Lat xx:xx:xx.xx, Lon xx:xx:xx.xx, according to the properties of the photos. But a goodly number of these photos are grossly displaced in WebODM3 … two photos in particular 0037 & 0218 are 30 meters south and 42 meters southwest of their true(by properties and by visual), from where they should be.
About a dozen(?), or so photos, are grouped about 30 meters south of the true location, and 900 feet south a string of centerline drone photos are grossly misaligned 30 meters south of the actual centerline, and skewed a few degrees.
I visually skimmed through the drone photos and they look in order.
If the drone doesn’t have an RTK receiver it can be more easily disturbed and loose signals. There’s something called multi-path that can fool a cheap gps, it’s when signals bounce against things.
The drone has GPS and is 300 feet up … no structures rise above 20 feet or so and trees rise about 70 feet above the lowest terrain(E-W Road in front), so multipath should not be a problem in a clear sky. The recorded locations data(photo properties), agrees with where the drone was when the photos were taken, but the locations indicated in WebODM sometimes produced the photos about 100 to 150 plus feet away and aimlessly wandering from photo to next photo.
The back of the property also appears to have gone in a steep vertical trajectory(property is flat).
After seeing this I ran an Ortho which appears rather normal(in comparison), with all the photos in their proper, relative location.
I had noticed a few photos around 0030-0036 indicating the proper conversion from DD.mmss to DD.dddd, for longitude, but in flights going north or south the converted changing Latitudes all remain pretty much the same, instead of going north or south
If you don’t have Doppler accuracy set in your exif, try running with the gps-accuracy flag set to 2x your expected accuracy. This will constrain camera movements in the SfM stage.
Doppler accuracy? I have always heard that once a fix is actually made(even with consumer GPS), that relative accuracy improves, I had always assumed this was what I surmised, “Doppler accuracy”.
I;m sure a Hubsan Zino Mini SE, doesn’t have a great GPS antenna, but I also don’t recall the drone having Doppler accuracy settings, I do have access to sids for the county that also indicates the data the drone have recorded, puts the drone where it states(exif/details), and in any case, the errors approach as much as 150 feet. In some of the haywire photos, the camera is actually facing nadir, but the results seem closer to 45 degrees(on the side of a mountain). A second project(Fast Ortho), with all the same photos, shows everything in the correct location, though at least one photo was skipped(?).
Sorry, pre-coffee post. DOP – dilution of precision. We assume a maximum DOP of 10m, which means your photos could get moved pretty far. Tightening that down to 1m or less will keep these positions from moving on model initialization.
So, e.g. set --gps-accuracy to 1.0 or 0.5. Just make sure to not set it so low you get failures from overconstraining the model initialization. 2x your anticipated accuracy is a good starting place, though 4x might be a bit safer. So if you are expecting decimeter accuracy, set your --gps-accuracy to 0.4m
If you can get DOP for each image and feel comfortable writing that to each image in the tags, that can parameterize the starting model even better. Otherwise, choose your max DOP or max anticipated DOP and multiply by 4. You can run again at lower DOP values up to 2x DOP if 4x max DOP works.
There are no problems with the recorded GPS locations … the worst offenders(in WebODM), fall exactly(within a few feet or so), of the location as depicted by the photo exif, A second run on the same data bears this out … there appears to be no problem with the GPS reports … the errors appear to be in WebODM … granted something I did might have caused this problem, but that’s not what I’m seeing, especially when I see a string of locations that appear to be hovering, when in fact the drone is moving north or south 10+ meters between photos … I have also suffered random(?), photos, in the task memory, not showing up, or being somewhere, where I can’t find it … others seem to have reported similar issues …
If I can find what I’m doing wrong, I’ll stop doing it …
Perhaps I’m misunderstanding the issue, but if the issue is with the incorrect displacement of photos relative to the more correct exif location, change your --gps-accuracy to match 2-4x your DOP and all should be well with the world. You can also increase your --min-num-features to 20,000 or 40,000 to increase the quality of matching between photos, which may be part of the underlying issue.
But: DOP is your first fix. Try it. I think you’ll like it!
These are not “hard”, displacements … None of these issues appear to be consistent through multiple projects(same data). I don’t recall such problems back in 2021/2022, but the drone I used then didn’t seem to record GPS data (no exif data), Anyway, if the data is good on one project session(same flight data), then it shouldn’t suffer such errors on a different session, and visa-versa
Been surveying since HP35 was introduced … long time …
I wonder if all that photo data in exif/properties can easily be dropped into a spreadsheet?
How does your elevation of the final cameras match with the exif elevation? I have seen quirky results where it seems the camera was way off both vertically and horizontally in a misguided attempt to match certian distinct patterns of pixels. It’s usually with very homogenious features and a few weird pattern features scattered throughout. The weird features in my case had a high whitness value and were scattered throughout the photos. They kept getting pushed and scaled in the point cloud to the same location, quite smaller and well below the normal pc surface. Never did resolve it.
I’m running another session(same data), so I try not to mess around too much till it finishes, but I did notice that the displaced camera locations appear to serve as vertexes(like a hinge), to the portion of the 3d map that appeared to be going up the side of a mountain/tall hill. I think that would make the distance from the displaced camera to the side of the “hill”, the same as the correctly placed locations to the flat area of the ground. All the photos front to back(constant rise front to back is about +10 meters elevation), consistently show 71 or 71.1 meter elevation … the worst outlier(35 or 36) reports 71.3 meters. Either the Zino adjusts to 71 meter(probably not), or it attempts to hold the 71 meters throughout the project, as such that 71 meters in the back is actually about 61 meters.
There was virtually no wind and all the photos appear to be correctly centered vertically from the recorded Lat/Lon.
Yup, we’ve got a lot of experts and expertise here. I’ve processed some of the largest civilian drone projects in the world for the purposes of flood modeling and I see hundreds of datasets / 100s of thousands of images a year here and in my other work, and while I’m in my 3rd decade in this and related spaces, I was born after the HP-35 was introduced.
I’m consistently surprised at the quality of insights and cool and challenging problems I see here daily. The number of times I suggest something and someone suggests a refinement to that in spite of my expertise is staggering, and I consider that a blessing and opportunity.
Advice here is freely given. When I see these kind of offsets on datasets, refining gps-accuracy defaults and increasing minimum number of features usually fixes things up. If it doesn’t for your data, then we’ll have other things to figure out.
Sometimes it doesn’t help. If it doesn’t, someone else may come along with a better idea. That’s what we are here for.
If you’ve got a dataset that is exhibiting these artifacts you can share for inspection and testing, happy to help in that way too. If you want support in finding solutions, we are here. Either way, good luck.
My last run(same data/same settings), came out very much different, to the point at all my photo on the west side of the project, got all scrambled up into two areas, to the east of the property.
I’m going to fire WebODM2 and use the same data again.
Just finished running the same data in WEBodm2, and everything looks near-perfect.
Ortho Raw measurements(no control points), and a parcel 846.75x155,measures845’x154.5.
All the photos look to be exactly where they should be, and in 3D, the flights are level, while the ground gently slopes up to the back(as it actually is)
You can download the log, in which case you get the full, untruncated version. It won’t fit here on the forum, but you can post to any file sharing or text sharing site and link here.
Yes: it’d be great to have logs from the same dataset processed in 2.x and 3.x version for comparison. Make sure you have processed with the very latest 3.x version.
