2026-06-27
Incremental encoders (covered last time) count edges from wherever they happened to be at power-up. That's fine for a mouse wheel, but a disaster for a robot arm that needs to know "am I about to swing into the wall?" before it moves. Absolute encoders report a unique code for every shaft position — no homing routine, no lost-count failures after a power glitch.
The two main flavors:
Single-turn vs multi-turn: A bare absolute encoder only knows position within one revolution. For multi-turn knowledge (e.g. lead-screw position over 50 turns), you either add a mechanical gear-reduction stage with a second encoder, or use a battery-backed turn counter — a tiny ultra-low-power counter that keeps ticking from a coin cell when main power is off. Lose the battery, lose the count.
Resolution math, rule of thumb: Resolution in degrees = 360° / 2ⁿ. So 10-bit = 0.35°, 12-bit = 0.088°, 14-bit = 0.022°. But accuracy is usually 5–20× worse than resolution due to magnet eccentricity, nonlinearity, and noise — an AS5048 datasheet brags 14-bit resolution but only ±0.05° accuracy after calibration. Don't confuse the two when sizing a system.
Real-world example: A 6-axis collaborative robot arm (think Universal Robots) uses absolute magnetic encoders on every joint, both pre- and post-gearbox. On power-up the controller instantly knows all six joint angles to ~0.01°, so the arm can resume a paused task without re-homing. Combine that with the post-gearbox encoder catching backlash, and you get the smooth, predictable motion that makes cobots safe to work alongside.
SPI gotcha: Most magnetic encoder ICs use SPI mode 1 (CPOL=0, CPHA=1), not the more common mode 0. Wire it up assuming mode 0 and you'll get garbage data with no error — check the datasheet timing diagram before debugging your code for three hours.
