Use sensor_msgs/NavSatFix message for nav_odom topic

[FletcherFT]

source: http://docs.ros.org/melodic/api/sensor_msgs/html/msg/NavSatFix.html

[Bmoradi93]

Has anyone fixed this?
The message type is completely wrong.
It should be sensor_msgs/NavSatFix

[doctorcolossus]

Hi @FletcherFT, @Bmoradi93, @bsb808, has anyone found a solution to use a sensor_msgs/NavSatFix message type?

I was interested in using this package for odometry with the GOOSE dataset, which includes topic /sensor/ins/oxts_rt3000/gps/fix of type sensor_msgs/NavSatFix.

Am I misunderstanding the purpose of this package, or has there been some historic change in the convention of these message types which has rendered this package obsolete?

[FletcherFT]

@doctorcolossus
My intention was to make this issue a suggestion to the devs, since it's confusing for integrators to have ellipsoid coordinates as the pose.position coordinates and sensor_msgs/NavSatFix is the correct container.

You might be better off with the navsat_transform_node since it will publish transformations to a UTM frame.
It depends if GOOSE has an nav_msgs/Odometry topic and a sensor_msgs/Imu topic. I'm not sure why navsat_transform_node needs an Imu source, since the odometry.pose.pose.orientation field could contain the required rotation. I suppose it's because the odom frame could be referenced to something else other than ENU. Note that you will something else publishing the tf between odom and base_link.

[doctorcolossus]

@FletcherFT, thanks for the clarification and suggestion!

Unfortunately GOOSE does not include either an odometry or an IMU topic, but it's good to know about that package nonetheless!

[bsb808]

Hi All.
Thank you for the interest and the suggestions. It would be great to have additional input message times such as NavSatFix and/or GeoPoint. I'd be happy to review a PR if it would help you with your use case.