Coordinates shift issue

WebODM
1

Hello,

I have been using ODM for two years for agricultural images stitching.

I often find an obvious shift on the output orthophoto, and I thought it was because the GPS information was inaccurate, so I always manually georeference the output tif files.

However, recently I found out that the GPS information was actually very accurate.

If I just rotate the images by their Yaw angle ( the drone was flying horizontally and the camera was set to take photos straight down, so I don’t need to worry about Roll and Pitch angles ) and resize them by their height so that each pixel was in their exact physical size on the map, and put them onto google map, I will find them locating on the exact place they should be, as the following two photos show:

odm_33
odm_33797×665 64.5 KB

demo_33
demo_33765×815 70 KB

So, what is the reason that ODM often tend to shift a bit? (By saying often, I mean sometimes it works well, by in most cases it will shift)

I was using a DJI Mavic 2, and I didn’t set any weird ODM parameters, I just chose fast-orthophoto.

I have found that my simple method always result in a better location accuracy.

1 Like
2

If your GPS accuracy is good, try setting --gps-accuracy to 0.1 (by default it’s 15).

1 Like
3

Thanks! I will have a try.

1 Like
4

Are you certain that Google Maps is 100% accurate in your location? It generally isn’t.

1 Like
5

OpenSfM now supports SfM using direct-aerotriangulation given GPS and OPK angles (though EXIF reading remains to be added, for DJI drones for example).

4 Likes
6

Do you have a dataset to share for us to investigate why accuracy isn’t good with ODM (and potentially add OPK DJI readings to test with direct triangulation) ?

2 Likes
7

Wow, just tried running the triangulation algorithm and I’m really, really excited about the runtimes! :grinning_face_with_smiling_eyes:

I’m going to add some code for reading the camera angles.

3 Likes
8

Does it really help the solution that much? That’s so cool!

Maybe I can close this soon thanks to Yann and Piero:

1 Like
9

Yep I think that can be closed; there’s support for omega/phi/kappa angles, I just need to tie it in in ODM. (Work in progress https://github.com/OpenDroneMap/ODM/pull/1383 )

3 Likes
10

sheffield cross processed in record times using the new triangulation algorithm:

image
image875×616 152 KB

27m57.882s (on my slow 4 core laptop) (from 173 images to orthophoto using --fast-orthophoto).

This is going to really help agricultural datasets.

2 Likes
11

I’ve added the OPK logic in ODM (we skip the extract_metadata command in ODM since we create the exif folder directly), but I’d be happy to port it to the extract_metadata command in OpenSfM and open a PR if there’s interest (@YanNoun) ?

1 Like
12

That is incredible! That’s a pretty hefty dataset depending upon settings!

13

This is awesome news ! OpenSfM would love to have few snippets of codes to get OPK angle in the EXIFs !

matching_graph_rounds combined with OPK usually provide dramatic speed-ups and excellent matching !

3 Likes
14

I’ll get to it!

2 Likes
16

Any chance to share the dataset somewhere ?

1 Like
17

If you mean that Sheffield’s Cross dataset Piero benched with, it is in our ODMDATA Repository:

Direct Link:

1 Like
18

Hello, guys. I have tried reducing the --gps-accuracy parameter, and it did improve a bit, but still not as good as expected.
Here is the dataset : my coor shift dataset

1 Like
19

I’m wondering if it is because the Mavic Zoom (FC2204) isn’t in upstream OpenSFM quite yet…

This is good, I have to make the sensor profile entry for another user anyway.

20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.