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 Like
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
1 Like
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
2 Likes
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?
1 Like
in a ppk workflow its not an issue.
in a realtime workflow yes its an issue.
i know i made sure the ellipsoid height was populated correctly on the herepro, but need to revisit the others.
and yes the ublox uses an approximated egm96 ellipsoid, so accuracy’s are not great