How to minimize the Z errors

Hi everyone!!!

i have just made a photogrammetric processing (ORTHOMOSAIC + DSM) both with webODM and another famous paid-software (the swiss one…), in order to match the results in term of a cross match about the vertical errors.
I would like to know the best process settings in webODM to be able to minimize errors, I found an excessive vertical error.
I specify that I have used a redundant number of GCP.

Could anyone suggest something to me about it?

Thank you very much,

bye!

Federico

1 Like

Lots of questions, as your post lacks all relevant details for evaluation :slight_smile: :

  • Can you share the dataset?
  • What is your sensor?
  • What is your platform?
  • What is your platform’s GPS settings?
  • What is your process for setting GCPs
  • How are you determining the error?
  • Is the error systematic or random?

Our experience with comparing ODM with GCPs to the Swiss software is that the error is almost identical in horizontal and vertical, though there’s a bit more noise visible in ODMs terrain models because we don’t use meshes the same way to reduce DEM noise.

The latest dataset was as follows:

  • Not yet sharable
  • SODA
  • eBee Plus
  • RTK GPS onboard, but as it’s a fixed wing, we see 0.5m error in final product without GCPs
  • RTK GPS for setting ground control with large clear targets
  • Overlaying GCPs on orthophoto and elevation model and measuring difference between placement in model and anticipated placement
  • Appears to be random

Point clouds look better than the Swiss software, but elevation models are not as smoothed.

I would have a little more detail above, but this is a project led by a collègue and he’s still deep in the processing, so I’m not bugging him for more detail yet. :smiley:

3 Likes

All this to say: we do see large errors in using GCPs with split-merge. But for running individual models, the results using the above setup has been very good. We need to find the issues with split-merge and address them.

2 Likes

Hi! thanks for the sudden reply. Unfortunately I cannot share the dataset because it is a job still in progress carried out by a collaborator , but I can anyway describe some details.
A DJI Phantom 4 Pro has been used; the surveyed area is a river bed area of ​​0.5 ha and 5 GCP points and 5 check points were well distributed. The detection of the targets on the ground was carried out with a Geomax GNSS receiver with an accuracy better than 2 cm horizontal and 3 cm vertical.
The error was then assessed through the check points, in both cases (my webODM elaboration and his Swiss software elaboration).
The Z error at the check points was significantly higher than that resulting from the processing carried out by the colleague, but I do not understand the reason; so, i tried to perform different processes with the options available on the webODM platform, but the results were similar. Could you suggest me how to customize rreconstruction process parameters?

Step One: What is your OpenDroneMap version? Related, in the log, does it indicate that it is using a brown camera? It is now the default camera, but if it’s an older version of OpenDroneMap, perspective was default, and needs manually set with --camera-lens brown.

If this isn’t the issue, then

Step Two:

Check your exif values. If they have GPSZAccuracy set, then use the following command in exiftool to set the GPSDOP flag to the value of your GPS Z accuracy. It can help with lens calibration issues:
exiftool "-GPSDOP<GPSZAccuracy" . If it doesn’t have GPS Z Accuracy, you can manually set this with something like exiftool "-GPSDOP=0.02" . to set the accuracy to 2cm. This tells OpenDroneMap to optimize camera pose (position and orientation) and lens calibration in such a way the keeps the camera positions from moving more than 2cm from where they are reported to be by the drone.

Since it’s a quad you are flying, are the shots taken during hover or while the drone is in motion? If it was in a hover, than the exiftool "-GPSDOP<GPSZAccuracy" . or exiftool "-GPSDOP=0.02" . settings above is fine. Otherwise, you may need to do something more like exiftool "-GPSDOP=0.04" ." or even something extreme like exiftool "-GPSDOP=0.1" ." just to give the drone positions a little less weight and the GCPs a little more weight, as moving drone even with RTK GPS is going to introduce some error.

Follow up question:
DJI Phantom Pro is the same camera as the SODA, so you should be able to get good results. Are you seeing bias, offset, or random error (hard to tell with 5 points), and can you quantify significantly higher?

I have webODM 1.8.5. The default setting is “camera lens AUTO”, is it right? or is it better if i put “brown”?
How can i modify exif values? i can’t find GPSDOP GPS accuracy setting.
The maximum z errors obtained are 20/30 cm, unlike those obtained by the colleague of an order of magnitude lower (3 cm).

Thanks!

Check the log to see which it is actually using. Auto is default setting when you launch, but it will try to use brown first in the sequence of automatic cameras to use. It used to almost always choose perspective. In current versions it tries brown first.

It’s probably best to rerun with brown set, but just to be sure update webodm:
./webodm.sh down && ./webodm.sh update && ./webodm.sh restart

GPSDOP isn’t going to be set. You will need to set it. You will modify the exif values with the command line tool exiftool: https://exiftool.org/.

You can use exiftool to set GPSDOP using GPSZAccuracy, if that is set in your data by running this command in your image directory exiftool "-GPSDOP<GPSZAccuracy" . (make sure to include the dot at the end after the quote and space) or if you don’t have GPSZAccuracy, then exiftool "-GPSDOP=0.04".

I am still not clear on what this means. Are they all offset by the same amount, or are they randomly different by 20-30cm? The answer to this gives me some sense of what might be happening.

1 Like