Section 5.3: Differential-drive and car-like robots

"The differential drive must spin to steer; the car must move to turn. Neither apologizes for the constraint."

A Ground Robot, Resigned

Two robots receive the identical command "face the shelf behind you" in the same narrow aisle: one pivots in half a second, the other is physically stuck, and nothing in their shared \((x, y, \theta)\) state hints at why. That gap is set at the wheel level. This section develops it from first principles into a usable mental model: define the object of study, connect it to the agent loop, then test it with a compact implementation.

The key question is practical: what must the agent know, what can it observe, what action is available, and what evidence shows that the action worked under the stated conditions?

Theory

The practical design rule is to make the interface inspectable before optimization begins: inputs, outputs, units, latency, bounds, and failure labels should all be visible in the saved artifact.

The first thing that interface must expose is which commands the platform even accepts, and here the two robots already diverge.

Two action interfaces, one plane

Differential-drive robots and car-like robots both live in the plane, but their action interfaces are different. A differential-drive base commands left and right wheel speeds, which convert into forward speed and yaw rate, where the yaw rate \(\dot\theta\) is how fast the robot's heading angle turns about the vertical axis, in radians per second. A car-like base commands forward speed and steering angle, which creates a turning radius rather than an in-place rotation. This section uses "car-like," "bicycle model," and "Ackermann-steered" as near-synonyms: "car-like" names the platform class, "bicycle model" names the simplified two-wheel abstraction used to derive its equations, and "Ackermann" names the specific steering linkage that keeps all four wheels on concentric arcs. When you see any of the three below, read it as referring to the same steering-angle-and-turning-radius contract. Both are examples of non-holonomic motion, since neither robot can move freely in all directions from a given pose. Figure 5.3A annotates the differential-drive geometry, showing how wheel radius and wheelbase map individual wheel speeds onto the robot's linear and angular velocity in the world frame.

This distinction changes the planner. A differential-drive robot can spin in place to face a target, while a car-like robot needs clearance for an arc; this is the minimum turning radius constraint, and it determines which goal poses are reachable at all. The same goal pose can therefore be easy for one platform and infeasible for another unless the path planner respects the platform's kinematic model. Figure 5.3B places the two side by side: the differential drive (left) turns opposite wheel speeds into in-place rotation with zero minimum turning radius, while the car-like base (right) must sweep an arc whose minimum radius \(R_{\min} = L / \tan\delta_{\max}\) is always greater than zero.

The warning below leans on the minimum turning radius \(R_{\min} = L / \tan\delta_{\max}\) already named in Figure 5.3B; its geometric derivation follows in the next few paragraphs, but the practical consequence for planners is worth stating first.

This constraint matters in embodied AI because real steering mechanisms have a hard physical limit on how far the front wheels can pivot. Exceed that limit and the axle binds or the tire scrubs. The robot's configuration space is therefore not fully connected. A goal directly behind the robot in a narrow corridor may be unreachable in a single smooth arc, which forces a multi-step maneuver or makes the goal infeasible entirely. In a 0.5 m-wide aisle a differential-drive robot typically reaches a reversed heading in one motion, taking roughly 0.2 seconds at a moderate commanded yaw rate. A car-like robot with the same wheelbase typically needs at minimum a 5-point turn spanning several meters of back-and-forth travel, and in tighter aisles it cannot reach that heading at all; the exact segment count depends on \(\delta_{\max}\) and the aisle's exact width. Any learned policy that ignores this emits commands the actuator silently saturates, so the robot tracks a different path than intended.

A learned policy that commands rotation in place on a car-like robot is not a policy for that robot; it is a policy for a different robot, running on the wrong hardware.

The mechanism is geometric. The bicycle model (a simplification that collapses each axle to a single centered wheel, so a four-wheeled car reduces to a two-wheeled bicycle) treats the rear axle as the reference point and the front wheel as a steerable pivot. At maximum steering angle \(\delta_{\max}\), the instantaneous center of rotation (the single point in the plane about which the whole rigid body is momentarily turning) lies on the rear axle extended, at distance \(R_{\min} = L / \tan\delta_{\max}\) from the rear wheel contact point. Smaller wheelbase or larger maximum angle both shrink \(R_{\min}\), tightening the accessible arc set.

