SLAM Basics for Mobile Robots: How Robots Map and Localize at the Same Time

SLAM basics for mobile robots start with a paradox: a robot needs a map to know where it is, but it needs to know where it is to build a map. Simultaneous Localization and Mapping (SLAM) is the family of algorithms that solves both problems at once, using the robot's own sensor data as it moves through an unknown environment.

This matters for any mobile robot that has to operate somewhere it hasn't been given a map in advance: a vacuum robot in a new house, a warehouse AMR before its site is surveyed, or a drone exploring a building after a disaster. Without SLAM, the robot either needs a pre-built map or a full stop-and-scan calibration step, neither of which scales to real-world deployment.

The Core Problem: Why Mapping and Localization Are Coupled

Imagine a robot with a range sensor (LiDAR, sonar, or a depth camera) and a way to estimate its own motion (wheel encoders, an IMU, or visual odometry). At each timestep it can measure distances to nearby walls and objects, and it can estimate how far it moved since the last step.

The trouble is that both of these measurements are noisy. Wheel encoders drift because of wheel slip. IMUs accumulate drift through double integration of acceleration. If the robot simply trusted its odometry and stitched sensor readings together, small errors would compound over time, and the resulting map would curl and drift away from the true geometry of the room.

SLAM addresses this by treating the robot's pose (its position and orientation) and the map (the set of landmarks or occupied cells) as a single joint estimation problem. Every new sensor reading updates both the map and the belief about where the robot is, and crucially, revisiting a known area lets the algorithm correct accumulated drift in both.

State Representation: What Exactly Is Being Estimated

Most SLAM formulations track a state vector that includes:

• The robot's pose: position (x, y, and sometimes z) plus orientation (heading, or a full 3D rotation).
• A set of landmarks or map features: distinct points, corners, or occupied grid cells that the robot has observed.

As the robot moves, two kinds of updates happen. A motion update predicts the new pose based on control inputs (wheel speeds, IMU readings) and adds uncertainty because motion is never perfectly known. A measurement update corrects that prediction using sensor observations of landmarks, and also refines the estimated position of those landmarks. This predict-correct cycle is the same structure used in a Kalman filter for robot state estimation, and in fact one of the earliest and most widely taught SLAM approaches, EKF-SLAM, is a direct extension of the Extended Kalman Filter to this joint pose-and-map state.

Main Algorithm Families

EKF-SLAM

EKF-SLAM stacks the robot pose and all landmark positions into one large state vector, then runs an Extended Kalman Filter over that vector. Its strength is a rigorous, well-understood uncertainty model: every landmark and the robot pose carry a covariance that shrinks or grows correctly as evidence accumulates. Its weakness is computational cost. The covariance matrix grows quadratically with the number of landmarks, so EKF-SLAM becomes impractical much past a few hundred landmarks.

Particle Filter SLAM (FastSLAM)

FastSLAM represents the robot's possible trajectories as a set of weighted particles, where each particle carries its own independent map estimate. Instead of one Gaussian belief over the whole state, you get many discrete hypotheses about where the robot has been, each with its own consistent map. This handles non-linear motion and non-Gaussian noise better than EKF-SLAM and scales more gracefully to larger maps, at the cost of needing enough particles to cover the space of plausible trajectories. Too few particles and the filter can lose track of the correct trajectory entirely, a failure mode called particle depletion.

Graph-Based SLAM

Graph-based SLAM is the dominant approach in modern systems (including most implementations built on ROS2, which is covered in ROS2 nodes and topics explained). It represents robot poses over time as nodes in a graph, with edges encoding relative motion constraints from odometry and relative position constraints from sensor observations. Instead of filtering step by step, the whole graph is optimized at once (or incrementally) to find the configuration of poses that best satisfies all constraints simultaneously. This is usually solved with non-linear least squares optimization. Graph-based SLAM handles loop closures naturally and scales well because the optimization only needs to touch the parts of the graph affected by a new constraint.

Loop Closure: The Piece That Actually Fixes Drift

Loop closure is the moment a robot recognizes it has returned to a previously visited location, even though its accumulated odometry says otherwise. Detecting a loop closure typically relies on comparing current sensor data (a LiDAR scan or a camera image) against previously stored data, using techniques like scan matching or visual place recognition.

Once a loop closure is detected, it becomes a new constraint in the map: this pose and that earlier pose are actually the same place. Graph-based SLAM propagates that correction backward through the whole trajectory, straightening out the accumulated drift. Without loop closure, SLAM degrades into pure dead-reckoning with occasional local corrections, and long-duration maps will visibly warp.

False loop closures are a real danger. A visually repetitive environment (a warehouse with identical aisles, a featureless corridor) can trick the matching algorithm into believing the robot is somewhere it isn't, and forcing that incorrect constraint into the graph can badly corrupt the map. Robust SLAM implementations include outlier rejection specifically to guard against this.

A Minimal Pseudocode Sketch

state = initial_pose, empty_map
for each timestep:
    control = read_odometry()
    state.pose = predict_motion(state.pose, control)

    scan = read_lidar()
    observed_features = extract_features(scan)
    state = update_with_observations(state, observed_features)

    if loop_closure_detected(scan, state.map):
        constraint = compute_loop_constraint(scan, state.map)
        state = optimize_graph(state, constraint)

Practical Considerations for a Real Robot

• Sensor choice matters more than algorithm choice. A 2D LiDAR gives clean, reliable range data for indoor flat-floor robots. Visual SLAM using a single camera is cheaper but far more sensitive to lighting and texture-poor scenes.
• Compute budget drives the algorithm family. An embedded robot with a limited CPU often can't afford full graph optimization at high frequency, so many systems mix a fast local filter with periodic global graph optimization.
• Map representation is a separate choice from the SLAM algorithm. Occupancy grids are simple and good for 2D navigation. Feature-based sparse maps are more compact and better suited to visual SLAM and loop closure matching.
• SLAM is not free localization once the map is built. Many systems run SLAM once to build a map, then switch to a lighter pure localization mode (like Monte Carlo localization against the fixed map) for day-to-day operation, since re-optimizing the whole map on every run is wasteful once the environment is known.

Conclusion

SLAM basics for mobile robots come down to one core idea: pose and map estimation have to be solved jointly, because each depends on the other. EKF-SLAM offers a clean probabilistic model but scales poorly, particle filters handle non-linearity better, and graph-based SLAM has become the practical standard because it scales to large environments and handles loop closure cleanly. Whichever family you pick, the real-world performance hinges on sensor quality, compute budget, and how robustly the system detects and validates loop closures.