Ask Your Question
2

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

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

tanasis gravatar image

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

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:

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

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

M@t gravatar image

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

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:

  1. 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.
  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.

edit flag offensive delete link more

Comments

Shouldn't that be sensor_msgs/Imu?

gvdhoorn gravatar imagegvdhoorn ( 2017-10-06 02:27:03 -0500 )edit

Oops, you're right! Thanks for correcting me.

M@t gravatar imageM@t ( 2017-10-06 17:13:29 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

3 followers

Stats

Asked: 2017-10-05 09:13:02 -0500

Seen: 269 times

Last updated: Oct 17 '17