0
$\begingroup$

Rosanswers logo

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:


Originally posted by tanasis on ROS Answers with karma: 97 on 2017-10-05

Post score: 2

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by M@t with karma: 2327 on 2017-10-05

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by gvdhoorn on 2017-10-06:
Shouldn't that be sensor_msgs/Imu?

Comment by M@t on 2017-10-06:
Oops, you're right! Thanks for correcting me.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.