Turning radius

Turning radius – definition

Turning radius is the radius of the circular path followed by a defined reference point on a mobile robot while it turns at constant linear and angular velocity. In mobile robotics, the reference point is commonly the robot base frame origin, typically base_link. The term must be qualified because a UGV has several relevant radii: the path radius of base_link, the radius traced by an inside wheel, the radius traced by an outside wheel, and the outer swept radius of the complete robot footprint.

For a differential-drive UGV, turning radius is derived from the instantaneous centre of curvature (ICC). The ICC is the point around which the robot is rotating at a given instant. A robot can rotate around a point outside its chassis, inside its footprint, or at the midpoint between its drive sides. The last case is commonly called a point turn or in-place rotation.

Turning radius is not a fixed ROS 2 message field. It is a kinematic and geometric property calculated from commanded velocity, wheel or track spacing, chassis geometry, tyre-ground interaction, and control limits. It is important for path planning, collision checking, local navigation, and safe operation in confined terrain.

Kinematic turning radius for differential drive

A differential-drive robot turns by commanding different velocities to its left and right drive sides. The standard ideal kinematic model assumes rolling without lateral slip and equal effective wheel radii. Under these assumptions, the signed path radius of the midpoint between the left and right wheels is calculated from linear velocity v and angular velocity ω.

R = v / ω

Here, R is the signed turning radius in metres, v is forward velocity in metres per second, and ω is yaw rate in radians per second. The geometric radius is |R|. ROS coordinate and unit conventions are defined by REP 103. ROS uses SI units, with angles expressed in radians.

When left and right wheel velocities are available, the same signed radius can be expressed using the effective wheel separation b.

R = (b / 2) × (vR + vL) / (vR - vL)

In this expression, vR and vL are the right and left wheel-side velocities. If both sides have equal velocity, the robot moves straight and the turning radius tends to infinity. If the sides have equal speed in opposite directions, the linear velocity at the midpoint is zero and the ideal turning radius is zero.

Leo Rover uses a differential-drive configuration. Therefore, its theoretical minimum kinematic radius can be zero when a controller permits counter-rotating wheel commands. The real operational radius can be larger because four fixed wheels generate lateral scrub during a turn. Surface friction, payload distribution, tyre deformation, motor control resolution, and wheel slip all affect the observed trajectory. The platform documentation should be used as the source for its current drivetrain configuration and supported control interfaces: Leo Rover technical documentation.

Turning radius versus swept radius

A path that is feasible for base_link may still cause a collision. Navigation systems must account for the chassis, mounted sensors, payload, and cable routing. This requirement is especially relevant when a LiDAR, depth camera, GNSS antenna, or compute enclosure extends beyond the nominal vehicle body.

The outer swept radius is the maximum radius of the circular paths traced by any point of the robot during a turn; it is not the distance travelled along those paths. For a rectangular footprint, it depends on the position of each corner relative to the ICC. A conservative calculation evaluates every footprint vertex.

r_i = sqrt(x_i² + (y_i - R)²)
R_swept = max(r_i)

Coordinates x_i and y_i describe each footprint vertex in the robot frame, using the REP 103 convention of x forward and y left. The equation assumes that R is the signed radius measured from the reference point to the ICC along the robot-frame y axis. The resulting R_swept should be used when checking clearance from walls, crop rows, construction obstacles, or inspection infrastructure. In ROS 2 navigation, this geometry is represented as a robot footprint or as a circular robot radius in the costmap configuration; costmap inflation additionally expands obstacle costs around obstacles.

Turning radius in ROS 2 navigation

ROS 2 represents commanded planar velocity with geometry_msgs/msg/Twist. The relevant fields are linear.x and angular.z. A common mobile-base interface exposes these commands on /cmd_vel, although ROS 2 does not impose one universal topic name for all base controllers.

ros2 topic echo /cmd_vel

linear:
  x: 0.25
angular:
  z: 0.50

For this command, the ideal radius at the reference point assumed by the controller is 0.25 / 0.50 = 0.5 m. This is a calculated command radius, not a guarantee that the physical UGV will follow the same arc. Odometry should be compared with wheel commands and, where available, IMU or visual/LiDAR localisation data.

The base pose and odometry frames should follow REP 105. In a typical UGV system, odom provides locally continuous motion estimation, while map provides a globally corrected frame when localisation or SLAM is active. The transform between base_link and these frames enables the measured turning path to be evaluated.

A differential-drive controller may expose wheel separation, wheel radius, velocity limits, and acceleration limits as configuration parameters. These parameters must match the physical rover. An incorrect wheel separation produces incorrect angular odometry and therefore an incorrect estimated turning radius.

diff_drive_controller:
  ros__parameters:
    wheel_separation: <measured_effective_separation_m>
    wheel_radius: <measured_effective_radius_m>
    publish_rate: <controller_specific_rate_hz>

Practical use with Leo Rover and Raph Rover

On Leo Rover, turning-radius analysis is relevant when integrating ROS 2 navigation, autonomous waypoint following, or teleoperation in constrained indoor and outdoor environments. A point turn can reduce the required path radius, but it can also increase wheel scrub and disturb loose soil, gravel, or soft ground. The navigation footprint must include all mounted hardware rather than only the factory chassis outline.

Raph Rover may carry sensor masts, enclosures, or research equipment with a larger swept envelope. Its required clearance can therefore differ substantially from the radius calculated at base_link. Integrators should measure the complete configured vehicle, define its footprint in the navigation stack, and validate turns with the final payload installed.

Key limitations

The ideal differential-drive model is useful for control and planning, but it does not model every field condition. Turning-radius estimates should be treated as kinematic predictions unless validated against measured odometry or external tracking.

Four-wheel differential UGVs can experience skid-steer effects during turning.
Wheel slip can cause the physical path radius to differ from the commanded radius.
A zero kinematic radius does not mean zero clearance requirement.
Costmap inflation and footprint geometry affect whether a planned turn is collision-free.
Payload changes can alter traction, wheel loading, and the effective swept envelope.

Normative references and technical sources

The following sources define the ROS conventions most relevant to turning-radius calculations and mobile-base integration. Hardware-specific limits must always be verified in the applicable platform documentation.