What Is Odometry in Robotics and How Robots Use It

By RWT Robotics Editorial Team · Checked against 8 sources · Published November 12, 2026

Odometry is how a robot estimates where it has moved by adding up its own measured motion from a known starting point. It works the way you count steps with your eyes closed, and like step counting it drifts: every small error is carried forward. This explainer covers the definition, the math with a worked example, every major type of odometry, how to calibrate it, and how it fits into FTC, VEX, ROS 2 and the Mars rovers.

What is odometry? (the short answer)

Odometry is the estimation of a robot’s change in position and orientation (its pose: x, y and heading) from motion sensors, measured relative to a known starting pose. It is relative and incremental. It can tell you how far you have come from the start, but it cannot tell you where you are on a map unless you knew exactly where you started, and its error grows with every meter.

The word comes from the same root as “odometer.” Merriam-Webster traces “odometer” to the French odomètre, from the Greek hodometron: hodos (way, road) plus metron (measure). Its first known English use dates to 1791. So the plain-English meaning of odometry is “measuring the way.”

Northwestern’s Modern Robotics course (Kevin Lynch and Frank Park) gives the engineering definition. Odometry estimates the chassis configuration by integrating wheel velocities. Errors build up from slipping, skidding and numerical integration, so it is normally supplemented by exteroceptive sensors such as cameras, range sensors and GPS.

Odometry vs odometer

An odometer is a device that counts total distance traveled, like the one in a car dashboard. It produces a single number with no direction. Odometry is a process that produces a full pose: where you are in two (or three) dimensions and which way you are facing. A car’s odometer reads 40,000 km whether you drove in circles or in a straight line. Odometry would know the difference.

Odometry vs dead reckoning

Dead reckoning is the general navigation technique of computing a current position from a known past position plus measured speed, heading and time. Ship navigators used it for centuries. Odometry is dead reckoning applied to robots using onboard motion sensors. Many robotics texts use the terms almost interchangeably. In practice, “odometry” usually means the sensor-specific motion estimate, and “dead reckoning” means the broader idea of navigating from it without outside fixes.

Odometry in one picture: counting your steps with your eyes closed

Stand in a room, close your eyes and walk “ten steps forward, turn right, five steps forward.” You will end up near the right spot, not on it. Your steps are slightly shorter than you think. Your right turn is 80° instead of 90°. Every mistake carries into the next leg. That is odometry: useful in the short term, unreliable over long distances unless you open your eyes now and then to check a landmark.

How wheel odometry works, step by step

Wheel odometry converts encoder ticks into wheel distance, combines the two wheel distances into forward travel and heading change, and adds that change onto the previous pose. It repeats this every control loop, often 50 to 1,000 times per second. Here is the full chain for a differential-drive robot (two driven wheels, one each side).

From encoder counts to distance

A rotary encoder on each wheel or motor shaft outputs ticks as it turns. A quadrature encoder uses two offset channels so it can count direction as well as rotation. To get distance:

1. Compute wheel circumference: π × wheel diameter.
2. Compute distance per tick: circumference ÷ ticks per wheel revolution (include any gear ratio between encoder and wheel).
3. Multiply the tick change since the last update by distance per tick.

From two wheels to robot motion

With left distance dL and right distance dR, the robot’s center moved d = (dL + dR) ÷ 2. The heading changed by Δθ = (dR − dL) ÷ b, where b is the track width (the distance between the wheel contact points). Positive Δθ means a counterclockwise turn under the usual convention. Notice that heading depends on dividing by b, which is why an incorrect track width wrecks turns but leaves straight lines nearly untouched.

Updating the pose (Euler vs midpoint vs exact arc)

The simplest update (Euler) moves the robot d along its old heading, then applies the turn. That skews the result during turns. The midpoint method moves d along the average of the old and new headings, which is far more accurate for almost no extra cost. The exact-arc method treats each step as a circular arc and is exact for constant wheel speeds. At high loop rates the midpoint and arc methods give nearly identical results.

Here is one complete update using illustrative numbers: 100 mm wheels, 1,000 ticks per wheel revolution, 0.30 m track width, starting at (0, 0, 0).

