How does a robot know where it is?

Counting wheel turns: how odometry works and why it drifts

Close your eyes in your kitchen and walk to the fridge. You'll probably get close, because you know roughly how long your steps are and which way you turned. Try the same thing across a parking lot and you'll miss by meters. Each step's small error gets carried into the next one, and nothing ever corrects it.

A wheeled robot does exactly this. It's called odometry: working out where you are by adding up how far your wheels have turned since a known starting point. Each wheel has an encoder, a sensor that counts tiny fractions of a turn. Multiply the count by the wheel's circumference and you've got distance. On a robot with two driven wheels side by side (a differential drive), the difference between the left and right distances tells you how much the robot turned. If the right wheel went farther, the robot curved left.

Johann Borenstein and Liqiang Feng at the University of Michigan described odometry as simple, inexpensive, and easy to accomplish in real-time, and named its weakness in the next sentence: its unbounded accumulation of errors. In their work on differential-drive robots, the two biggest systematic culprits were uncertainty about the effective wheelbase (the distance between the wheels) and unequal wheel diameters.

A worked example: one wheel 0.2% too big

Take a small robot with its wheels 30 cm apart, and suppose the right wheel is 0.2% bigger than the left. On a 10 cm wheel that's a fifth of a millimeter, far too small to spot by eye. The software assumes the wheels are identical. So when both encoders report the same count, it records a straight line. Meanwhile the right wheel covers 0.2% more ground on every turn, and the robot quietly curves left.

Here's how far off it gets. Over 10 m, the right wheel travels 0.2% × 10 m = 2 cm more than the left. Divide that gap by the 30 cm wheelbase and you get the heading change: 0.02 / 0.30 = 0.067 radians, about 3.8°. The robot has really driven a gentle arc with a 150 m radius, and it ends up about 33 cm to the left of where odometry says it is.

Look at what happens each time the distance doubles. The heading error doubles, but the sideways error roughly quadruples. A heading error doesn't just add up. It gets multiplied by every meter you drive afterward, which is why a tiny mismatch you'd never see with a ruler turns into meters of error across a warehouse.

Real robots also slip on smooth floors and bounce over cables, which adds random error on top of the systematic kind. Calibration helps a lot: Borenstein and Feng report that their calibration method improved accuracy against systematic errors by at least one order of magnitude. But calibration shrinks the drift. It can't stop it.

What an IMU adds, and why it drifts in a different way

An IMU (inertial measurement unit) is a small package with two kinds of sensor. A gyroscope measures how fast the robot is rotating. An accelerometer measures how fast its speed is changing. Neither one touches the floor, so wheel slip can't fool them. That makes a gyro a great partner for wheel odometry when it comes to tracking which way the robot is facing.

The catch is that an IMU never measures position. To get heading from a gyro, you add up (integrate) its rotation rate over time, once. To get position from an accelerometer, you integrate twice: acceleration into speed, then speed into distance. Any error in the reading gets integrated right along with the real signal.

Oliver Woodman's University of Cambridge report on inertial navigation spells out the arithmetic. A gyro with a constant bias (a small offset in its reading, present even when nothing is moving) produces a heading error that grows linearly with time. An accelerometer with a constant bias ε produces a position error of s(t) = ε · t²/2, which grows with the square of time.

How fast that adds up

How big is a realistic bias? Gravity is the usual troublemaker. An accelerometer can't tell gravity from motion, so if the sensor is tilted even slightly, part of gravity shows up as fake sideways acceleration. Borenstein and Feng point out that typical accelerations for a mobile robot are around 0.01 g, and that a fluctuation that size already occurs if the sensor tilts by only 0.5°, say on an uneven floor. Work it out: 9.81 m/s² × sin(0.5°) ≈ 0.086 m/s².

Plug that into s = ε · t²/2, along with a bias ten times smaller, and here's how far off you'd be if you trusted the accelerometer alone:

That's why nobody tracks a ground robot's position from its accelerometer alone. The gyro behaves better, since its error grows linearly instead of with the square of time, and that's where an IMU earns its place: heading.

So the two sensors fail in opposite ways. The Nav2 robot navigation docs put it in one line: IMUs drift over time while wheel encoders drift over distance traveled, which is why they're often used together. A parked robot's wheel odometry doesn't drift at all, while its IMU keeps drifting. A robot spinning its wheels on ice racks up odometry error while the IMU correctly reports it isn't going anywhere.

