Lost in a Building You Have the Map For
Imagine waking up in a large office building with a perfect floor plan in your hand. You know every corridor, door, and stairwell — yet you still have no idea which room you are standing in. The map answers "what does the world look like," but it cannot answer "where am I right now." That second question is the whole job of localization: given a map the robot already trusts, work out its own pose — its position and which way it is facing — inside that map.
Notice that localization assumes the map is given. That is what separates it from the harder problem of building the map at the same time, called SLAM. Here the map is fixed and trustworthy — often an occupancy grid, a fine checkerboard in which each cell is marked free, occupied, or unknown. The robot's only mystery is its own location.
Why Counting Your Wheels Is Not Enough
A wheeled robot's first instinct is to track itself by counting wheel rotations. If you know the wheels rolled forward by so many centimeters, you can add that motion to your last known pose and update your guess. This running total of motion is called odometry, and the broader habit of estimating position purely from your own motion — with no outside reference — is dead reckoning.
The trouble is that every step adds a tiny error, and those errors never cancel — they pile up. A wheel slips on a wet tile, one tire is slightly underinflated so it covers less ground than its mate, the floor has a gentle slope. Each glitch is small, but odometry keeps adding new motion onto an already-wrong estimate, so the guess slowly slides away from the truth. This steady accumulation is called drift. Quantization in the wheel encoders adds a little sensor noise on top, but the main culprit is that systematic errors get integrated step after step. Run long enough on odometry alone and a robot can be confidently certain it is in the kitchen while it is actually parked in the hallway.
The cure is to look outward. A range sensor such as a LiDAR sweeps the room and reports the distance to nearby walls. Those measurements can be checked against the map: if the robot truly stood where it thinks it does, the wall it sees three meters ahead should line up with a wall drawn three meters ahead on the map. When the readings and the map disagree, the robot has caught its own drift and can correct the guess. Localization, then, is a constant tug-of-war between motion estimates that drift and sensor readings that pull the estimate back onto the map.
A Cloud of Guesses That Votes for the Truth
How does a robot juggle drift and correction at once? One of the most intuitive answers is Monte Carlo localization. Instead of betting on a single best guess, the robot scatters hundreds or thousands of guessed poses across the map. Each guess is one tiny hypothesis — "maybe I am here, facing this way" — and the whole crowd of them together is called a particle filter. Every single guess is a particle.
The filter runs a simple three-beat loop, over and over. Each beat is cheap; the magic is in repeating it many times a second.
- Move every guess. When the robot drives forward, push all the particles forward by the same odometry estimate — plus a little random jitter, because the motion itself is uncertain. The whole cloud shuffles along with the robot.
- Score every guess. Take the latest LiDAR scan and ask, for each particle, "if the robot really stood here, would these distance readings match the map?" A particle whose imagined view matches the real readings gets a high weight; one that would be staring at a wall while the sensor actually sees open space gets a low weight.
- Resample. Build a fresh crowd by drawing particles in proportion to their weight — well-matched guesses get copied many times, poorly-matched ones tend to vanish. The cloud thins out wherever the readings rule a spot out, and thickens wherever they fit.
Run this loop as the robot rolls down a corridor and something satisfying happens: the scattered cloud collapses. As more scans rule out more wrong spots, the surviving particles huddle tighter and tighter around the one pose that explains everything the sensor has seen. The robot has gone from "I could be anywhere" to "I am right here," not by a single clever calculation but by letting many guesses compete and letting the evidence vote. This is one concrete face of recursive Bayesian estimation: keep a belief about where you are, and refine it with each new measurement.
Tracking a Known Start vs. the Kidnapped Robot
Not all localization problems are equally hard, and the difference comes down to how much you know at the start. The easy case is pose tracking: you already know roughly where the robot began, and you only need to keep that estimate honest as it moves. Here the particles can start as one tight cluster around the known starting pose, and the loop's whole job is to nudge that cluster along and resist drift.
The hard case is global localization: the robot wakes up with no idea where it is, exactly like our person lost in the office building. Now the particles must start spread across the entire map, and the filter has to sift the whole space before the cloud can converge. Monte Carlo localization shines here precisely because a crowd of guesses can blanket many rooms at once, where a single best-guess estimate would have no way to even begin.
The nastiest version has a nickname: the kidnapped robot problem. Picture a confidently-localized robot that someone picks up and sets down somewhere completely different. Its particles are all huddled in the old, now-wrong spot, smugly agreeing with one another — and none of them is anywhere near the truth. A good localizer has to notice that every guess suddenly explains the sensor readings poorly, then deliberately scatter fresh particles to re-search the map. It is a sharp reminder that a tight, confident cloud is not the same thing as a correct one.