EVO RTK Accuracy Report

Attached is the accuracy report, did it twice with the same results.
150’ AGL, 6 MPH, 80/75 overlap, using RS2 as a caster to drone, RS2 receiving corrections from NTRP.
No checks, No GCPs as the drone has proven to be reliable enough on its own through many, many tests against CPs

is this POSSIBLE?

Also ran this through meta shape, and gave me similar results…

1 Like

There’s no way that’s correct because the RTK positioning is not even that accurate. It is odd that Metashape would produce the same. Can you share that report? I know there were issues when processing Phantom 4 RTK data because the system did not know how to weight them especially if you had GCP’s. I would have DroneDeploy check it on their side.

Curious why you are running corrections to your base? It’s usually best practice to achieve the position and then have it manually entered into base mode. Document that point so that you can return to it every time. You really don’t want the base station changing its position in the corrections while you’re roving or drowning. For the most part it should stay within a 0.10ft but any of that error combined with the error from the drone itself just compounds.

The reason for running through the base receiver is it has a much longer and greater connection to NTRIP than the drone does by itself, does that make sense first of all?

Not really. If you’re casting your base you’re creating an NTRIP for the drone to get corrections from so I don’t understand why it would be any different for the drone to pick up on a remote base NTRIP. Once you have established an RTK point for the base there’s no longer a need for corrections to it. This also comes into play if you plan on revisiting this site.

1 Like

same map as the one above.

Those numbers look more believable. Note that it is in meters and not feet so 0.02m = 0.07ft which is what we are getting with the H520E now. Having hundredths of a foot at 0 is better than a total station sooooo nope. Trying again DD.

1 Like

DD I am seeing is not properly weighted or able to deal with an RTK drone, when you add GCPs or Checks it goes completely wacked out on the report…

Do you see the same< and why am I paying 50$ a shot to produce GCPs… I prolly spent over 300$ in the last month with DD. Do you think they would give me my money back… LOL

Drone Deploy? Please look at my account, I processed a single map with GCPs and CPs half a dozen times to try and figure things out, with no success! turning to Metashape where I can change values of said GCPs

Can someone tell me how to get a response from DD? really… I need some money back… or I can see a lot of people switching platforms

Yes, we have done a lot of testing and the system does not seem to like both RTK and GCP’s. We end up with more accurate Maps doing elevation calibrations outside of DroneDeploy. I don’t know what they did with the P4 RTK but it was experiencing the exact same issues. Although I don’t know if it was ever completely fixed.

Email support. They will do their best but what you probably will experience is that because it’s not a supported drone there’s not much they can do without a lot of effort back and forth. It’s still boggles my mind that we are 7 years into it and they still only support DJI.

another one, 200’ AGL, 7 MPH, 80/75 overlap

I think I will be switching to Metashape soon

1 Like

Have you contacted support yet? This is the same thing that was happening to @Sam_De_Long with his P4RTK.

Regarding the EVO2 with the 6K “PRO” (XT 705) camera: I have received an RTK imagery test data set captured by a vendor showing also unbelievably good RMSE results with “all-zero-offsets”. The DD quality report says:

  • “RMSE of Camera GPS Location X 0.00m Y 0.00m Z 0.00m RMSE 0.00m”
  • “Average GPS Trust 0.03m”

That seems too good to be true, or not?
The vendor used the EVO2 Enterprise version with the optional RTK module, that does not only provide real time in flight positioning (like the M2EA), but also RTK imagery including rinex.obs and timestamp.mrk files for PPK.
Would be a nice compact solution with “absolute” accuracy, if these DD QC report values are “true”.

1 Like

Your report is in meters which is not a good unit for this report as 0.01 m is 10 cm and you can definitely be better than that. @JChandler is in feet and there is no way a drone can maintain better than a 0.05ft positional fix at speed. You would be lucky to hit that with a professional rover in the ground at walking speed.

There are two directions that can be gone in processing when using RTK data that can cause completely different results. You can either put too much weight on the position of the image or too little. They should really be given the tolerance of the GNSS equipment itself. The GPS trust for the P4 RTK and the Evo II RTK is pretty good but the RMSE numbers on the camera positions can’t be correct. This tells me they are putting too much weight on the images which also explains why using GCP’s corrupts the results. Anytime GCP’s are used they should be the strong point.

With our Yuneec H520E RTK the results are the other way. They’re only giving us 10 m trust which then causes the RMSE’s to be reported high. In reality per the hardware spec they should be around 1 inch horizontally and 1.5-2 inches vertically or 2.5 and 4 cm.

When using GCP’s those numbers will be worse because you are forcing the images to the survey collected position of the GCP. Even though the report is worse the final product is more accurate and absolute accuracy… If the images and GCP’s are weighted correctly.

1 Like

Best report I have ever seen
No I have not contacted DD

1 Like

In Meta shape, you can change the weighted values… Its too bad because DD produces the best orthos and models I have been able to produce, as far as pretty!
and DD is so easy to use and fast at processing

1 Like

If these values are true! BOOM EVO for everyone!

is DD on the forums?

1 Like