Section 5.3: Differential-drive and car-like robots

A Careful Control Loop

This section develops the technical contract for Differential-drive and car-like robots into a usable mental model. First we define the object of study, then we connect it to the agent loop, then we test it with a compact implementation.

The key question in Differential-drive and car-like robots 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

For Differential-drive and car-like robots, 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.

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. A car-like base commands forward speed and steering angle, which creates a turning radius rather than an in-place rotation.

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. 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.

Worked Example

The example integrates both planar models from identical "spin to face the target" commands. The differential-drive base converts equal-and-opposite wheel speeds into in-place yaw; the car-like bicycle model has no such command, so the same intent produces a forward arc with a finite turning 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 silently swapped one platform model for the other.

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. This makes the section useful to students, builders, and researchers at the same time: 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.