Improve reconstruction/georeferencing between GCP points

[andriizayac]

Hi ODM community!

First, let me thank you for all your work and an amazing software!
I’d greatly appreciate some thoughts on the project I’m working on. Here’s the rough outline, but happy to provide more details.

Software: ODM version 3.0.4 (same behavior on WebODM version 1.9.19) both using native installers on Windows 10.

Context: The images come from flying DJI Mavic 2 Pro over low-statured vegetation following the recommended cross-grid + small offset flight plan.The reconstruction seems to work perfectly in most of the scene and the quality of ground features is totally satisfying throughout. We use GCPs to georeference the model and that seems to be a success too.

Problem description: In a certain parts of the scene (~25% of ROI) there is =< 70 cm error (more of a shift than random error) in ground mapped RTK points and the model. In the remaining 75% of the scene the match is almost perfect, suggesting this is not a GPS error.

Things I’ve tried that did not lead to pretty much any changes in this aspect (neither positive or negative):

• increase the number of photos referenced in the gcp_list.txt
• re-run the process using only nadir shots (included in the reprex data)
• various quality settings from very high (ultra) to medium, including mesh-size, min-num-features, resolution, pc-quality, feature-quality.
• Matcher type: bruteforce, flann; sfm_alogrithm: incremental, triangular, plain
• rolling shutter options on/off

Questions:
What aspects of the processing workflow are likely contributing to this artifact and what can I try to improve the errors? Happy to experiment more and try to improve outputs as matching the model to ground features is important.

If this is just the limitation that can’t be resolved, can this behavior be retrieved/approximated/predicted from any of the ODM outputs (reports, etc)?

Dataset: repex_odm1 - Google Drive

Illustrations of the problem:
Entire scene (white=gcp, purple= rtk pts) with the affected areas roughly outlines:

GCP (representative of all GCPs)

Good matches (~75% of ROI):

Poor matches (~25% of ROI):

Transition from good to bad matches:

Would greatly appreciate any feedback!!

Andrii

[Saijin_Naib]

Welcome!

Have you tried constraining your GPS-accuracy value yet? Do you have an idea of typical accuracy for your survey above?

[andriizayac]

Thanks for a prompt response! I usually let the gps-accuracy parameter to default because the on-board GPS on Mavics isn’t great. Perhaps someone will correct me, but +/- 3-10 m error would not be uncommon, especially on Z. I’m not sure if that’s of any value, but usually the processing reports indicate camera GPS error ~5-19 m, when the reconstruction seems decent visually.
I tried processing the the images setting gps-accuracy at 5 and 15 m, but that lead to very minor changes in the final product (though the objects did move slightly). Here’s the full set of parameters that used for the last run:

--feature-quality medium --auto-boundary --dem-resolution 1.0 --dsm --optimize-disk-space --orthophoto-resolution 1.0 --rolling-shutter --rolling-shutter-readout 62 --skip-3dmodel --sfm-algorithm planar --gps-accuracy 15

The GCP accuracy is pretty good, ~2 cm, but the rtk points that are distributed around the scene would be slightly less accurate (~4-5 cm).

[Saijin_Naib]

Have you done a run with Default to compare as a baseline?

[MikeF]

@andriizayac

The GCP accuracy is pretty good, ~2 cm, but the rtk points that are distributed around the scene would be slightly less accurate (~4-5 cm).

I don’t if you factored this in, generally with gps, vertical error is usually 2 times the horizontal error. Just a thought.

[gabrieldeluca]

@andriizayac

[…] suggesting this is not a GPS error.

Why do you think it is not a GPS error?

Seeing the accuracy of the fit between the model and the control points, and since the error zones are between three control points (they are not zones outside of them), I would doubt more about RTK processing in the field than about the generated model. Do you not have the possibility of post-processing those points?

[andriizayac]

Thank you for all the suggestions! I initially considered that the misalignment may be due to the GPS errors, but all of those points have been collected on the same days and post-processed in the same way with the points that match the plants perfectly. Nonetheless, since nothing seems to be out of ordinary on the imagery/processing/GCP side, that’s where I should probably look closer, explore more the RTK output and perhaps re-post-process the data. Thanks!