Better IMUs exist, but you pay for them in price, size and weight. Woodman compares two Honeywell gyros: a laser gyro with a bias stability of 0.0035° per hour, and a three-axis MEMS (chip-scale) gyro rated at under 70° per hour. The laser unit weighs 454 g against the MEMS package's 136 g. Even the good one drifts eventually, which brings us to measurements that don't.

GPS, landmarks and maps: position fixes that don't drift

Odometry and IMUs are relative sensors. They tell you how you moved, not where you are. To stop drift you need an absolute reference: something that measures your position against the outside world, so its error doesn't build on yesterday's error. Borenstein and Feng list the usual options as navigation beacons, active or passive landmarks, map matching, or satellite-based navigation signals.

GPS: great outdoors, but meters off on a phone

GPS is the obvious one outdoors, and its error doesn't grow the longer you drive. The U.S. government's GPS site says GPS-enabled smartphones are typically accurate to within a 4.9 m (16 ft.) radius under open sky, and that accuracy gets worse near buildings, bridges and trees. The same page lists why: structures and trees block the satellite signals, signals bounce off walls (called multipath), and indoors or underground the device often can't get a usable signal at all.

Five meters is fine for turn-by-turn directions in a car. It isn't fine for a delivery robot deciding which side of a doorway it's on, and it's no help at all to a robot inside a warehouse.

Landmarks and map matching: what indoor robots use

A landmark is anything the robot can recognize and whose position it already knows: a reflector on a warehouse pillar, a printed marker on a wall, a door frame, the corner of a shelf. If the robot's laser scanner (lidar) measures the corner 2.0 m straight ahead, and the map says where that corner is, the robot can work backward to where it must be standing. Map matching does the same with a whole scan at once. The robot slides its lidar outline of the walls around on the map until it lines up, and wherever it fits best is where the robot probably is.

Absolute fixes have problems of their own. They're noisy, they usually arrive less often than wheel counts, and they can be fooled. Two identical corridors look the same to a lidar. A shelf that's been moved since the map was made looks like a wall in the wrong place.

So robots run both kinds of sensor at once. The Nav2 docs describe the standard arrangement: wheel and IMU odometry give a smooth, continuous estimate that drifts, and a separate localization step uses the map to correct it. The smooth one is what the robot steers by from moment to moment. The corrected one is what keeps it from wandering off over minutes and hours.

How sensor fusion decides which sensor to trust

Sensor fusion means combining several imperfect measurements into one estimate that's better than any of them alone. The best-known tool for it is the Kalman filter, which R. E. Kalman published in 1960. Greg Welch and Gary Bishop's widely used tutorial from the University of North Carolina describes it as a loop with two steps, predict and correct:

1. Predict. Use the motion you measured (wheel counts, gyro) to move your position estimate forward. Make your uncertainty a little bigger while you're at it, because every bit of motion adds error.
2. Correct. When an absolute measurement arrives, like a landmark sighting or a GPS fix, nudge the estimate toward it and shrink the uncertainty.

The interesting question is how far to nudge. The filter keeps a number for how unsure it is, written as a variance. That's the square of the standard deviation, and the standard deviation is roughly the typical size of the error. The size of the nudge is called the Kalman gain. Welch and Bishop describe how it behaves: as the measurement's error shrinks toward zero, the actual measurement is trusted more and more, and as the prediction's error shrinks toward zero, the measurement is trusted less and less.

A worked example in one dimension

A robot is driving down a corridor. Odometry says it's 10.0 m from the start, and after all that driving the filter's uncertainty has grown to a standard deviation of 0.5 m (variance 0.25 m²). Then the lidar spots a door frame that's on the map, and works out that the robot is at 10.6 m, with a standard deviation of 0.2 m (variance 0.04 m²).

With a single number to estimate, the gain is the prediction's variance divided by the total variance:

gain = 0.25 / (0.25 + 0.04) = 0.86

So the filter moves 86% of the way from its prediction toward the measurement:

new estimate = 10.0 + 0.86 × (10.6 − 10.0) = 10.52 m

Its uncertainty shrinks too: (1 − 0.86) × 0.25 = 0.034 m², which is a standard deviation of about 0.19 m. That's smaller than either source on its own. Two shaky estimates, weighted by how shaky each one is, beat the better of the two.

