RTAB-Map: graph-based SLAM for ROS 2, standalone C++ and mobile

What RTAB-Map solves, and who is actually supposed to use it

The problem is loop closure in a trajectory that returns to places it has already seen. Odometry drifts, and a map built only from odometry folds back on itself. RTAB-Map is built around appearance-based place recognition: it compares incoming sensor data against a memory of past observations to decide when the robot has revisited a location, then corrects the whole trajectory. That is the mechanism the project is named for, and it is the reason the repository carries topics like localization, mapping and slam rather than only mapping.

The audience is narrower than the topic list suggests. This is a C++ library first. The repository layout shows corelib/ for the library, guilib/ for the graphical application, app/ for the standalone tool, and separate examples/ directories for BOWMapping, LidarMapping, RGBDMapping, WifiMapping and NoEventsExample. Someone who wants a Python-first SLAM stack or a single pip install is not the target reader. Someone building a robot with a depth camera, a stereo pair or a LiDAR, who can compile C++ or consume a ROS package, is.

The presence of android and ios topics, plus an Android build workflow in the CI table, says the project also targets phone and tablet capture. That is unusual for a SLAM library and it changes who can use it: a field surveyor with a phone is a plausible user, not just a robotics engineer with a workstation.

How the memory and loop-closure mechanism is structured

The architecture visible from the repository is a library plus several front ends. corelib/ holds the SLAM implementation, guilib/ holds the Qt-based application, and app/ holds the standalone entry point. The examples/ tree is the clearest signal of the supported input modes: RGBDMapping for depth cameras, LidarMapping for laser scans, BOWMapping for bag-of-words style appearance matching, WifiMapping for radio signal input, and NoEventsExample for a configuration without event handling. Each example is a small program rather than a tutorial chapter, so the repository expects you to read code to understand data flow.

The data flow implied by that structure is: sensor input enters through a front end, features or signatures are extracted and matched against a stored memory to propose loop closures, and a graph of poses is optimized with those constraints. The parameters that govern this are not in the README. The README points to the API documentation at introlab.github.io/rtabmap/api/latest/, which it says lists all parameters and all command-line tools. That is the honest place to look, and it also means the repository root tells you almost nothing about tuning.

A consequence worth stating plainly: because the tuning surface lives in generated API documentation, the quality of your results depends on how carefully you read that parameter list. There is no defaults file in the repository root that a reviewer can inspect, and the README does not summarize which parameters matter most.

Installing RTAB-Map and running a first mapping session

The README does not give install steps. It says installation instructions and examples are on the wiki at github.com/introlab/rtabmap/wiki, and it lists ROS binary package names. For ROS users the package is named ros-$ROS_DISTRO-rtabmap, so the distribution is substituted at install time. The README's binary table covers ROS 1 Noetic and ROS 2 Humble, Jazzy, Kilted, Lyrical and Rolling, with separate build jobs for each, which tells you the maintainers test those combinations specifically.

On a ROS 2 system, the install is an ordinary apt call against the ROS repositories. Replace the distribution with your own:

sudo apt install ros-$ROS_DISTRO-rtabmap

After that, the ROS wiki page linked from the README (wiki.ros.org/rtabmap) is where the node-level usage is described, not the repository README. Expect to need a launch configuration rather than a single command, because RTAB-Map consumes sensor topics and publishes a map and a pose estimate.

If you are not on ROS, the README points to the wiki for building from source, and the repository carries a top-level CMakeLists.txt, a vcpkg.json manifest, a docker/ directory and a Dev Container configuration. The Docker image published by the project is introlab3it/rtabmap on Docker Hub, which the README lists alongside the ROS binaries. A container run is the shortest path to the graphical application without resolving C++ dependencies yourself:

docker pull introlab3it/rtabmap

The repository also ships bundle_windows_deps.bat and bundle_windows_deps_cuda.bat at the top level, which indicates Windows packaging is handled by scripts rather than by a documented installer. What you should see after a successful install is the standalone application from app/ and the GUI from guilib/, plus the library headers for linking. The README does not document what a first run looks like, so treat the wiki as required reading rather than optional.

Where RTAB-Map is the wrong choice

The clearest limitation is documentation placement. The repository README is a set of links: home page, wiki, API documentation, ROS wiki. If your evaluation process is to read a README and decide, you will not get a decision out of this one. The parameter list and the command-line tools are in generated API docs, and the install steps are on a wiki, which means the repository itself is not self-describing. That is a real cost for anyone doing a dependency review or an offline build.

