I planned out an experiment to test the absolute real world accuracy of our RS+ emlid set. We have a drone with its own reliable RTK service so we placed some GCPs and created an orthophoto to get the locations of these from the orthoimage. We had the base set up and left this to average for over an hour as per the advice I read on this forum. We then used the rover to collect the center points of the GCPs.
I don’t have access to check the firmware versions right this second, but I did update the app and firmware on both devices on the morning of the data collection. (6th Feb)
We collected the data points 3 times, with an emlid reboot between each and a re-averaging of the base station so that we could test the repeatability.
I downloaded all 3 sets of RINEX logs from the base and rover and I got base station data from trimble at 1 second refresh rate from local CORS station.
In emlid studio, I used the Stop and Go and uploaded the files as directed and they seemed to process well and we had fix for the majority of the time. I downloaded the corrected CSV to compare against the drone imagery and initial CSVs.
Summary of error between drone and emlid Test 1: 1.9m - PPK increases error to 3.6m Test 2: 2.6m - PPK increases error to 3m Test 3: 1.4m - PPK increases error to 9.8m
(Just an example of GCP data collection point - emlid has a very high relative accuracy so this is pretty much identical for all the GCPs.)
Disclaimer: I understand that the drone RTK itself will have a small margin of error, as would the emlid so I’m not expecting perfect results, but these are significantly larger than expected. We are hoping to achieve sub 0.5m accuracy between the different systems.
Does anyone have any advice on why the PPK hasn’t worked or something different we could try?
What system, how were your GCP’s derived? Was their a localization involved? If so, it is possible that the PPK corrections were not on the exact same basis and/or did not take a localization into account. I process using projections and Geoids and while my native data gets very close (+/- 3-5cm) to where the surveyed location indicates it can deviate as much as 10m depending on how the base was derived and whether or not a localization was involved.
Hi @SpudTechAg, welcome to the community, and let’s troubleshoot this!
Do I understand correctly that you compare the point collected with RS+ base and drone with the point collected with CORS data + drone?
Did you average it in single? Additionally, please share the drone type. I’d need to check since RS+ is a single-band receiver that won’t really work as a base for a dual-band receiver.
The GCPs were markers on the ground. Our drone has its own reliable RTK NTRIP separate to emlid so we took the centre points of the GCPs from the drone imagery. The emlid was set to collect in default ESPG:4326 and the drone natively collects in ESPG:32630 but I reprojected this in QGIS to also match.
That’s an interesting point. I’m out today collecting more drone data so I will put a few gcps out and test collecting with emlid set to the local crs instead. Thanks
Our drone (DJI M3M) has its own Ntrip Rtk corrections so this all independent to emlid. We know this to be reliably accurate within a few cm. We were using GCPs and the drone imagery as a way to compare the accuracy of the emlid points taken on the GCPs.
Yes I had the base averaging on single for over an hour, but the rover was connected and reviving a fix for the duration of this time.
I am going to try Michael’s suggestion of changing the crs, but I am still hesitant that this will fix the problem as in the last test, each 3 attempts gave wildly different corrections.
Do you post-process your RS+ static base first and then run Stop&Go against it or do you directly post-process the rover against a CORS? I didn’t get that from what I read but it might have an impact with a much shorter baseline for the rover.
For me now it looks like a setup issue, but I need more information to understand the workflow.
How did you process the base? Did you use static data with CORS or PPP? Also, what do you refer as the rover here, another Reach device or the DJI M3M?
I had missed this step in my workflow, but used the base Rinex and CORS data to generate the long/lat/height in the .pos file in the static processing stage.
The when I went to process in stop and go, I used this new position data when importing the base file.
I hope this was the right thing to do, but the results seemed successful!
I think Gabriel has pointed me in the right direction. I didn’t realise I needed to do static process on the base first in emlid studio. After doing this, the results improved significantly (I posted results in the reply to Gabriel.)
But just for clarity in the thread, I was using 2 RS+ receivers, one as the fixed base and one as the rover.
Yes, you will need to have an accurate base point to be able to get centimeter-level accuracy. Thank you for sharing the result! Feel free to create a thread or contact us if you have any questions.