Glossary

Fictionlab > Glossary > RTAB-Map

RTAB-Map

RTAB-Map – definition

RTAB-Map, short for Real-Time Appearance-Based Mapping, is an open-source framework for simultaneous localization and mapping (SLAM). It estimates a mobile robot’s pose while building a map from sensor data. The framework was introduced by Mathieu Labbé and is maintained as the rtabmap core library with ROS and ROS 2 integration packages.

In mobile robotics, RTAB-Map is primarily used for visual SLAM, RGB-D SLAM, stereo SLAM, and LiDAR-supported mapping. It applies appearance-based loop closure detection to recognize previously visited places. A successful loop closure reduces accumulated odometry drift by adding constraints to the pose graph and running graph optimization.

For a UGV, RTAB-Map is not a complete autonomous navigation stack. It provides localization and mapping outputs that can be connected to ROS 2 navigation components, including Nav2. On Leo Rover or Raph Rover, it is typically combined with wheel odometry, an IMU, a depth camera or LiDAR, robot state transforms, and a local obstacle-detection pipeline.

How RTAB-Map works on a mobile robot

RTAB-Map receives synchronized sensor observations and an initial transform estimate from odometry. Each accepted observation can become a node, often called a signature, in a graph. Edges between nodes represent spatial constraints derived from odometry, visual registration, ICP registration, or loop closure detection.

The main processing stages are as follows:

  • Odometry estimation: wheel encoders, visual odometry, LiDAR odometry, or an external estimator provides the transform between consecutive robot poses.
  • Feature and appearance analysis: when visual sensors are used, camera images are processed to create visual words and descriptors for place recognition.
  • Loop closure detection: RTAB-Map compares the current observation against stored locations and validates candidate matches geometrically.
  • Pose graph optimization: accepted constraints are optimized to improve the global trajectory consistency.
  • Map generation: depth images, point clouds, laser scans, or occupancy observations are projected into 2D occupancy grids, 3D point clouds, or octomap-style volumetric representations.

The localization problem can be expressed as finding robot poses X = {x1, ..., xn} that minimize residuals from graph constraints:

X* = arg min Σ(i,j) eij(X)T Ωij eij(X)

Here, eij is the error associated with a spatial constraint between poses i and j, while Ωij is its information matrix. Loop closures add non-sequential constraints that can correct drift accumulated along the route.

RTAB-Map in ROS 2

The ROS 2 package ecosystem exposes RTAB-Map through packages such as rtabmap_ros, rtabmap_slam, rtabmap_odom, and rtabmap_util. Exact executable names and parameters depend on the installed RTAB-Map release and ROS 2 distribution. Leo Rover can be integrated with ROS 2 distributions supported by its software stack, so integration should use the ROS 2 branch and package documentation matching the selected distribution.

A typical ROS 2 transform tree follows REP 105 conventions. The global map frame is normally map, the locally continuous odometry frame is odom, and the robot body frame is base_link. RTAB-Map commonly publishes the map → odom correction, while wheel or visual odometry publishes odom → base_link.

Interface Typical ROS 2 message type Purpose
RGB image sensor_msgs/msg/Image Visual features and place recognition
Depth image sensor_msgs/msg/Image 3D structure and obstacle mapping
Camera calibration sensor_msgs/msg/CameraInfo Projection model and image geometry
Laser scan sensor_msgs/msg/LaserScan 2D mapping and scan matching
Point cloud sensor_msgs/msg/PointCloud2 3D LiDAR or depth-camera mapping
Pose estimate nav_msgs/msg/Odometry Relative motion input

The following launch pattern illustrates a depth-camera configuration. Topic names must match the camera driver and the robot TF tree.

ros2 launch rtabmap_launch rtabmap.launch.py \
  rgb_topic:=/camera/color/image_raw \
  depth_topic:=/camera/depth/image_rect_raw \
  camera_info_topic:=/camera/color/camera_info \
  frame_id:=base_link \
  approx_sync:=true \
  use_sim_time:=false

Sensor integration for Leo Rover and Raph Rover

RTAB-Map requires reliable timestamps, calibrated sensor intrinsics, and valid transforms between sensor frames and base_link. A depth camera should publish aligned or geometrically compatible RGB and depth streams. A 2D LiDAR requires a stable laser frame transform. An IMU can improve the upstream state estimate, but RTAB-Map does not replace a dedicated sensor-fusion filter when wheel odometry is noisy or wheel slip is significant.

On Leo Rover, the default Raspberry Pi compute unit can run basic mapping workloads, but performance depends on image resolution, frame rate, enabled visual features, database size, and point-cloud processing. Lower sensor rates, reduced image resolution, voxel filtering, and limited working-memory settings are common engineering controls. Leo Rover has differential drive and four wheels, so odometry errors are expected on loose terrain, thresholds, and uneven surfaces.

Raph Rover can carry larger sensor payloads and higher-power compute hardware where a project requires multiple cameras, 3D LiDAR, or denser mapping. Its larger payload capacity does not change RTAB-Map’s core requirements: accurate extrinsics, consistent clocks, and a valid ROS 2 TF graph remain essential.

Practical limitations and configuration

RTAB-Map depends on observable environmental structure. Plain walls, repeated corridors, low light, motion blur, dust, rain, and reflective surfaces can reduce visual or depth-based registration quality. LiDAR can improve robustness in low-texture environments, but scan matching can also fail in geometrically repetitive areas.

Before using the generated map for autonomous navigation, validate these conditions:

  • The map, odom, base_link, and sensor frames are connected without conflicting transform publishers.
  • Image, depth, scan, and odometry timestamps use a consistent clock source.
  • Camera intrinsics are provided through CameraInfo and sensor extrinsics are measured or calibrated.
  • Occupancy-grid resolution and inflation parameters are selected separately in the Nav2 costmaps.
  • The map is checked against measured dimensions before it is used for route planning or inspection documentation.

References and ROS conventions

RTAB-Map integration should be verified against the versioned documentation of the installed package. ROS coordinate-frame conventions are defined in REP 105, while standard message definitions are maintained in the ROS 2 interface packages.

See also