Skid steering

Skid steering – definition

Skid steering is a ground vehicle steering method in which the robot changes direction by creating a speed difference between wheels or tracks on the left and right side. The wheels are usually fixed relative to the chassis. There is no dedicated steering joint such as an Ackermann front axle. Turning is produced by differential longitudinal motion and by lateral tire slip against the ground.

In mobile robotics, skid steering is common on compact UGV platforms because the drivetrain is mechanically simple and robust. A four-wheel skid-steer rover typically has two kinematic sides: left and right. Each side is driven at an independently controlled angular velocity. When both sides move at the same linear speed, the robot drives straight. When the side speeds differ, the robot follows a curved path. When the sides rotate in opposite directions, the robot can perform a near zero-radius turn, although the actual turning radius depends on wheelbase, track width, tire compliance, surface friction, and controller limits.

For ROS and ROS 2 users, skid steering is often modeled at the velocity command level in the same way as differential drive. The standard command interface is usually a geometry_msgs/Twist message on /cmd_vel, with linear velocity in x and angular velocity around z. This abstraction is practical, but it is still an approximation. Real skid-steer vehicles exhibit wheel slip, asymmetric traction, and non-ideal odometry, especially on soft soil, gravel, grass, or ramps.

Kinematic model used on UGV platforms

The simplest control model for a skid-steer rover is the unicycle or differential-drive model. It is used because the vehicle has two controllable sides and because many ROS navigation stacks expect planar velocity commands in that form. For low to moderate speeds, this is usually sufficient for teleoperation, waypoint following, and local planning.

If v is the linear velocity of the chassis center and ω is the yaw rate, then the ideal side velocities are:

v_left  = v - (ω * W / 2)
v_right = v + (ω * W / 2)

where W is the effective track width. In practice, the effective track width is not always equal to the geometric distance between wheels. On skid-steer vehicles it is often calibrated empirically because tire scrub changes the yaw response. This matters for odometry and controller tuning.

For a four-wheel skid-steer rover, the wheels on one side may share the same commanded velocity, or each wheel may be driven independently but constrained to the same side setpoint. The second option helps with torque distribution and traction control, but the navigation layer still usually works with left-side and right-side velocities.

How skid steering is represented in ROS 2

In ROS 2, skid-steer motion is usually integrated through the same interfaces used for differential drive bases. The robot receives body velocity commands and publishes odometry and transforms. The most relevant message and frame conventions are defined in standard ROS interfaces and REPs.

The core elements are:

geometry_msgs/msg/Twist on /cmd_vel for commanded planar motion
nav_msgs/msg/Odometry on /odom for estimated pose and twist
tf2 transform chain, typically map -> odom -> base_link
Frame naming and body conventions aligned with REP 103 and REP 105

REP 103 defines standard units and coordinate conventions in ROS. REP 105 defines common mobile robot frames such as base_link, odom, and map. For a skid-steer rover, this is important because navigation, SLAM, and sensor fusion nodes depend on consistent frame semantics.

A typical ROS 2 command stream looks like this:

ros2 topic pub /cmd_vel geometry_msgs/msg/Twist \
"{linear: {x: 0.4, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.6}}"

At the controller level, a hardware interface or motor driver converts this body command into left and right wheel targets. On ROS 2 systems based on ros2_control, this is typically handled by a drivetrain controller plus a hardware plugin. Exact implementation details differ between robot vendors and custom platforms.

Odometry, slip, and sensor fusion

The main technical limitation of skid steering is slip. During turning, the wheels must scrub laterally because their rolling direction does not align with the instantaneous center of rotation. As a result, wheel encoder odometry alone is often biased. The error increases on high-friction floors during aggressive turns and on deformable terrain where sinkage and unequal traction occur.

For this reason, skid-steer UGVs usually combine encoders with additional sensors:

IMU for yaw rate and short-term attitude stabilization
LiDAR for 2D or 3D scan matching and localization
Depth camera for visual odometry or obstacle perception
GNSS or GNSS RTK for global pose outdoors

In ROS 2, sensor fusion is commonly done with robot_localization, for example by combining wheel odometry and IMU into an EKF estimate. A minimal configuration may publish a filtered odom -> base_link transform at 30-100 Hz, depending on encoder and IMU rates. Typical encoder update rates on mobile bases are in the tens to low hundreds of hertz, while IMUs often publish at 100-400 Hz. Exact values depend on the motor controller and selected sensor.

ekf_filter_node:
  ros__parameters:
    frequency: 50.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,
                  false, false, false]

Practical context for Leo Rover and Raph Rover

In the Fictionlab ecosystem, skid steering should be distinguished from differential drive. Leo Rover is a four-wheel platform with skid steering, implemented as a left-right drive rover with fixed wheels and no dedicated steering joints. At the ROS layer, it is often controlled through the same command abstraction as a differential-drive base, but the mechanical steering behavior relies on tire slip. On Leo Rover, the glossary distinction matters because developers often use the same high-level interfaces for both concepts even though the underlying mechanics are not identical.

Raph Rover, as a larger UGV platform with higher payload capacity, is also a typical context for discussing skid-steer behavior. On heavier outdoor platforms, steering by wheel slip is often acceptable because it reduces mechanical complexity and supports robust operation in terrain. The trade-off is higher energy loss during turning, increased tire wear, and odometry drift that must be corrected by sensor fusion.

In practical deployments:

Leo Rover is mechanically a skid-steer platform, though in ROS 2 it is often controlled with the same high-level interfaces used for differential drive
Raph Rover may require skid-steer-aware calibration if its mechanical layout uses fixed wheels and side-speed steering
Both platforms can use the same high-level ROS 2 interfaces such as /cmd_vel, Nav2, and robot_localization
Neither platform becomes autonomous out of the box – navigation requires integration of perception, localization, and safety layers

Key parameters and engineering trade-offs

For engineering work, the following parameters determine skid-steer performance more than the abstract kinematic model does. They should be measured on the actual rover and terrain.

Parameter	Why it matters
Track width	Affects yaw response and side velocity mapping
Wheelbase	Influences scrub forces and turning resistance
Tire diameter and compliance	Changes effective rolling radius and slip behavior
Surface friction	Determines lateral scrub and current draw during turns
Encoder resolution	Sets odometry precision at low speed
IMU rate and bias stability	Improves yaw estimation when wheel odometry slips

The main trade-off is simple mechanics versus non-ideal motion. Skid steering reduces steering hardware complexity, but the control and estimation stack must handle slip. This is why high-quality IMU integration, careful URDF modeling, and realistic simulation are important when building ROS 2 applications for outdoor UGVs.

Normative references and standards

The most relevant technical references for this topic are the ROS standards for coordinate frames and interfaces, plus hardware specifications for the specific sensors and motor controllers used on the vehicle.

REP 103 – Standard Units of Measure and Coordinate Conventions
REP 105 – Coordinate Frames for Mobile Platforms
ROS 2 message definitions for geometry_msgs/msg/Twist and nav_msgs/msg/Odometry
ros2_control documentation for hardware interfaces and drivetrain controllers
Platform documentation at docs.fictionlab.pl/leo-rover for Leo Rover integration details