Error when processing RTK data from DJI M300

[johnhalifax]

We are having problems processing data from the DJI M300 RTK.

We use Trimble VRS Now to give us an RTK fix
.
We have tried numerous ways to process the data using the recommended way for Agisoft pro with the DJI M300 RTK.

Firstly we set the preferences.

Then load the images. The accuracy shows.

We then Align Images.
 
Once alignment is complete we optimise as per the instructions. We then build mesh.
 
The Reference settings are as per Agisoft instuctions.

The camera calibrations are produced automatically and seem ok.
 
We are getting errors to the check GCP's of around 2m.

Our supplier uses Pix4D and shows us screen shots to show that everything works. But not in Agisoft. They say it is somthing to do with the conversion in Agisoft.
 
We are also Wingtra users. With the wingtra we are able to separate the images from the geo-reference, take the WGS84 lables into Gridinquest and convert them to OSGB36 then after importing images we import the OSGB36 lables. This works. But we are unable to do this with the M300 as the image name is different in the Tags.

Anyone out there using an M300 with Agisoft ( you need to have checked you out-put to make sure it’s correct) who has a workflow that works.

[Paulo]

Hello johnhalifax,

I have processed data from M300 RTK using different cameras (H20T, P1, L1) without any problem. Seems to ba datum problem on your side....

[johnhalifax]

Did you use the same workflow?

[johnhalifax]

What reference setting do you have.
We have tried  Coordinate system WGS 84 (EPSG:4326) Camera Reference WGS 84 (EPSG:4326) Marker reference OSGB36/ National Grid (EPSG:27700)
Also tried Coordinate system OSGB36/ National Grid (EPSG:27700)) Camera Reference WGS 84 (EPSG:4326) Marker reference OSGB36/ National Grid (EPSG:27700)
It seems to work out a transformation but I don't know how it arrives at this

[johnhalifax]

We have put the DJI lat long in and processede using GCP's and got all the GCP's coming in correctly and the data all correct but an error of 2ms in the Camera positions.
Use the camera positions and the GCP's as a check and the GCP's have a 2m error but this data is wrong. It apperas that the data from the DJI is wrong or is it not WGS 84 (EPSG:4326)?

[Paulo]

Hello john,

are the camera positions RTK processed? What does the mrk file give as your drone-dji:RtkFlag:

“0”:
No satellite signal is available.
“15”:
No position solution is available.
“16”:
Single point position solution with precision of meters.
“34”:
Floating ambiguity position solution or pseudo-range differential solution with precision of decimeters.
“50”:
Integer narrow-lane ambiguity position solution with precision of centimeters.

Unless you have a flag or code of 50 than precision is dm or m level. The reference datum is WGS84 (supposing your VRS is in WGS84)....If you do have cm level camera positions, then the 2 m error is probably caused by uncertainty in the transformation from WGS84 to OSGB36 (GridInquest vs Metashape transformation)...

[Paulo]

Confirmed,

the 2 m discrepancy comes from different implementation of WGS84 to OSGB36 transformation between Grid Inquest and Metashape. I transformed same point (point 1) from WGS84 (long 0.0000, lat 51.0000) to OSGB36 British National Grid with Metashape and Grid Inquest and there is clearly a more than 2 m difference.... see attachment

[Paulo]

Solved,

using the general OSGB36 / British National Grid datum in Metashape uses a 7 parameter transformation to WGS84 which is not very precise compared to a deformation grid. To get a precise transformation (consistent with GridInquest) you must define a compound CS using ODN height with ogsb36_OSGM15.tif as in following:

[JRM]

For your information, the PROJ project has several comments about the way Agisoft handles the transformation grids :
https://lists.osgeo.org/pipermail/proj/2022-September/010768.html