Message set for GNSS/INS ROS Driver (node) - Standardized

asked 2017-10-05 09:13:02 -0600

tanasis
97 ●14 ●17 ●23

updated 2017-10-17 04:33:37 -0600

Hello, I am trying to develop a driver (node) for a commercial GNSS/INS unit. For that I think it is important NOT to use custom message sets, but rather standardized ones.

I have found the following:

sensor_msgs/NavSatFix.msg for position (and GPS status)
nav_msgs/Odometry.msg which gives position (again) and twist (velocities)
sensor_msgs/Imu.msg IMU data
GPSFix.msg and GPSStatus.msg from gps_common, which has a lot of types

What would be the best design approach?

Can any one with experience or not point me to the right direction? I think this would be important for people doing similar work as mine! Thanks!

EDIT 1:

After some digging, here also some extra pointers:

Check REP 103 and REP 105
Check ROS Robot Localization package.
I wouldn't recommend using gps_common.

answered 2017-10-05 22:18:17 -0600

M@t

2327 ●55 ●80 ●81

updated 2017-10-06 17:12:45 -0600

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.
sensor_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:

A sensor_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.
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.