Ackermann steering

Ackermann steering – definition

Ackermann steering is a steering geometry used in wheeled ground vehicles where the front wheels, or another steered axle, turn at different angles during a corner. The inner wheel follows a tighter radius than the outer wheel. This reduces lateral tire slip and allows the wheels to roll around a common instantaneous center of rotation. In mobile robotics, the term usually refers both to the mechanical steering layout and to the kinematic model used by a controller, simulator, or ROS 2 interface.

The concept comes from classical vehicle geometry. For a vehicle with wheelbase L, track width W, and turn radius R measured to the rear axle center, the ideal low-speed Ackermann condition is commonly written as:

tan(delta_in)  = L / (R - W/2)
tan(delta_out) = L / (R + W/2)

Here, delta_in and delta_out are the inner and outer steering angles. In practice, real linkages only approximate this condition over part of the steering range. At higher speeds, tire slip angles, compliance, and dynamics matter more than pure kinematics, so the ideal geometric relation is no longer sufficient.

In UGV work, Ackermann steering is distinct from differential drive and skid steering. Leo Rover is a skid-steer platform, so it does not use Ackermann steering in its stock drivetrain. Raph Rover may be used as a custom research base for alternative locomotion layouts, but Ackermann steering is only relevant if the hardware is designed with a dedicated steered axle and the corresponding control stack. This distinction is important when selecting ROS 2 controllers, odometry models, and navigation constraints.

How Ackermann steering is used in mobile robotics

In a mobile robot, Ackermann steering is typically implemented with one driven axle and one steered axle, or with front-wheel steering plus rear-wheel drive. The robot accepts a longitudinal velocity command and a steering command. The controller then maps these commands to wheel rotational speeds and steering joint positions.

This model is common in outdoor robots because it is mechanically efficient on compacted soil, pavement, and long corridors. Compared with skid steering, it generally causes less tire wear and lower scrubbing losses. The trade-off is a larger turning radius and more complex path tracking at low speed in tight spaces.

Low-slip turning: each front wheel points toward a compatible turn center.
Directional stability: useful for longer wheelbases and higher travel speeds.
Non-holonomic constraints: lateral motion is not directly actuated.
Path planning impact: feasible trajectories must respect curvature limits.

For autonomous navigation, this means planners should generate curvature-bounded paths. A controller designed for a differential robot can still be used in some cases, but only if the kinematic assumptions are adapted. In ROS 2 Nav2, this usually affects controller tuning, minimum turning radius, reverse motion behavior, and footprint inflation.

Ackermann steering in ROS and ROS 2

ROS and ROS 2 do not define a single mandatory Ackermann interface at the level of core messages, but there are common conventions. Velocity commands are often still transported with geometry_msgs/msg/Twist on /cmd_vel, where linear.x is forward speed and angular.z is often interpreted by the vehicle interface as desired yaw rate. Another common pattern is to use a dedicated Ackermann command message, such as ackermann_msgs/msg/AckermannDriveStamped or ackermann_msgs/msg/AckermannDrive, which expresses steering angle, steering angle velocity, speed, acceleration, and jerk.

In practical integrations, the choice depends on the control stack and ros2_control setup. For a physically correct vehicle model, steering joints and wheel joints should be represented explicitly in URDF, and odometry should be derived from steering angle and wheel speed rather than from differential wheel speeds.

ROS element	Typical choice	Purpose
Command topic	`/cmd_vel` or `/drive`	High-level velocity or Ackermann command input
Message type	`geometry_msgs/msg/Twist` or `ackermann_msgs/msg/AckermannDriveStamped`	Controller input abstraction
Robot description	URDF	Steering joints, wheel joints, frames
Control framework	ros2_control	Hardware interface and controller execution
Odometry output	`nav_msgs/msg/Odometry`	Pose and twist estimate for localization

Frame naming should follow standard ROS conventions. REP 103 defines standard units and coordinate conventions. REP 105 defines the relationship between frames such as base_link, odom, and map. These REPs are directly relevant when publishing odometry for Ackermann robots.

