Wheel encoder

Wheel encoder – definition

A wheel encoder is a sensor that measures wheel rotation and converts it into discrete counts, pulses, or angular position data. In mobile robotics, it is used to estimate traveled distance, wheel speed, and robot motion. On a UGV with differential drive, such as Leo Rover, wheel encoder data is one of the basic inputs for odometry.

In practice, a wheel encoder does not measure global position. It measures wheel motion at the drivetrain level. Position in the odom frame is then estimated by integrating wheel rotations over time with a kinematic model. In ROS and ROS 2 systems, encoder-derived odometry is usually published as nav_msgs/Odometry, while transforms are published according to the frame conventions defined in REP 105 and units follow SI conventions from REP 103.

For UGV platforms, the term usually refers to incremental rotary encoders mounted on a motor shaft, gearbox output, or wheel axle. Absolute encoders also exist, but they are less common in small and mid-size research rovers. On Leo Rover and Raph Rover, wheel encoders are relevant for dead reckoning, velocity control, low-level state estimation, and fusion with IMU, GNSS, LiDAR, or visual odometry.

How wheel encoders work on mobile UGV platforms

The encoder produces a sequence of electrical transitions as the shaft rotates. These transitions are counted by a motor controller, MCU, or embedded computer interface. The count difference over a time interval gives angular displacement and angular velocity.

For a wheel with radius r and encoder resolution N counts per revolution, the linear distance from one wheel can be approximated as:

distance = 2 * pi * r * (delta_counts / N)

For a differential-drive robot, left and right wheel distances are combined into body motion. If dL and dR are left and right wheel distances and b is wheel separation, then:

d_center = (dR + dL) / 2
d_theta  = (dR - dL) / b

This model is standard for differential-drive odometry. It works well on flat terrain and short trajectories. Accuracy drops when slip, deformation, backlash, or uneven ground are significant. This matters on outdoor UGVs more than on indoor lab robots.

Encoder data in ROS 2

ROS 2 does not define one universal raw encoder message in core packages. Integrators usually expose encoder counts through a hardware interface, a custom topic, or directly through ros2_control. The derived outputs that matter most for the rest of the autonomy stack are joint states, wheel velocities, odometry, and TF.

In a typical ROS 2 setup, encoder data appears in these interfaces:

sensor_msgs/JointState – wheel joint position and velocity
nav_msgs/Odometry – integrated robot pose and twist in the odometric frame
tf2 transforms – typically odom -> base_link
ros2_control hardware state interfaces – position and velocity for wheel joints

Frame semantics should follow REP 105. Units should follow REP 103, which means radians, meters, seconds, and SI-derived quantities. For navigation in Nav2, encoder odometry is usually one of the motion sources fused in robot_localization.

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    two_d_mode: true
    odom_frame: odom
    base_link_frame: base_link
    world_frame: odom
    odom0: /wheel/odometry
    odom0_config: [false, false, false,
                   false, false, false,
                   true, true, false,
                   false, false, true,
                   false, false, false]
    imu0: /imu/data
    imu0_config: [false, false, false,
                  false, false, true,
                  false, false, false,
                  false, false, true,
                  true, false, false]

This example fuses planar velocity and yaw rate from wheel odometry with IMU orientation, angular velocity, and linear acceleration. It is a common baseline for UGV state estimation in ROS 2 Humble and newer distributions.

Key parameters and metrics

Encoder quality is not described by a single number. The useful parameters depend on where the encoder is mounted and how the drivetrain is built. For a rover, the combination of encoder resolution, gearbox ratio, wheel diameter, and controller update rate determines odometry granularity.

Parameter	Meaning	Why it matters
CPR / PPR	Counts or pulses per revolution	Sets angular measurement granularity
Quadrature	Two-channel phase-shifted output	Enables direction detection and x4 counting
Mounting point	Motor shaft, gearbox output, wheel axle	Changes effective resolution and backlash sensitivity
Update rate	How often counts or velocity are reported	Affects control loop stability and estimator latency
Wheel radius	Effective rolling radius	Directly affects distance estimation
Track width	Distance between left and right wheel contact centers	Directly affects yaw estimation

Two calibration values have especially high impact: effective wheel radius and wheel separation. Even if the mechanical CAD is known, real odometry often improves after empirical calibration because tire compression and terrain change the effective geometry.

Practical use on Leo Rover and Raph Rover

On Leo Rover, wheel encoders are a primary source for local motion estimation on a compact differential-drive platform. The onboard compute unit is Raspberry Pi-based, and ROS 2 support is available. This makes encoder odometry a practical base layer for teleoperation feedback, dead reckoning, and integration with SLAM or Nav2. It should not be treated as sufficient for full outdoor autonomy by itself.

Typical Leo Rover use cases include:

estimating short-range displacement indoors or on hard surfaces
closing the wheel velocity control loop
providing odometry to LiDAR SLAM or visual SLAM as a motion prior
fusing wheel odometry with IMU in robot_localization

On Raph Rover, the same principles apply, but payload, mass, and terrain profile are usually more demanding. A heavier UGV may experience stronger wheel slip on soil, gravel, or construction surfaces. In such cases, encoder data remains useful, but it usually needs fusion with IMU and, if available, GNSS/RTK or LiDAR-based localization.

Limitations and trade-offs

Wheel encoders are simple, low-cost, and deterministic. Their main weakness is that they measure wheel rotation, not actual vehicle displacement over ground. Any wheel slip creates systematic odometry error.

Common error sources include:

wheel slip during acceleration, braking, or turning
uneven terrain and partial wheel lift
gearbox backlash and drivetrain compliance
incorrect wheel radius or track width parameters
low count resolution at very low speed
timestamp jitter between MCU and ROS 2 host

These limitations are important for outdoor robotics. A UGV operating in agriculture, inspection, or field research should not rely on encoder odometry alone for long-range localization. The standard engineering approach is sensor fusion. Encoders provide short-term motion continuity, while IMU stabilizes orientation and exteroceptive sensors bound long-term drift.

Implementation notes and ROS 2 example

In a ROS 2 differential-drive stack, encoder feedback is often handled through diff_drive_controller in ros2_control. The controller consumes wheel joint state and publishes odometry and TF. Exact parameters depend on the hardware interface and drivetrain.

diff_drive_controller:
  ros__parameters:
    left_wheel_names: ["left_front_wheel_joint", "left_rear_wheel_joint"]
    right_wheel_names: ["right_front_wheel_joint", "right_rear_wheel_joint"]
    wheel_separation: 0.38
    wheel_radius: 0.0625
    publish_rate: 50.0
    base_frame_id: base_link
    odom_frame_id: odom
    enable_odom_tf: true
    use_stamped_vel: false

For verification, inspect odometry and TF consistency during straight runs and in-place rotations. A quick ROS 2 check may look like this:

ros2 topic echo /odom
ros2 topic hz /odom
ros2 run tf2_ros tf2_echo odom base_link

If yaw drift during pure straight motion is high, the first checks should be wheel radius symmetry, encoder sign convention, left-right scaling, and track width calibration.

Normative references and standards

The concept of wheel encoder itself is hardware-specific, but its use in ROS-based mobile robotics is constrained by standard message, unit, and frame conventions. The most relevant references are REP 103 for standard units and coordinate conventions, and REP 105 for mobile platform frames such as base_link, odom, and map. For implementation, ROS 2 packages such as ros2_control, diff_drive_controller, and robot_localization define the practical integration pattern used on UGV platforms.