Step	Formula	Example value
Distance per tick	π × 0.100 m ÷ 1,000	0.000314 m
Left wheel distance	500 ticks × 0.000314	0.1571 m
Right wheel distance	600 ticks × 0.000314	0.1885 m
Forward distance d	(0.1571 + 0.1885) ÷ 2	0.1728 m
Heading change Δθ	(0.1885 − 0.1571) ÷ 0.30	0.1047 rad (6.0°)
New x (midpoint)	0 + d × cos(0 + Δθ/2)	0.1726 m
New y (midpoint)	0 + d × sin(0 + Δθ/2)	0.0090 m
New heading θ	0 + Δθ	6.0°

In code, the whole loop is about ten lines:

dist_per_tick = math.pi * WHEEL_DIAMETER / TICKS_PER_REV
dL = (left_ticks - prev_left) * dist_per_tick
dR = (right_ticks - prev_right) * dist_per_tick
prev_left, prev_right = left_ticks, right_ticks
d = (dL + dR) / 2.0
dtheta = (dR - dL) / TRACK_WIDTH
x += d * math.cos(theta + dtheta / 2.0)
y += d * math.sin(theta + dtheta / 2.0)
theta = (theta + dtheta + math.pi) % (2 * math.pi) - math.pi  # wrap to [-pi, pi)

This loop needs to run at a steady rate. On microcontrollers it usually sits in a fixed-period task, which is one reason robot firmware often runs on a real-time operating system.

Mecanum, omni and Ackermann robots

The same idea extends to other drivetrains. Modern Robotics writes each wheel’s speed as a linear function of the chassis twist (forward, sideways and rotational velocity). Inverting that relationship gives a matrix, called F in the book, that maps measured wheel motion back to chassis motion. For mecanum and omni drives, F is a pseudoinverse because there are more wheels than chassis degrees of freedom. Car-like (Ackermann) robots use rear-wheel distance plus steering angle instead of a wheel-speed difference.

Types of odometry

Odometry is defined by its method, not by the sensor. Any sensor that measures relative motion can feed it: wheels, unpowered tracking wheels, inertial sensors, optical floor sensors, cameras or lidar. Each one drifts for a different reason, which is exactly why they are combined.

Wheel and dead-wheel odometry

Wheel odometry reads encoders on the driven wheels. It is cheap and precise on hard, flat floors, but it fails whenever a wheel slips. Dead-wheel odometry (called odometry pods or tracking wheels in FTC and VEX) uses separate, unpowered, spring-loaded wheels that roll along the floor. Because they are not driven, they slip far less under hard acceleration.

Inertial odometry

Inertial odometry uses an IMU: a gyroscope measures rotation rate and an accelerometer measures linear acceleration. A gyro heading is excellent over seconds to minutes. Position from an accelerometer, however, means integrating twice, so a tiny bias grows quadratically with time and becomes useless within seconds on low-cost parts. In practice, most mobile robots use the IMU for heading only. Newer learned inertial odometry methods (often for phones and pedestrians) reduce this drift but do not remove it.

Optical-flow tracking sensors

These sensors work like a mouse sensor pointed at the floor and measure surface motion directly. The SparkFun Optical Tracking Odometry Sensor (OTOS), built on the PixArt PAA5160E1 with a Qwiic connector, combines an optical tracker with an IMU on a 1 in × 1 in board. SparkFun’s spec sheet rates tracking accuracy at 3 to 5% and tracking speed up to 2.5 m/s, and lists it at $84.95. Height above the floor and surface texture matter a lot. Changes in either are a common reason users report wrong distances even after calibrating.

Visual and visual-inertial odometry

Visual odometry (VO) estimates motion by tracking features between camera frames. Stereo cameras give metric scale directly. A single camera needs another source, typically an IMU, which gives visual-inertial odometry (VIO). VIO is the standard motion estimate on drones, AR headsets, micro air vehicles and many legged robots, because it does not depend on wheel contact. It fails in darkness, on blank walls, with motion blur and in scenes dominated by moving objects.

Lidar odometry

Lidar odometry aligns consecutive laser scans (with ICP-style scan matching or feature-based methods) to compute the motion between them. It is accurate in structured spaces and does not care about lighting. It degrades in long featureless corridors, open fields and anywhere the geometry looks the same from one scan to the next.

