QUADRATURE ENCODING.

A single-channel encoder only counts ticks, so it can tell you the wheel moved but not which way. Quadrature uses two channels (A and B) that are physically offset, and the order in which their edges arrive recovers direction as well as speed. That is what lets the odometry distinguish rolling forward from rolling backward, which matters the moment the car reverses out of a wall.

FROM COUNTS TO /odom.

THE RESOLUTION TRADEOFF.

Counts per revolution (CPR) is the knob that sets how finely the encoder resolves motion. A higher CPR means each tick covers a smaller slice of wheel travel, so the odometry is finer. The cost is that every edge is an interrupt the MCU has to service, so a higher count puts more load on the microcontroller. The two pull against each other, which is the tension worth keeping in mind when you read an odometry value and wonder how precise it really is.

FUSION WITH LiDAR.

On its own, odometry drifts. Run long enough and the dead-reckoning position wanders away from the truth. That is fine, because the osracer SLAM and Nav2 stack does not trust it alone. It fuses the odometry from /odom with the LiDAR scans, using the encoders to fill in the motion between scans and the LiDAR to correct the drift. Together they let the car map and localise, which neither signal does well by itself.

• Encoders give continuous, high-rate motion between LiDAR frames.
• LiDAR gives absolute structure that pins the drift back down.
• The /odom topic is where the fused estimate starts, listed alongside every other ROS 2 topic.

SPECIFICATIONS.