Sometimes more RS2’s are simply better!
Like when you have trees and metal building all around, and you still need precise GCP’s without a total station.
For a stockpile volume jobsite I installed a perimeter of large screws around the stockpiles, so I can lay out GCP’s quickly every time I visit the site, which is regularly.
The jobsite is very challenging from a GNSS perspective to say the least. On one side it has 25 meter high trees, that in the summer-time partially covers the side of the stockpile. Another side has a large metal structure in 13 meters height. Plenty of obstructions.
From previous visits I know that for the challenging positions near the trees or structures even 15 mins obs times wouldn’t be enough. So to be sure to get a good average and the ability to fix even with L1 only, I planned for at least 40 minutes on each point. With 40 minutes on each point and 19 points, I wouldn’t be able to complete 1 workday with a classic Rover/Base pair.
So instead I planned on using 1 Base and then 3 static rovers. Given the obs-times, this will allow me multiple baselines for each point, which makes for a rigid structure of interlined baselines.
This exercise requires a lot of planning though to make sure overlap between the different points are optimized, so they have at least 20 minutes of overlap. Additionally, careful planning will make sure that excessive walking-around is prevented.
Time-planning and visualizations were done and prepared in Excel, and then used on-site on an iPad to register start-stop time, which receiver was used and height of the ARP for each positions.
Here is a visual representation of the end-result overlap:
So now with a lot of data collected, it is time to put it all together! I had collected 4 long, continuous logs, and then split them up into the different observed points using RTKLib provided by Emlid.
The resulting static Rinex files where then fed into EzSurv for the post-processing step.
For absolute reference I used a nearby NTRIP-station from RTKconnect (which is a RS2 based NTRIP network here in Denmark).
With a baseline of just 4 km, I could easily use the NTRIP to fix numerous point on the site, as well as my own local base.
However, as expected, even though I had 40+ mins of obs-time on each point, not all would fix anyhow. This lack of fix resulting in some solutions being Float and some even Single. And that’s where the multiple baselines come into play.
Using these multiple baselines, EzSurv is capable of doing a Least Square Adjustment on the data, using user-defined references. I used the Low-rms Fixed solutions as references for the less good observations. The resulting will be an “averaged” point with much higher confidence!
As an example the BS2 and #6 points are particular tricky, and even though BS2 point was observed for over an hour, all 3 baselines-results came in as Floats, with an RMS of .3 meters. After the network-adjustment, this error was now down to 5 cm vertical.
Here is how all the baselines look in EzSurv after the network-adjustments:
If we do to only process using our local base, it would instead look like this:
Alright, so far it has been a bit theoretic all of this. It there actually a difference when the points are used “in anger”? Well, let’s do a small comparison between the network-adjusted points, and then a single-base solution with the same 40 mins obs.
I use Metashape to do my photogrammetry-stitching, so lets take a look at the resulting position-errors. The sparse-cloud was computed using a custom-made, pre-calibrated, all parameters fixed camera-profile for my DJI Phantom 4 Pro. GSD of 0.7 cm/px. 12 Ground control points, 7 check points’s. Roughly 550 images.
Network-adjusted:
Horizontal error (checkpoints, N/E): 0.005/0.009 m
Vertical error (checkpoints): 0.01 m
Single-base:
Horizontal error (checkpoints, N/E): 0.042/0.019 m
Vertical error (checkpoints): 0.072 m
Here screenshots from Metashape:
Network-adjusted:
Single-Base:
Preetty awesome results!
You can also do this in a Stop&Go flow, if you make multiple short observations on the same point. Observe your points in Reachview2 or 3, and then import the CSV and raw-files into EzSur,v, and you are on your way. EzSurv will help you identify what points have been observed multiple times.
I will do a project-share on this topic in the coming months!
Thanks for reading!