Blog · 2026-07-05 · Odometry
The encoder is the sense organ that turns a spinning shaft into numbers. Here's how the main types work, what the confusing specs actually mean, how to read one without dropping counts, and which kind belongs on your robot.
A motor without an encoder is open-loop: you command power and hope. Add an encoder and the motor becomes a conversation — you command, the shaft reports back, and suddenly velocity control, position moves and odometry are all on the table. For such a transformative part, encoders are cheap (often built into the motor for a couple of dollars extra) and conceptually simple. The complexity, and all of the beginner pain, lives in the terminology and in reading them correctly at speed.
An incremental encoder answers "how much did the shaft move since last time?" It emits pulses as the shaft turns; your code counts them. Power-cycle the robot and the count restarts at zero — the encoder has no idea where the shaft is, only how it changes. This is what's inside virtually every encoder gearmotor, and it's exactly what drive odometry and velocity control need, since both are about change.
An absolute encoder answers "what angle is the shaft at right now?" — it reports a unique value for every position, retained through power cycles. The hobby favourite is the AS5600-style magnetic angle sensor: a diametrically magnetized magnet on the shaft end, a chip beneath reading the field angle to 12 bits (4,096 positions per turn). Absolute encoders shine on robot arm joints and steering axes, where "where is it?" at boot-up matters and you'd otherwise need a homing routine or limit switches.
Optical encoders shine light through (or off) a slotted disc onto a photodetector — high resolution, clean signals, but vulnerable to dust and shock, which is why they dominate lab equipment more than combat robots. Magnetic encoders read a rotating magnet with Hall-effect sensors — lower native resolution, but sealed, shockproof, dirt-immune and dirt-cheap; the little board on the back of an N20 or 37 mm gearmotor is a magnetic quadrature encoder. Conductive/mechanical encoders (the clicky knobs on control panels) use wiping contacts; fine for human input at human speeds, hopeless on a motor shaft where they'd wear out in hours and bounce constantly. For robot drivetrains the default answer is magnetic incremental; for joints needing absolute angle, magnetic absolute.
A single-channel encoder can count pulses but cannot tell direction — the pulse train looks identical spinning either way. The fix is quadrature: two channels, A and B, offset by a quarter cycle (90°, hence the name). Now the signal pair cycles through four states — 00, 01, 11, 10 — and the order of states reveals direction: A leading B means one way, B leading A the other. Direction detection is why nearly every motor encoder has two outputs.
1× decoding: count rising edges of A only → PPR counts/rev
2× decoding: count both edges of A → 2 × PPR
4× decoding: count every edge of A and B → 4 × PPR
Quadrature also quietly multiplies resolution. Since each pulse cycle contains four distinct state transitions, counting every transition (4× decoding) yields four counts per pulse — free resolution, at the cost of four times the interrupt rate. This brings us to the spec-sheet minefield.
PPR (pulses per revolution) is the number of full pulse cycles per channel per shaft turn — a physical property of the disc or magnet. CPR (counts per revolution) usually means PPR × 4, the counts after full quadrature decoding — but some datasheets use CPR to mean PPR, some say "resolution" and mean either, and motor listings compound it by sometimes quoting counts at the gearbox output instead of the motor shaft. A "1320 CPR" gearmotor might be an 11 PPR encoder × 4 decoding × 30:1 ratio, measured at the wheel. The defence is empirical: rotate the output shaft exactly one turn by hand, read your accumulated count, and let reality define your constant. The Odometry Calculator then converts that verified number into mm-per-count and warns you about the interrupt load.
Missed counts don't announce themselves; they just silently corrupt position. Three escalating strategies:
Interrupts (the default). Attach an interrupt to channel A (and B for 4×), read the pin states, update the count via a state table. On an Arduino Uno–class board this is reliable up to roughly 20–50k edges per second total; beyond that, interrupt overhead starts eating the CPU and edges get dropped, especially if other libraries disable interrupts (Servo, NeoPixel and software serial are notorious).
Hardware counters (the upgrade). Modern microcontrollers count quadrature in silicon: ESP32's PCNT peripheral, RP2040's PIO, STM32 timers in encoder mode. Zero CPU cost, no missed edges at any hobby-relevant speed. If you're choosing a board for a robot with encoders, this feature should be on the checklist.
Off-board counting. Dedicated decoder chips or the encoder inputs built into smart motor drivers (ODrive-style controllers, RoboClaw) move the whole problem off your processor and hand you a register to read.
Whatever the method, add the electrical hygiene: pull-ups on open-collector outputs, twisted or short encoder wires kept away from motor leads (PWM edges love to couple into encoder lines and appear as phantom counts), and 100 nF capacitors only if the datasheet permits — RC filtering that's too aggressive rounds edges enough to break fast quadrature.
| Application | Pick | Why |
|---|---|---|
| Drive motors / odometry | Magnetic incremental on motor shaft | Free resolution via gear ratio; rugged |
| Arm or steering joint | Magnetic absolute (AS5600 class) | Knows position at power-up, no homing |
| Precision positioning | Optical incremental, high PPR | Resolution and signal quality |
| Human input knob | Mechanical detented | Cheap, tactile, slow is fine |
| Retrofit to plain motor | Ring-magnet kit or reflective optical strip | No shaft machining needed |
On resolution: buy for the job, not the biggest number. Drive odometry saturates its usefulness around 1,000–2,000 counts per wheel revolution (sub-0.2 mm per count — slip dominates beyond that, as covered in Wheel Odometry Explained). Velocity PID wants enough counts per control period to compute smooth speed, which motor-shaft mounting behind a gearbox almost always provides. An arm joint doing slow precise moves is where genuinely high resolution (12-bit absolute and up) earns its cost.
Better incremental encoders add a third channel, Z or index — one pulse per revolution at a fixed angle. It gives an incremental encoder a repeatable reference: home the axis once against the index and you have near-absolute behaviour with incremental hardware, which is exactly how CNC machines and brushless-motor commutation setups use it. Differential outputs (A+/A−, B+/B−) are the other premium feature, transmitting each channel as a voltage pair so noise picked up along the cable cancels at the receiver — worth it for encoder cables longer than ~30 cm sharing a chassis with high-current motor wiring.
Often, yes. If the motor has a rear shaft stub, glue a diametric magnet on it and mount an AS5600 board behind it. No rear shaft: a reflective optical sensor reading a printed stripe pattern on a wheel or gear works, at modest resolution. Wheel-shaft mounting is also always available — you lose the gear-ratio multiplication but gain immunity to gearbox backlash.
The count itself doesn't — digital counting is exact. What drifts is the inference: position estimated from counts inherits every slip and calibration error. Absolute encoders don't drift at all within a turn; multi-turn tracking of an absolute encoder can, if reads are missed while the shaft moves more than half a revolution.
An unpowered, spring-loaded wheel whose only job is carrying an encoder. Because no torque flows through it, it doesn't slip under acceleration — the highest-accuracy odometry input available to a competition robot short of external sensing.
Before a new encoder earns your trust, run this bench sequence. First, the one-turn test: zero your count variable, rotate the output shaft exactly one revolution against a pencil mark, and read the accumulated count — this single number verifies PPR, decoding factor and gear ratio all at once, and it's the constant your odometry should actually use. Second, the direction test: rotate each way and confirm the count rises and falls as your code expects; if it's inverted, swap the A and B channel assignments in software rather than rewiring. Third, the return-to-zero test: spin the shaft back and forth vigorously for thirty seconds, then return to the pencil mark — the count should land within a handful of ticks of zero. A count that walks steadily away means missed edges (interrupt overload or noise), and it's far cheaper to discover that on the bench than to discover it as a robot that thinks it's somewhere it isn't.
With the encoder understood and verified, the counts are trustworthy — and turning trustworthy counts into position is precisely the subject of Wheel Odometry Explained. Start with your own hardware's numbers in the Wheel Speed & Odometry Calculator.