Method	What it measures	Typical hardware	Main error / drift source	Fails when	Best for
Wheel	Drive-wheel rotation	Motor or wheel encoders	Slip, wheel diameter, track width	Wheels skid, spin or push	Indoor differential-drive robots
Dead wheel / pod	Unpowered wheel rotation	goBILDA pods, VEX tracking wheels	Pod lift, offsets, scale	Pods leave floor, bumps	FTC/VEX, mecanum drives
Inertial	Angular rate, acceleration	Gyro and accelerometer (IMU)	Bias, double-integration drift	Used alone for position	Heading, short gaps
Optical flow	Floor surface motion	SparkFun OTOS (PAA5160E1)	Height, surface texture, scale	Glossy or uneven floors	Small robots on flat fields
Visual / VIO	Camera feature motion	Stereo or mono camera plus IMU	Feature tracking, scale (mono)	Darkness, blur, blank walls	Drones, rovers, legged robots
Lidar	Scan-to-scan alignment	2D/3D lidar	Scan-matching error	Featureless corridors, open fields	AMRs, outdoor vehicles

What is an odometry error? Why every odometry estimate drifts

An odometry error is the gap between the pose the robot computes and where it actually is. Because each update is added onto the last, errors never reset themselves: they accumulate. Johann Borenstein and Liqiang Feng split them into two groups, systematic and non-systematic, and the split still drives how you fix them.

Systematic errors: wheel diameter, track width, encoder resolution

Systematic errors come from the robot’s own design and build. Borenstein and Feng identified the two dominant ones as unequal wheel diameters and uncertainty about the effective wheelbase (track width). They are repeatable, so you can measure and correct them. Their paper also notes that systematic errors dominate on smooth indoor floors.

Non-systematic errors: slip, bumps, carpet, collisions

Non-systematic errors come from the interaction with the environment. They are random and cannot be calibrated away. They dominate on rough surfaces, and they are why mecanum robots drift under hard acceleration.

Error	Type	Cause	Symptom	Fix
Unequal wheel diameters	Systematic	Tolerances, uneven load, tread wear	Robot curves when driving “straight”	Correct diameter ratio (UMBmark)
Wrong effective track width	Systematic	Wide wheel contact patch, CAD value	Turns over- or under-counted	Rotation test, UMBmark
Wrong average wheel diameter	Systematic	Tire compression, nominal size	Distances consistently long or short	Long straight-line test
Encoder resolution	Systematic	Too few ticks per meter	Jittery pose on slow moves	Higher-resolution encoder or gearing
Wheel slip	Non-systematic	Acceleration, loose surfaces	Pose ahead of real position	Dead wheels, traction control, fusion
Bumps and uneven floor	Non-systematic	Field tiles, cables, seams	Random jumps in heading	Suspension, IMU heading
Carpet direction	Non-systematic	Pile pushing wheels sideways	Steady sideways creep	Absolute correction (landmarks)
Collisions	Non-systematic	Contact with walls or robots	Large sudden error	Re-localize after impact

Why heading error is the expensive one

Distance error grows in step with distance traveled. Heading error is worse: it rotates every later meter of travel. Drive 10 m with a 1° heading error and you end up 10 × sin(1°) ≈ 0.17 m to the side. Across a 3.66 m FTC field, a 2° error puts you about 13 cm off.

This answers a very common question: why is odometry accurate going straight but way off after turns? Straight driving barely uses track width. Turning divides by it. If your coded track width is 2% wrong, every 90° turn is mis-estimated by about 1.8°, and each later leg is pointed in the wrong direction.

How to calibrate odometry (UMBmark and a quick shop-floor version)

Calibration fixes systematic errors by measuring them and changing the constants in your code. The reference method is UMBmark, published by Johann Borenstein and Liqiang Feng in “Measurement and Correction of Systematic Odometry Errors in Mobile Robots,” IEEE Transactions on Robotics and Automation, vol. 12, no. 5, October 1996. They report that calibrating with it improved systematic odometric accuracy by at least an order of magnitude.

Distance scale test

Drive straight for several meters, measure the real distance with a tape and scale your wheel diameter by real ÷ reported. A long run matters. Over 30 cm, one encoder tick and a millimeter of tape error can hide a 1% scale error.

Turning scale test

Command ten full rotations in place, measure the final heading against a floor mark and scale the track width by reported ÷ real rotation. Ten turns turn a hard-to-see 0.5° error per turn into a clear 5°.

