Wheel Odometry Calculator

Convert wheel encoder tick counts into position, heading change, linear velocity, angular velocity, and turning radius — the foundational calculation in every differential-drive robot’s base controller and ROS 2 odometry node.

⚙️ Input Parameters

Wheel Configuration

Ticks per Revolution

Common: 512, 1024, 2048, 4096

Wheel Diameter (m)

Measure actual outer tyre diameter

Wheel Separation (m)

Distance between tyre contact patches

Encoder Readings (this interval)

Left Wheel Ticks (Δ)

Increment since last update

Right Wheel Ticks (Δ)

Time Interval (ms)

Encoder polling period

📊 Results

⚙️

Enter encoder tick counts for one time interval to compute position, heading, and velocity for your differential-drive robot.

Centre Distance Travelled

—m

Left wheel distance—

Right wheel distance—

Heading change Δθ—

Linear velocity v—

Angular velocity ω—

Turning radius—

Wheel Odometry: The Foundation of Robot Dead-Reckoning

What This Calculates

Wheel odometry converts encoder tick counts into robot motion estimates using the differential drive kinematic model. The robot travels straight when both wheels turn equally; it turns when they differ. Δθ = (d_right − d_left) / wheel_separation captures this precisely. This runs continuously as a baseline in every robot, even those using SLAM or GPS correction.

When to Use It

Verifying your ROS 2 odometry node calculations before deployment
Debugging unexpected robot heading drift per-interval
Converting encoder resolution to real-world distance during robot setup
Calculating expected odometry accuracy over a test trajectory
Understanding odometry error before adding SLAM correction

Formula

d_L = (ticks_L/TPR) × π × diameter d_R = (ticks_R/TPR) × π × diameter d_centre = (d_L + d_R) / 2Δθ = (d_R − d_L) / wheel_separation v = d_centre / Δt ω = Δθ / Δt R_turn = d_centre / Δθ

ROS 2 connection: These values map directly to nav_msgs/Odometry: twist.linear.x = v, twist.angular.z = ω. Pose is accumulated by integrating Δθ and d_centre at each step: x += d_centre × cos(θ), y += d_centre × sin(θ), θ += Δθ. See the UDHY ROS 2 Jazzy Tutorial for a complete Python implementation of this odometry node.

Built by Dr. Dilip Kumar Limbu · Co-Founder, MooVita · Former Principal Scientist, A*STAR · UDHY Engineering Tools

FAQs on Wheel Odometry Calculator

1. How do I convert encoder ticks to distance for wheel odometry?

The formula is: distance = (ticks / ticks_per_revolution) × π × wheel_diameter. For a wheel with 1024 ticks per revolution and 0.3m diameter: one full revolution = 1024 ticks = π × 0.3 = 0.942m. For 512 ticks: distance = (512/1024) × 0.942 = 0.471m. This calculator handles the conversion automatically — enter your encoder resolution, wheel diameter, and tick count for instant results. Always measure actual outer tyre diameter rather than using nominal size, as tyre compression under load reduces effective diameter by 1–3%.

2. How does differential drive odometry calculate heading change?

Heading change Δθ = (d_right − d_left) / wheel_separation. If both wheels travel equal distance, Δθ = 0 (straight line). If the right wheel travels further, Δθ is positive (turning left in the standard convention). Wheel separation must be measured accurately — even 5mm of error introduces a systematic heading error that compounds into significant position error over long trajectories. Calibrate wheel separation empirically by commanding the robot to rotate exactly 360° and measuring actual rotation, then adjust the parameter until the measured rotation matches.

3. What is the difference between linear velocity and angular velocity in differential drive?

Linear velocity (v) is the speed of the robot’s centre of mass along its heading direction: v = average_distance / time_interval. Angular velocity (ω) is the rate of heading change: ω = Δθ / time_interval. These map directly to ROS 2’s nav_msgs/Odometry: twist.linear.x = v and twist.angular.z = ω. A robot moving straight has v > 0 and ω = 0; a robot spinning in place has v = 0 and ω > 0; a robot following a curved path has both v > 0 and ω ≠ 0.

4. How accurate is wheel odometry for robot navigation?

Accuracy depends primarily on wheel slip, encoder resolution, and calibration accuracy. In ideal indoor conditions (smooth, level, hard floor), wheel slip below 0.5% is achievable, giving position error under 0.5m per 100m of travel. Outdoors on varied terrain, slip can be 2–10%, giving 2–10m error per 100m — unusable for navigation without correction. This is why practical robots augment odometry with IMU, SLAM, or external localisation. Use the SLAM Accuracy Estimator to see how loop closure corrects accumulated odometry drift.

5. How do I map wheel odometry calculations to ROS 2?

In ROS 2, wheel odometry is published on the /odom topic as nav_msgs/Odometry. Implementation: subscribe to encoder topic → compute d_left and d_right per interval → compute Δθ and d_centre → integrate into absolute pose (x += d_centre × cos(θ), y += d_centre × sin(θ), θ += Δθ) → publish pose in header.frame_id = “odom”, child_frame_id = “base_link” → broadcast the odom → base_link TF transform. See the ROS 2 Jazzy Tutorial linked above for a complete Python implementation with proper covariance matrix population.

6. What encoder resolution do I need for accurate odometry?

Quantisation error per reading is ±(0.5/TPR) × π × diameter metres per wheel. For a 0.3m wheel: at 1024 TPR ≈ ±0.46mm; at 512 TPR ≈ ±0.92mm; at 128 TPR ≈ ±3.7mm per reading. At 10Hz update rate and 0.5 m/s speed, 128 TPR introduces approximately 7.4% quantisation noise — significant for navigation. For most mobile robot applications, 512–2048 TPR provides a good balance of accuracy and cost. Higher resolutions (4096+) are beneficial for slow, precise manipulation tasks but offer diminishing returns for general mobile robot navigation.