Servers by jDrones

RTK and general GNSS inaccuracies

gpslog
gnss
rtk
(George Zogopoulos Papaliakos) #15

Thank you for your reply,

I’ll hunt into the code the variable declarations for documentation purposes and edit my post for completeness.

Editing the drivers to use double instead of floats doesn’t sound do gnarly. Double math is much slower than float, but sparse use won’t break the loop rate.

On the other hand, converting the EKF to double could have a significant impact on memory and loop rate.

Is any of the above the reason why this hasn’t been done yet, or it’s just that demand isn’t high enough?


Regarding precision loss, it’s true that hunting down all of the error sources and propagating them down to the EKF is an ugly business. That’s why one would pay $$$$$ for a good INS and still have have to be careful with the integration.

(George Zogopoulos Papaliakos) #16

Hunted down some sources for RTCM correction representation. Inserted links where appropriate.
Will follow up with more info on the UAV side.

(George Zogopoulos Papaliakos) #17

Updated flow diagram and fixed information up to on-board GNSS receiver.

(Mike Boland) #18

Thank you @Georacer for inputting some useful information on this.
While RTK still seems to be the rising ‘catch phrase’ it would be good to get this precision shortcoming sorted.

I feel it would be of great benefit in the long run to Ardupilot to have this extra precision added.
Your work has at least narrowed down where we should be looking for improvements.

(George Zogopoulos Papaliakos) #19

You’re welcome! I’m not done yet, although I am sure @WickedShell has already answered the question on which are the pain points.

Still, I hope that if I do a good enough job in documentation, it may become easier to someone to make some progress on the matter.

(WickedShell) #20

X_a' and X_e are both stored in int32’s and have exactly 7 decimal places of precision.

(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.

3 Likes
(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.

1 Like
(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.

1 Like
(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 ???

(George Zogopoulos Papaliakos) #29

Hi @ktrussell,

Sorry for not noticing your message earlier.

The resolution for the current representation of position for the EKF is a floating-point value in meters (source code link). This is equivalent to sub-millimeter resolution for a typical range of 1000m.
Its precision cannot be easily quantified, as it depends on the precision of many sensors, such as the GPS, accelerometer, gyroscope and others.

However, the GPS precision is a major contributor of inaccuracies, and its own representation is an int32 value in degrees (lon/lat) * 1E7.
The minimum increment which can be recorded is an angle of 0.000001 degrees. Projecting this to meters gives us:

Δx = sin(Δθ)*Re = sin(π/180 * 0.0000001) * 6.3781e6 = 0.0111 meters

It seems I had missed a decimal place in my earlier post, I apologize.
Thank you for reviewing my post.

(Kenny Trussell) #30

Thank you George for the excellent explanation that clears up my understanding completely. A silly thought: the precision will be greater for longitude as you move further from the equator, so planning a mowing pattern that runs north-south rather than east-west would theoretically allow one to have more precision between passes… My mower isn’t tuned that well yet, anyway. I overlap by 20".

I would throw my hat in the ring of hoping the developers find the time to increase the precision at some point, though.
Thanks again!

(Nathan E) #31

I don’t think your first and second statements agree. Is there a zero missing somewhere? 0.000001 degrees is roughly 0.11m, not 0.011m according to Wikipedia’s table.

(George Zogopoulos Papaliakos) #32

Sigh… There is definitely a zero missing somewhere, I have given two different numbers for minimum angle increment in my last post. Sorry I messed up again.
Let’s use the scientific notation to avoid further typographical errors.

So, as we know, the GPS subsystem of Ardupilot reports coordinates in units of degrees*1e7.
This information is conveyed in an int32 variable.

Thus, the minimum increment which a coordinate value can change by is as large as a unit in the least significant digit.

Now, let’s take this really slow so that I don’t make a mistake again.

  • 1e7 units are read as 1 degree (in latitude or longitude)
  • 1 unit (the minimum possible increment of the reported coordinates) is read as 1e-7 degrees.

So, doing again the above math we get:
Δχ = sin(Δθ)*Re = sin(π/180 * 1e-7) 8 6.3781e6 meters = 0.0111 meters.
which is the same as my previous derivation (thankfully).

Sorry for another late answer. I have so many notifications on discord that the replies get lost in the clutter.
Try PMing me if you really want to get through to me in time.

Have a nice day!

(George Zogopoulos Papaliakos) #33

While I agree that the resolution of reported longitude and latitude is greater at greater latitudes (and consequently the precision as well), I don’t see how north-south passes could be more accurate;
The local resolution of the GPS subsystem (i.e. the flat plane of land you mow) is constant.

Yes, in high latitudes, longitude has more resolution (in meters). I found this image from wikipedia to have a nice visualization:

However, by doing north-south passes you would trade accuracy in one direction for the other (east-west). I don’t see how it would help.

Still, by now you must have a very well-trimmed lawn, considering 20" overlap :smiley:

(Kenny Trussell) #34

@Georacer
My thinking is that if I mowed in an up and back pattern north and south that my distance between each line would be more precise. What would still have the latitude error, which is larger, would be the end points where the mower turns around, e.g. the mower would turn around at different latitudes. It is all kind of academic I guess anyway. (And I prefer to mow in a polygonal shape from outside in, anyway. )