| Situation | Effect on localization | Planning use |
|---|---|---|
| Known start pose, distinctive map features | Uncertainty stays in one compact region, so a single estimate with a covariance describes it well. | An extended Kalman filter is a sound, economical choice for tracking. |
| Unknown start pose or a robot that has been lost | Several positions are plausible at once, so one estimate is misleading. | Use a particle filter such as AMCL so that many hypotheses stay alive until the sensor data rules them out. |
| Repeating corridors or symmetric rooms | The belief splits into clusters that look equally good. | Keep the multi-hypothesis filter, give it a good initial pose and let motion through the building break the tie. |
| Wheel odometry drifting between corrections | Motion-only uncertainty grows until a sensor update shrinks it. | Set the motion noise honestly and rely on frequent measurement updates against the map. |
| Occupancy-grid map and a range scanner | Each scan can be scored against the map without extracting landmarks. | AMCL in ROS is the usual starting point. |
The probabilistic framing behind these decisions comes from Thrun, Burgard and Fox’s Probabilistic Robotics, a book concerned with perception and control in the face of uncertainty.
Robot localization algorithms estimate where a robot is on a known map by combining motion estimates with sensor readings. Choose an extended Kalman filter for tracking from a known pose, and a particle filter such as AMCL when the pose is uncertain.
Localization is one building block of artificial intelligence in robotics. It is a state-estimation problem with a mathematical footing, which sets it apart from learned approaches such as those covered in machine learning in robotics.
What the choice of algorithm changes in practice
The algorithm decides how a robot behaves when the map is ambiguous, when it is switched on in an unknown place and when its wheels slip. Those behaviours matter more day to day than the maths behind them.
Start-up and recovery
A filter that holds one Gaussian estimate needs a reasonable starting pose. If the robot is placed in the wrong room, that filter can settle confidently on a wrong answer and never recover. A sample-based filter can start with hypotheses spread across the whole map and let the measurements prune them. That is the main reason particle filters are standard for robots that are moved, rebooted or lose power between jobs.
Computing load and map type
The cost of a Kalman-style filter depends mainly on the size of the state it tracks. The cost of a particle filter depends on how many samples it carries and how expensive each scan comparison is. A small embedded controller with a fixed set of landmarks favours the first. A robot with a scanner and a grid map of a building favours the second, because no landmark extraction is needed.
Decisions this leaves you with
- Pick by starting knowledge. If the start pose is always known and the environment has distinctive features, a Kalman-style tracker is enough. If the start is unknown, plan for a particle filter.
- Pick by map representation. A feature or landmark map suits an EKF. An occupancy grid suits scan scoring and therefore AMCL.
- Pick by failure tolerance. If being lost for a while is unacceptable, prefer the filter that keeps several hypotheses.
- Do not expect either to fix a poor map. Both assume the map matches reality, so a map that is out of date degrades both.
Extended Kalman filter vs particle filter
The comparison of the extended Kalman filter and the particle filter comes down to how each represents belief, the robot’s probability distribution over its pose. Probabilistic Robotics presents its algorithms on a single overarching mathematical foundation, and both filters are different ways of approximating the same recursive Bayesian update.
How the EKF represents the pose
The EKF stores a mean pose and a covariance. It predicts forward with the motion model, then corrects with a measurement. Because the motion and measurement models are nonlinear, it linearises them around the current estimate. This is fast and gives a smooth estimate, but it assumes one dominant hypothesis. If the real distribution has two peaks, the Gaussian cannot describe it.
How the particle filter represents the pose
The particle filter stores many weighted pose samples. Each sample is moved by the motion model with random noise, weighted by how well the sensor reading agrees with the map at that pose, and then resampled so that likely poses multiply and unlikely ones disappear. It handles multiple peaks and strongly nonlinear sensor models. Its costs are computation and a sampling error that grows if too few samples are used.
A rule for choosing
Use the EKF when three things hold: the start pose is known, uncertainty stays small relative to the map’s features, and each measurement can be matched to the right landmark. Use a particle filter when any one of them fails, and in particular when the robot must localize globally or recover after being moved. When in doubt on an indoor robot with a scanner and a grid map, start with the particle filter, since its failure mode, a spread of samples, is visible and recoverable. The EKF’s failure mode, a confident wrong pose, is not.
How a robot works out where it is on a map
A robot works out its position on a map by repeating a two-step cycle: predict the new pose from its own motion, then correct that prediction by comparing what its sensors see with what the map says should be visible. Probabilistic Robotics treats this as perception and control in the face of uncertainty, so the output is a distribution over poses, not a single point.
Odometry as the motion input
Wheel encoders count rotation, and the motion model turns those counts into a pose change. Wheel slip, uneven floors and small wheel-size errors make this estimate drift, and the error accumulates without bound if nothing corrects it. The filter therefore treats odometry as a noisy prediction, never as the truth.
Range measurements as the correction
A range scanner reports distances to nearby surfaces. For each hypothesised pose, the filter asks how well those distances match walls and obstacles on the map. Poses that explain the scan gain weight, and poses that do not lose it. Because the map is known, the correction pins the robot to a place instead of only reducing relative drift.
Why the loop converges
Each pass shrinks the set of plausible poses a little, provided the environment has enough structure to tell places apart. A long, featureless wall gives little information along its length, so the estimate can stay uncertain in that direction while becoming sharp across it. Estimating the pose from a distribution and not a single guess is what lets the robot notice that it is unsure.
AMCL in ROS
AMCL, adaptive Monte Carlo localization, is the particle filter most ROS users meet first. It takes an occupancy-grid map, odometry and a scan, and publishes the correction between the map frame and the odometry frame. The ROS navigation stack relies on that correction to keep a planned path aligned with the real building. Tuning it is mostly about telling the filter honestly how noisy the robot is.
Tuning priorities
- Set the initial pose. Give an approximate starting pose in the map whenever one is known. Global initialisation works, but it takes longer to settle and is easier to fool in symmetric buildings.
- Match the odometry model to the drive. The odometry model type and its noise parameters should describe the real base. If the particle cloud spreads too fast while the robot drives straight, the noise is set too high. If the cloud is tight but the pose slides off the map, it is set too low.
- Bound the particle count with care. The minimum and maximum particle settings trade robustness against CPU load. Raise the maximum for large or ambiguous maps and lower it only when the robot localizes reliably and the processor is the constraint.
- Choose the sensor model deliberately. The likelihood-field laser model is usually more forgiving of clutter than the beam model. Using fewer beams per scan saves time but gives the filter less evidence per update.
- Control update frequency. Thresholds on how far the robot must move or turn before an update stop the filter from collapsing its diversity while stationary.
Symptoms and what they usually mean
A cloud that never tightens suggests a map mismatch, a wrongly mounted scanner frame or excessive sensor noise settings. A cloud that tightens quickly on the wrong place suggests an over-confident model or an ambiguous map. Fix the frames and the map before touching the particle count, because more particles cannot repair a scanner that is declared in the wrong place.
Ambiguous places and failure modes
Identical corridors, repeated door bays and long plain walls are the classic problems for any map-based localizer. Several poses explain the scan equally well, so the particle cloud splits into clusters.
The practical remedies are about information, not algorithms. Drive far enough to see something unique, such as a corner, a doorway of different width or an item on the map that is not repeated. Add distinguishing features to the map where the building allows it. Start from a known pose after a restart. For tracking tasks inside a single repetitive corridor, an EKF with a well-known starting pose can work, but it will not warn you when the pose is wrong, so pair it with a check against a distinctive landmark.
A related lesson applies to neural network robot control: a controller is only as good as the pose estimate it receives, so a localizer that reports its own uncertainty is worth more than one that reports a single confident number.
Reading Probabilistic Robotics
Probabilistic Robotics by Thrun, Burgard and Fox was published by MIT Press in 2005. According to its abstract, each chapter provides example implementations in pseudo code, detailed mathematical derivations and discussions from a practitioner’s perspective. That makes it the reference to read when you need the derivation behind a filter setting, not just the setting itself. Readers who only need to deploy AMCL can begin with the practical tuning above and return to the book when the behaviour of the filter needs explaining.
Frequently asked questions
Is AMCL an EKF or a particle filter?
AMCL is a particle filter. It keeps many weighted pose samples on an occupancy-grid map and adapts how many it uses.
When is an EKF the better choice?
An EKF suits a robot that starts from a known pose, has distinctive features it can match reliably and needs a light-weight estimate. It is a poor fit when the robot must recover from being moved.
Why does odometry alone not give a reliable position?
Odometry integrates small errors from wheel slip and wheel-size mismatch, so the error keeps accumulating. A correction against the map is what stops the drift.
What should I check first when AMCL loses the robot?
Check the initial pose, the scanner frame and whether the map still matches the building. Those faults are more common causes than a wrong particle count.
