PPK/RTK images processing accuracy

[ThorZ]

Hi all,

Recently I processed some high-accuracy GPS datasets, but I couldn’t get good accuracy results. I’d like to share this dataset and see if I can get some help.

Here is the workflow. A PPK device is attached to the drone, at the beginning of the flight, the drone will stop at two marked locations on the ground, take several photos there (check the image below), then execute the regular flight path. After that, the PPK data will be used to generate the geo.txt which contains x,y,z, and vertical, horizontal accuracy. The images, along with the geo.txt, will be used in ODM to process the data. After the processing is completed, I will check the elevations of the marked positions in the 3D model and compare them with the elevations from the PPK photos taken at the marked positions.

Unfortunately, I tried many different settings but still couldn’t get one result that has really good accuracy. For example, using all the default arguments, I get an error of around 2m. Then I tried to explicitly set gps-accuracy to 10, 1, and 0.1, and surprisingly, gps-accuracy=10 actually gives me the best accuracy, which is around 0.6m. (I do want to try the new triangulation approach, but something prevents me from doing that, I will explain it at the end.) I also processed it in pix4d with default processing options, and I obtained the error around 0.15m.

I will share the datasets and reports I have from odm and pix4d later. My expectation is to get something close to the pix4d result, Error less than 1ft(0.3048m) is acceptable. Hope I can get some suggestions.

About the triangulation approach, the drone image does have yaw, roll, pitch tag, but I can’t combine them with geo.txt(in geo.txt, omega, phi, kappa are all 0). And if I try to use ExifTool to modify the GPS x,y,z tag in image EXIF data directly, The xmp tag for yaw, roll, pitch will be changed slightly. For example, previous xmp tag for yaw is @drone-dji:GimbalYawDegree, after updating, it will become drone-dji:GimbalYawDegree(@ is missing), then ODM failed to extract it. If someone can tell me a proper way to modify EXIF data without changing other data tags, I can try the triangulation approach as well to check the accuracy.

Any suggestion will be appreciated.

[ThorZ]

Here is the link for the dataset, odm_ppk_exp.zip - Google Drive

[ichsan2895]

It seems you have wrong format of GCP.

GCP file format:

<projection>
geo_x geo_y geo_z im_x im_y image_name [gcp_name] [extra1] [extra2]

Example:

EPSG:4326
544256.7 5320919.9 5 3044 2622 IMG_0525.jpg
544157.7 5320899.2 5 4193 1552 IMG_0585.jpg
544033.4 5320876.0 5 1606 2763 IMG_0690.jpg

You can also use GCP interface in WebODM. You can input

EPSG:4326
GCP1 544256.7 5320919.9 5 3044 2622
GCP2 544157.7 5320899.2 5 4193 1552
GCP3 544033.4 5320876.0 5 1606 2763

It little bit difficult to use for first time, but, please see the tutorial on Youtube.

I also try to fix your GCP, sorry I fixed it just for 10 points

+proj=utm +zone=10 +ellps=WGS84 +datum=WGS84 +units=m +no_defs	
518146.04	4688231.45	923712	2735.00	1538.00	DJI_0003.JPG	DJI_0003
518172.54	4688354.54	923002	2735.00	1538.00	DJI_0028.JPG	DJI_0028
518331.28	4688349.55	923264	2735.00	1538.00	DJI_0137.JPG	DJI_0137
518331.25	4688148.62	923331	2722.00	1544.00	DJI_0117.JPG	DJI_0117
518146.10	4688145.81	924857	2735.00	1538.00	DJI_0010.JPG	DJI_0010
518251.07	4688252.24	923.43	2735.00	1538.00	DJI_0073.JPG	DJI_0073
518331.86	4688253.31	923052	2735.00	1538.00	DJI_0129.JPG	DJI_0129
518251.21	4688143.29	923.52	2735.00	1538.00	DJI_0052.JPG	DJI_0082
518251.32	4688351.19	923212	2735.00	1538.00	DJI_0065.JPG	DJI_0065
518251.14	4688203.66	923339	2735.00	1538.00	DJI_0077.JPG	DJI_0077

[ThorZ]

It’s not a gcp dataset, I use geo.txt to provide high accuracy GPS information, as described here Image Geolocation Files — OpenDroneMap 2.7.0 documentation.

[ichsan2895]

I ran your dataset with default setting, geo.txt is located in images folder. I got 0,36 m of GPS errors (accuracy). My ODM version are :

>>> docker image ls
opendronemap/nodeodm          gpu         6f7d3fe63270   12 hours ago    5.85GB
redis                         latest      7614ae9453d1   3 weeks ago     113MB
opendronemap/webodm_webapp    1.9.11      265dccea7d29   2 months ago    1.6GB
opendronemap/webodm_db        latest      e40c0f274bba   4 months ago    695MB

[ichsan2895]

I ran your dataset (again) with custom settings. Happily got GPS error = 0.128 m which approve with your requirement (0.3048 m)

dem-resolution 2
mesh-octree-depth 12
mesh-size 300000
orthophoto-resolution 2
pc-geometric true
pc-quality high
use-3dmesh true
resize to 2048px

