Skip to the lesson
FixTheRobot Explore Robotics / Localization & SLAM / M7 SLAM with ROS 2 / M7-T5

Localization & SLAM · Theory · M7

M7-T5 — Mapping vs Localization Mode

Mapping asks “what is the world?”; localization asks only “where am I in it?”. Using the wrong one, or the right one with the wrong start pose, looks like a broken SLAM.

  • Lesson 5 of 8
  • Module 7: SLAM with ROS 2
  • Theory
  • About 9 minutes to read

Most robots map once and then work for months in the same building. After the map exists the question changes from building the map to finding the robot in it. ROS 2 offers several ways to answer that: SLAM Toolbox in localization mode on a serialised pose graph, AMCL on a saved occupancy grid, or continued mapping that keeps updating. This lesson compares them and covers the step that most often fails: telling the localiser where to start.

Learning objectives

After this lesson, you should be able to:

  • Distinguish mapping, localization and lifelong operation and what each assumes about the map.
  • Describe SLAM Toolbox localization mode and AMCL with a saved map, and what each needs as input.
  • Explain why the initial pose matters and how to provide it, including global localization.
  • Recognise failures: wrong start pose, kidnapped robot, changed environment and mode confusion.

The problem and the intuition

Imagine arriving in a city with a street map. First you have to find where you are on it: look for a street sign and say “I am here”. After that you only need to update the position as you walk. If you point at the wrong place on the map, every later estimate is consistent with that wrong place; you will confidently walk through buildings. A localiser behaves the same way: given a map and a rough start it tracks well; given a start in the wrong room it either converges to a wrong one or never converges.

Mapping mode has the opposite risk. It trusts the data so much that it will happily add a moved chair or a person to the map and warp the graph. Localization mode freezes the map and therefore resists such changes, at the price of failing when the environment is truly different.

Fixed map: stable, cheap, needs a correct start pose. Growing map: adaptive, costlier, can be corrupted by changes. Choose by how much the world changes.

Mapping versus localizationIn mapping mode the robot builds the map and the pose graph while moving. In localization mode the map is fixed and loaded; the robot only estimates its pose in it, starting from an initial pose given by the operator or found by global search.MappingLocalization scans + odometry estimate pose AND mapgraph grows, loops close new map + map→odom saved map + initial pose scans + odometryestimate pose only pose in the saved map = map→odom
Mapping builds the map; localization finds the robot in a fixed one.

The options and what they need

Problem. Operate a robot in a previously mapped environment, estimating its pose in the map frame continuously, recovering from a wrong start or from being moved, and optionally adapting to slow change.

Assumptions. The saved map matches the environment well enough; the lidar sees enough fixed structure; odometry is available for prediction; the operator or a global search can provide an approximate start.

OptionMap it needsHow it localisesStrengthsLimits
SLAM Toolbox, mode: localizationSerialised pose graph (.posegraph + .data)Scan matching against stored scans; adds temporary nodes without changing the saved mapSame code and frames as mapping; accurate in structured mapsNeeds the graph, not only the image; initial pose required; heavier than AMCL on large maps
AMCL (Nav2)Occupancy grid from map_server (.yaml + image)Particle filter (M3-T3, Monte Carlo localisation) with a likelihood-field laser modelLight, standard in Nav2, has a global-localization serviceNeeds a good occupancy map; poor in long symmetric corridors; particle count sets cost
Continued / lifelong mappingSerialised pose graph loaded in mapping modeAdds new scans, loop closes, may remove old onesAdapts to changeCan accumulate errors or corrupt the map; needs monitoring

Initial pose

A localiser needs a prior belief about where the robot is. Ways to give it:

  • RViz “2D Pose Estimate” publishes a geometry_msgs/PoseWithCovarianceStamped on /initialpose. Click on the map where the robot is and drag to give the heading. AMCL (and SLAM Toolbox in localization mode) use it.
  • Parameters. AMCL’s set_initial_pose with initial_pose.x/y/yaw; SLAM Toolbox’s map_start_pose or map_start_at_dock when loading a serialised graph.
  • Global localization. AMCL provides a service /reinitialize_global_localization that spreads particles over the whole free space; the robot must then move so that observations disambiguate the hypotheses. It works in asymmetric maps and can fail in symmetric ones.

How the particle filter uses the start

AMCL keeps N particles (hypotheses of the pose); the number adapts between min_particles (500 by default) and max_particles (2000) using KLD sampling (Fox, 2001). Given an initial pose with covariance, particles are drawn from that Gaussian. If the true pose is outside the cloud, none of the particles matches the scan well and the filter either converges to a lookalike or spreads out. Motion updates are applied only after the robot has moved update_min_d (0.25 m) or rotated update_min_a (0.2 rad), so a stationary robot does not correct itself.

particle weight
wi∝∏beams p(zk ∣xi, map)w_{i}\propto \prod _{\text{beams}}\,p(z_{k}\,\mid x_{i},\,\mathrm{map})
likelihood field
x^=∑ wi xi∑ wi\hat{x}=\frac{\sum \,w_{i}\,x_{i}}{\sum \,w_{i}}
/initialpose
topic on which a start pose with covariance is given to the localiser.
global localization
initialising the particle cloud over the entire free space.
kidnapped robot
the robot is moved without the localiser being told.
KLD sampling
adapting the number of particles to the spread of the posterior.

Failure modes

