LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

SLAM in Practice

17 min read Robotics & Control Systems
roboticsslammappinglidarcomputer-visionautonomous-vehicles
Contents

SLAM — Simultaneous Localization and Mapping — is the chicken-and-egg problem at the heart of mobile robotics. To build a map, you need to know where you are when you observe each landmark; to know where you are, you need a map to localize against. SLAM solves both problems at once by treating them as a single joint optimization: given a stream of noisy sensor measurements, find both the robot’s trajectory and a consistent map of the environment that together best explain the measurements. The first practical solutions appeared in the late 1990s and were good enough to demonstrate the principle on indoor robots with whisker sensors. Modern SLAM systems run on a Roomba navigating your living room, on the autonomous vehicles mapping city streets, on quadrotors flying through warehouses, and on the AR system on your phone tracking the table in front of you — and the math underneath is essentially the same family in all of them. What changes between applications is the sensor modality, the scale of the map, the speed requirements, and how much accuracy you really need. This post walks the chicken-and-egg structure, the sensor and algorithm choices that decide what a SLAM system is good at, the loop-closure problem that determines whether your map stays consistent over hours, and the honest accuracy reality across the price spectrum from a $300 vacuum to a $300,000 research vehicle.

The Chicken-and-Egg Problem, Formally

The naive way to build a map is to localize yourself first and then drop landmarks at their measured positions relative to known you. The naive way to localize is to compare your sensor readings to a known map. Neither works on its own at the start of a session: there is no map yet, and there is no prior localization. SLAM resolves this by jointly optimizing the trajectory and the map.

Concretely, every SLAM system maintains two things that get updated together as new measurements arrive:

  • A pose estimate — where the robot believes it currently is in some world frame, usually expressed as (x, y, theta) in 2D or (x, y, z, roll, pitch, yaw) in 3D.
  • A map — a representation of the environment, which can be an occupancy grid (2D cells marked free, occupied, or unknown), a point cloud (3D scattered points), a feature map (a list of distinctive landmarks the robot has seen), or some hybrid.

Each new sensor measurement is treated as a constraint that the trajectory and map should be consistent with. The system finds the best joint solution that satisfies all the constraints jointly. The classical formulation casts this as either a probabilistic filtering problem (Bayesian belief over the joint state, propagated forward through time) or a graph optimization problem (a graph where nodes are poses and landmarks, edges are measurements, and you find the configuration that minimizes total error). Both work; modern practice has converged on graph optimization for most applications because it handles loop closure cleanly.

A typical SLAM data flow:

                 sensor measurements          control inputs
                 (lidar / camera / IMU)       (wheel velocities, etc.)
                          │                            │
                          ▼                            ▼
                  ┌──────────────────┐         ┌─────────────────┐
                  │  feature extract │         │   odometry      │
                  │  / preprocessing │         │ (dead reckoning)│
                  └────────┬─────────┘         └────────┬────────┘
                           │                            │
                           ▼                            ▼
                  ┌──────────────────────────────────────────────┐
                  │      data association                        │
                  │  (which measurement matches which landmark?) │
                  └──────────────────────┬───────────────────────┘
                                         │
                                         ▼
                  ┌──────────────────────────────────────────────┐
                  │      pose-graph optimization                 │
                  │   minimize global error across all edges     │
                  └────────────┬─────────────────────────────────┘
                               │
                ┌──────────────┴────────────────┐
                ▼                                ▼
        current pose estimate              consistent map
        (continuously updated)             (updated on revisits)

The interesting parts of any specific SLAM system are: what sensors feed the front end, how features are extracted and associated, what the underlying graph optimizer is, and how loop closures are detected and handled. Everything else is engineering.

Sensor Modalities Decide Everything

The biggest choice in any SLAM system is what sensors it consumes. Each modality has fundamentally different strengths and creates different failure modes downstream.

2D Lidar SLAM. A scanning 2D lidar (RPLidar, Hokuyo, Sick) sweeps a laser horizontally, returning range measurements at hundreds of angles around the robot many times a second. The output is an annulus of distance readings to whatever the laser hit at the robot’s height. SLAM systems like GMapping (an older Rao-Blackwellized particle filter), Cartographer (Google’s graph-based system, currently the de facto production standard), and slam_toolbox (the modern ROS2 default) consume this and produce 2D occupancy grids. 2D lidar SLAM works extremely well indoors and in structured outdoor environments, is computationally light, and is the right tool for the vast majority of indoor wheeled robots — including most Roombas, warehouse AMRs, and hospital delivery robots.

