Closed OsamuSekino closed 4 years ago
The issue here is that the nmea_navsat_driver
wants to be lightweight and thus not define any own messages. Therefore it uses the default ROS NavSatStatus
message, which doesn't know about any specific RTK states:
http://docs.ros.org/melodic/api/sensor_msgs/html/msg/NavSatStatus.html
The currently used STATUS_GBAS_FIX
is the "best" available class there, fits as "ground-based augmentation" to RTK and therefore used for all RTK solutions, no matter whether they are float or fix. There is no option to distinguish between those two.
In order to solve this issue properly custom messages would be needed, which kind of conflicts with the light-weight approach.
It seems like you're confusing "GNSS fix" with "RTK fix" in your pull request. "GNSS fix" means there is a valid position solution. "RTK fix" means the receiver is using RTK corrections and was able to fix the integer ambiguities of all used satellites.
I am inclined to agree with @ggaessler's analysis. STATUS_NO_FIX
would indicate that there is no position solution at all, which certainly isn't true in this case. Similarly, it's correct to say that in the RTK Float status, there is "ground-based augmentation," which makes STATUS_GBAS_FIX
correct.
This driver is rather limited, and if you're using an RTK system, you probably would benefit from more features. If you're using a Novatel system, my former colleagues at Southwest Research Institute created a driver for Novatel GPS systems which you may find more useful than this driver.
Whether RTK is FIX or Float, it will be output as STATUS_GBAS_FIX. It is not possible to tell if it is FIX or Float.
https://github.com/ros-drivers/nmea_navsat_driver/blob/master/src/libnmea_navsat_driver/driver.py#L140
Shouldn't you actually define a STATUS_NO_FIX on this line? It would be great to have your input.