UMBmark bidirectional square test

UMBmark separates the two main systematic errors, which can cancel each other out in a single-direction test.

The logic is clean. Track-width error (Borenstein’s Type A) causes the clockwise and counterclockwise end points to drift in mirror-image directions. Unequal wheel diameters (Type B) push both directions the same way. Two centroids give two equations and two unknowns. Do not trust one run, because non-systematic errors scatter individual results.

Making odometry better: sensor fusion and absolute corrections

You cannot calibrate away drift, so real robots do two things. They fuse several relative sensors for a smoother short-term estimate. Then they correct that estimate with absolute references that do not drift.

Wheel + IMU fusion

The most common pairing takes distance from wheels and heading from a gyro. Wheels are good at distance, gyros at rotation, and their failure modes rarely coincide. An Extended Kalman Filter (EKF) weights each input by its stated uncertainty. In ROS 2, the robot_localization package provides ekf_node for exactly this. The classic mistake is double-counting: feeding the same quantity (say, yaw from wheels and yaw from the IMU) as if both were independent and fully trusted. That makes the filter overconfident. Fuse each quantity from the sensor that measures it best, and set covariances honestly.

Odometry vs localization vs SLAM

These terms get mixed up constantly. The distinctions are simple.

Concept	Answers	Reference	Drifts?
Odometry	How far and which way have I moved?	Start pose	Yes, grows with distance
Localization	Where am I on a known map?	Existing map	No, if matching succeeds
SLAM	Where am I, and what does the map look like?	Map it builds	Bounded by loop closures
GPS/GNSS	Where am I on Earth?	Satellites	No, but noisy and needs sky view

SLAM uses odometry as its motion model between observations, then corrects it when it recognizes a place it has seen before (loop closure).

When GPS isn’t an option

Indoors, underground or on another planet, absolute fixes come from the environment: AprilTag fiducials on FTC fields, reflectors in warehouses, scan matching against a prebuilt map, or landmarks a camera recognizes. Teams often test these correction pipelines in simulation first, which is one place digital twins in robotics earn their keep.

Odometry pods, dead wheels and tracking wheels (FTC and VEX)

In FIRST Tech Challenge (FTC) and VEX V5, odometry usually means dead wheels: small unpowered omni wheels on encoders, spring-loaded against the field tiles. Game Manual 0 (gm0), the community FTC reference, explains why. Mecanum drivetrains lose traction, so tracking with drive-motor encoders drifts under hard acceleration.

How an odometry pod works

A pod is a free-spinning omni wheel, a quadrature encoder and a spring or swing mechanism that keeps the wheel on the floor. The omni rollers let the wheel slide sideways freely, so each pod measures motion along one axis only. goBILDA sells two pod families: the Swingarm pod with a 48 mm wheel and the 4-Bar pod with a 32 mm wheel.

Can the shaft encoders used for odometry be connected to the driving wheels? Yes, on a traction-wheel tank drive with gentle acceleration that works acceptably. On mecanum, or anything that slips, unpowered wheels win. Are pods ground truth? No. They drift too, just much more slowly: through pod lift over seams, wrong offset values, missed counts at high speed and slight wheel compression.

Two pods + IMU vs three pods

One pod is not enough. It measures forward motion but cannot see sideways drift, so a mecanum strafe goes uncounted. The real choice is between two pods plus an IMU and three pods.

Setup	Sensors	Heading source	Pros	Cons
Drive encoders	Motor encoders	Wheel difference or IMU	No extra hardware	Drifts badly with mecanum slip
3 dead wheels	2 parallel + 1 perpendicular pod	Difference of parallel pods	Heading from same sensors, low lag	Uses three encoder ports, more space
2 dead wheels + hub IMU	1 parallel + 1 perpendicular pod	Control Hub IMU	Fewer parts	Heading can lag or drift more
2 pods + Pinpoint	2 pods + onboard IMU coprocessor	Fused internal IMU	Offloads math from the hub, one I²C cable	Extra device to configure and mount
Optical tracker	SparkFun OTOS	Internal IMU	Tiny, no pods	Sensitive to floor height and texture
VEX tracking wheels	Rotation sensors or 3-wire encoders	Parallel wheels or inertial sensor	Flexible layouts	Port budget, mounting rigidity

