How does one assess the accuracy of rover positions from RTKPOST?
It’s easy to do QA/QC on single points by just looking at the stats in RTKPLOT.
How can this concept be applied to the entire path of a rover (say in a UAV flight)?
2 Likes
Example of why this is important: two drastically different solutions from the same data processed with different options (in this case elevation mask).
How do we assess which one is accurate?
Are you using your own base, using known coordinates?
The difference you display above, is that a result of settings changes or using different input, like clocks and so on?
Base station position is known, RMS values between .0001 and .004.
I’m more curious about best practices for all projects, not this particular example.
But, in this particular example, one set of events is processed with a 10 degree elevation mask, and one with a 15 degree. Both are fixed solutions, except for takeoff/landing.
Could you please share log from your rover. Also settings used in RTKpost
Again- this isn’t a great example quality wise- but I need to know how to qualify how good or bad it is on future projects.
Rover log attached.
One solution:
% pos mode : kinematic
% freqs : L1
% solution : combined
% elev mask : 10.0 deg
% dynamics : on
% tidecorr : off
% ionos opt : broadcast
% tropo opt : saastamoinen
% ephemeris : broadcast
% navi sys : gps glonass
% amb res : fix and hold
% amb glo : off
% val thres : 3.0
The other:
% pos mode : kinematic
% freqs : L1
% solution : combined
% elev mask : 15.0 deg
% dynamics : on
% tidecorr : off
% ionos opt : broadcast
% tropo opt : saastamoinen
% ephemeris : broadcast
% navi sys : gps glonass
% amb res : fix and hold
% amb glo : off
% val thres : 3.0
raw_201807232012.obs (5.4 MB)
I am not able to look at the. Obs file right now but if there is noice in the lower part of the sky this might throw your position of. Also it seems to be where your UAV turns, is it banking alot?
Fix & hold should be OK to use and your signals should handle a more restrictive filter when up in the air.
I would try turning dynamic off, glonass AR on and forward mode.
What do you get then?
But I would suspect when turning, there is some input of bad data that gives you different result and that mask angle is filtering them out with different mask angle.
If you would do the run again with not so much banking, maybe the result would be more of the same?
What height is the UAV flying at?
One more thing. If banking is the cause I would think continuous mode would fix some of the straight part, maybe not in the turn…
1 Like
Thanks much for your input!
The UAV was at 90m. Turn banking was limited.
Yes, adjusting things like AR or dynamics could help get more fixed results.
The point is, depending on options and settings, I get different position results.
The question is not- “help me clean up this flight” but “help me understand how to evaluate how accurate my rover path/events are”?
Am I missing something on how to evaluate the results?
My thought was to determind a setting so you would avoid this kind of difference.
You need to trace the root of problem causing a track to output two different route.
There is no magic answer to look for, telling you this is right and this is wrong.
At this point you have discovered a shift in the tracklog when sat.mask angle is changed and with the visual info on the plot showing the shift around turning points, in direction E-W and in combinaion with fix&hold i would suspect multipath of some kind is the issue here.
My first try would be to run post again in Continuous modes and see if its get better. Continuous mode is way more restrictiv with fixed output.
I think experience and knowledg is the way to tell if this is accurate or not. The numbers are there, one just need to know what they are telling you.
If you have all the raw data, i might give it a shot if you like
And that’s what I want to learn!!! Where is this documented?
So no one can point me to documentation to allow me to gain knowledge and experience of whether rover data is accurate or not?
This makes it very difficult to trust the system, and market it to clients.
Just saying “it is accurate” doesn’t cut it.
Until someone provides a link for you, I think it is safe to say that the answer you seek lies in checking your work. This is what a surveyor does. He checks his work against things that have been previously determined and using standards that are provided to him by an authority.
Your check should be something that lies outside of the system you are using. If we let the processing software check itself, it is liable to become corrupt, just like … um, er … well, let’s not go there.
If you have no set of known points (GCPs) included in your aerial survey, then how could you think of claiming accuracy without some other means of determining it?
Let us stretch this question to the extreme. Say you flew 100 surveys, all with known points included. Some matched up and some didn’t. In analyzing the log files, you see a pattern forming. In the surveys that didn’t match up, you noticed some of these traits:
- number of satellites was below figure X
- average SNR was below figure Y
- DOP was below figure Z
- etc.
- etc.
- forgot to put SD card in survey camera
- etc.
Through your experience, you could say that in all cases where none of these negative elements were present, your surveys were correct (meeting a certain standard). So in this new survey which included zero known points, you will presume, based on experience, that because none of these negative elements are present, then you are confident that your survey is correct. (Until proof is shown that it is not)
This is not documentation, or even advice on how you should go about your business, but just one logical path to follow to allow you to reach your goal.
In the meantime, we wait for some good documentation or paper to show up on how to check/confirm/certify the accuracy of an aerial survey with no GCPs. 
3 Likes
Exactly 
And this comes to mind
1 Like
While I am not a Registered Land Surveyor, I have been completing surveys for civil engineering projects professionally since 2002 with levels, transits, total stations, and GNSS.
Understanding your equipment is paramount to understanding the results that it gives.
I totally agree that completing checks is the answer- which is ongoing for our business. But because checking rover accuracy requires checking a final product- the time commitment is immense. Immense to the point that if I can’t trust this equipment, and testing it takes hundreds of hours- it would make good business sense to invest in better hardware (L1/L2/L5 GNSS).
If there is no published data on the standard operating procedures, equipment limits, and accuracy, how can I trust the results?
1 Like
Could you share the refrence file for the base, to complete the process?
This example dataset is not worth trying to salvage. It’s not worth anyone’s time.
I started this discussion because I’ve seen the resulting shift in rover track on several marginal quality datasets that I’ve collected, and someone on Facebook posted a similar question.
I want to know how to assess the accuracy of rover datasets.
It sounds like the answer is that there are no tools or documentation to quickly assess the quality of rover data.
Ok, i was just trying to show how i would troublshoot.
And I appreciate that very much. But this is about the ‘how’, not the ‘results’.
So if you want to look at marginal data, go for it!Base-raw_201807232013_RINEX-3_03.zip (1.6 MB)
igr20111.zip (89.9 KB)
cors-maon.zip (2.0 MB)
Rover-raw_201807232012_RINEX-3_03.zip (1.4 MB)
1 Like
I edited my post above to accommodate your question. Still no? 
Sorry, I’ve been offline for a couple of days. This deserves more than a 15sec answer so I’ll come back to it after work unless somebody else beats me to it.
1 Like