I thought I would share a workflow we’ve figured out that we think is a good measure to figure out absolute position. If we have an error, hopefully it can be corrected and it can be a useful guide for those in a similar position to us.
We are working in a situation where we have no known points, CORS is frequently not possible, and we cannot use an M+/M2 because we have a DJI drone.
We are using two RS2s (rover, base), a DJI drone (thus no M2), and ground control points (GCPs).
Here is our process:
Place the base station on a high point. Turn on the base and let it average it’s position. Turn on logging.
Place six GCPs around the property, roughly around the perimeter.
Fly the drone survey.
Turn on the rover. Turn on logging. Get FIX.
Start a Reachview survey either via browser or Reachview3 connection. Drive to the first GCP, collect the point and let it collect data for 20 minutes. Drive to the second GCP, collect data for one minute. Drive to the 3rd, collect for one minute etc.
Go back to camp. Download the logs from the base and the rover. Download the GCP survey as a .csv.
Because our base position was not absolute, we need to have it corrected via a reference station. In our case, being in Canada, we used NRTCan PPP.
We uploaded our base station RINEX-3_03.zip file as in the picture and within half-an-hour received the corrected file back. In our case, we received a .pos file. We now have the absolute position of the base.
We downloaded our rover log in RINEX 3.03 but it only produces files in the .21B, .21O and .21P format. So import the rover .ubx file into RTKConv, and click “convert”. If you download RTKLib from Emlid, it seems all the settings are already correct and don’t require adjustment.
Open RTKPost. Again, as it was downloaded from Emlid all the settings appear correct without adjustment. Enter the Rinex rover .obs file and the Rinex base .obs.
In our case, we received a .pos (and .csv) from NRTCan for the base correction so I used the .pos file in place of the .obs. This may have been an error - but as far as I can tell RTKLib processed the data fine.
Click execute. We now have the corrected rover position in a .pos file.
Always survey before you fly. This way, if you bump the GCP while measuring, there isn’t a difference between the measured GCP and the photographed GCP.
If you for some reason need to measure after the flight, then make sure that GCP’s are absolutely fixed to the ground with screws or nails, especially the center.
The best thing to do is to measure before flight (when setting them up) and then again after the flight, and then run a Network Adjustment on them (using a capable processor like EzSurv, or simply by averaging the 2 measurements) . Then you also account for changing satellite geometry etc, setup errors etc.
Why collect for 20 mins on the first and then 1 minute on the other?
Remember the height accuracy of an Ultra Rapid NRCAN PPP solution is around 20 cm. The Rapid is around 10 and Final is around 3-5, if my memory serves me correctly. So, if you need absolute accuracy, you have to wait the 16 or so days for the final product.
You dont have a nearby CORS station instead?
While this software is awesome, also try the Emlid Studio Beta, it provides a more integrated Work Flow.
As a final note, remember to transform the ITRF14 from NRCAN PPP to the appropriate system, otherwise your absolute coordinates will not be exact on the ground.
In another thread someone else had mentioned doing this. It’s not necessary?
This is our first time using NRCAN and it gave us no options for a rapid (or non-rapid) solution. Do you know if it automatically sends a second corrected file later on? Specifically in this case, we’re fine with 20cm height accuracy.
Re: CORS we frequently work in areas with no cell coverage. Given both this and that cm-accurate surveys are not something we always need, I’ve assumed the cost of CORS often won’t be worth it.
Ah, I made a mistake in selecting ITRF. And I’ll re-run this with Emlid studio and update.
It’s automatic. The system will always return the best available solution at the time of query. Same day will be ultra-rapid. Rapid is next day and Final is 14 days later.
You do not need to convert your RINEX files to .obs format. 21B, 21O, and 21P formats are standard and should be successfully processed in any post-processing software, including our RTKlib or Emlid Studio.
It’s not necessary to stand on the point for 20 minutes. If the receiver gets the fix, several minutes are usually enough.
I ran into an error where it won’t process. I’m trying to get my GCP locations so I’m doing the Stop and Go option. The one issue might be that I exported my CSV from the browser Reachview (not Reachview 3) but as far as I can tell the CSV is the same format.
Yes, you’re right. At the moment, the Stop and Go option in Emlid Studio works with the CSV project from Reach View 3 only. This is because the CSV file from Reach Panel (web-based app) does not contain all the fields you need for processing.