Open FletcherFT opened 6 years ago
Has anyone fixed this? The message type is completely wrong. It should be sensor_msgs/NavSatFix
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?
@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.
@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!
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.
source: http://docs.ros.org/melodic/api/sensor_msgs/html/msg/NavSatFix.html