rtabmap odometry source

edit

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:

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.

Question

@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!