Community guidance, such as Studica’s FTC odometry notes, says two-pod systems tend to drift more than three-pod systems because heading comes from an IMU that can lag or drift. With three pods, the two parallel pods set your heading accuracy, so their spacing matters most. A wider gap means each tick of difference represents a smaller angle.

Odometry computers (goBILDA Pinpoint V2)

The goBILDA Pinpoint Odometry Computer fuses two dead-wheel pods with an internal IMU and reports the pose over I²C. It is supported in the FTC SDK. The original Pinpoint is SKU 3110-0002-0001. The Pinpoint V2 (SKU 3110-0002-0002) replaces it, and goBILDA says it expands the security, range and customizability of the data. It works with any quadrature dead-wheel system, not only goBILDA pods. A Pinpoint reset zeroes the pose and recalibrates the IMU, so do it while the robot is stationary. A coprocessor does the integration at a high, steady rate and frees the Control Hub’s loop for path following. Computing on the hub works fine too, but your loop time then sets your odometry update rate.

VEX tracking wheels

VEX V5 teams build tracking wheels with either the V5 Rotation Sensor or the older 3-wire optical shaft encoder. Each 3-wire encoder takes two three-wire ports, so three of them use 6 of the Brain’s 8. The Rotation Sensor uses one Smart Port and is the higher-resolution option, which makes it the usual choice for new builds. If gears sit between the sensor and the wheel, enter the ratio, or every distance will be scaled wrong.

Is inaccurate odometry a code problem or a hardware problem? Check hardware first: wheel contact over the whole field, rigid mounts, correct offsets. Then push the robot by hand along a measured line and a measured rotation. If hand-pushed readings are right but driven runs are wrong, the problem is slip or loop timing, not math.

Odometry in ROS 2

In ROS 2, odometry is published as a nav_msgs/Odometry message and as the odom → base_link transform. The message carries a pose (in the odom frame) and a twist (in the child_frame_id, usually base_link), each with a covariance matrix. If you are new to the framework, it helps to know what ROS 2 is before wiring this up.

The odom frame and REP 105

REP 105 defines the standard frame tree map → odom → base_link. The odom frame is continuous: the robot’s pose in it never jumps, which makes it a good short-term local reference. It also drifts, which makes it a poor long-term one. A localization component (AMCL, SLAM Toolbox or similar) computes the robot’s pose in map. It then publishes map → odom as a correction, leaving odom → base_link smooth. That split answers the common question of how Nav2 gets map → odom: Nav2 does not compute it, your localization node does.

What Nav2 expects

Nav2’s setup guides require the odom → base_link transform plus a nav_msgs/Odometry topic for velocity. Exactly one node may publish odom → base_link. If robot_localization’s EKF publishes it, turn off TF publishing in your diff-drive controller. To check the chain:

ros2 run tf2_ros tf2_echo odom base_link
ros2 topic echo /odom --once

Odometry in the real world: from robot vacuums to Mars

Odometry runs inside nearly every mobile robot, from consumer vacuums to warehouse AMRs to planetary rovers. The pattern repeats everywhere: a relative estimate for smooth short-term motion, corrected by something absolute.

Mars rovers

NASA’s Jet Propulsion Laboratory gives some of the best public data on how wheel odometry fails. On the Mars Exploration Rovers, visual odometry converged 97% of the time on Spirit and 95% on Opportunity. It also let the rovers drive on 15–30° slopes, where wheel odometry alone was untrustworthy.

Perseverance takes this much further. A 2026 JPL paper reports that over 90% of its driving has been autonomous and over 99% has used visual odometry to measure actual position and estimate slip.

Consumer and warehouse robots

Many robot vacuums combine wheel encoders with a gyro and correct drift with lidar or camera mapping. Warehouse AMRs usually fuse wheel odometry and an IMU in the odom frame, then scan-match lidar against a facility map. A legged robot such as a dog robot replaces wheels with leg kinematics and VIO, but the principle is the same.

A short history of the term

Wheel odometry is as old as the odometer, but “visual odometry” is recent. David Nistér, Oleg Naroditsky and James Bergen coined it in their 2004 CVPR paper, choosing the name by analogy with wheel odometry. Their system estimated the motion of a stereo head or a single moving camera in real time.

FAQ

What does odometry mean in plain English?

