Fascinated and excited to see these discussions.
We operate robotic boats for marine science and in particular, seafloor mapping. Our navigation accuracy requirements can be pretty stringent, but equally important is the ability to quantify that accuracy both in real time and in the recorded data. Honestly, we achieve this with purpose-built INS aided GPS systems which integrate directly to the sonar outside of ROS, as this is the industry standard for crewed vessels. We rarely if ever use ROS for this, as it just doesnât have to tooling, although we would like to.
Regarding ECEF vs UTM:
AaronP1 makes a terrific point that is REALLY important and worth repeating. âGlobal frames (ECEF or LLA) need to be referenced by a Datum and Epoch.â This is really important for any mapping application. This can be tricky. For example, a standard uncorrected GPS fix will use the WGS-84 IRTF datum/epoch, but if it is receiving RTK corrections from a reference station, the resulting fix will be in the datum of the reference station. If that reference station is a CORS station in the US, the RTK fixes will be in NAD83. A receive can gain and lose RTK corrections frequently during operations, and so the fix type must be monitored to apply the right datum metadata correctly.
Since local frames are referenced from global frames, I think TF frame definitions should probably have a place holder to record the Datum and Epoch from which they are derived.
While I think ECEF is the way to go, GPS provides notoriously poor positioning in the vertical due to the geometry of the measurements, and (as has been mentioned) this can cause all manner of problems if not ignored or constrained by another measurement. Iâll mention in passing, for marine commercial survey-grade navigation systems, when GPS corrections are not available to make the vertical uncertainty small, an INS and a complementary filter are used, which provid a zero-mean vertical offset (e.g. âheaveâ). Of course this is designed for vessels at sea, and would not be directly appropriate for aerial robots.
We travel far enough distances in our operations that we suffer from the bias that grows between a local tangential map reference frame and ECEF coordinates. (If I recall correctly, I think about 15 km is where this seems to start to matter.) At the moment, we know the problem exists but we donât yet handle it in ROS.
It might be possible to add a transform to the TF tree that captures the bias that grows between the local map frame and the ECEF projected coordinate at the robotâs position. This transform would be near zero for positions near the map origin, and would grow with distance from it. If this works the way I think it should, the map frame should never need to be shifted once established, maintaining the continuity of the math applied by various nodes in that frame. [I guess Iâm proposing we become flat-earthers.] As I think about it, this would limit operations to the hemisphere of operations centered on the map frame origin, but that doesnât seem like much of a constraint.
One architectural note. In our robots we initially built a ROS Service to convert Lat/Lon to ECEF, but found this too slow for may. We now use a C++ library so the math can optionally be accomplished within the node itself.
Uncertainty:
In addition to the problems others have noted with regard to underestimation of GPS uncertainty, one should note that GPS measurement errors are correlated in time, and this too is not captured by DOP or other uncertainty measurements provided by the receiver.
There are several reasons for this, including internal kaman filters and the fact that the previous position is typically used as a seed for the solution for the next position. One can see the correlation clearly by plotting the latitude or longitude of the position with time and noting the measurements âwalkâ about the long term mean in a smooth way, rather than jumping stochastically from one measurement to the next. (There are sometimes discontinuities in the path, but this is usually due to a loss/gain of satellite or multi path.) This paper describes the effect and how to measure both the correlation length and long-term uncertainty of a receiver (one would have to repeat this for various fix types):
https://www.degruyter.com/document/doi/10.2478/jogs-2013-0016/html?lang=en
In GPS aided inertial navigation systems, this kind of correlation is typically handled in a kalman filter by the adding additional states to the state vector to model the random walk. I donât know of a ROS based solution that does this.
Finally, one big omission in the TF library that would be wonderful to see addressed, is the inability of the TF libraries to propagate uncertainty between reference frames. (Some other packages do provide this.). Uncertainty propagation is also required for conversions to/from LLA and ECEF too, which is a little trickier since that math is not matrix based.
My 2 cents.
)