ros2 topic echo /odom
ros2 topic echo /joint_states
ros2 control list_controllers

Key parameters and metrics

Ackermann steering performance depends on a small set of geometric and control parameters. These values should be measured from the actual platform and reflected in the URDF, controller configuration, and planner constraints.

Wheelbase L: distance between front and rear axle centers. It determines curvature response.
Track width W: left-to-right distance between wheels on the same axle.
Maximum steering angle: usually limited by linkage geometry and tire clearance.
Minimum turning radius: derived from wheelbase and maximum steering angle.
Steering rate: how fast the steering actuator can change angle, typically in rad/s.
Odometry update rate: often 20-100 Hz in ROS 2 mobile bases, depending on encoder and controller design.

A common single-track approximation, also called the bicycle model, uses:

kappa = tan(delta) / L
omega = v * tan(delta) / L

Here, kappa is path curvature, delta is the equivalent steering angle, v is forward velocity, and omega is yaw rate. This approximation is standard in control and planning, but it ignores left-right steering asymmetry and tire effects.

Supported hardware and integration constraints

Ackermann steering requires hardware that can actually steer a wheel pair or axle. This sounds obvious, but it is a frequent source of modeling errors in research projects. A differential-drive or skid-steer robot cannot be made into a true Ackermann platform by software alone.

For Fictionlab platforms, the practical interpretation is straightforward. Leo Rover is a four-wheel skid-steer UGV with native ROS support on Raspberry Pi-based compute hardware. Its stock drivetrain should be modeled and controlled as skid steer, not as Ackermann. Navigation on Leo Rover therefore relies on skid-steer or differential-drive approximations unless the mechanical platform is heavily modified.

Raph Rover is a larger payload-capable platform for custom engineering work. If a project uses Raph Rover as a base for a custom wheeled chassis with a steered axle, then Ackermann steering becomes relevant at the mechanical, control, and simulation layers. In such a case, the integration usually includes:

steering encoders for left and right knuckles or a central steering rack,
wheel encoders for traction wheels,
IMU for yaw-rate validation and state estimation,
optionally RTK GNSS for outdoor localization drift control.

Use cases with Leo Rover and Raph Rover

On Leo Rover, Ackermann steering is mainly a comparative concept. It is useful when teaching mobile robot kinematics, benchmarking planners in simulation, or integrating external vehicle models in ROS 2. It is not the native motion model of the platform. For example, a student may compare how the same Nav2 global plan behaves on a skid-steer robot versus a curvature-limited Ackermann robot.

On Raph Rover, Ackermann steering is relevant in custom field robotics projects where reduced surface disturbance, better straight-line efficiency, or car-like handling is preferred. Typical examples include inspection routes on firm terrain, agricultural row following, and outdoor autonomy experiments where a larger turning radius is acceptable.

Limitations and trade-offs

Ackermann steering is not universally better than differential or skid steering. It is a design choice with clear consequences for software and hardware.

Larger turning radius: less suitable for tight indoor spaces.
More mechanical complexity: steering linkages, actuators, and calibration are required.
Controller sensitivity: steering backlash and encoder errors degrade odometry.
Planner constraints: curvature and reverse motion must be handled explicitly.

In simulation, these effects should be represented in URDF and the physics engine as accurately as possible. Otherwise, the robot may track unrealistically sharp turns or produce odometry inconsistent with the real chassis.

Normative references and standards

The most relevant references for implementing Ackermann steering in ROS-based UGV systems are REP 103 for units and coordinate conventions, and REP 105 for mobile platform frame semantics. Message and interface choices should be verified against the ROS 2 distribution used in the project, because available controller packages and hardware interfaces may differ between releases such as Humble and newer versions.

For vehicle modeling, the bicycle model and Ackermann geometry are standard textbook and control-engineering formulations. For deployment, the authoritative source is always the actual hardware specification: wheelbase, steering limits, encoder resolution, controller frequency, and actuator latency.