Open-Source SLAM Frameworks: ORB-SLAM, Cartographer, RTAB-Map, and Others

Open-source Simultaneous Localization and Mapping frameworks have become the primary substrate for robotics and autonomous systems research, offering peer-reviewed algorithmic implementations that commercial deployments can adopt, audit, and extend. This page covers the four most widely deployed open-source SLAM systems — ORB-SLAM3, Google Cartographer, RTAB-Map, and OpenVSLAM — along with the technical distinctions that determine which framework suits a given sensor configuration and deployment context. Understanding these boundaries is foundational to any serious SLAM architecture design decision.

Definition and scope

Open-source SLAM frameworks are publicly licensed software libraries that implement the full SLAM pipeline: sensor ingestion, feature extraction or scan matching, pose graph construction, loop closure detection, and map output. Unlike proprietary stacks, these systems expose their source code under licenses such as GPLv3 (ORB-SLAM3), Apache 2.0 (Google Cartographer), and BSD (RTAB-Map), allowing independent verification of algorithmic behavior.

The four frameworks addressed here span the dominant sensing modalities in modern robotics:

Each system has been benchmarked against public datasets maintained by the Technical University of Munich (TUM), the European Robotics League (ERL), and the Karlsruhe Institute of Technology (KITTI) benchmark suite (KITTI Vision Benchmark Suite). Performance figures cited in academic literature consistently use these standardized trajectories, making cross-framework comparison tractable. For a broader view of how algorithm families differ structurally, the SLAM algorithm types compared reference covers filter-based, graph-based, and direct method approaches.

How it works

Each framework executes the SLAM pipeline through discrete phases, though internal implementations differ substantially.

ORB-SLAM3 (published by Campos et al., 2021, IEEE Transactions on Robotics) operates through three parallel threads:

  1. Tracking — extracts ORB (Oriented FAST and Rotated BRIEF) features from each incoming frame and estimates camera pose via PnP (Perspective-n-Point) solvers against the local map
  2. Local mapping — creates and refines keyframes, triangulates new 3D map points, and applies local bundle adjustment
  3. Loop closing and full BA — detects revisited places via DBoW2 bag-of-words descriptors and triggers pose graph optimization or full bundle adjustment to correct accumulated drift

ORB-SLAM3 achieves keyframe-based map reuse, meaning a previously built map can be loaded and localization performed without rebuilding — a property formalized as "map merging" in the 2021 paper.

Google Cartographer (Cartographer documentation, Google) structures its pipeline as:

  1. Local SLAM — accumulates LiDAR scans into submaps using scan-to-submap matching (Ceres solver-based nonlinear least squares)
  2. Global SLAM — detects loop closures by matching finished submaps against all prior submaps and runs Sparse Pose Adjustment (SPA) on the resulting pose graph

Cartographer supports both 2D occupancy grid maps and 3D point cloud submaps and was designed for real-time operation on robotic hardware with constrained CPUs, a property relevant to real-time SLAM architecture requirements.

RTAB-Map (Real-Time Appearance-Based Mapping) introduces a memory manager that partitions the map graph into Working Memory (WM) and Long-Term Memory (LTM). Nodes exceeding a configurable retrieval threshold migrate to LTM and are recalled only when a matching visual or geometric signature is detected. This design allows RTAB-Map to sustain mapping sessions exceeding 10,000 keyframes without unbounded RAM growth — a documented property in Labbé and Michaud's 2019 publication in the Journal of Field Robotics.

OpenVSLAM mirrors ORB-SLAM2's thread architecture but replaces the map database with an SQLite-backed binary format, enabling persistent map storage and retrieval independent of the process lifecycle.

The loop closure in SLAM architecture page details the pose graph optimization mechanics shared across these systems.

Common scenarios

Framework selection follows sensor configuration and operational duration:

Scenario Recommended Framework Primary Reason
Indoor mobile robot, 2D LiDAR Cartographer Submap-based 2D occupancy, ROS-native
Indoor drone, RGB-D camera RTAB-Map Memory-managed long sessions, multi-modal
Outdoor autonomous vehicle, 3D LiDAR Cartographer (3D mode) Proven on KITTI sequences
Handheld monocular camera ORB-SLAM3 Scale-ambiguity handling, map reuse
Wide-angle or fisheye robotics OpenVSLAM Native equirectangular/fisheye model support

RTAB-Map sees heavy use in SLAM architecture for indoor navigation deployments where session length exceeds the working memory of simpler graph backends. Cartographer dominates LiDAR-based SLAM architecture workflows integrated with the Robot Operating System (ROS), as Google contributed official ROS wrappers maintained under the ROS-Industrial consortium.

For visual SLAM architecture deployments on autonomous vehicles, ORB-SLAM3's stereo-inertial mode on KITTI sequences achieves median translational errors below 1% on standard benchmark trajectories, as reported in the 2021 IEEE Transactions on Robotics paper.

Decision boundaries

Selecting among these frameworks requires matching 4 primary constraints to framework capabilities:

  1. Sensor modality — ORB-SLAM3 and OpenVSLAM require a camera; Cartographer requires a LiDAR; RTAB-Map accepts RGB-D, stereo, monocular, or LiDAR and is the only framework supporting all four natively.
  2. Map session duration — Sessions beyond 5,000 keyframes favor RTAB-Map's LTM architecture over ORB-SLAM3's unbounded in-memory map.
  3. Licensing constraint — ORB-SLAM3's GPLv3 license requires derived works to remain open source; Cartographer's Apache 2.0 and RTAB-Map's BSD license impose no such restriction on integration into proprietary products.
  4. ROS dependency — Cartographer's primary distribution assumes ROS; ORB-SLAM3 and OpenVSLAM compile independently of ROS, though ROS wrappers exist for all four systems. Integration patterns are covered in SLAM architecture ROS integration.

A secondary axis is computational budget. Cartographer's Ceres-based scan matching runs on single-core CPUs at 10 Hz LiDAR rates. ORB-SLAM3's full bundle adjustment is GPU-agnostic but benefits from multi-core parallelism. RTAB-Map's memory manager trades I/O latency for RAM efficiency, making it suitable for SLAM architecture edge computing platforms with limited memory but adequate flash storage.

For deployments requiring evaluation against standardized benchmarks, the SLAM architecture evaluation and testing reference covers TUM RGB-D, KITTI, and EuRoC MAV benchmark methodology. Researchers assessing institutional contributions to these frameworks can consult SLAM architecture research institutions in the US for university-affiliated groups maintaining active forks.

References