Unit 5 · Week 9

What Odometry Is

Knowing where the robot is, anywhere on the field, all the time.

You'll learn

What position tracking means and why top teams use it.
The coordinate system: x, y, and heading (θ).
How odometry beats dead reckoning.

The core idea

An Absolute Positioning System keeps track of the robot's position (cartesian coordinates) and orientation (heading) at every moment. With odometry, instead of saying "drive forward 24 inches", you can say "drive to point (48, 36) and face 90°". The robot figures out the path itself.

Real impact: the Pilons (team 5225) credit their odometry-based motion control system as a major reason they won the 2018 VEX Worlds. Once you know where you are, autonomous becomes a planning problem instead of a sequence of guesses.

The coordinate frame

Pick a corner of the field as (0, 0). Measure x and y in inches. Measure θ (the robot's heading) in radians or degrees, pick one and stick with it. Use inches and radians internally because the C++ trig functions take radians natively.

How is this different from dead reckoning?

Dead reckoning, drive 24 inches, turn 90, drive 12. If any step is off, all later steps are off too. Errors stack.
Odometry, every 10 ms, update the robot's best guess at (x, y, θ). When you want to go somewhere, calculate the path from where you actually are right now.

What you need to make odometry work

Sensors that measure how each wheel has moved (the built-in motor encoders work; dedicated tracking wheels work even better).
An update loop that runs at high frequency (every 10–20 ms).
The math that turns encoder changes into (Δx, Δy, Δθ).

That last part is the tricky bit. Next week we'll write the actual update loop. For now, the goal is to understand why odometry exists and what it tracks.

Why this matters for VEX IQ specifically

Most IQ teams don't use full odometry, they use dead reckoning because IQ matches are short and the field is small. But understanding odometry gives you superpowers: smarter autonomous routines, position-based logic (e.g., "if I'm closer to the goal than the opponent, do X"), and a head start when you move to V5 or FRC.

Curated references

Find the Bug

Two odometry concept questions with code that looks reasonable but is wrong.

Problem 9A

A teammate writes this to update the robot's x and y position. The x and y values are wildly wrong. The math seems right. What's the bug?

double poseT = 90;   // heading in degrees
double d     = 5.0;  // moved 5 inches

poseX += d * cos(poseT);
poseY += d * sin(poseT);

Problem 9B

This code is supposed to track the robot's heading by reading both wheels. The heading drifts badly even when the robot moves perfectly straight. Why?

double leftInches  = ticksToInches(LeftMotor.position(degrees));
double rightInches = ticksToInches(RightMotor.position(degrees));

poseT = leftInches / TRACK_WIDTH;
// (heading updated using only the left wheel)

← Week 8 Next: Odometry Code →