GNSS: 1060.Fix.uavcan ECEF instead of LLA

[glennib]

Some GNSS receivers output ECEF coordinates instead of LLA. Are there plans to provide support for these fields in a GNSS fix message?

[pavel-kirienko]

There are vague plans to define a replacement message instead of the current uavcan.equipment.gnss.Fix (let it be called uavcan.equipment.gnss.Fix2, for a want of a better name). The concerns to address are the following:

• define a single covariance matrix 6x6 for position and velocity instead of two separate 3x3 matrices. This will allow the receiver to report covariance between position and velocity estimates.

• as you mentioned, the position vector should be represented either or both in LLA (angular degrees scaled by 1e8) and ECEF (signed integer millimeters). LLA should probably be made mandatory, since most applications expect this representation, and ECEF should be made optional. We can reduce the bus traffic overhead when ECEF is not reported by stashing its fields into a dynamic array of length 0..1, e.g. ECEFPosition[<=1] ecef_position, where ECEFPosition is defined like int37[3] xyz (this is just an example, don't take it literally).

• address the issues raised by @WickedShell in GNSS: Limitations of the current uavcan.equipment.gnss.Fix message #7.

Would you volunteer to draft such a message definition? Feel free to submit a pull request. Also paging @mhkabir, he might suggest a thing or two.

[glennib]

I can do that. I haven't set up a build system for this library, so I will just draft the definition and push it in to a separate branch. Expect a pull request shortly.