THE MOTOR ENCODER.
A Hall-effect encoder on the motor shaft reports how far the drivetrain has turned. The MCU (microcontroller unit) counts its pulses in hardware, folds in the gear ratio and the car's steering geometry, and publishes the result on /odom at ~200 Hz. That is the car telling you, between LiDAR scans, how far and how fast it has travelled.
SHAFT-SIDE COUNTING.
The encoder sits on the motor shaft, before the gearbox, which is the right side to measure from: one wheel turn is many shaft turns, so every centimetre of travel produces plenty of pulses. The MCU's hardware pulse counter tallies them without interrupting the processor, which is how the count stays honest even at full speed.
FROM COUNTS TO /odom.
Counted on the shaft
Fused on the MCU
Published on /odom
WHAT SETS THE PRECISION.
Three numbers decide how finely the odometry resolves motion: the pulses per shaft revolution, the gear ratio, and the wheel diameter. Together they set how much ground one pulse represents. Measuring on the shaft side of the gearbox multiplies the resolution by the gear ratio, which is why a simple Hall sensor is enough for clean odometry.
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 SLAM and Nav2 stack does not trust it alone. It fuses the odometry from /odom with the LiDAR scans, using the encoder 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.
- The encoder gives continuous, high-rate motion between LiDAR frames.
- LiDAR gives absolute structure that pins the drift back down.
- The /odom topic is where the estimate starts, listed alongside every other ROS 2 topic.
SPECIFICATIONS.
| Field | Value |
|---|---|
| Encoder type | Hall effect |
| Location | Motor shaft (one encoder) |
| Counting | MCU hardware pulse counter |
| Topic | /odom at ~200 Hz |
| Message | nav_msgs/Odometry |