Localization & SLAM · Theory · M1
M1-T1 — What Is SLAM?
A robot that must build a map to know where it is, and know where it is to build the map.
A robot dropped into an unknown building has one job before any other: say where it is. The map that would tell it is exactly the thing it does not yet have. This lesson states that chicken-and-egg problem precisely, shows why it cannot be split into two easy problems, and says what the rest of the track does about it.
Learning objectives
After this lesson, you should be able to:
- State the SLAM problem in words and as a probability: the trajectory and the map, estimated together from controls and measurements.
- Explain why a robot cannot simply localize first and map second, using a worked numeric example.
- Separate what SLAM estimates (poses, landmarks, map) from what it assumes (a sensor model, a motion model, a map representation).
- Name three places SLAM is used and the kind of failure that matters in each.
The intuition: a map you draw while lost
Imagine you are blindfolded in an unfamiliar house, then given a torch with a very short beam. You walk, you count your steps, and you sketch what the torch shows. Every wall you draw is placed relative to where you believe you are. If you miscounted the steps, your sketch is wrong in exactly the same way. Later you find a doorway you drew earlier, but on your sketch it is in the wrong place. You now have a clue: either your step count was wrong or your sketch was, and you can fix both.
SLAM is the discipline of using that clue properly: the map and the path are one unknown, and every observation constrains both.
Robotics gives this a name: Simultaneous Localization And Mapping (SLAM). The robot has a way to sense motion (wheel encoders, an inertial sensor, or visual movement) and a way to sense the world (a laser scanner called LiDAR for Light Detection And Ranging, or a camera). Neither is perfect. Motion sensing drifts. World sensing is noisy and sees only part of the scene. A SLAM system fuses both into a consistent picture.
Why not do the two jobs one after the other?
If a precise external positioning system existed everywhere, mapping would be easy: log each sensor reading with the exact pose and draw. If a perfect map existed, localization would be easy: match what you see to it. SLAM matters precisely when neither is available, which is indoors, underground, underwater, on other planets, and in any building that was not surveyed beforehand. The two jobs depend on each other, so they have to be solved together.
The mathematics: a joint estimate
Write the unknowns first. The robot visits poses at times 1 to T, and the world contains landmarks or map cells. We never see them directly. We see controls and measurements.
- xt
- robot pose at time t: position and heading. In a plane, xt = (x, y, θ).
- ut
- the control or odometry input between time t−1 and t: for example, wheel encoder ticks converted to a forward distance and a turn.
- zt
- the measurement at time t: for example, a range and bearing to a landmark, or a LiDAR scan.
- m
- the map: a set of landmark positions, or an occupancy grid, or a point cloud. The representation is a choice.
- x1:T
- the whole trajectory, poses 1 to T. Note the colon: it means "from 1 to T".
Full SLAM asks for the posterior probability of the entire trajectory and the map given everything observed:
Online SLAM keeps only the current pose and the map, summing out older poses:
Both are statements about uncertainty, not single answers. A good SLAM system reports a best estimate and how much to trust it. The next lessons build the tools: motion and sensor models, filters (Module 3), and graph optimization (Module 4).
Assumptions made by the formulation
- A motion model says how xt follows from xt−1 and ut, with noise. Without it, odometry cannot be weighed against measurements.
- A measurement model says what zt the sensor would produce from a pose and a map, with noise. This is how a measurement constrains the map and the pose.
- A static world, usually. Landmarks and walls are assumed not to move. Moving people and cars are handled as exceptions (Module 8).
- Data association: knowing which map element each measurement refers to. This is often the hardest part in practice and is treated as a problem of its own.
The key is that m and the poses appear in the same probability. You cannot estimate one while holding the other fixed at a wrong value.
A worked robotics example: the door in the corridor
A wheeled robot starts at x = 0 m at the end of a straight corridor and drives forward. Its LiDAR measures the distance straight ahead to a door frame. We use plain numbers so every step can be checked by hand.
- First sighting. Wheel odometry says the robot has moved 5.0 m, so it believes it is at x = 5.0. The LiDAR measures 3.0 m to the door. The mapping rule is door = pose + range, so the door is placed at 8.0 m.
- What was true. The wheels slipped slightly: the robot actually moved 5.2 m, so the true door position is 5.2 + 3.0 = 8.2 m. The map is wrong by 0.2 m. This is exactly the pose error: the map inherits it.
- Second sighting. The robot drives on, turns, and later approaches the door again from another place. Odometry says it is at x = 2.0 m. The true position is 2.3 m, and the LiDAR measures 5.9 m. The estimate for the door is 2.0 + 5.9 = 7.9 m.
- The disagreement. We now hold two estimates of one door: 8.0 and 7.9. They differ by 0.1 m. Neither is the truth (8.2), but the difference is real information: between the two sightings the robot moved 5.9 − 3.0 = 2.9 m relative to the door, while odometry claims 3.0 m. At least one of them is wrong by 0.1 m.
- What SLAM does with it. It treats the poses and the door position as unknowns and chooses the values that best satisfy all measurements together, weighting each by how much it is trusted. With more doors and more passes, the contradictions accumulate and the errors become correctable. The correction cannot recover the absolute truth when only relative information exists, but it makes the map self-consistent.
Three things to notice. The map error was not independent of the pose error. Having two views of the same thing is what allowed the correction at all, which is why recognising a place seen before (loop closure) is the most valuable event in SLAM. And a pure, non-joint approach, which trusts odometry and writes the map, would simply have stored 8.0 and then 7.9 as two different doors.
Engineering implications and limitations
Where SLAM is used
| Application | What matters most | Typical failure |
|---|---|---|
| Warehouse robot | Repeatable localization in a mostly known layout; map updates when shelves move | Long aisles look identical, so the pose slips along the aisle |
| Robot vacuum | Cheap sensors, coverage of a changing home | Furniture moved overnight; map conflicts with the world |
| Drone indoors | Low latency, low weight, motion that is fast and 3D | Fast rotation blurs images; tracking is lost |
| Self-driving research vehicle | Accuracy over kilometres, with GPS as extra information | Dense traffic and moving objects confuse static map assumptions |
Limitations to carry forward
- SLAM is not magic accuracy. Without any external reference, the map is correct only relative to the start. A drifting estimate can be consistent and still be offset from the world.
- It is only as good as its models. An overconfident noise model makes the system trust bad data; an underconfident one wastes good data.
- It can be fooled. Repetitive corridors, featureless walls, glass, moving objects and darkness all create situations where measurements are ambiguous or missing.
- It has a cost. Keeping every pose and landmark grows with time and area. Practical systems bound this with sparsity, keyframes and submaps.
Production systems such as Cartographer, SLAM Toolbox, ORB-SLAM3 and RTAB-Map each pick a different set of trade-offs. The labs here use simplified educational versions so you can see what is going on inside; Module 9 ties them into a full pipeline.
Common misconceptions
“SLAM is a single algorithm.”
SLAM is a problem. EKF-SLAM, particle-filter SLAM, graph-based SLAM, LiDAR SLAM and visual SLAM are different solutions to it, with different sensors, assumptions and failure modes.
“SLAM gives me the true position in the world.”
It gives a position in the frame of the map, which is anchored where the robot started unless you add an outside reference such as GPS or a surveyed landmark.
“If localization is good, mapping will be good.”
Localization uses the map. If the map is wrong, localization against it is wrong, and the new observations are placed with that wrong pose. Errors feed each other.
“More sensors always fix it.”
More sensors add more models that can be wrong, and more calibration (Module 2 and 5). Fusion helps when the sensors fail in different ways, and not otherwise.
Engineering takeaways
- SLAM estimates the robot’s trajectory and the map as one joint unknown, because each depends on the other.
- A pose error becomes a map error unless something, such as seeing a landmark again, contradicts it.
- Two inconsistent views of the same thing are not a problem: they are the evidence SLAM runs on.
- SLAM depends on models (motion, measurement), on data association, and on a mostly static world.
- The result is uncertain by nature: always ask what the system believes and how sure it is.
References and further reading
Established foundations. Active research directions are covered in Module 8.
- Cadena, C. et al. (2016). Past, Present, and Future of Simultaneous Localization and Mapping: Toward the Robust-Perception Age. IEEE Transactions on Robotics 32(6). The standard survey; defines the SLAM problem and its open questions.
- Durrant-Whyte, H. and Bailey, T. (2006). Simultaneous Localization and Mapping: Part I. IEEE Robotics & Automation Magazine 13(2). The classic tutorial on the probabilistic formulation.
- Smith, R., Self, M. and Cheeseman, P. (1990). Estimating Uncertain Spatial Relationships in Robotics. In Autonomous Robot Vehicles, Springer. The origin of the idea that map and pose uncertainty are correlated.
- Thrun, S., Burgard, W. and Fox, D. (2005). Probabilistic Robotics. MIT Press, chapter 10. Textbook treatment of the online and full SLAM posteriors.
Knowledge check
Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.
Question 1
A robot has a perfectly accurate map of a building. Which problem is it solving when it works out its own position in it, and what does that tell you about why SLAM is harder?
Explanation
It is solving localization: the map is known and only the pose is estimated. SLAM is harder because neither is known, so any error in the pose is copied into the map, and a wrong map then misleads the next pose estimate.
Question 2
In the corridor example, the two sightings of the door gave 8.0 m and 7.9 m, and both were wrong. Why is the 0.1 m disagreement still useful?
Explanation
Because it reveals an inconsistency among the poses and the map that cannot all be right. SLAM treats it as a constraint and adjusts the poses and the door position until the contradictions are as small as the measurement noise allows. Without a second sighting the error would be invisible.
Question 3
A colleague says: "We run SLAM, so the final map is anchored to the world frame of the building." What is missing from this claim?
Explanation
SLAM alone anchors the map to where the robot started. To tie it to the building’s frame you need an external reference such as a known starting pose, a surveyed landmark, or GPS. Otherwise the map can be perfectly self-consistent and still be offset or rotated relative to the building.
What’s next
You now have the problem statement. Next, the three related estimation problems are separated by what is known and what is unknown, which tells you which tool to reach for.
Related content
Nothing below is required to finish this lesson.
- LabM1-L1: Understand Localization, Mapping, and SLAM
A robot has a landmark map but no pose, or poses but no map, or neither: decide what can be estimated and compute the first two.
Get notified when the next lesson and new labs are released.
One email per new lesson or lab.