Ask Your Question

rtabmap odometry source

asked 2015-01-30 04:37:55 -0500

Huibuh gravatar image

I have been experimenting with rtabmap_ros lately, and really like the results I am getting. Awesome work Mathieu et al.! First, let me describe my current setup:


  • ROS Indigo/Ubuntu 14.01
  • rtabmap from apt-binary (ros-indigo-rtab 0.8.0-0)
  • Custom robot with two tracks (i.e. non-holonomic)
  • Custom base-controller node which provides odometry from wheel encoders (tf as /odom-->/base_frame as well as nav_msgs/Odometry messages)
  • Kinect2 providing registered rgb+depth images
  • XSens-IMU providing sensor_msgs/Imu messages (not used at the moment)
  • Hokuyo laser scanner providing sensor_msgs/LaserScan messages

Problem Description

The problem I am having is the quality of the odometry from wheel encoders: while translation precision is good, precision of rotation (depending on the ground surface) is pretty bad.

So far, I have been using gmapping for SLAM/localization. This has been working good, gmapping subscribes to the /odom-->/base_frame tf from the base_controller as well as laser scan messages. In my experiments, gmapping does not have any problems in indoor environments getting the yaw-estimate right.

Using rtabmap's SLAM instead of gmapping works good as long as I don't perform fast rotations or drive on surfaces on which track slippage is high (i.e. odom quality from wheel encoders is poor). This results in rtabmap getting lost. To improve rtabmap performance, I would like to provide it with better odometry information. My ideas are:

  1. Use laser_scan_matcher subscribing to laser scan + imu/data + wheel_odom OR
  2. Use robot_pose_ekf subscribing to imu/data + wheel_odom OR
  3. Use robot_localization subscribing to imu/data + wheel_odom OR
  4. Use gmapping subscribing to tf + laser scans OR
  5. Use hector_mapping subscribing to laser scans

Solution (5) only uses laser scans and does not work reliably enough according to my experiments. (4) works great, but is overkill for this purpose and uses too many resources. (3) and (2) only use relative sensor sources (i.e. do not do their own ICP matching using laser scans), but might be worth a try. (1) would be my preferred solution as it uses laser scans as absolute reference. However, laser_scan_matcher only provides geometry_msgs/Pose2D and no nav_msgs/Odometry which is required by rtabmap.


@matlabbe Can you advise what would be you recommendation in my case? I have been looking at the ideas from this thread as well as the laser_scan_matcher mod listed here, but I am unsure whether rtabmap uses the pose and twist information contained in nav_msgs/Odometry, or if providing pose only would suffice. Please advise.

Thanks you!

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2015-01-30 11:24:33 -0500

matlabbe gravatar image

Can you show which parameters are used for the rtabmap node (example launch file)? The parameter "RGBD/PoseScanMatching" can be set to true for odometry correction with laser scans like in the Robot mapping demo (which may correct the yaw).

The laser_scan_matcher seems also a good solution. RTAB-Map doesn't use twist information, you could just convert the geometry_msgs/Pose2D into a nav_msgs/Odometry message by filling the "pose" field (you can set the covariance matrix to null) as well as the header with corresponding TF frames and timestamp.

edit flag offensive delete link more


I checked my setup, "RGBD/PoseScanMatching" was already set to true during my experiments. I am now in the process of writing a node that converts geometry_msgs/Pose2D into nav_msgs/Odometry to check out how laser_scan_matcher performs as a odometry source for rtabmap. I will report back here.

Huibuh gravatar image Huibuh  ( 2015-02-05 01:18:18 -0500 )edit

I got it to work, but laser_scan_matcher fails to localize correctly in my test environment (e.g. at end of long halls). Ideally, I would like to use gmapping as odometry source (it localizes flawlessly). However, gmapping publishes its own map->odom transform, which interferes with rtabmap...ideas?

Huibuh gravatar image Huibuh  ( 2015-03-10 09:53:45 -0500 )edit

You could disable loop closure detection and set "publish_tf" to false in rtabmap, but the whole map would not be corrected when gmapping closes a loop. I did some updates to PoseScanMatching recently, you may want to try to compile rtabmap from source and see if it could work better.

matlabbe gravatar image matlabbe  ( 2015-03-10 10:46:31 -0500 )edit

I have compiled the latest rtabmap 0.8.6 from source. The localisation performance has improved a great deal, I can now for the first time map the test environment without getting lost every time. Good work!

Huibuh gravatar image Huibuh  ( 2015-03-12 05:40:38 -0500 )edit

answered 2016-08-16 20:28:20 -0500

quentin gravatar image

@Huibuh , in case you are still working on your robot project, I have one question: where did you get the indigo release of gmapping? Thanks a lot for your help!!!

edit flag offensive delete link more


you should be able to get it with sudo apt-get install ros-indigo-gmapping

matlabbe gravatar image matlabbe  ( 2016-08-22 09:09:37 -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



Asked: 2015-01-30 04:37:55 -0500

Seen: 2,430 times

Last updated: Aug 16 '16