Robot Localization & Mapping: Filters, Fusion, SLAM

Robot Localization and Mapping

A robot cannot navigate, avoid obstacles, or return to its dock without knowing where it is. No single sensor answers that reliably. Wheel odometry drifts as wheels slip; cameras fail in darkness and on blank walls; lidar is confused by glass and long corridors; GNSS is unavailable indoors and degraded near buildings; IMUs drift within seconds. Localization combines these imperfect sources into a best estimate with an honest measure of uncertainty.

Often the robot also lacks a map, or the map is out of date. Simultaneous localization and mapping (SLAM) builds a map while estimating the robot's position in it — a chicken-and-egg problem solved by probabilistic estimation and by recognizing previously visited places. This page covers the building blocks and the practical failure modes engineers deal with in deployments.

TL;DR

Odometry (wheel, visual, inertial, lidar) estimates relative motion and drifts without bound.
Estimation is probabilistic: Kalman filters and EKF/UKF for Gaussian uncertainty, particle filters for multimodal cases such as global localization.
Fuse sensors with complementary errors, using correct timestamps, frames, and noise models.
Use the map → odom → base_link frame convention: smooth local motion plus occasional global corrections.
SLAM builds a map while localizing; pose graph optimization with loop closure removes accumulated drift.
Choose map representations for the task, plan for failure modes, and evaluate with ground truth and drift metrics.

Quick Example

A minimal Kalman filter fusing a motion model with occasional position fixes:

The filter recovers the velocity it was never told and reports how uncertain its position is — the same structure, extended to 3D poses and many sensors, runs inside production localization stacks.

Core Concepts

Odometry and Drift

All odometry estimates relative motion; errors accumulate. Combining sources with different failure modes — visual-inertial or wheel-inertial odometry — reduces drift but never eliminates it. Wheel odometry depends on kinematic models; see Robot Kinematics and Dynamics.

Probabilistic Estimation

Every filter needs noise models: overconfident covariances make the filter ignore good measurements; underconfident ones make it jittery. Gate outliers with innovation checks so one bad measurement cannot drag the estimate away. The math rests on Bayes' rule and Gaussian distributions; see Probability and Linear Algebra for Computing.

Frames: map, odom, base_link

ROS's REP 105 convention separates two estimates: odom → base_link is continuous and smooth but drifts (good for control), and map → odom holds global corrections from localization, which may jump. Controllers use the smooth frame; planners use the global one. Consistent frames and timestamps matter as much as algorithms — fusing measurements with wrong time offsets or extrinsics corrupts estimates. See Sensor Calibration and Time Synchronization.

SLAM

SLAM estimates the robot's trajectory and a map together:

Front end: extract features or scans, match them over time (odometry), and detect loop closures — recognizing a previously visited place.
Back end: build a pose graph whose nodes are robot poses and whose edges are relative measurements, then optimize it so all constraints agree; loop closures pull accumulated drift back.

Common systems include Cartographer and slam_toolbox for 2D lidar, ORB-SLAM3 for visual and visual-inertial SLAM, and lidar-inertial systems for 3D mapping. Wrong loop closures are catastrophic — they bend the whole map — so robust back ends reject inconsistent constraints.

Map Representations

Maps go stale: furniture moves, pallets come and go. Plan for map updates and localization that tolerates change.

Outdoor Positioning

GNSS gives global position with meter-level accuracy; RTK corrections reach centimeters in open sky. Near buildings and trees, multipath and outages are common, so fuse GNSS with odometry and IMU, and track solution quality rather than trusting every fix.

Failure Modes

A localization system should report its confidence, and the robot should slow down, stop, or ask for help when confidence drops. See Robot Safety and Fleet Operations.

Evaluating Localization

Record datasets with ground truth (motion capture, surveyed markers, RTK) and measure absolute trajectory error (ATE) for global accuracy and relative pose error (RPE) for drift over distance. Track localization failures per hour and recovery time in field operations, and re-run evaluations on recorded data whenever algorithms, parameters, or calibration change.

Best Practices

Fuse Sensors With Different Failure Modes

Combine odometry, inertial, visual or lidar, and global sources so no single failure blinds the robot.

Get Frames, Timestamps, and Noise Right First

Most localization bugs are wrong transforms, time offsets, or covariances — not wrong algorithms.

Monitor Confidence and Act on It

Expose covariance and match quality, and trigger slowdowns or relocalization when confidence drops.

Evaluate on Recorded Data

Keep regression datasets from real deployments and measure drift and failures before releasing changes.

Common Mistakes

Trusting Wheel Odometry Alone

Overconfident Covariances

Accepting Every Loop Closure

FAQ

What is the difference between localization and SLAM?

Localization estimates the robot's pose in a known map. SLAM builds the map while simultaneously estimating the pose, typically when no reliable map exists.

Why does odometry drift?

Odometry integrates relative motion measurements, so small errors from slip, noise, and bias accumulate over time without any absolute reference to correct them.

What is a Kalman filter?

An algorithm that estimates a system's state by combining predictions from a motion model with noisy measurements, weighting each by its uncertainty. Extended and unscented variants handle nonlinear models.

What is loop closure?

Recognizing that the robot has returned to a previously visited place and adding that constraint to the map, which corrects drift accumulated along the way.

How do I know if localization is good enough?

Measure trajectory error against ground truth on recorded datasets, monitor confidence and failure rates in the field, and verify that downstream tasks — docking, path following, picking — succeed reliably.