Seeking Assistance with RTK Drone Survey: Discrepancies in Metashape Accuracy

[Photo]

I have performed a drone survey with a RTK drone from DJI and for this, I have scattered Ground Control Points (GCPs) which were measured with a GNSS antenna. So, the data from both are in the centimeter range. If I adjust the accuracy of the drone's camera and the GNSS antenna to 2.5 cm in Metashape, the deviations are very, very large, which I cannot understand. However, if I leave them at 0.001 m, it seems to fit better, but it's still incorrect. I have the parameters from the camera calibration, I believe the values are fine. I have attached a few photos, showing the deviations before and after. So, once with 0.001m and once with 0.025m. Additionally, I took a screenshot of my camera calibration. Maybe you notice something that isn't correct here, I would be very happy if someone could support me on this occasion.

Many thanks
Photo

[Paulo]

Hi,

I would look at the errors pane in your reference markers window to see how error is distributed between X, Y, Z. I would think that error is largely in height and this is normal with RTK flight...However, the magnitud of the error suggests a datum problem. Normally your RTK camera coordinates are in WGS84 ellipsoid height. Was the base reference coordínates correctly entered in WGS84?
Also how were your GCPs GNSS coordinates determined? Same datum as WGS84?

One suggestion is to use additional corrections in optimizing your data set...

[Photo]

Hello Paul,

The GCPs are in Gauss-Kruger and I've taken additional corrections into the calculation, but it's still very poor. You're right, the largest is in the height and everything else fits perfectly. Have you ever had this problem? In the model, I can see that the points match correctly.

best regards
Photo

[Paulo]

Hello photo,

half a meter or more in height does suggest a vertical datum issue. Please check that the vertical datum for both camera and GCPs are the same: i.e. ellipsoid height referred to WGS84 or GRS80 ellipsoid. If they were determined by differential processing from a reference point, double check their h coordinates....

Something is fishy here!

In RTK surveys without any GCPs and with mainly vertical looking down images, a small error in focal length can be directly  propagated into Z or h error on the ground as seen in following attachment. So a 1% error in f will lead to something like a z error of 1% in flying height. For typical drone flight of 100 m AGL that could lead to something like 1 m error...So this could be the cause.. But having a GCP (which is your case) and ticking it, would remedy this effect....

PS. another thing. Was your RTK survey done with a D RTK2 station from DJI? If so check how your base coordinates were entered during setup. These coordinates must be entered with height relative to antenna reference point (bottom of antenna). So to your base known height you must add distance from point to bottom of antenna...which could account for this more than 50 cm error.... To check this, you could select all cameras and modify their accuracy to 0.015/1 and keep your GCP/marker accuracy to 0.01/0.02 and do new optimization and see the results. Should be OK with camera Z error around 0.5 m....

[olihar]

Start with projecting the drone images into the correct GEOid. This should fix your issue.

[Photo]

When I transform the coordinates of the drone to UTM32, I have no problems at all. I have the geoid and it fits perfectly. I use the GCPs here only for control and it matches 100%. I only have a problem when I try to transform the coordinates to Gauss-Krüger or DBREF. I understand that WGS84 is geographic and other coordinate systems are projections, but I wonder why it always works with UTM/ETRS89 but when I have another system, I always have problems. I'm slowly realizing that such evaluations are no longer fun unfortunately. I am very grateful that there are people like you who try to help, thank you.

Regardless of the system, I always have enough GCPs to correct my model, but I keep the coordinates of the drone. However, after the new alignment, after I have set my GCPs, I still have about 50 cm deviation in height.

And to answer your question, I use the RTK MODULE from DJI, so no station.

[olihar]

Yes again, you need to project the images of the drone into the correct GEOid. Before you do anything else. You need to get the drone images into the correct Z height and the geometry of the GEOid.

[Paulo]

Hello again,

if you are using DBREF with geoid and when in your transformation of camera coordinates from WGS84/ETRS89 to DBREF you do not have the geoid taken into account then this 0.5 m difference can be explained. If you have the coordinates of one of your GCPs, I can check....

[Photo]

Hey,

When I import my GCPs, they fit reasonably well, not 100% but it's okay, there are only small deviations either in the position or the altitude but we're only talking about 2 to 3 cm, no more. However, when I then set the markers, the error increases up to approximately 50 cm, so visually it fits but the error in the table does not, and I somehow cannot comprehend this because I see that the geoid has already been used. Otherwise, it wouldn't exactly lie there, (see screenshot).

[Paulo]

Hello photo,

i would probably more information. I guess that your GCPs are in DBREF + geoid i.e. height above MSL. Now I would need to know how you define this datum DBREF + Geoid when you transfer cameras from WGS84.

In attached example, you see that transformation parameters fro DBREF + DHHNN 2016 height have both a 7 parameter transformation from the local ellipsoid Bessel1841 (non geocentric) to WGS84 as well as the tif geoid file that defines difference between local ellipsoid and MSL.... you should this type of transformation defined...

see first attachment.

in seconf I show difference of height between DBREF and DBREF + geoid for 2 markers placed... around 50 to 90 cm difference...

[Photo]

Hey Paulo,

So, I have my photos and they are in WGS84 and depending on my GCPs, for example in this project, they are in DBREF2016 Zone 3. I can actually transform the coordinates from WGS 84 to DBREF2016 directly without first converting to ETRS89. So the next step I do is that I transform the coordinates from the camera into the selected system. I have already provided the coordinate system in Metashape with the correct geoid, meaning, when I transform, the difference is subtracted, so everything is fine up to here. Next, I import my GCPs, which are also measured in DBREF with GPS, so these points also have the correct coordinates, and by correct coordinates I mean the corrected height.

Once I have done this and everything fits, I calculate the remaining steps.
I have attached a screenshot for you

[Paulo]

Sorry,

it beats me. Your CS DBREF + height 2016 seems to be correctly defined.... The only thing that in your geodetic software when calculating the GCPs coordinates in DBREF 2016, same transformation and geoid are applied....However MSL height should be the same or practically whether referenced to DBREF or ETRS89 datum....

[Photo]

Hi Paulo,

This morning, I decided to import the coordinates in WGS84 into Metashape and then transform everything into DBREF. And then I will compare the points with the points I measured with the GNSS antenna.

It appears that Metashape adds 1m to all heights after the transformation, which I find very peculiar. But if I transform WGS84 to ETRS89, then everything matches, even with coordinates that I have exported from GNSS. And speaking of the location, the conversion from WGS84 to DBREF is perfect, it matches the coordinates from GNSS too. Unfortunately, Metashape adds 1m to all heights, which I cannot comprehend and do not know why it is happening, although I have checked all the parameters. Has this ever happened to you?

[Paulo]

Hello photo,

if the transformation adds 1 m to height then definitely there is an offset in your geoid file.

To check you can transform from DBREF + geoid height to ETRS89 + geoid height and should get the same height (at less than a  mm or two) as in following example where I transform a point from these 2 CS and print the coordinates. Of course the DBREF geoid file was created from ETRS89 geoid file using https://agisoft.freshdesk.com/support/solutions/articles/31000161533-what-to-do-if-you-need-to-use-an-existing-geoid-on-another-datum