SLAM and mapping

Overview

SLAM, simultaneous localisation and mapping, solves two problems that depend on each other. To build a map you need to know where the robot was when it took each measurement. To know where the robot is you need a map. SLAM estimates both together from the robot’s own sensors, with no external positioning.

Most deployed mobile robots use SLAM once, to build a map during commissioning, and then localise against that map in daily operation. Robots that explore unknown places, such as field robots, drones and some legged robots, run SLAM continuously. This hub is for engineers choosing a SLAM system, tuning one, or working out why a map has a double wall or a corridor that bends.

Key ideas

Front end and back end

Cadena and colleagues’ 2016 survey describes modern SLAM as two parts. The front end turns raw data into constraints: it matches each lidar scan to the last one or tracks image features between frames, giving relative motion, and it decides which observations refer to the same landmark or place. The back end takes those constraints and solves for the trajectory and map that fit them best, usually as a pose graph optimised by nonlinear least squares. That is the factor-graph machinery from /topics/state-estimation/, and Grisetti and colleagues’ tutorial walks through it for SLAM.

The split matters in practice because the two halves fail differently. Front ends fail on data: featureless corridors, glass, motion blur, moving people. Back ends fail on wrong constraints: one bad data association can pull the whole map out of shape.

Lidar and visual SLAM

Lidar SLAM matches point clouds directly. Two-dimensional lidar SLAM on a planar floor is mature: slam_toolbox, which the Nav2 bringup launch files use for mapping, builds a pose graph from scan matching. In 3D, LOAM extracts edge and planar points to register scans, and KISS-ICP argues that plain point-to-point ICP, carefully done, is enough for odometry. Lidar gives metric scale and works in the dark. It struggles in long featureless corridors and open fields where every scan looks alike.

Visual SLAM tracks features or pixel intensities across camera frames. It is cheap and gives rich data for place recognition, but a single camera cannot recover metric scale, and lighting changes and fast motion break tracking. Adding an IMU (visual-inertial odometry) fixes scale and gravity direction and bridges short dropouts. ORB-SLAM3 supports monocular, stereo and RGB-D cameras, with or without an IMU, and keeps several maps that it merges when it recognises a place.

Occupancy grids and other maps

An occupancy grid, introduced by Elfes (1989), divides space into cells and stores the probability that each is occupied. Each range reading raises the probability of the cell it hits and lowers it along the ray. Implementations store log-odds so an update is an addition. Grids are what path planners consume, and 3D versions use voxels. Point-cloud maps keep raw geometry for localisation. Sparse feature maps store only landmarks, which is compact and good for relocalisation but useless for planning on its own.

Loop closure and localisation in a known map

Odometry drift accumulates, so a robot that drives round a building and returns to its start will not line up with where it began. Loop closure recognises the revisited place and adds a constraint between the two poses. The back end then spreads the correction along the whole loop. A correct loop closure straightens the map. A false one, between two similar-looking corridors, can fold it, so systems check geometric consistency before accepting one and use robust cost functions in the optimiser.

Once a map exists, localisation is easier than SLAM. Nav2’s AMCL runs a particle filter against an occupancy grid, and slam_toolbox has its own localisation mode. Both follow REP 105: they compute the robot’s pose in map and publish the map to odom correction, so the odom frame stays continuous for local control.

Where to start

/learn/beginner/07-differential-drive/ gives you odometry and shows how it drifts. /learn/beginner/08-grid-path-planning/ plans on the kind of grid SLAM produces. /learn/beginner/06-sensors-and-noise/ explains the noise that makes the problem hard.

Tools and platforms

Common mistakes

• Mapping with bad odometry and expecting the SLAM back end to fix it. Calibrate wheel radius and track width first.
• Leaving the lidar-to-base transform wrong by a degree. Every scan is then rotated and walls thicken.
• Mapping during busy hours. People and pallets become permanent walls.
• Accepting every loop closure. One false match can ruin a map that took an hour to build.
• Running full SLAM in production when localisation in a fixed map would be more predictable.

Going deeper

• C. Cadena, L. Carlone, H. Carrillo, Y. Latif, D. Scaramuzza, J. Neira, I. Reid and J. J. Leonard, Past, present, and future of simultaneous localization and mapping: toward the robust-perception age, IEEE Transactions on Robotics 32(6), 2016.
• G. Grisetti, R. Kümmerle, C. Stachniss and W. Burgard, A tutorial on graph-based SLAM, IEEE Intelligent Transportation Systems Magazine 2(4), 2010.
• J. Zhang and S. Singh, LOAM: lidar odometry and mapping in real-time, Robotics: Science and Systems X, 2014.
• C. Campos, R. Elvira, J. J. Gómez Rodríguez, J. M. M. Montiel and J. D. Tardós, ORB-SLAM3: an accurate open-source library for visual, visual-inertial and multimap SLAM, IEEE Transactions on Robotics 37(6), 2021.
• W. Hess, D. Kohler, H. Rapp and D. Andor, Real-time loop closure in 2D LIDAR SLAM, ICRA 2016. The paper the Cartographer documentation cites for its 2D approach.
• S. Macenski and I. Jambrecic, SLAM Toolbox: SLAM for the dynamic world, Journal of Open Source Software 6(61), 2021.
• Sebastian Thrun, Wolfram Burgard and Dieter Fox, Probabilistic Robotics, MIT Press, 2005.