It means “measuring the way.” A robot works out where it has moved by adding up its own measured motion, like counting your steps with your eyes closed.

How do you pronounce odometry?

oh-DOM-uh-tree, with the stress on the second syllable, the same way as in “odometer.”

What is odometry in robotics?

It is the estimation of a robot’s pose (position and heading) relative to its starting point, using motion sensors such as wheel encoders, IMUs, cameras or lidar.

What is an odometry error?

It is the difference between the computed pose and the real pose. Systematic errors (wrong wheel diameter or track width) can be calibrated out. Non-systematic errors (slip, bumps, collisions) need sensor fusion and absolute corrections.

How do odometry pods work?

A spring-loaded, unpowered omni wheel rolls on the floor and turns an encoder. Because it is not driven, it slips far less than drive wheels. Two or three pods, sometimes plus an IMU, give x, y and heading.

What is odometry used for?

It provides the short-term motion estimate for navigation, path following, autonomous FTC and VEX routines, and the motion model inside localization and SLAM.

What is visual odometry?

It estimates camera motion by tracking visual features between frames. Visual-inertial odometry adds an IMU for scale and robustness.

What is inertial odometry?

It estimates motion from gyroscope and accelerometer data. Gyro heading is reliable over short periods. Position from acceleration drifts quickly because it is integrated twice.

What is wheel odometry?

It converts wheel encoder ticks into distance and heading change, then integrates them into a pose. It is cheap and precise until a wheel slips.

What is the difference between odometry and SLAM?

Odometry only tracks relative motion and drifts. SLAM builds a map while localizing in it, and uses loop closures to correct the drift that odometry accumulates.

Why does my mecanum robot’s position drift when it accelerates hard?

Mecanum rollers lose traction under hard acceleration, so drive-motor encoders count motion that never happened. Track position with unpowered dead wheels or an optical tracker instead.

My SparkFun OTOS is returning incorrect distances despite calibration. Why?

Check mounting height and the floor surface first. Optical trackers are sensitive to both, and a change after calibration shifts the scale. Then recalibrate the linear and angular scalars over long runs.

Where to go from here

If you take one thing from this page, make it this: treat odometry as a short-term estimate that will always need correcting. Calibrate the systematic errors once with a long straight run, a ten-turn spin and a bidirectional square. Then design for the drift that remains: dead wheels on slippy drivetrains, a gyro for heading, and an absolute reference (AprilTags, a map or GPS) that pulls the estimate back.

Keep reading

Autonomy & PerceptionMicro Air Vehicles Explained With Real ExamplesA micro air vehicle (MAV) is a very small uncrewed aircraft, classically defined by DARPA as no larger…Oct 28, 2026 · 6 min readAutonomy & PerceptionAurora and Its Self Driving Trucks Explained SimplyAurora Innovation is a Pittsburgh-based self-driving technology company that builds the Aurora Driver, a hardware and software system…Oct 21, 2026 · 6 min readRobotics NewsAgile Robots’ $8.5B valuation rests on a 2,000-humanoid target the company set for 2026Agile Robots raised $500M at $8.5B, led by SoftBank with Nvidia. Its humanoid output figures are company claims,…Nov 12, 2026 · 4 min read

Credits and sources

By RWT Robotics Editorial Team

• Facts were checked against the sources below before publication.
• Published November 12, 2026

Checking and sources

• Researched from 8 sources, listed below.
• Facts are checked against those sources; anything we cannot confirm is corrected, labelled or removed.

Sources (8)

1. Odometer – Merriam-Webster (merriam-webster.com)
2. Borenstein & Feng, Measurement and Correction of Systematic Odometry Errors in Mobile Robots (UMBmark) (apps.dtic.mil)
3. Borenstein & Feng 1996 paper (systematic odometry errors) (cs.au.dk)
4. Nistér, Naroditsky, Bergen – Visual Odometry (CVPR 2004) (mlanthology.org)
5. NASA JPL – Two Years of Visual Odometry on the Mars Exploration Rovers (robotics.jpl.nasa.gov)
6. NASA JPL 2026 paper on Perseverance autonomous driving (robotics.jpl.nasa.gov)
7. Modern Robotics 13.4 Odometry (modernrobotics.northwestern.edu)
8. REP 105 – Coordinate Frames for Mobile Platforms (reps.openrobotics.org)

How we make this