Odometry is the foundation of autonomous consistency. This page explains the two main FTC layouts and how to calibrate them using your Decode codebase.
Layouts
Two pods + IMU: most common FTC architecture.Three pods: better redundancy, more mechanics to maintain.
Compare
Type
Good For
Main Cost
2-pod + IMU
Beginner and intermediate teams, simpler maintenance, lighter design
Heading depends heavily on IMU quality and calibration
3-pod
Teams needing stronger independent heading estimation from odometry
More hardware complexity and higher mechanical tuning overhead
National Pedro reference: .../pedroPathing/Constants.java
Step 2
Set Correct Hardware Names and Signs
Mismatch here will produce fake drift and impossible trajectory tuning.
parallelEncoder = new Encoder(hardwareMap.get(DcMotorEx.class, "Back_Left"));
perpendicularEncoder = new Encoder(hardwareMap.get(DcMotorEx.class, "Back_Right"));
// Check reversals based on your mount direction
// parallelEncoder.setDirection(...);
// perpendicularEncoder.setDirection(...);
Step 3
Calibrate in This Order
Encoder direction and unit conversion first.
IMU heading offset and orientation second.
Path follower and marker timing last.
If you tune follower gains before localization is stable, every later result becomes unreliable.
Step 4
Run Standard Tests
Straight 2m forward/back endpoint check.
Square path endpoint + heading error check.
Repeated quick stop/start to catch pod slip issues.
Full-cycle test with shooter vibration to detect mount flex.
Step 5
Use Vision as an Assist, Not a Crutch
AprilTag pose refresh can reduce long-run drift.
Only apply pose correction under safe conditions (stationary/valid tags).
Your base odometry should still work even with camera blocked.
Next
Continue to Road Runner 0.5.6 Implementation to connect localization into full autonomous cycle paths.