3D Lidar SLAM. A 3D rotating lidar (Velodyne, Ouster, Hesai) returns a full 3D point cloud each rotation, typically 16, 32, 64, or 128 vertical channels at 5-20 Hz. SLAM systems like LOAM (LiDAR Odometry and Mapping) and its descendants LeGO-LOAM and LIO-SAM consume this and produce 3D point cloud maps. 3D lidar SLAM is the workhorse for autonomous vehicles and outdoor mobile robots; it works in environments without flat ground or uniform structure, captures the full vertical geometry, and degrades gracefully when conditions change. The cost has historically been the lidar itself ($5,000-50,000 for an automotive-grade unit), though MEMS and solid-state lidars are pushing prices down.

Visual SLAM (vSLAM). A camera, or a stereo pair, or an RGB-D camera (like the Realsense or Kinect families) feeds a SLAM system that extracts distinctive image features (ORB, SIFT, or learned features), tracks them across frames, and triangulates 3D landmarks from the parallax between observations. ORB-SLAM3 is the current open-source standard and supports monocular, stereo, and RGB-D inputs. Visual SLAM is the cheapest sensor setup, works in environments where lidar struggles (tight indoor spaces, low-feature outdoors with distinctive textures), and is what your phone uses for AR. It is the most sensitive to lighting, motion blur, and texture-less surfaces (a white wall is invisible to ORB), so it almost always benefits from being paired with an IMU.

Visual-inertial SLAM (VI-SLAM). Add an inertial measurement unit (gyro + accelerometer) to a visual SLAM system and you get a much more robust setup. The IMU provides high-rate motion estimates during the brief windows when the camera loses features, and the camera provides the slow-drift correction the IMU needs. Most production VR/AR tracking and modern drone autonomy uses VI-SLAM. The challenge is the calibration between the IMU and the camera, which has to be precise enough that the fusion does not get confused.

Multi-modal SLAM. Modern systems increasingly fuse all three: lidar for geometric ground truth, cameras for semantic feature detection and texture recognition, IMU for high-rate motion. LIO-SAM and its descendants in the autonomous-vehicle world are the typical examples. The fusion is computationally heavier but gives the best accuracy across the broadest set of conditions.

Modality Cost Best environment Failure mode Typical system
2D lidar $100-2k Indoor, structured Long featureless hallways Cartographer, slam_toolbox
3D lidar $1k-50k Outdoor, structured/cluttered Heavy rain, snow LIO-SAM, LeGO-LOAM
Monocular camera $20-500 Textured indoor/outdoor Motion blur, white walls ORB-SLAM3 (mono)
Stereo camera $100-2k Same as mono + better depth Same + calibration drift ORB-SLAM3 (stereo)
RGB-D camera $200-2k Indoor short-range Sunlight (IR-based depth) ORB-SLAM3 (RGB-D), RTAB-Map
VI-SLAM $100-5k AR, drones IMU bias drift ORB-SLAM3 + IMU, OpenVINS
Multi-modal $5k-50k+ Autonomous vehicles Calibration complexity LIO-SAM, vendor stacks

Particle Filters Versus Graph Optimization

The two algorithmic families that have dominated SLAM are filter-based methods (extended Kalman filters and particle filters) and graph optimization methods. The split is conceptually important and the field has moved decisively toward the latter.

Particle filters — particularly the Rao-Blackwellized version that GMapping popularized — represent the robot’s belief about its pose as a population of hypotheses (particles), each with its own estimated trajectory and map. New observations resample the particles to favor the ones that explain the data well. This works and was the dominant approach through the 2000s, but it scales poorly: more particles needed for more environments, computational cost grows with map size, and the particles eventually diverge unless you resample carefully.

Graph optimization treats the SLAM problem as a sparse non-linear least-squares problem. You build a graph where each node is either a robot pose at some moment in time or a landmark (or, in modern systems, a submap). Each edge is a constraint: a measurement that says “the relative pose between node A and node B is approximately this.” The cost of the graph is the sum of squared residuals on all the edges. Finding the maximum-likelihood configuration is then a non-linear least-squares optimization, which has well-developed solvers (Ceres, g2o, GTSAM).

The reasons graph optimization won:

  1. It handles loop closure cleanly. When the robot revisits a previously mapped area, a single new edge in the graph ties the present pose to the past one, and re-optimizing the graph distributes the correction across the entire trajectory. Filter-based methods struggle to do this because they have no representation of past poses to correct.
  2. It scales sub-linearly. The graph is sparse — most node pairs have no measurement edge connecting them — and sparse solvers like Ceres are extremely efficient. Modern systems can re-optimize graphs with hundreds of thousands of poses in real time.
  3. It composes. Submaps (small locally-consistent maps) become nodes in a higher-level graph, enabling truly large-scale SLAM.

