How to build a reliable odometry system for FTC

A reliable FTC robot knows where it is on the field, rather than only where its motors were commanded to go. How to build a reliable odometry system for FTC starts with separating wheel odometry from full pose estimation: encoders measure wheel motion, while inertial or visual sensors can correct heading and position. The result supports repeatable paths, accurate alignment, and faster recovery when the drivetrain slips.

Most failures come from inconsistent assumptions, not weak hardware. Teams mix millimetres and inches, reset the robot at the wrong moment, or tune on carpet before competing on another surface. A dependable design uses one coordinate frame, one clock, repeatable calibration, and explicit rules for uncertain measurements. It also logs enough data to show whether an error began with a sensor, the estimator, or the mechanism.

Choose the right sensor architecture

First, match the architecture to the job. Position that resets at a known field location may need only encoders and a gyro. A robot that hunts, scores, or avoids obstacles from variable positions benefits from external correction. Wheel odometry is excellent over short distances, but slip, wheel-radius error, and gyro drift accumulate with time.

Sensor approach	Main inputs	Primary strength	Main weakness	Best fit
Wheel encoders	Driven wheel counts	Low cost and low latency	Slip and scale drift	Short, reset-based routes
Encoders plus gyro	Wheel counts and gyro rate	More reliable heading	Gyro bias accumulates	Most general FTC robots
Full inertial fusion	Encoders, gyro and accelerometer	Better motion consistency	Vibration and tuning burden	Bumpy or uneven surfaces
Vision-assisted	Camera target plus odometry	Absolute field correction	Lighting, occlusion and latency	High-accuracy positioning
Layered fusion	Encoders, IMU and optional vision	Graceful degradation	More code and validation	Mature competition systems

For most FTC platforms, use quadrature encoders on every driven wheel and a separate IMU for yaw. The IMU should be mounted rigidly near the robot’s centre, away from motors and power wiring. A gyro measures rotation directly, whereas accelerometer data is too noisy under drivetrain vibration to treat as a position sensor. Mecanum systems need special care because sideways motion relies on opposing wheel slips that an ordinary forward-motion model cannot interpret.

Vision can provide an absolute position check where the rules and processing budget allow it, but it should correct the estimate rather than replace it. Camera latency, changing lighting, and field occlusion can interrupt a visual fix. A practical design runs dead reckoning continuously, applies a confidence-weighted correction when a reference appears, and preserves the last trustworthy pose during a brief dropout.

Build hardware that suits Australian teams

Hardware reliability begins with the drivetrain, not the estimator. Measure each wheel’s actual rolling radius, check encoder direction in software, and make the chassis rigid enough that wheel loads do not distort the frame. Secure encoder connectors, add strain relief, and route motor cables away from the IMU. Keep spare encoder cables, motor connectors, and matched wheels on hand, because competition repairs are easier when the team can replace parts without changing the mechanical setup.

Australian teams in Melbourne, Sydney, and Brisbane can source through local robotics distributors and Australian online stores, while direct international orders may require customs paperwork and extra courier time. Budget in Australian dollars and allow for the 10 per cent GST that may apply to imported goods; some low-value purchases can have different treatment. Compare landed cost and delivery time before ordering, then run every new part through the same calibration process. Buying one motor early is usually better than buying several mismatched units on event day.

Design for the local event environment as well. Australian teams often measure and record distances in metres, so use a 2-metre tape baseline and keep the estimator’s base unit consistent even when a manual uses inches. In Perth, summer heat and dust can affect electronics; elsewhere, repeated travel between venues can loosen fasteners and expose cables to wear. A ventilated battery bay, labelled wiring, and a torque-check routine reduce field failures, while a modular drivetrain makes field repairs faster.

A reliable build also depends on continuity. New drivers and returning students should inherit the same configuration and test habits. For Australian feeder teams, Maryland FIRST Robotics’ Junior FIRST LEGO League program can serve as an age-appropriate model for introducing younger builders and structuring mentor handovers.

Implement a consistent estimation pipeline

Adopt a simple frame before writing complex code. Put the robot’s reference point at the centre of the drivetrain, call forward motion positive x, leftward motion positive y, and counter-clockwise rotation positive yaw. Store one internal angle unit, preferably radians. All modules should consume the same timestamp and publish pose estimates in the same frame; otherwise tiny differences in when a sensor is sampled become visible path errors.

At each update, convert encoder counts into distance using a calibrated distance-per-count value, then add the measured change in wheel travel to the position estimate. Update heading with gyro rate multiplied by elapsed time. For planar robots, a complementary filter or lightweight Kalman filter can blend the gyro with encoder-based heading, using a larger correction when the two disagree beyond an expected threshold. Increase measurement noise after bumps or wheel slip so one bad reading cannot dominate the estimate.

Treat resets and dropouts as normal operating conditions. Re-zero only on a level, stationary surface, and make the starting pose an explicit input. When an encoder reports impossible speed, the IMU becomes inconsistent, or the camera loses its target, flag the estimate, avoid applying a large correction, and continue with a reduced confidence. Log raw counts, gyro rate, update interval, correction magnitude, battery voltage, and pose at a manageable rate. Those traces make tuning evidence-based rather than anecdotal.

Test with a repeatable calibration routine

Calibration should be a repeatable experiment. On the same floor used for practice, push the robot along a measured 2-metre line in both directions and rotate it through two full turns. Repeat each run several times. Use the average count-to-distance scale while checking the spread; a large variation points to slipping, loose wheels, or encoder noise before it points to software. Compare the robot’s final pose with the physical marks to reveal yaw and scale errors separately.

Next, test a short route with a 90-degree turn and a final return to the start. The route should end within a defined position and heading tolerance on every run, not merely on an average run. Repeat after a battery change, after a heavy match, and after transporting the robot. Keep the software version, floor type, tyre condition, and battery level with each result, because a change in any of those variables can justify recalibration.

• Run three complete routes before tuning, and record the worst error as well as the average.
• Measure forward, backward, and turning distances separately instead of applying one scale factor everywhere.
• Save a named calibration file for each robot configuration and date it after verification.
• Test with realistic payloads and cables fitted, not with an empty chassis that moves more freely.
• Review logged corrections after practice and remove any filter setting that hides wheel slip.

Make these results part of a team ritual: one person records, one checks the route, and one reviews the logs before the next run. Every test should answer a specific question, such as whether a heading correction reduced the final error or merely moved it elsewhere. A change should be accepted only after repeated runs show a clear improvement.

Turn odometry knowledge into community action

Reliable odometry is ultimately a shared engineering asset. Publish the coordinate convention, calibration files, test route, and known failure modes so another mentor can reproduce the work. Ask sponsors to support repeatable test surfaces and spare components rather than only visible robot parts. Teams can then compare results, organise joint workshops, and involve university students or local engineers without rebuilding the entire estimator.

Before applying this workflow, connect with the wider robotics community through the NConnect community, then use local FIRST Tech Challenge Australia groups, school clubs, and regional events to exchange testing methods. Choose one baseline design for the next meeting, collect one week of route data, and document the improvement. Share the configuration with another Australian team and invite feedback at the next event. Build the baseline now, keep every assumption visible, and turn the next practice session into a measured step toward a robot that knows exactly where it is.