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?
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.
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 ???
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.
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!
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.
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.
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!
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 
@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. )
After the release of the ZED-F9P, cm-level reliable positioning is here without spending thousands of $$$$. How much effort does it take to have navigation to the cm-level in ardupilot? Is this simply changing the format of a few variables to remove the truncation, or is this far more involved? Moving-baseline heading is now very accurate, but navigation still suffers.
The Zed-F9P version from Ardusimple is purposely built for the Ardupilot world. So that, and it being the lowest cost version so far, is why I chose it. It has the JST connectors already on the board. Note: I do not sell these. 
It has XBEE connectors already on it, too. I chose the 900 MHz versions for comms between the base unit and the one(s) on the drone(s.) It also (probably) does not interfere with most control comms between the drone(s) and the controllers.
Personally, I -do- need accuracies of 1-3 mm, both for the drones and for the lawnmower. There is a slope on the lawn that meets directly with the curb to a heavily traveled road. <noisy, too! Sigh> I always feel like I’m going to tip over onto the road for about 70 feet of that section. As the Ardupilot code stands right now, I cannot trust the controller to prevent the lawnmower from simply steering itself onto that road. (The wheels have to actually ride on top of the curb.) Some of that mission -may- be solvable with CV; just not sure.
More importantly, I need the flying drones to locate themselves, and report their locations, as accurately as possible. GPS stamping the photos is a whole separate issue but AFAIK that data does not come from the Cube, so I’m setting the companion up to feed the camera.
Help, please!
Thanks.
David,
I’m curious what type of mower you have that you can get very close to a curb reliably from a mechanical point of view? I may not be understanding what you mean, actually. But, with my large Zero Turn, I have come to realize that it will never cut close to some objects, at least without a LOT of precision mission planning. The frame of the mower is so large relative to the deck that the direction it approaches a particular feature of the yard can make a difference in how much it goes past my desired point. I hope one day to build a more nimble, likely electric, version for closer cutting around obstacles.
I would love to see your machine if you have videos or pictures. Sounds like you are doing good things!
Kenny
Kenny,
Kubota BX 2660 with the 60" cutting deck. Probably all over the
web.
David
I plan to include 3D vision on it as well, like the Intel D435 or 435i. Or maybe, finally have a use for my jetson TX2 since it has six lanes of MIPI video input. LIDAR might be in it’s future, too.
Or is that getting over the top? Toys, toys, toys!
I’m quite certain that AP’s accuracy can be 1cm (or better) and that the conclusion that it can be no better than 11cm is incorrect.
I guess there are various places where the accuracy could be lost:
FYI @tridge, @priseborough
Currently all lat/lng’s handled by AP are limited to 7 decimal places. This gives a worst case 1.1cm resolution. Internally the EKF typically has much greater precision (depending on distance from home) but since the EKF usually relies heavily on lat/lng input from GNSS this is the limiting factor. Additional precision is possible but not trivial and of dubious benefit for most…
1.1cm is awesome and who could ask for more. In the discussion above (from 3 years ago), it was stated as 11cm. I guess there is a factor of ten issue somewhere.
Dear all,
its not a matter of precision digits, but more of a “chicken and egg” situation…
The EKF gives you the advantage to fuse the IMU data thus spatially interpolate GPS Values beneficially for accurate positioning. Which results in better -or more precise navigation especialy for rovers.
But when i need to accuratelly timestamp the data of this “fused” RTK data with my lets say sonar, camera, etc, then the only way is to have:
a. a valid geod
b. a valid base or NTRIP etc.
On the other hand if i PPK the data, then i loose all the EKF goodies as well as the timestamping becomes a nightmare.
From my testings so far, after a huge amount of data collection and manipulation with RTK (L1, or L1/L2), with static base or NTRIP, with hot-shoe or not. I have found that the actual position drifts more than 25cm and specially in Z axis. I’ve narrowed it down to the Ellipsoid VS Geoid transformation but i dont exactly understand if the Ardupilot inherently uses a geoid (ie EGM96) which messes post-proccecing to projected datums.
The thorough descriptions of @Georacer and simplified yet definitive explanations from @rmackay9 helped a lot to understand what happens when we need to use these data for other than navigation purposes and expected accuracies. I thing a lot of users would appreciate some further insights regarding “under the hood” geo-tagging capabilities and processes.
Best,
Dimitris
The geoid used depends on the GPS you use, the ublox uses EGM96, all the srtm data for terrain following uses EGM96, so it depends on the data source being used. The ellipsoid alt is available, just not sure if it’s logged atm
That was the kind of info, I was afraid of.
Logging with EGM96 heights, means that we need to convert them back to ellipsoid heights first and then to a preferable projected datum, inducing inaccuracies that are based on the EGM96 Grid cell and inefficient 6 parametric calcs during transformation.
I think it’s mandatory to log the ellipsoid heights (along with pos estimates) with all RTK enabled GPS’s, if we want survey grade use of the data.
Can we summarize this topic to raise a feature request?