The mathematical bridge between the two families is that an extended Kalman filter is essentially a graph optimization that only keeps the most recent state, marginalizing out the past. Throwing away the past makes the algorithm fast and the storage bounded, but it also throws away the ability to correct the past when new information arrives. For any system where loop closure matters — and that is most real systems — graph SLAM is the right framework.

Loop Closure: The Most Important Thing

The single biggest determinant of long-term SLAM accuracy is loop closure — the ability to recognize that you have returned to a previously visited place and use that recognition to correct accumulated drift in your trajectory.

Without loop closure, every SLAM system drifts. Pure odometry (wheel encoders, visual odometry, lidar odometry) integrates incremental position changes; any error in those increments accumulates over time. After an hour of driving, the position estimate may be off by meters or tens of meters. The map drawn on top of that estimate inherits the same drift, so a corridor that the robot drove twice may show up as two parallel corridors slightly offset from each other in the map.

Loop closure detects “I have been here before” and adds a constraint to the graph that pins the present pose to the past one. The re-optimization then redistributes the error across the entire trajectory — the corridor snaps to a single line, the map becomes consistent, and future localization restarts with much smaller error.

The challenge is detecting loop closure reliably. The robot needs to know that the place it sees right now is the same as somewhere it has been before, without being fooled by a similar-looking other place (a false positive that would yank the map into a wrong configuration) or missing the match (a false negative that wastes the correction opportunity). Practical approaches:

  • Place recognition by appearance. Compute a compact descriptor (bag of visual words, learned embeddings) for each location the robot has visited and look for similar descriptors when revisiting. This is the standard visual SLAM approach.
  • Scan matching. Try to align the current lidar scan against past scans in nearby places (based on the current pose estimate); a good alignment indicates a loop closure. This is Cartographer’s approach for 2D lidar.
  • Place recognition with verification. Use a fast appearance check to find candidate matches, then do a geometric verification (do the 3D positions of features actually align?) to filter out false positives. Most production systems do something like this.

When loop closure fires, the graph optimization redistributes the correction across all the poses since the last loop. The visual effect on a map is dramatic: a previously twisted trajectory suddenly snaps to a clean rectangle, the map’s contours align with reality, and your localization confidence jumps back to high. Watching this happen on a SLAM visualization is one of the most satisfying things in robotics.

The honest weakness: in environments without distinctive features (long uniform corridors, open warehouses with identical aisles, repeated geometry like office buildings) loop closure is unreliable and SLAM systems degrade noticeably. This is why fiducial markers, RFID tags, or other infrastructure aids are still common in production logistics deployments — they give the SLAM system unambiguous anchors that purely geometric loop closure cannot.

How a Roomba and an Autonomous Vehicle Share the Same Math

The same SLAM machinery scales from a $300 Roomba to a $300,000 research autonomous vehicle. What changes is the sensor stack, the compute budget, the map representation, and the accuracy required.

A modern Roomba runs visual SLAM with a single monocular camera looking up at the ceiling, optionally augmented by wheel odometry and IMU. The map is a 2D occupancy grid covering one floor of a typical house — maybe 100 square meters and a few thousand cells. The compute is whatever ARM SoC fits in the price point, the loop runs at maybe 10 Hz, and the accuracy target is “centimeters good enough to not bash into furniture.” Loop closure detects that the robot has returned to the dock or to a known reference point.

A research autonomous vehicle runs a multi-modal SLAM with 3D lidar (often two or three), several cameras, GPS-INS (a fused inertial system tied to GPS for outdoor ground truth, the same kind of precise time and position the GPS infrastructure delivers), and wheel speed. The map is a 3D point cloud covering an entire city, gigabytes in size. The compute is GPUs plus dedicated SoCs, the loop runs at 100+ Hz, and the accuracy target is “centimeters relative to high-definition maps that were surveyed offline.” Loop closure detects that the vehicle has driven the same intersection before — but in practice, autonomous vehicles often rely on localization against a prior HD map rather than building the map online, which is technically a degenerate SLAM (mapping is solved offline; only localization runs at vehicle speed).

The same underlying math:

  • A graph of poses connected by relative-motion edges from odometry.
  • Landmark or scan-match constraints from the current sensor data.
  • Loop closures (or HD-map matches) that pin global pose to global truth.
  • A non-linear least-squares solver (Ceres or GTSAM) that maintains a consistent solution.

The art is in tuning the sensor weights, the loop closure detection, the optimization tolerances, and the map representation for the specific application. The reason the Roomba and the autonomous vehicle look so different is application engineering, not algorithmic difference.

The Honest Accuracy Reality

