Differential drive

Differential drive – definition

Differential drive is a mobile robot locomotion model in which robot motion is generated by commanding different angular velocities on the left and right sides of the drivetrain. In the standard planar model, the platform has two independently actuated wheel groups separated by a track width. Forward motion appears when both sides rotate at the same linear speed. Rotation appears when the speeds differ. This is one of the most common kinematic configurations in UGVs because it is mechanically simple, easy to model, and well supported in ROS and ROS 2 software.

In mobile robotics, the term usually refers to a non-holonomic base. Non-holonomic means the robot cannot move directly sideways in its own body frame. Its planar state is typically described as (x, y, yaw), and the body-frame command is expressed as linear velocity v and angular velocity ω. In ROS, this command is conventionally transported with geometry_msgs/Twist, most often on the /cmd_vel topic. Odometry is usually published as nav_msgs/Odometry and transforms are broadcast in the odom -> base_link chain according to REP 105 frame conventions.

For UGV platforms such as Leo Rover, differential drive is the native drivetrain concept. Leo Rover has four wheels, but from a kinematic perspective it behaves as a skid-steer or differential-like platform where the left wheels are driven together and the right wheels are driven together. This matters in practice: a ROS 2 controller may expose the base as differential drive, while real motion still includes wheel slip during turning, especially on loose terrain. On larger platforms such as Raph Rover, the same control abstraction is often retained because it integrates well with ROS 2 navigation stacks, even if the vehicle is heavier and carries more payload.

Kinematic model and equations

The basic differential drive equations are simple and widely used in controller design, simulation, and odometry estimation. They connect wheel-side velocities to body motion. The model assumes planar motion, no wheel deformation, and limited slip. These assumptions are reasonable on smooth indoor floors, but less accurate on soil, gravel, or grass.

If the left and right wheel linear velocities are v_l and v_r, and the wheel separation is b, then the body linear and angular velocity are:

v = (v_r + v_l) / 2
ω = (v_r - v_l) / b

The inverse mapping, used by many low-level controllers, is:

v_l = v - (b/2)ω
v_r = v + (b/2)ω

If wheel angular speed is measured instead of linear speed, wheel radius r is included:

v_l = r * ω_l
v_r = r * ω_r

For encoder-based odometry, pose is integrated over time from these velocities. Accuracy depends strongly on calibration of wheel radius, effective track width, encoder resolution, and timing. On outdoor UGVs, the effective track width can differ from the geometric width because lateral tire scrub changes the turning behavior.

How differential drive is used in ROS 2

ROS 2 has a well-established software path for differential drive robots. At the command level, velocity references are usually sent to /cmd_vel. At the control level, a base controller converts these commands into wheel joint velocities. At the state-estimation level, odometry and transforms are published for localization, mapping, and navigation.

In modern ROS 2 deployments, a common implementation is based on ros2_control with a differential drive controller. A typical integration includes these elements:

geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped on /cmd_vel for commanded body velocity
nav_msgs/msg/Odometry on /odom for estimated motion
tf2 transforms following REP 105, usually map -> odom -> base_link
URDF joint definitions for left and right driven wheels
sensor_msgs/msg/JointState or hardware feedback from encoders

Example controller configuration in ROS 2 can look as follows:

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.36
    wheel_radius: 0.065
    publish_rate: 50.0
    base_frame_id: base_link
    odom_frame_id: odom
    enable_odom_tf: true
    cmd_vel_timeout: 0.5
    use_stamped_vel: false

For Leo Rover and Raph Rover, exact values such as wheel_separation and wheel_radius must come from platform documentation, CAD, or measurement, then be validated experimentally. Using nominal dimensions without calibration often causes curvature errors and drift.

Key parameters and metrics

Several parameters determine how well a differential drive base performs in simulation and in the field. These are not only geometric constants. They also affect controller stability, navigation tuning, and odometry quality.

Parameter	Meaning	Typical ROS 2 use
Wheel radius	Converts wheel angular speed to linear speed	Controller and odometry model
Wheel separation	Distance between left and right wheel contact lines	Angular velocity calculation
Encoder resolution	Ticks per revolution or equivalent	Odometry precision
Odometry publish rate	Frequency of state updates, often 30-100 Hz	Localization and Nav2 input
Command timeout	Maximum age of valid `/cmd_vel`	Safety and fail-stop behavior
Max linear/angular velocity	Controller limits	Navigation and teleoperation constraints

For navigation stacks such as Nav2, differential drive also influences acceleration limits, minimum turning radius assumptions, local planner behavior, and footprint inflation. If these parameters are inconsistent with the real platform, path tracking degrades.

Practical context on Leo Rover and Raph Rover

On Leo Rover, differential drive is a practical abstraction for education, research, and prototyping with ROS 2 Humble or newer. The onboard compute is often based on Raspberry Pi, so the drivetrain interface should remain lightweight and deterministic. Encoder feedback, IMU data, and optional LiDAR or depth camera data are typically fused for localization. Leo Rover is not autonomous out of the box. A full navigation pipeline still requires integration of localization, costmaps, planners, and safety logic.

On Raph Rover, the same motion model is useful when the platform carries heavier sensor payloads such as 3D LiDAR, RTK GNSS, or edge AI compute. The larger mass and terrain use case increase the importance of traction, controller tuning, and state estimation beyond wheel odometry alone. In both platforms, IMU fusion with odometry through robot_localization is common, and GNSS or RTK can be added for outdoor global consistency.

Limitations and trade-offs

Differential drive is robust and easy to deploy, but it has known limitations. The main issue in outdoor UGV work is slip. During turns, especially with four driven wheels and compliant tires, the ideal no-slip model is violated. As a result, pure wheel odometry can drift quickly on low-friction or deformable surfaces.

Other trade-offs are also relevant:

It is simpler than omnidirectional drive, but less maneuverable in narrow lateral alignment tasks
It works well with ROS 2 tools, but controller tuning is still required for each platform mass and terrain
It is efficient for UGVs, but repeated skid turning can increase tire wear and power consumption

In practice, differential drive on field robots should be paired with additional sensors. LiDAR supports scan matching and SLAM. IMU improves short-term yaw estimation. GNSS or RTK improves global localization outdoors. Depth cameras help in traversability and obstacle detection.

Normative references and standards

The ROS frame conventions used with differential drive are defined in REP 105, which specifies coordinate frames for mobile platforms. Units in ROS follow SI conventions under REP 103, so linear velocity is in meters per second and angular velocity in radians per second. Message-level interoperability relies on standard ROS interfaces such as geometry_msgs/Twist, nav_msgs/Odometry, and sensor_msgs/JointState. For ROS 2 controller behavior, the relevant implementation details come from the ros2_control and differential drive controller documentation for the specific distribution in use.

When building a reproducible stack for Leo Rover or Raph Rover, the recommended approach is to document the exact ROS 2 distribution, controller package version, wheel geometry values, and odometry source. This is necessary because behavior can differ between ROS 1 and ROS 2, and also between ROS 2 distributions.

Differential drive