I started using my Reach M2 a few days ago and did some first test with it.
So I put it on my Copter and connected it to a L1/L2 helical GNSS antenna.
I use my own CORS so I recorded a RINEX file. I layed out 10 GCPs and georeferenced them with my RTK measure pole (same base used as Reach M2, RTK fixed solution). But I only used them as check points to see, how accurate the PPK solution is.
After the flight, I uploaded the rover and base RINEX files in Emlid Studio (Drone Data processing) and one nav file as well. I get 100% fixed solution so everything seems fine.
Then I put all image files into Metashape and checked, if the coordinates of the uploaded files match the log files of Emlid studio and they do.
Your gcp error estimates really aren’t very good… did you actually post process the GCP’s ? Usually our GCP’s errors are less than 3cm in both the vertical and horizontal components after PP. That’s a major part of your error in your project.
I used my GCPs only as checkpoints so I didn’t process the images with them. What is your usual workflow with PPK?
I thought that I didn’t need any GCPs except as checkpoints.
This usually happens when the GCP’s and the M2 data isn’t referenced to the same base?
But agree with @EBE111057, it seems like your GCP’s weren’t collected using a fixed solution, but a single solution?
The screenshot seems to show that the inaccuracy is systematic (ellipses are all the same size and orientation) so I don’t think checkmarks recorded in single would look like that.
Could it be because the camera/antenna offset wasn’t taken into account?
@wizprod good to know but both rovers used the same source which is my own base located just a few meters away. The GCPs were measured with fixed solution for sure.
@Gabriel_C thats what I would think as well. It could be because of camera/antenna offset but how (and where) would you take care of it? I tried it with Metashape but I had the feeling that didn’t change anything.
I found the solution! It was my own fault. I have set up my own CORS, which had different coordinates setup than I have sent via RTKLIB.
That was the reason why RTK worked fine (position via RTCM msgs) and PPK had the significant offset (coords coming from RINEX header file).
Now I got much better resolution!
What accuracies do you guys get with PPK and how much GCPs do you use? Especially for the Z-error correction?
Are you flying double grid? Are you taking your images nadir or at a slight angle? Try with an angle of 75-80° off horz (it helps for elevation). Also, you might want to fly at two different elevations. Your checkmarks are in the most challenging area (between buildings) so having enough data is crucial.
Yes, in this example I flew double grid but only nadir. Today I did another test with nadir and obligue (70°) and it seems to have a smaller error. Thanks for the tips, this helps a lot!
Normally I only do mapping missions on agricultural fields, so only single grid nadir.
edit: I know that my GCPs are not spreaded evenly over the area. I was just for a first test but the results are impressive, though.
What accuracies do you guys get with PPK and how much GCPs do you use? Especially for the Z-error correction?
Reach M2 and Emlid Studio help you geotag images with centimeter-accurate coordinates. The optimal number of GCPs depends on the area, but 10 GCPs should be enough.
As for the final orthophoto’s accuracy, it’s affected by different factors. If the X and Y errors are small, and the Z error is rather big, like in your case, I’d suggest double-checking the vertical datums used for the control points and the orthophoto. If they don’t match, it can result in a significant difference in heights.
Thanks for the info. Where do I need to change the vertical datum? I’ve found one option in RTKLib where I can change the height model from Ellipsoidal to Geodetic. What would you suggest?
Emlid Studio provides geographic coordinates in the datum of your base station. So, it uses only ellipsoidal heights. Adjusting the coordinates to a specific vertical datum is usually done during further processing in photogrammetry software. For instance, it should be possible to use some points with orthometric heights to tie your results to the vertical datum.
