GPS FLOAT case is missing

[mattiadutto]

Hello to everyone, I'm working with UGV, and the next big step for my work is to add GPS to the system.
In my facility, we are using EMLID Reach products, in particular RS+ as a base and M+ as a receiver.
The GPS signal can be in 3 different states: SINGLE / FLOAT / FIX. Unfortunately, the current version of the nmea_driver_sat is managing in the same way as FLOAT and FIX. Looking at the NavSatService message, I discovered that it is missing the case for FLOAT messages.

What I propose is to add a FLOAT case in one of the two following ways:

int8 STATUS_UNKNOWN = -2        # status is not yet set
int8 STATUS_NO_FIX =  -1        # unable to fix position
int8 STATUS_FIX =      0        # unaugmented fix
int8 STATUS_SBAS_FIX = 1        # with satellite-based augmentation
int8 STATUS_GBAS_FIX = 2        # with ground-based augmentation
int8 STATUS_GBAS_FLOAT = 3  # with ground-based augmentation

Or in a more logical way

int8 STATUS_UNKNOWN = -2        # status is not yet set
int8 STATUS_NO_FIX =  -1        # unable to fix position
int8 STATUS_FIX =      0        # unaugmented fix
int8 STATUS_GBAS_FLOAT = 1 # with ground-based augmentation
int8 STATUS_SBAS_FIX = 2       # with satellite-based augmentation
int8 STATUS_GBAS_FIX = 3        # with ground-based augmentation

If this is something that can work, I can open a PR and later open another one to edit nmea_driver_sat

On nmea_driver_sat, there is also this issue that is talking about the missing FLOAT case.

[mjcarroll]

I think that the general consensus is that the NavSatStatus message is intended to be maximally compatible across many GPS vendors and visualization tools, at least based on the most recent conversation: #220

The risk that we run changing a core message type is that it will invalidate bags recorded with previous message implementations.

I agree that distinguishing between RTK FLOAT and RTK FIX is critical for high-precision robotic applications, but I think we would want some additional community consensus before making that break. In the meantime, it seems that many drivers implement vastly more complete messages and only provide NavSatStatus for the most general purposes.

Examples: https://github.com/aussierobots/ublox_dgnss/blob/main/ublox_ubx_msgs/msg/UBXNavStatus.msg

@Ryanf55 and @peci1 do you have thoughts/opionions or desire to start a working group here?

[Ryanf55]

If we add enums, does that invalidate bags? Otherwise, I'm a fan of adding a float status. My Trimble PX-1 would use that (actually, it reports a PPP status, which is supported in MAVLink and GPSD, but not ROS 2 NavSatFix).
Thanks for the ping!
Yes, I'm always happy to work on interfaces, we have a seemingly larger amount of people interested in more descriptive but vendor-agnostic GPS messages.

[tfoote]

We should definitely not change enum values this will silently break code in undetectable ways. We should only append values.

Historically adding Enums didn't change the hash, but before taking action on that we should re-validate that memory.

[mattiadutto]

So the idea to add this line int8 STATUS_GBAS_FLOAT = 3 # with ground-based augmentation is it possible?

[peci1]

So the idea to add this line int8 STATUS_GBAS_FLOAT = 3 # with ground-based augmentation is it possible?

Sounds good to me.

do you have thoughts/opionions or desire to start a working group here?

I don't have the capacity to lead a WG, but if Ryan or someone else leads, I'll be glad to be a part of the WG.