A practical guide to what real SLAM systems deliver in 2026:

  • Indoor robots with 2D lidar and Cartographer-class SLAM: 5–20 cm position accuracy, drift of ~0.5% of distance traveled before loop closure, consistently in normal indoor environments.
  • Roombas and similar consumer vacuums with visual SLAM: 20–50 cm position accuracy, occasional getting-lost events on uniform carpets or in dim rooms, gradually improving with each pass.
  • AR/VR systems with VI-SLAM (Quest, Vision Pro, ARKit, ARCore): sub-centimeter tracking accuracy in feature-rich environments, jittery degradation on uniform surfaces.
  • Drones with VI-SLAM: 10-30 cm accuracy in well-lit environments with visible features, often supplemented by GPS outdoors.
  • Outdoor robots with 3D lidar SLAM: 5-50 cm accuracy depending on environment, larger drift on long featureless sections (e.g., highways without landmarks).
  • Autonomous vehicles with HD-map-based localization: 5-10 cm accuracy when matched against a recent HD map.

The drift before loop closure is the single most useful number to know about any given SLAM system. A robot that drifts at 1% of distance traveled, never closes a loop, and operates over 1 km will have an accumulated error of about 10 m at the end. The same robot in an environment with frequent loop closures (a small floor it traverses repeatedly) will hold itself to 10-50 cm error indefinitely. The application defines whether this is acceptable.

The math behind SLAM is genuinely beautiful in the way that the iterative least-squares optimization in inverse kinematics is beautiful: a hard nonlinear problem reduces to a sparse linear-algebra problem that fast solvers handle, and the result is geometric reasoning the robot can act on. Understanding the SLAM stack on a real robot, with ROS2 plumbing connecting the nodes and PID-style controllers driving the motors underneath, is one of the most rewarding pieces of robotics to learn — because it is the layer where the robot stops being a remote-controlled toy and starts being something that understands the world around it.

Choosing a SLAM Stack

A practical decision framework if you are building something:

  • 2D indoor mobile robot: slam_toolbox or Cartographer running on a 2D lidar. ROS2-native, mature, fast enough on a Raspberry Pi 4 or 5.
  • 3D outdoor mobile robot: LIO-SAM or FAST-LIO2 running on a Velodyne, Ouster, or Hesai lidar plus IMU. Substantial compute requirement (small NUC class at minimum).
  • Drone or AR application: ORB-SLAM3 for offline study, vendor SDK for production. VI-SLAM is the standard.
  • Wheeled hobby robot with camera only: RTAB-Map is the most beginner-friendly visual SLAM in ROS2 and produces useful maps with a Realsense or a stereo pair.
  • Autonomous vehicle research: SLAM is one piece of a much larger stack (perception, prediction, planning, control). Look at Apollo, Autoware, or the academic stacks from CMU, MIT, and Stanford as starting points.

For all of these, the development environment is almost universally Ubuntu plus ROS2 in 2026, the simulation environment is Gazebo Sim, and the production deployment is whatever the application requires. Building a SLAM stack from scratch is rarely the right move; consuming a tuned library and learning where its assumptions break is the working-engineer path.

Verdict

SLAM is the chicken-and-egg problem at the heart of mobile robotics, solved by treating localization and mapping as a single joint optimization over a stream of noisy sensor measurements. The sensor choice — 2D lidar, 3D lidar, monocular or stereo or RGB-D camera, possibly with IMU — decides what environments and conditions the system can handle and is the most consequential design decision before any code is written. The algorithmic family has converged decisively on graph optimization over the older particle-filter and EKF approaches because graphs handle loop closure cleanly, scale sub-linearly with map size, and compose into submap-based representations that work at city scale. Loop closure is the single most important thing about long-term SLAM accuracy because without it every system drifts; with it, accumulated error can be redistributed across the entire trajectory whenever the robot recognizes a place it has been before. The same underlying math powers a Roomba mapping a living room and an autonomous vehicle navigating a city, with the application engineering decisions (sensor stack, compute budget, map representation, accuracy target) dwarfing the algorithmic differences. The honest accuracy reality is good enough for the use cases the technology has actually been deployed for — centimeters in well-conditioned environments, decimeters in challenging ones, occasional drift that loop closure fixes when geometry permits and that infrastructure aids fix when it does not. For someone building a robot in 2026, the right path is to use one of the mature production stacks (slam_toolbox, Cartographer, LIO-SAM, ORB-SLAM3, RTAB-Map) on top of ROS2, learn what each one assumes about the world, and treat the algorithmic details as engineering you tune rather than science you re-derive. The math is beautiful, the libraries are good, and the field is mature enough that mobile autonomy is now a capability you assemble rather than one you invent from scratch.

Sources

Comments