FailureSymptomCause / remedy
Wrong or missing initial poseScan does not overlap the walls in RViz; particles in two cloudsSet the pose properly; use global localization and move
Kidnapped robotConfident but wrong pose after carrying the robotDetect with low scan match scores; trigger global localization; add recovery behaviour
Map changed (moved furniture)Slow degradation, drifting pose near the changed areaUpdate the map, or use a long-term mapping mode with care
Wrong modeMap grows over the saved one; or nothing updatesCheck mode and which node is running
Map–odom frame offsetPose correct only near the originCheck map_frame, odom_frame and the saved map’s origin
Symmetric environmentPose flips between two hypothesesAdd asymmetric landmarks, other sensors or a better prior

A worked example: a start pose that is too far off

  1. The setup. A warehouse map has two identical aisles 6 m apart. The robot is in aisle A at (12.0, 2.0). The operator clicks on the map at aisle B, (12.0, 8.0) with a covariance of 0.25 m² (σ = 0.5 m) on x and y.
  2. Why it fails. AMCL draws particles from N((12, 8), 0.25). The nearest to the true pose is six standard deviations away: the probability of any particle within 1 m of the truth is about 10−9. The scan taken in aisle A fits aisle B’s walls just as well (the aisles are identical), so the particles converge on aisle B with a high score. The pose is wrong and confident.
  3. How it would be detected. The robot drives out of the aisle and sees the end wall at a distance that does not match the map: scan match scores drop and the particle cloud spreads. In the meantime Nav2 plans from the wrong position.
  4. The remedies. (1) Put the initial pose in the right aisle. (2) If unknown, call /reinitialize_global_localization and drive; the end of the aisle breaks the symmetry. (3) Give each aisle a distinctive feature (a pillar, a sign) so that the map is not self-similar.
  5. Cost of the particle filter. With 2 000 particles and a scan of 360 beams, each update evaluates 2 000 × 360 = 720 000 likelihood lookups; at a 10 Hz scan rate and an update every 0.25 m of travel (0.5 m/s gives 2 updates per second) that is 1.44 million lookups per second, trivial for a CPU. Reducing the beam count with max_beams: 60 cuts it by six.

Engineering implications and limitations

Engineering implications

  • Make the start pose explicit in the workflow. A docking station as the known start, or a launch parameter for the usual pose, removes the most common failure.
  • Monitor localisation health. Watch the AMCL covariance and the scan match score; trigger recovery when they degrade.
  • Decide how you handle change. A fixed map plus periodic re-mapping is simpler and safer than lifelong mapping for most deployments.
  • Keep the map and the robot’s frames consistent. The map origin and the map frame must be the same in the saved file and the running system (M7-T6).
  • Test the kidnapped case. Lift and move the robot in a test and confirm that your system notices and recovers.
  • Version your maps. Store them with the date, the parameter file used and a screenshot.

Limits

A fixed-map localiser has no good answer for an environment that has changed a lot; it gives either a poor pose or none. Particle filters need enough particles to cover the uncertainty, and in large symmetric buildings global localization is slow or ambiguous. Both systems are 2D and assume the lidar sees the same structure that was mapped, which fails if the lidar is mounted at a different height or the room is rearranged.

Common misconceptions

“Localization mode builds a bit of the map as it goes.”

In localization mode the saved map is fixed; the localiser adds temporary data only for tracking.

“The localiser will find the robot from anywhere.”

Only global localization attempts that, and it can fail in symmetric maps. A normal start needs an approximately correct prior.

“A high confidence means a correct pose.”

A wrong start in a self-similar map gives a confident wrong pose.

“AMCL and SLAM Toolbox localization use the same map file.”

AMCL uses the occupancy grid; SLAM Toolbox localization uses the serialised pose graph.

Engineering takeaways

  1. Mapping estimates pose and map together; localization estimates pose in a fixed map.
  2. SLAM Toolbox localization needs the serialised graph; AMCL needs the occupancy grid and a yaml file.
  3. The initial pose must be within the localiser’s capture range, or global localization must be used.
  4. The kidnapped robot, a changed map and symmetric environments are the standard failure cases.
  5. Monitor localisation health and plan the recovery path in advance.

References and further reading

Primary papers and authoritative documentation.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

Question 1

You click the initial pose in the wrong aisle of a symmetric warehouse. Why might AMCL show high confidence?

Explanation

The scan fits the identical wrong aisle as well as the right one, so the particles near the clicked pose score high and the filter converges there. High confidence measures agreement with the map at that place, not correctness; the symmetry hides the error until the robot sees something unique.

Question 2

What do you need to save from a mapping session if you want to use both Nav2 AMCL and SLAM Toolbox localization later?

Explanation

Both the occupancy grid (image plus yaml, for AMCL and map_server) and the serialised pose graph (.posegraph and .data, for SLAM Toolbox localization).

Question 3

Why does AMCL not correct a stationary robot’s pose even if the scan disagrees with the map?

Explanation

It performs a filter update only after the robot has moved by update_min_d or rotated by update_min_a; a stationary robot never triggers one, so the particles are unchanged until it moves.

What’s next

Both the picture of a map and the graph behind it can be saved. The next lesson explains what each file contains, how to save and reload them, and the mistakes that make a saved map unusable.

Practice this lesson

Configure Mapping and Localization

Build a map, save it and serialised graph, then relaunch in localization mode with a correct initial pose.

Next lesson

M7-T6 — Map Saving and Reuse

Distinguish a saved occupancy map from a serialised pose graph and reuse each correctly.

Nothing below is required to finish this lesson. The last entry is a lesson of other courses on this site that teach the background or go further.