EVO RTK Map Process with 4 GCPs and 2 CHECKPOINTS
- Thread starter jmason702
- Start date
OHHHH, wait... I can not use just checkpoints, Due to the ellipsoid and geoid differential in mapping. EVO uses Ellipsoid and my coord system is in Nevada state plain Geoid, NAV 88
My bad on that one...
My bad on that one...
There lies another problem in its self, are the EVO and ALL drones use Ellipsoid vertical datum. Were or state plain systems do not. With the non-RTK drones, the GCPs corrected everything... With RTK drones using ellipsoid and our checkpoints are using Geoid. Any input on a fix to this?? or am I missing something...
Processed in WGS84 elipsoid camera and WGS84 elipsoid markers.
I always use reference data in WGS84 elipsoid for cameras and marker and set project datum that i need to use in export, works well with all ours RTK drones.
Forgot to add: ROLLING SHUTTER COMPENSATION included
Last edited:
So are you saying record GCPs in WGS 84 and Geoid vertical datum? In the past, it was always best to record in my state plaines coords
Dave Pitman
Well-Known Member
@elistechnology those #s are very good. That elevation error is pretty surprising on the 4GCPs and no rolling shutter comp. An anomaly in a good way. It clearly demonstrates that more than 1 GCP is beneficial. I am a bit surprised that z error is lower than x/y
If @jmason702 shot those markers in state plane, you converted them to WGS84 after ingesting into MS?
If @jmason702 shot those markers in state plane, you converted them to WGS84 after ingesting into MS?
| Name | Easting | Northing | Elevation | Longitude | Latitude | Ellipsoidal height |
1 | 764339.899 | 26702945.499 | 2435.154 | -115.21760099 | 36.00308014 | 714.298 |
Try to process in WGS84 + elipsoid and export model (LandXML) in state plaines coords.
Open it in C3D or anything that support LandXMLs, import your point and compare to surface.
If it fits in reasonable value, great. If not it can be related to the difference in your geoid between DroneDeploy and software that you use to survey.
Few weeks ago i brake my legs on some geoid that software (new in my company for testing) producer gave me, only 8,7cm diference here and there on benchmarks, it wasn't even constant error, tried to kill the blame on a faulty receiver (which worked fine on other software) . I copied datums from other software, convert it to format from the new software and works great now, so sh** happens.
Back to Autel.
If you unpack Explorer.apk using winrar or similar you will find a folder with layouts that Autel uses, I assume that in the FW of the drone as well.
Explorer_V1.1.7.93-modelc-release.apk \ uk \ me \ jstott \ jcoord \ ellipsoid \
There are coordinate systems, including the WGS84 ellipsoid created in JAVA by some Johnathan Scott.
* Class defining the WGS84 reference ellipsoid.
* </p>
*
* <p>
* (c) 2006 Jonathan Stott
* </p>
*
* <p>
* Created on 02-Apr-2006
* </p>
*
* @author Jonathan Stott
* @version 1.1
* @since 1.1
I got a height error of 4 inches from your photos without using GCP.
For me in Poland, these values reach at least 8 to even 12 inches, I assume that something may be wrong with this ellipsoid.
Results from Pix4D
I made some assumptions.
I am assuming that the metadata in the images is the updated RTK info
I assumed that the altitude in the images was orthometric heights (Above Sea Level) in NAVD88 (Geoid12 or 18) (I saw the images were 740 ish meters and the Control Points 713ish)
I used Pix4D arbitrary elevations and did not have Pix apply their EGM/Geoids for Above MSL
I used 1 GCP and 5 CPs. It was also done with me fast marking the Points and I only marked them in 5 images. I could tighten this up by marking all images and also being more precise.
I must say I am very impressed with the image quality from the Evo 2 Pro camera. Does it use an Auto setting when in the mapping mode or did you manually do the settings.
I made some assumptions.
I am assuming that the metadata in the images is the updated RTK info
I assumed that the altitude in the images was orthometric heights (Above Sea Level) in NAVD88 (Geoid12 or 18) (I saw the images were 740 ish meters and the Control Points 713ish)
I used Pix4D arbitrary elevations and did not have Pix apply their EGM/Geoids for Above MSL
I used 1 GCP and 5 CPs. It was also done with me fast marking the Points and I only marked them in 5 images. I could tighten this up by marking all images and also being more precise.
I must say I am very impressed with the image quality from the Evo 2 Pro camera. Does it use an Auto setting when in the mapping mode or did you manually do the settings.
you can do auto or manual settings, I choose auto do to lowest aperture and fastest shutter, Yes the PRO camera is awesome!
The data in the RTK drone images appear to be all in wgs 84 and episode
The data in the RTK drone images appear to be all in wgs 84 and episode
Last edited:
so a little less then 4 1/4" on the Z error ? is that correct, been a while since I used Pix, X = 1 3/4" and Y = 1" Correct?
Dave Pitman
Well-Known Member
I'm not sure how the error of the GCP can be higher than the checkpoints, Especially the z value?
This is GREAT, comparing 3 different software to the same data set
SO what I think, is the drone's data is in WGS 84 ellipsoid, when I am pulling points, the points are in State Plane data Geoid. So we have to process everything in WGS84 and export it in whatever state plane you are in.
SO what I think, is the drone's data is in WGS 84 ellipsoid, when I am pulling points, the points are in State Plane data Geoid. So we have to process everything in WGS84 and export it in whatever state plane you are in.
Last edited:
Dave Pitman
Well-Known Member
I don't process in Drone Deploy or Pix4D. But in Metashape, you have options that should, in theory, result in the same output. If the drone uses WGS84 exclusively, that makes sense and is a good thing. @elistechnology mentioned he thought that the WGS84 elipsoid model on the drone may be off, which is not good but if true could probably be fixed easily with FW. In MS, you can tell the application to give higher weighted value to either the camera positions or the GCP. Generally, the GCP will receive the highest accuracy value. An RTK driven drone, a little less, and a consumer GPS drone, much less. That way the cameras are adjusted to the GCP and not the other way around. That is why the Pix4D result with the lower accuracy for the GCP than the Check points is curious.
In DD you have very few options, cloud-based, but does a damn good job if everything is correct. produces the best ortho I have seen and some of the best-looking
models. I think DD orthos are the best for measuring, I would not measure anything in DDs 3D models.
I have tried PIX and Meta Shape. I think they all are good. But I may dump DD and go with Meta Shape in the future...
They all have their good and bad points in my opinion, but most of my experience is with DD.
Dave Pitman
Well-Known Member
My work that involves DEM accuracy is for surveyors and engineers. They don't care about the orthomosaic at all except for a reference. All they typically want is the surface mesh as accurate as possible.
It this screen grab provided by @elistechnology you can see where he is telling MS that the GCP is expected to be 10x more accurate than the camera positions. MS processes accordingly.
That's good to know, and I see the options are endless compared to DD. Most of my work is for construction sites- project management and inspections.
Similar threads