Now swap the lidar for a much vaguer fix, with a standard deviation of 5 m, about the size of the phone-GPS error above. The variance is 25 m², so the gain becomes 0.25 / 25.25 = 0.01. The filter moves just 1% of the way, from 10.0 m to 10.006 m. That's the right call: a guess good to 5 m shouldn't yank around an estimate that's good to half a meter. But odometry's variance keeps growing as the robot drives, so on a long enough trip even a vague fix starts to carry real weight.

Real robots run the same arithmetic on position, heading and speed together, using matrices instead of single numbers. Because a turning robot's motion isn't a straight-line (linear) function, they often use a variant called the extended Kalman filter (EKF), which Welch and Bishop also cover. Another common choice is a particle filter, which tracks a large set of guesses about where the robot might be and keeps the ones that best agree with what the sensors see.

What SLAM does when there's no map yet

Everything so far assumes the robot already has a map. A new robot vacuum in your living room doesn't. It has to build the map and find itself on that map at the same time. That sounds circular: you need to know where you are to put things on the map, and you need the map to know where you are.

That problem is called SLAM, short for simultaneous localization and mapping. The 2016 survey by Cesar Cadena and colleagues in IEEE Transactions on Robotics defines it as the concurrent construction of a model of the environment (the map), and the estimation of the state of the robot moving within it. In practice the robot drives, adds what it sees to a growing map, and keeps track of how uncertain both the map and its own position are.

What keeps SLAM honest is loop closure. When the robot comes back to a place it's seen before and recognizes it, the gap between where odometry thinks it is and where the old part of the map says it must be shows how much it has drifted. That error can then be corrected across the whole path, not just at the last step. The Cadena survey puts it this way: without a map, dead reckoning would quickly drift over time, but with distinguishable landmarks the robot can reset its localization error by revisiting known areas.

SLAM isn't always needed. The same survey notes that when landmark positions are known in advance, like beacons on a factory floor, or when the robot has GPS, SLAM may not be required. It also points out that indoor operation rules out GPS for bounding the localization error. That's why SLAM is so common indoors, in homes, warehouses and anywhere else a robot arrives with no map and no satellites.

Where beginners go wrong about robot localization

• "Calibrate the wheels and odometry is solved." Calibration removes systematic error, like the 0.2% wheel mismatch above. Slip and bumps are random and they still add up. Only an absolute reference, such as a landmark, a map match or GPS, puts a ceiling on the error.
• "An IMU tells you your position." It measures rotation and acceleration. Position takes two rounds of integration, and the table above shows a half-degree tilt putting you about 4 m off within ten seconds. On a ground robot, the IMU's real job is heading.
• "GPS fixes everything." Phone-grade GPS is good to a few meters under open sky, gets worse near buildings and trees, and often doesn't work indoors at all. Outdoor robots still lean on wheels and an IMU between fixes and under bridges.
• "Just average the sensors." A plain average gives a 5 m GPS fix the same vote as a 20 cm lidar fix. In the corridor example, averaging 10.0 m and 10.6 m gives 10.3 m, well short of the 10.52 m the filter picks by weighting each source by its uncertainty. Weighting is the whole reason to use a filter.
• "The answer is a single point." A useful position estimate comes with an uncertainty attached. Without one, the filter has no way to decide how much to trust the next measurement, and nothing tells the robot that its idea of where it is has gone stale.

Put together, the honest answer to "how does a robot know where it is" is that it never knows exactly. It keeps a running best guess plus a measure of how wrong that guess might be, and it updates both every time a sensor reports in.

Common questions

Learn it properly

Physical AI & Robotics Engineering picks up where this leaves off, with lessons on state estimation and the Kalman filter, sensor fusion, and SLAM, alongside kinematics, control and motion planning. It's the advanced robotics path, so Robotics Foundations is the place to start if you've never worked with a robot.

See Physical AI & Robotics Engineering in the Toorova catalog →

Sources

1. Measurement and Correction of Systematic Odometry Errors in Mobile Robots (Borenstein & Feng, IEEE Transactions on Robotics and Automation, 1996) · University of Michigan
2. An introduction to inertial navigation (Woodman, Technical Report UCAM-CL-TR-696) · University of Cambridge Computer Laboratory
3. Setting Up Odometry · Nav2 documentation
4. GPS Accuracy · GPS.gov (U.S. government)
5. An Introduction to the Kalman Filter (Welch & Bishop, TR 95-041) · University of North Carolina at Chapel Hill
6. Past, Present, and Future of Simultaneous Localization And Mapping: Towards the Robust-Perception Age (Cadena et al., 2016) · IEEE Transactions on Robotics (arXiv)