Consider a specific case: a TurtleBot 4 (differential drive, wheelbase \(L = 0.233\,\text{m}\), wheel radius \(r = 0.033\,\text{m}\)) navigating a tight warehouse aisle 0.6 m wide. Setting \(\omega_L = -\omega_R = 5\,\text{rad/s}\) produces pure in-place rotation at \(\dot\theta = rL^{-1}(\omega_R - \omega_L) \approx 1.4\,\text{rad/s}\) with zero translation. Now send the same command to a small car-like robot: a 1:10 scale Ackermann-steering chassis with \(L = 0.26\,\text{m}\) and \(\delta_{\max} = 30°\), whose minimum turning radius is \(R_{\min} = L/\tan\delta_{\max} \approx 0.45\,\text{m}\). (Ackermann geometry keeps all wheels on concentric arcs during a turn, eliminating tire scrub.) That robot requires at least 0.45 m of lateral clearance to begin the turn. In the 0.6 m aisle it can just barely execute a three-point turn; in a 0.4 m aisle it cannot reorient at all. This single numeric comparison drives the platform selection before any learning or optimization begins.

Worked Example

One "spin to face the target" intent, two integrators. The differential-drive base turns equal-and-opposite wheel speeds into in-place yaw. The bicycle model has no such command, so the identical intent produces a forward arc of finite radius.

import numpy as np

def diff_drive(state, wL, wR, r, L, dt):
    x, y, th = state
    v = r/2 * (wR + wL)            # body forward speed
    w = r/L * (wR - wL)           # yaw rate
    return np.array([x + v*np.cos(th)*dt, y + v*np.sin(th)*dt, th + w*dt])

def bicycle(state, v, delta, L, dt):
    x, y, th = state
    return np.array([x + v*np.cos(th)*dt,
                     y + v*np.sin(th)*dt,
                     th + (v/L)*np.tan(delta)*dt])

dt, r, L = 0.01, 0.05, 0.30
# Differential drive: wheels turn opposite -> pure rotation
s = np.array([0.0, 0.0, 0.0])
for _ in range(int(1.0/dt)):
    s = diff_drive(s, wL=-4.0, wR=+4.0, r=r, L=L, dt=dt)
print("diff-drive after 'spin':", np.round(s, 3), "-> moved:",
      round(float(np.hypot(s[0], s[1])), 4), "m")   # ~0 m, theta changed

# Car-like: max steering, constant speed -> minimum-radius arc, no in-place spin
s = np.array([0.0, 0.0, 0.0])
delta_max = np.deg2rad(30)
for _ in range(int(1.0/dt)):
    s = bicycle(s, v=1.0, delta=delta_max, L=L, dt=dt)
R_min = L/np.tan(delta_max)
print("car-like after 'turn' :", np.round(s, 3), "-> R_min:",
      round(R_min, 3), "m")     # nonzero displacement, bounded curvature

The differential-drive base ends at roughly the origin with a changed heading; the bicycle base sweeps an arc of radius \(R=L/\tan\delta\). A path planner that lets the car-like robot rotate in place has swapped one platform model for the other, and the swap stays hidden until the actuator saturates.

Catching that silent swap before it reaches hardware is exactly what the following recipe enforces, by fixing the interface and the failure labels ahead of any optimization.

Practical Recipe

1. Write the observation, action, and success metric before choosing a model.
2. Build a baseline that is simple enough to debug by inspection.
3. Add the library implementation only after the baseline behavior is understood.
4. Record failures as structured cases: perception error, state error, planning error, control error, or evaluation error.
5. Run at least one perturbation test before trusting the result.

Production Pattern

Differential-drive and car-like robots sits inside the Part II robotics contract: geometry defines where things are, kinematics defines what motion is possible, dynamics defines what motion costs, control defines how errors are corrected, and sensing defines what the agent can know on time.

Check wheel radius, axle length, sign convention, and integration step before trusting a mobile-base trajectory. The idea has an intuitive role, a formal interface, a runnable check, and a failure mode that can be reproduced.

Use this recipe when turning Differential-drive and car-like robots into code, a simulator experiment, or a robot diagnostic. The point is not to use every library. The point is to keep the hand-built baseline and the maintained-tool path comparable.

1. Write the joint vector, frame target, velocity convention, and constraint set before solving.
2. Check forward kinematics on a known posture, then perturb one joint and inspect the end-effector delta.
3. Compare an analytic or numerical Jacobian with Pinocchio, Robotics Toolbox, or Drake on the same robot model.
4. Log residual error, joint-limit distance, manipulability, and solver iteration count in one artifact.
5. Treat singularities and infeasible targets as design signals, not as solver annoyances.

Kinematic failures often arrive as a plausible pose with an impossible motion. Inspect wheel radius, wheel separation, steering angle limits, integration step, and sign convention before blaming the planner. For this section, first reproduce one short arc by hand, then rerun it through Robotics Toolbox for Python, Drake, ROS 2 navigation tools, or a small NumPy rollout. If the two disagree, inspect conventions and timing before changing the model.