Servers by jDrones

RTK and general GNSS inaccuracies

rtk
gnss
gpslog

(George Zogopoulos Papaliakos) #21

Happy new year, everyone!

I went through EKF3, traced the location update and populated the inner workings in the previous, aggregate post.
Please correct me if I have misunderstood any part of it.

The inner position state and output are expressed in NED and in meters, in float32. This means that there is plenty of resolution to accept RTK accuracy, being a bit conservative to account for flat-Earth modeling.

However, the GPS location is read from the GPS driver as the well-known int32_t degree*10^7 representation which kills all resolution below 11cm.
From my point of view, if somehow the GPS drivers could offer higher resolution, the EKF could happily oblige and produce better results.

One more thing: During the measurement update, the used position accuracy is set to:

float alpha = constrain_float(0.0002f * (lastTimeGpsReceived_ms - secondLastGpsTime_ms),0.0f,1.0f);
[...]
gpsPosAccuracy *= (1.0f - alpha);
float gpsPosAccRaw;
if (!gps.horizontal_accuracy(gpsPosAccRaw)) {
    gpsPosAccuracy = 0.0f;
} else {
    gpsPosAccuracy = MAX(gpsPosAccuracy,gpsPosAccRaw);
    gpsPosAccuracy = MIN(gpsPosAccuracy,100.0f);
}

meaning that, depending on the size of gpsPosAccuracy its value may overshadow a better RTK accuracy.

On the other hand, if gpsPosAccuracy is actually smaller than the actual RTK accuracy, then the truncated RTK values, there is a mismatch between the final measurement uncertainty gpsPosAccuracy and the actual resolution of the GPS position.
This may result in an underperforming filter.

Of course, all of the above is probably already known to the EKF developers, but it was a good exercise for me and a piece of documentation I could not find elsewhere.


(George Zogopoulos Papaliakos) #22

@mboland
Do you know if a dev could weigh in on this and give an opinion on how much of what I have written is true and how easily RTK precision could be added in the EKFs?

I have a friend who’s doing GIS professionally and is interested in it.


(Nathan E) #23

I’m not a developer, but @WickedShell might be able to weigh in on this. I’m guessing most of what you say is true, but I can’t say for sure.

In my opinion, improving the EKF accuracy down to the sub decimeter level would be neat, but most vehicles wouldn’t respond a lot differently due to other navigational inaccuracies (tuning, etc.).

Since most of us who us GNSS for GIS and surveying conduct post-processing, I don’t think there’s much advantage to real-time position estimates by the EKF anyway. Post-processing will probably always win because reliance on a wireless link for real-time corrections isn’t as good. Post-processing can also have custom filtering, data manipulation, etc. Since logging and post-processing already narrows us to sub-cm accuracy in many cases, I don’t think it matters if aircraft are a few cm off in their navigation routes.

In general, I don’t think many users have an interest in hitting the same 3-cm point every time with their vehicles. I guess rovers conducting lawn-mowing and precision navigation could benefit.


(Mike Boland) #24

Only the Dev’s that have had input to this discussion
@WickedShell
@Michael_Oborne
@OXINARF

At least you have highlighted that there is good decimal accuracy that is being truncated from float32 to int32_t in the code.
It seems good practise to me that it should remain float32 throughout to provide at least consistency.


(Kenny Trussell) #25

@Naterater I am mowing and would like to see the accuracy greater. My tuning is not quite what it should be yet, so I certainly would not say any inaccuracy in my navigation is really due to the 11cm limit. But, it would just be nice to know that this one variability was eliminated.


(George Zogopoulos Papaliakos) #26

Well, even if you want to to offline processing, don’t you need to have a log of the onboard RTK receiver somehow somewhere, correlated with Roll-Pitch-Yaw values?
Where is this captured right now? On an SD card in the receiver? Not 100% informed on this topic.

And one other thing, for which I’m in the dark: What about indoor navigation, with small quads etc.
Is the same resolution truncation happening for UltraWideBand positioning sensors as well?


(Nathan E) #27

Most survey-grade GNSS units have separate on-board logging of the GPS data from the flight that can be post-processed. The easiest way is without lever-arm corrections (keep the GPS directly above the camera), however when the GPS moves a lot relative to the camera, then the lever-arm offsets can be a little more important and then are extracted and estimated from the autopilot logs. Roll-Pitch-Yaw are generally discarded as modern photogrammetry software uses automatic triangulation anyway. If you want to read-up on an inexpensive system that does this, Emlid has a good amount of basic information. https://docs.emlid.com/reachm-plus/common/tutorials/ppk-introduction/

The truncation of some of these EKF items is actually a little concerning, especially for more precise applications like optical flow and as @Georacer said, indoor navigation.


(Kenny Trussell) #28

So, I need straightening out on one thing. Is the current precision in the navigation routines of Ardupilot (not logging) 11 cm or 11 mm? Here https://github.com/ArduPilot/ardupilot/issues/5287 and the wikipedia article https://en.wikipedia.org/wiki/Decimal_degrees it refers to say millimeters. In this thread, I see centimeters. That should be at the equator for longitude and everywhere for latitude, I believe. Longitude gets more accurate as you move away from the equator.

mm or cm ???