((I must resize your picture to 2048 px, because it will run of memory))

I got this result

Good enough right, bro?

[ThorZ]

Thanks a lot for your help.

I think there are some misunderstandings of the “accuracy” I referred to. In fact, I didn’t use the GPS accuracy in the report to indicate the processing accuracy. Instead, it’s more similar to collecting a dataset with both PPK and ground control points. But the ground control points are not involved in reconstruction, they are only used to measure actual errors after the 3D model is generated. The “ground control points” are surveyed by landing the drone on the target place and taking a PPK photo.

In this dataset, the photos DJI_0001, DJI_0002, DJI_0138, DJI_0139 are taken at position 1, DJI_0140 and DJI_0141 are taken at position 2. Then I check their elevation at geo.txt, I can find that position 1’s elevation is 863.5m, position 2’s elevation is 864.94m. So I can compare the elevation difference with the reconstructed 3D model at the same positions. This is how I measured the accuracy and noticed the errors in the reconstructed model.

By the way, how do you add geo.txt in webodm processing? It’s supported in ODM (use the command line directly) but I didn’t find a way to upload it in webodm.

[ThorZ]

I noticed there is a new version released this week so I used it to reprocess the dataset, but the result is similar. The interesting thing is that using the default GPS DOP 10 is always better than the PPK DOP(around 0.05).

I also tried to process this dataset in ODM2.3.1 and the accuracy is quite good. I started to use this way of measuring accuracy when ODM2.3.1 was the latest version, and I didn’t notice any issue at that time.

[Saijin_Naib]

@ThorZ

But the ground control points are not involved in reconstruction

Have you done a reconstruction under the latest ODM using the GCPs to see how it reconstructs versus using them solely as check-points after reconstruction?

[ichsan2895]

Ahh I understand your problem. I tried your way to access accuracy. I got 1,7 m delta (Reality - DEM)

Sorry, I can’t help you anymore since I dont know how to make it more accurate.

[ichsan2895]

I found an interesting thing.
DJI_0140 has altitude (in your geo.txt) = 864,94
DJI_041 has altittude (in your geo.txt) = 923,53

Its right? the distance within two images is short (6 m) but the difference of elevation is Huge (923.53-864.94=58.59

[ThorZ]

Yes, it’s fine, only the images I mentioned above are for the ground points survey, the rest are collected in a regular flight path.

[ThorZ]

I’m not able to do so because only two points are surveyed to compare the difference

[ichsan2895]

Owh I see… The rest of GPS coordinates are collected by regular flight path… My suggestion, If you want to increase the accuracy, please add another GCP, If you add the GCP, it wont collected regular flight path’s GPS metadata.

This things is the reason why your accuracy is not accurate.

DJI_0140 has altitude (in your geo.txt) = 864,94
DJI_041 has altittude (in your geo.txt) = 923,53

Its right? the distance within two images is short (6 m) but the difference of elevation is Huge (923.53-864.94=58.59

[ThorZ]

The whole idea is to use the PPK rectified image locations to process the data, the “GCP” images I referred to are only an additional step to measure the accuracy. Again, the geo.txt is the file to provide PPK rectified GPS location for all the images, it’s not a GCP file, so the image flight path, whether the drone is flying or landing on the ground, doesn’t matter. DJI_0140 is taken on the ground, so it has 864.94m height, DJI_041 is taken when flying, so it has 923.53m height.

[smathermather]

What sensor, and is the drone stopping for each shot?

[ThorZ]

DJI phantom 4 pro, camera model FC6310S, the flying speed is 6-7 recorded in metadata, not sure the units.

[ThorZ]

I did many experiments recently on this, so far I can’t achieve good accuracy by tweaking ODM’s flags directly. But I do manage to get good accuracy by tweaking opensfm’s configs. There are some extra opensfm configs I added during processing. Since ODM doesn’t provide an option to provide direct config to opensfm, I added a breakpoint in dev mode to edit the configs.

exif_focal_sd: 0.2
principal_point_sd: 0.01
radial_distortion_k1_sd: 0.2
radial_distortion_k2_sd: 0.2
radial_distortion_k3_sd: 0.2
radial_distortion_k4_sd: 0.2
tangential_distortion_p1_sd: 0.2
tangential_distortion_p2_sd: 0.2
loss_function_threshold: 0.001
bundle_max_iterations: 1000

This will make the processing time a bit longer, but it does give quite good accuracy (tested with several datasets).

As you may observe the configs above, the problem is that the camera parameter is not optimized properly. So I also tested with taking calibrated camera parameters from an accurate dataset and using --cameras to process the dataset, this way also gives good accuracy. I set gps-accuracy to 10 for all the processing, smaller DOP can easily cause large errors somehow.

So I guess the best way to achieve good accuracy at this point is to calibrate the camera ahead and use it to process the dataset.

I wonder if ODM has a recommended way to calibrate the camera? Is opencv’s calibration method good enough? I guess the rolling shutter effect could be a problem, is it possible to calibrate it as well?