I’ve recently been working with MicroStrain, Trimble, and ArduPilot on their ExternalAHRS support. I’m adding support for the bleeding edge GNSS+INS devices from these companies into ArduPilot. The sensors provide 1cm positioning, orientation, and run a full kalman filter. Both can output a ton of data, including covariances. They also have validity flags for different parts of the data, and much more fine reporting of the health of the EKF.
There currently are not any messages in ROS I know of to support these kinds of devices. GNSS+INS gives different data than a dual antenna GNSS system that does orientation.
Exactly how fuse is supposed to work when the GNSS+INS is already running a kalman filter is not clear to me, however MicroStrain’s device supports outputting both the raw sensor measurements (traditional GPS data from each antenna), as well as its fused data in the filter packets. I have a pretty comprehensive document on message definitions.
If we can take 3-4 commercial GNSS+INS devices and generate a comparison of the data fields added, I think that will be really helpful in drafting either a new or modified message
Another thing to note is that many SLAM frameworks using IMU build models under ECI (Earth-centered inertial) coordinates. Because the model under ECI is more concise than that under ECEF. So we also need a tool for ECI to ECEF conversion.
I don’t understand the argument for ECEF. In my opinion, ECEF shouldn’t be a target coordinate system, as the z-axis here does not correspond to the direction of gravity (except at the poles :-)).
Pros and Cons of UTM and ECEF from my perspective:
ECEF:
[+] no distortions of angles or distances/areas
[- - -] not a horizontal coordinate system
UTM:
[++] horizontal coordinate system (x= easting, y=northing, z=altitude)
[++] global standard for all kinds of geodata
[++] angle-preserving, so it is a conformal map projection
[+] covariances of GNSS receiver are typically given in such a horizontal coordinate system
[-] UTM has minimal distortions of distances (scale varies between 0.996 and 1.0), however, I can’t imagine that these are relevant in a typical robotic application
[-] Splitting into zones, but it shouldn’t be a problem to fix the zone for a single robotic mission
Certain minor problems exist in both coordinate systems:
[-] large coordinates (ECEF: x,y,z, UTM: only y), meaning you have to reduce the coordinates through a local origin in both cases.
But maybe I’m just misunderstanding something. In my opinion, ECEF should maximally be an intermediate coordinate system when transforming from LLA to UTM.
I think @pglira makes some good points about ECEF vs UTM, but I want to touch on one specifically that has been problematic both for myself and for others: UTM
[-] Splitting into zones, but it shouldn’t be a problem to fix the zone for a single robotic mission
I think this is generally true for a lot of engineer-operated robots and robots that operate only in a few areas. I previously worked with UAV applications where we used UTM as the underlying coordinate system to great success. Whenever we operated, we did many simulations and tests and validated that the specific flight plans we used would not be problematic. However, for wide-usage and operators that may not have ever heard of UTM, let alone be aware of the complications that can arise operating across a zone boundary, this will come up and it will be an issue. As unlikely as it seems, in one of our very early deployments at Greenzie, we were mowing a field that had the boundary of two UTM zones go straight through the middle.
This led to the implementation of a local-coordinate system option (instead of UTM) inside R_L’s navsat_transform node. While that supports some use cases fairly well (robotic lawn mowing), it does not all of them. Especially as we want robots traveling further distances from where they turn on.
If we want robots that are capable of being operated anywhere at any time (within reason), we will need a robust solution for handling operation across a UTM zone boundary (possibly avoiding UTM entirely).
I don’t understand the argument for ECEF. In my opinion, ECEF shouldn’t be a target coordinate system, as the z-axis here does not correspond to the direction of gravity (except at the poles :-)).
I don’t think the argument was for ECEF, it’s for a local cartesian coordinate system, what you would get out of ecef2ned or lla2ned in MATLAB/navpy.
That eliminates the large coordinates (as everything is referenced to some local datum), and makes it a horizontal coordinate system with very very small distortions when you move far enough away from the datum.