Rosanswers logo

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!

Originally posted by Huibuh on ROS Answers with karma: 399 on 2015-01-30

Post score: 0


1 Answer 1


Rosanswers logo

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.

Originally posted by matlabbe with karma: 6409 on 2015-01-30

This answer was ACCEPTED on the original site

Post score: 1

Original comments

Comment by Huibuh on 2015-02-05:
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.

Comment by Huibuh on 2015-03-10:
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?

Comment by matlabbe on 2015-03-10:
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.

Comment by Huibuh on 2015-03-12:
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!


Your Answer

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