Revision history [back]

I'm sure one of the regulars can give you a better answer than me, but here's my 2 cents worth based on my experience working with GPS/navigation/localization.

• sensor_msgs/NavSatFix Most of the GPS drivers/devices I've used with ROS publish a sensor_msgs/NavSatFix message. And certainly several localization modules like navsat_transform in the robot_localization package expect GPS data of that message type.

• nav_msgs/Imu seems to be the standard and expected ROS message for IMU data.

• nav_msgs/Odometry is an odometry data type, so the data has to be relative to some reference frame. Often localization packages will publish this message with data relative to a reference frame (commonly called odom or map) that is created when the localization package is launched.

I don't know much about the gps_common package sorry as I haven't used it. I have used the nmea_navsat_driver package though. You could look at both for inspiration.

As for what you want your driver to publish, I'm not sure what best practice is. A lot of ROS localization/mapping packages will expect an nav_msgs/Imu message at the least, so that's almost certainly data you'll want to provide whether it's raw or combined GNSS/INS. As a potential user I would want to see:

1. A nav_msgs/Imu and sensor_msgs/NavSatFix message containing raw, uncombined data. Possibly also duplicates of these messages, but with combined data from your aided INS engine.
2. Combined GNSS/INS data in a nav_msgs/Odometry message relative to either the 0,0 location of the UTM grid or to a ROS reference frame created when the drivers are launched.

Hope that helps.

I'm sure one of the regulars can give you a better answer than me, but here's my 2 cents worth based on my experience working with GPS/navigation/localization.

• sensor_msgs/NavSatFix Most of the GPS drivers/devices I've used with ROS publish a sensor_msgs/NavSatFix message. And certainly several localization modules like navsat_transform in the robot_localization package expect GPS data of that message type.

• nav_msgs/Imusensor_msgs/Imu seems to be the standard and expected ROS message for IMU data.

• nav_msgs/Odometry is an odometry data type, so the data has to be relative to some reference frame. Often localization packages will publish this message with data relative to a reference frame (commonly called odom or map) that is created when the localization package is launched.

I don't know much about the gps_common package sorry as I haven't used it. I have used the nmea_navsat_driver package though. You could look at both for inspiration.

As for what you want your driver to publish, I'm not sure what best practice is. A lot of ROS localization/mapping packages will expect an nav_msgs/Imu message at the least, so that's almost certainly data you'll want to provide whether it's raw or combined GNSS/INS. As a potential user I would want to see:

1. A nav_msgs/Imusensor_msgs/Imu and sensor_msgs/NavSatFix message containing raw, uncombined data. Possibly also duplicates of these messages, but with combined data from your aided INS engine.
2. Combined GNSS/INS data in a nav_msgs/Odometry message relative to either the 0,0 location of the UTM grid or to a ROS reference frame created when the drivers are launched.

Hope that helps.