Second, the licence field is NOASSERTION in the repository metadata even though the README badge says BSD and links to a LICENSE file. Those two things disagree at the metadata level. If your organisation gates on machine-readable licence detection, this repository will require a manual check of the LICENSE file rather than an automated pass. That is a process cost, not a legal conclusion, and it is worth resolving before you vendor the code.

Third, the ROS binary coverage is uneven. ROS 1 support in the README table is Noetic only, on Ubuntu Focal arm64. If you are pinned to an older ROS 1 distribution, the binary path is closed and you are building from source. The ROS 2 table is broader but still tied to specific Ubuntu releases per distribution, so a mismatch between your OS and the listed build target puts you back on source builds.

Finally, RTAB-Map is a general SLAM system with a large parameter surface. If your environment is a clean, single-floor indoor space where a simpler scan-matching approach already holds, the appearance-based loop closure machinery is extra configuration you will pay for in tuning time without a corresponding gain.

Alternatives and how their approach differs

The most common comparison is against ORB-SLAM3. The difference in approach is the sensor model and the map representation. ORB-SLAM3 is built around visual feature tracking with visual-inertial fusion and is oriented toward camera rigs. RTAB-Map is built around a pose graph with appearance-based loop closure and accepts multiple input modalities, which is why the repository has separate RGBDMapping, LidarMapping and even WifiMapping examples. If your sensor is a camera rig and you want visual-inertial odometry as the core, ORB-SLAM3 is the closer fit. If you have a depth camera, a LiDAR, or a mixture, RTAB-Map's input surface is wider.

Against slam_toolbox, the split is 2D versus 3D and online versus graph-based. slam_toolbox is a ROS 2 package aimed at 2D laser scan mapping with a lighter footprint. RTAB-Map handles 3D maps and carries the appearance-based loop closure machinery. For a planar robot with a single 2D LiDAR, slam_toolbox is the smaller tool for the job. For a 3D reconstruction task, it is not.

Against Cartographer, the difference is integration model. Cartographer is a Google project designed around submaps and scan matching with its own ROS integration. RTAB-Map is a standalone C++ library that also happens to ship ROS packages, which matters if you want to link the SLAM core into a non-ROS application. The repository's examples/ directory, which builds small programs against the library directly, is the evidence for that use case.

Octomap is not really a competitor despite appearing in the same search results. Octomap is an occupancy mapping representation. RTAB-Map produces a trajectory and a map; if you want a volumetric occupancy grid, the two are complementary rather than alternatives, and the question of which to use is a question about outputs, not about SLAM.

Maintenance, releases and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-09-22. The most recent release listed is 0.23.8 from 2026-07-05, following 0.23.1 in 2025-10-13 and 0.22.1 in 2025-07-13. That is a release cadence measured in months, not weeks, with patch releases inside a minor line rather than a constant stream of tags. For a SLAM library consumed as a dependency, that is a reasonable rhythm: you are not chasing a moving target every sprint, and you are also not waiting years for fixes.

The upgrade cost is dominated by the parameter surface, not by the API. Because parameters are documented in generated API documentation and the README does not carry a changelog, a version bump means diffing the parameter documentation between versions rather than reading release notes in the repository. The README does not document rollback, and the repository shows no migration guide. If you pin a version, pin it deliberately and keep a record of the parameter values you tuned against, because the repository will not reconstruct them for you.

On licence: the README badge identifies the project as BSD and links to the LICENSE file at the repository root, while the repository metadata reports NOASSERTION. The README does not spell out which BSD variant applies, so read the LICENSE file itself. This is not legal advice; it is a note that the machine-readable and human-readable signals differ and one of them is authoritative.

Editorial conclusion

Adopt RTAB-Map if you already run ROS 2 (Humble, Jazzy, Kilted, Lyrical or Rolling all have binary builds) or need a C++ SLAM library you can link against without a middleware stack, and if appearance-based loop closure over a revisiting trajectory is the behaviour you want. Do not adopt it if you need a single self-contained README to get running, if you want a pure LiDAR-only pipeline without tuning, or if you are on a ROS 1 distribution other than Noetic, which is the only ROS 1 binary listed. Verify first that a binary exists for your exact distribution and architecture, then run the database viewer on a recorded session before you commit to a parameter set, because the parameter list lives in the API documentation rather than in the repository root.

Frequently asked questions

Official sources

1. introlab/rtabmap on GitHub
2. Issues
3. Project website
4. README
5. Releases