Drivetrain

Drivetrain – definition

In mobile robotics, a drivetrain is the set of mechanical and electromechanical components that convert actuator torque into controlled vehicle motion. For a UGV, the drivetrain typically includes motors, motor drivers, gearboxes, shafts or hubs, wheels or tracks, and the mechanical interfaces that transmit force to the ground. In practice, the drivetrain also includes elements that determine kinematic behavior, such as wheel arrangement, reduction ratio, wheel radius, and traction characteristics.

In ROS and ROS 2 projects, the drivetrain is not only a hardware subsystem. It is also a modeling and control boundary. It defines which kinematic model is valid, how velocity commands should be interpreted, and how odometry should be estimated. On a differential-drive UGV such as Leo Rover, the drivetrain determines the relation between commanded linear and angular velocity and the wheel speeds reported by the low-level controller. This relation directly affects navigation, localization, slip behavior, and path tracking accuracy.

For Fictionlab platforms, the term should be understood in the context of ground mobility. Leo Rover uses a 4-wheel differential-drive layout. This means left and right wheel groups are controlled to produce forward motion and yaw rotation. Raph Rover, as a larger payload-capable UGV, uses drivetrain design choices that must support higher mass, higher torque demand, and field operation constraints such as uneven terrain, rolling resistance, and longer duty cycles.

Drivetrain architecture in UGV platforms

A drivetrain in a research rover is usually described by three coupled layers: mechanical transmission, electrical actuation, and control interface. Separating these layers is useful when integrating the rover with ROS 2 and with higher-level autonomy software.

For mobile robots, the most important drivetrain properties are listed below.

Drive layout – differential drive, skid-steer, Ackermann, mecanum, or tracked.
Actuator type – brushed DC, BLDC, or stepper, usually with encoder feedback in UGVs.
Transmission – gearbox ratio, efficiency, backlash, and torque multiplication.
Ground interface – wheel diameter, tire material, tread, contact patch, and friction coefficient.
Control loop – open-loop duty control or closed-loop speed control.
Feedback source – encoder ticks, hall sensors, motor current, IMU fusion, or external localization.

In a practical robotics stack, these properties influence low-level velocity control, odometry covariance, and feasible acceleration limits. A drivetrain with high backlash or wheel slip can still move the platform, but it will degrade dead reckoning and reduce navigation performance.

Drivetrain and kinematics in ROS 2

ROS 2 treats the drivetrain through standard interfaces rather than through a single drivetrain-specific abstraction. For differential-drive rovers, the most common reference model is the differential drive controller in ros2_control. It consumes body velocity commands and maps them to wheel velocities using platform geometry. The controller usually publishes odometry as nav_msgs/msg/Odometry and may publish the transform between odom and base_link through TF2, depending on configuration.

According to REP 103, SI units should be used in ROS interfaces. For drivetrain control this means linear velocity in m/s, angular velocity in rad/s, wheel radius in meters, and axle separation in meters. Coordinate frame conventions are defined by REP 103 and frame semantics are commonly applied together with REP 105 for mobile platforms.

For a differential drivetrain, the standard wheel speed equations are:

v_left  = v - (w * L / 2)
v_right = v + (w * L / 2)

omega_left  = v_left / r
omega_right = v_right / r

Where:

v – commanded linear velocity in m/s
w – commanded angular velocity in rad/s
L – wheel separation in m
r – effective wheel radius in m
omega_left, omega_right – wheel angular velocity in rad/s

If the drivetrain uses four wheels but behaves as a differential drive, the left pair and right pair are usually treated as two virtual sides. This is the relevant model for Leo Rover at the navigation layer.

Key parameters and metrics

When engineers evaluate a drivetrain for a UGV, they usually need parameters that affect both mobility and software integration. These parameters should come from measured hardware data or from the manufacturer specification.

Parameter	Why it matters	Typical ROS 2 relevance
Wheel radius	Converts wheel angular speed to linear speed	`diff_drive_controller` configuration
Wheel separation	Determines yaw response	Odometry and command mapping
Gear ratio	Sets torque-speed trade-off	Motor tuning and max velocity limits
Encoder resolution	Sets quantization of speed and distance	Odometry precision, low-speed control
Maximum continuous torque	Determines climb and payload capability	Trajectory feasibility
Backlash	Affects control stability and deadband	Low-speed path tracking
Slip ratio	Reduces odometry accuracy on loose terrain	Sensor fusion with IMU, GNSS, LiDAR

In field robotics, effective wheel radius is often more important than nominal radius. Tire deformation, payload, and terrain compliance change the true kinematic response. For this reason, drivetrain calibration is usually performed empirically, not only from CAD dimensions.

Practical integration on Leo Rover and Raph Rover

Leo Rover is a 4-wheel differential-drive platform with ROS support on a built-in Raspberry Pi compute unit. In this context, the drivetrain should be modeled as a differential mobile base. The autonomy stack should not assume holonomic motion. Navigation software must account for non-zero turning radius effects caused by wheel-ground interaction, especially on high-friction or deformable terrain.

On Leo Rover, drivetrain quality directly affects:

odometry drift during dead reckoning
Nav2 controller performance
repeatability of teleoperation and waypoint following
SLAM consistency when wheel odometry is fused with IMU or LiDAR

Raph Rover operates in the same mobile robotics domain but with different constraints. A larger rover usually needs more drivetrain torque reserve, stronger thermal margins in motor drivers, and more robust mechanical transmission under payload. Higher mass increases the importance of acceleration limiting, braking behavior, and power distribution. In software, these constraints often appear as lower safe acceleration, tighter velocity limits, and stronger dependence on fused state estimation.

Example ROS 2 configuration

A differential drivetrain is commonly exposed through ros2_control. The exact hardware interface depends on the motor controller, but the controller configuration typically looks similar to the example below.

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
    use_stamped_vel: false

The values above are example values only. Wheel separation, wheel radius, and velocity limits must be set from the actual rover specification or from calibration measurements.

Limitations and trade-offs

No drivetrain model is perfect once the robot leaves ideal indoor conditions. UGV drivetrains operate on surfaces that introduce slip, sinkage, compliance, and uneven load distribution. For this reason, wheel-encoder odometry alone is not sufficient for reliable autonomous navigation in many outdoor scenarios.

The main trade-offs are straightforward.

Higher gear reduction gives more torque but lower top speed.
Larger wheels improve obstacle traversal but reduce tractive force at the ground for the same wheel torque.
A heavier platform improves traction on some surfaces but increases current draw and stopping distance.
A rigid drivetrain improves control response but may transmit more shock to sensors and electronics.

For ROS 2 deployments on Leo Rover or Raph Rover, drivetrain limitations are usually mitigated by sensor fusion. Wheel odometry is combined with IMU data, and in outdoor applications often with GNSS/RTK or LiDAR localization. This shifts the drivetrain from being the only motion reference to being one source in a broader state estimation pipeline.

Normative references and standards

The drivetrain itself is a hardware concept, but its software representation in ROS follows established conventions. The most relevant references are REP 103 for standard units and coordinate conventions, REP 105 for mobile robot frame semantics, and ROS 2 control documentation for controller and hardware interface structure. Message-level interoperability relies on standard ROS message types such as geometry_msgs/msg/Twist, nav_msgs/msg/Odometry, and TF2 transforms.

For UGV engineering, drivetrain validation should also include hardware documentation such as motor datasheets, gearbox specifications, encoder resolution, and driver current limits. These values are necessary for safe tuning and for realistic performance envelopes in simulation and field testing.