SLAM, Mapping, Localization, and Odometry Drift

A mobile robot needs two related answers: what does the environment look like, and where is the robot inside it? Simultaneous localization and mapping (SLAM) estimates both while the robot explores. Once a stable map exists, a localization system can estimate pose against that fixed map without rebuilding it.

SLAM is not a replacement for odometry. It uses local motion estimates to connect sensor observations, then corrects their accumulated drift when the environment provides enough evidence.

Separate the four jobs

The terms are easier when each has a clear output:

• Odometry: smooth local motion from wheel encoders, inertial sensing, visual motion, or their fusion. It drifts over time.
• Mapping: build a representation such as an occupancy grid from sensor observations and poses.
• Localization: estimate robot pose in an existing map.
• SLAM: build the map while estimating poses and revising past estimates.

Navigation adds planning and control on top. A good map does not generate a safe velocity command by itself.

Follow the information through the system

For two-dimensional indoor SLAM, a common data flow is:

1. Wheel encoders and an inertial measurement unit estimate local motion.
2. A lidar publishes range scans with timestamps and a sensor frame.
3. TF2 relates the sensor to base_link and local pose to odom.
4. Scan matching aligns new observations with recent scans or the growing map.
5. The backend optimizes a graph of poses and constraints.
6. An occupancy grid is updated from the corrected poses and range data.

Odometry supplies a useful initial guess. Without it, scan matching may search a much larger space or align to the wrong repeated structure. Without external observations, odometry errors remain unbounded.

Understand scan matching and loop closure

Scan matching finds a relative pose that best aligns current range measurements with existing structure. It can correct small wheel slip and scale error, but it needs geometric features. A long featureless corridor, glass wall, moving crowd, or highly repetitive shelving can make several poses look alike.

A loop closure occurs when the system recognizes a previously visited place and adds a constraint between the current pose and an older pose. Optimizing that constraint can distribute accumulated error across the trajectory and make walls line up again.

A loop closure is not automatically correct. A false match in two similar corridors can fold or tear the map. Robust systems use geometric checks, scores, and configurable acceptance thresholds. Review suspicious large corrections rather than celebrating every closed loop.

Prepare the robot before tuning SLAM

SLAM cannot compensate for a broken input contract. Verify these first:

• encoder direction, scale, and timestamps;
• reasonable local odometry during straight and rotating tests;
• correct odom → base_link → sensor transforms;
• range data in correct units with invalid readings identified;
• clock agreement across nodes;
• a rigid sensor mount;
• enough range and field of view for the environment.

Drive slowly while establishing the baseline. Motion distortion and sparse scans become harder as rotational speed increases. If the sensor or driver supports timing compensation, configure it from measured behavior rather than assuming it is unnecessary.

Build a map deliberately

Start in a feature-rich location and move through loops instead of only long out-and-back paths. Rotate smoothly so the scanner observes the same structures from overlapping viewpoints. Avoid carrying or moving large objects beside the robot during mapping.

Monitor the live map for doubled walls, smeared corners, jumps, and disconnected rooms. These are evidence, not cosmetic problems:

• doubled parallel walls suggest pose or timing error;
• curved walls during rotation suggest bad transforms or motion distortion;
• gradual scale drift suggests wheel calibration or weak scan constraints;
• sudden global rearrangement suggests loop closure, correct or false.

Save the map only after checking that important corridors remain traversable at the chosen resolution. A finer grid costs memory and can preserve sensor noise; a coarse grid can close narrow passages.

Localize in the saved map

After mapping, switch to localization mode against the saved map. A particle-filter localizer such as Adaptive Monte Carlo Localization (AMCL) estimates pose from range observations and motion. It still needs a reasonable sensor model, transforms, and odometry.

Give an initial pose close enough for the system to identify the correct location, especially in symmetric environments. Test recovery by starting with small pose errors, then larger ones. “Kidnapped robot” recovery is a separate requirement, not something to assume because normal tracking works.

In the standard frame model, local odometry publishes odom → base_link, while SLAM or localization publishes map → odom. The global transform corrects drift without forcing the locally smooth control frame to jump.

Measure accuracy and repeatability

Use physical landmarks with surveyed or carefully measured positions. Record the estimated pose when the robot stops at each landmark from different approach directions. Separate:

• repeatability at the same location;
• short-term local drift;
• global map consistency after a loop;
• recovery time after temporary sensor loss.

Compare the map with known distances, but do not judge only by a visually pleasing image. Navigation needs correct free space, obstacle boundaries, and pose stability more than pretty wall thickness.

Log scans, odometry, transforms, and SLAM outputs so a failure can be replayed. A live-only problem is far harder to diagnose.

Diagnose common SLAM failures

• Walls double while driving straight: odometry scale, sensor time, or scan matching is inconsistent.
• The map bends during rotation: sensor transform, angular odometry, or motion distortion is wrong.
• Pose jumps in repeated corridors: scan matching or loop closure accepted an ambiguous alignment.
• No loop closes: route lacks overlap, observations are too sparse, or acceptance thresholds are too strict.
• Localization works only near the initial pose: the environment is symmetric or global recovery is not configured.
• The map looks correct but navigation clips walls: footprint, inflation, or costmap configuration is wrong.
• Tuning every SLAM parameter changes nothing: the upstream odometry/TF/sensor contract is still broken.

Begin with quadrature encoder calibration and differential-drive odometry, then use ROS 2 TF2 coordinate frames to verify the geometric chain. The Sensor Simulator shows why bias and drift cannot be removed by simple smoothing alone.