So I’ve been out collecting some flights lately and have come across an interesting issue…
UAV - Mavic 3E with latest firmware
Base - Reach RS2+ with latest firmware
Ortho Software - Correlator 3d v10
So if I set up the base on a known point and fly the mission using RTK, I see pretty consistent errors of about 3.4’ in X, 2’ in Y, and 0.5-1’ in Z across all the check points. The one mission I set up using coordinates for the base derived from NTRIP yielded sub 0.1’ errors in all directions. I’m not sure where the hiccup is coming from since the rover checks in fine to all other known points when the base is set up on a known point.
Consistent errors across all your checkpoints can indicate a Coordinate Reference System (CRS) mismatch. Ensuring that both your checkpoints and drone imagery use the same CRS is crucial for accurate alignment and measurements.
In what CRS the checkpoints are based on?
How about the known coordinates of the base: what datum is it based on?
The checkpoints and Emlid Flow project are all set up in Washington North Zone NAD83 (2011) with Geoid18 Ortho Heights
Known point was selected from Emlid Flow project
CRS for Correlator is the same as the Emlid Flow project. I’ve checked this in another post-processing software as well and have the same shift so it’s got to be something in the CRS between setting up the base and the drone receiving the RTK correction.
Definitely seems to be some issue between Emlid and Mavic3e as it’s consistent across projects and processing platforms. The Emlids work fine together though, so that’s the troubling part. I must be doing something wrong as all I keep seeing is how folks are getting cm level results right out of the box.
The drone is expecting wgs84 (geographic CRS) with ellipsoid height. If you are sending corrections to the drone using a point in a projected system and with a geoid adjustment offset, you are making it really complicated on yourself.
My projects in Emlid Flow are set up in state plane, along with all the control points. Emlid project shows the correct geographic coordinates for the points under the Global tab, and should be then sending those global values over to the drone if I’m not mistaken. Seems like I would be making my life more difficult if I had to convert everything to WGS84 and ellipsoid, just to have to go back the other way for the deliverable?
I don’t know what the base output NTRIP stream would be if the base point is in a projected system. Emlid staff will have to chime in.
The drone will be happy with geographic horizontal in any CRS, and the recorded camera positions should reflect that. Vertical is another story I think.
Something to keep in mind is that when surveying with gnss, the native CRS is wgs84. So when you set up your points in Emlid in state plane, you are converting away from the native CRS for the equipment in use. The drone doesn’t have any option to convert on the fly the way gnss receivers can.
In my case, I will use whatever CRS is used in the project. But to send corrections to the drone, I use geographic x/y and elipsoid height. I can offset to geoid in Metashape in post process to match the control CRS if necessary.
I can’t say your issue is related to this. But to find out, try running a simple test mission using a geographic CRS with elipsoid height. Shoot in a couple of check points then fly the drone and see what you get. If the errors drop to survey grade, then you will know you are loosing it it the transformations somewhere. If the error is still there, then you can look at the hardware.
I think what I’m going to do when I get a minute out of the office is set up the base on the known point as I have in the past, and then set the drone on the ground over the known point, or another one close by to see what it says.
I’m also going to try another round of getting the base position from a network NTRIP solution and see what that does. That, so far, has been the only flight that’s produced survey accurate data.
Sounds good. I’m going to guess that your network NTRIP is using geographic (NAD83(2011) with ellipsoid heights. And you seem to be getting good results with that. If you replicate that with your own base/NTRIP setup, you should be good too!
OK, I’ve reprocessed the image data and realized that the software was processing in NAD83 HARN, which is actually what the control is technically in. Generally speaking, there’s only a couple of tenths difference around here between the two, but if I run it through using Nad83 2011, it comes out beautiful…with the exception of some vertical shift that I need to work out. I suspect it’s something with the geoid offset I have to put in, but I’ll work on that next.
