Mobile robot types & differential-drive kinematics

The differential drive is so common because it achieves excellent mobility with remarkable mechanical and control simplicity. It's the cheapest, simplest arrangement that still gives a ground robot full planar manoeuvrability (the ability to reach any position and orientation in a flat space). Mechanically it's just two independently-driven wheels (typically with a passive caster for balance) (no steering linkage, no complex mechanism) so it's inexpensive, robust, and easy to build. Yet it's highly manoeuvrable: by driving the two wheels at different speeds it can go straight, follow arcs of any radius, and even spin in place (zero turning radius), which car-like (Ackermann) robots cannot do. And its kinematics are simple: forward speed is the average of the wheel speeds and turn rate is their difference, an easy relationship to compute and invert. This combination (cheap and simple to build, yet manoeuvrable, with simple math) is why differential drive dominates indoor, educational, and research robots (and robot vacuums, etc.). But the differential drive (like most wheeled ground robots) is ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍nonholonomic: it cannot move sideways. At any instant it can only move along the direction it's facing (forward or backward) and rotate. It has no way to translate directly to its left or right. This is a genuine constraint on its instantaneous motion, and it has real consequences for control and planning. For control: to get to a point that is off to the side, the robot cannot simply slide there. It must turn to face (or partly face) the direction it needs to go, then drive. So motion is a coordinated sequence of turning and driving, not arbitrary translation; controllers command (v, omega) and the robot's heading must be managed as part of reaching a position. For planning: the constraint means not every path is feasible. A path that required instantaneous sideways motion (or an infinitely sharp change of direction at speed) is not executable; feasible paths must respect that the robot moves along its heading and changes heading by turning. This is why, for example, parallel-parking a car (also nonholonomic) takes a back-and-forth manoeuvre rather than sliding sideways into the spot, and why motion planning for nonholonomic robots must produce paths the robot can actually follow given it can't move sideways (smooth paths with feasible curvature, or turn-then-drive sequences). Nonholonomic does ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍not mean the robot can't reach any pose (a differential drive can get to any (x, y, heading) in free space) it just can't do it by arbitrary instantaneous motion; it must compose turning and driving. So the nonholonomic constraint shapes robotics deeply: controllers must coordinate heading with position (you steer by managing orientation), and planners must generate paths that obey the can't-move-sideways limit. Understanding this explains why ground-robot navigation looks the way it does (turn toward the goal, drive, adjust) and distinguishes these robots from omnidirectional ones (which can translate sideways and so escape the constraint, at the cost of mechanical complexity). The differential drive's popularity and its nonholonomic constraint are two sides of its simple two-wheel design: that design buys cheap, simple manoeuvrability, but at the cost of not being able to slide sideways. A constraint that control and planning must respect.

The wheel-speeds-to-(v, omega) relationship is the essential bridge between the robot's motors and its motion because the robot's hardware and the robot's intent speak two different languages, and this relationship is the translator between them. The hardware, the actuators, can only do one thing: spin each wheel at some speed. That's the entire physical interface to the robot's motion; everything the robot does to move, it does by setting wheel speeds. But the ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍control and planning layers don't think in wheel speeds; they think in intuitive robot motion: 'drive forward at this speed and turn at this rate'. That is, in terms of the robot's linear velocity v and angular velocity omega. A path planner produces a route; a controller decides 'I need to go forward at 0.3 m/s while turning left at 0.5 rad/s'. It reasons about how the robot should move, not about individual wheels. So there's a gap between the language of intent (v, omega: how the robot body should move) and the language of the hardware (wheel speeds), and differential-drive kinematics is exactly the bridge across it: forward kinematics maps wheel speeds to robot motion (v = average, omega = difference/separation), and inverse kinematics maps a desired robot motion back to the wheel speeds that achieve it. Without this bridge, the control/planning layers, which necessarily think in robot motion, simply couldn't be connected to the motors, which only accept wheel speeds; you literally could not turn 'go forward and turn left' into actuator commands, nor interpret the wheels' motion as the robot's movement. This makes the relationship foundational: it's used ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍forwards by odometry and simulation (read or assume wheel motion, compute how the robot moved) and backwards by control (want a (v, omega), compute the wheel speeds), tying the whole stack to the hardware. The same forward/inverse-kinematics idea matters throughout robotics because this gap between 'the motion we want, described naturally' and 'the actuator commands that produce it' is universal. It appears wherever actuators don't directly correspond to the motion you care about. The clearest recurrence is robotic manipulators (arms): there, the actuators are joint angles, but you care about the position and orientation of the end-effector (the gripper) in space. Forward kinematics maps joint angles to end-effector pose (where does the hand end up given the joint angles?), and inverse kinematics maps a desired end-effector pose back to the joint angles that achieve it (what joint angles put the hand there?): exactly analogous to the differential-drive case, just with joints instead of wheels and end-effector pose instead of (v, omega). The same pattern appears for any robot: there is a 'task space' (the motion or pose you care about) and an 'actuator space' (what the motors directly control), and kinematics is the mapping between them, forward (actuators to task) and inverse (task to actuators). Recognising this means the differential-drive derivation isn't a one-off trick but your first instance of a deep, recurring structure: robots are commanded in terms of meaningful motion but actuated in terms of motors, and kinematics, forward and inverse, is always the bridge. Mastering it here (where it's simple: average and difference of two wheel speeds) prepares you for the same idea in its harder forms (manipulator FK/IK in Turn 2), and explains why 'translate between intended motion and actuator commands' is one of the most fundamental and frequently-used operations in all of robotics.

Differential-drive kinematics is best understood through the way a tank or a wheelchair steers: there's a wheel on each side and no steering wheel at all. First, you steer by driving the two sides at different speeds. Spin both sides at the same speed and it rolls ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍straight. Spin the right side faster than the left and it curves to the left (the faster side swings around the slower side). Spin one side forward and the other backward and it spins right on the spot, turning without going anywhere. So the 'steering' isn't a wheel you turn: the difference between the two wheel speeds is the steering. Second, that gives a lovely simple rule: the average of the two wheel speeds is how fast the robot goes forward, and the difference between them is how fast it turns. Both wheels at the same speed -> a big average, zero difference -> straight ahead. Wheels equal-and-opposite -> zero average, big difference -> spinning in place. Anything in between -> it curves along an arc, tighter or gentler depending on how different the two speeds are. That's the whole of differential-drive kinematics: average -> forward speed, difference -> turn rate. Third, it can't slide sideways. Unlike a crab (or a special omnidirectional robot), a tank/wheelchair-style robot can only go in the direction it's facing and turn. It has no way to scoot directly to its left or right. So to reach a spot off to the side, it has to ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍turn to face that way first, then drive, which is why these robots navigate by a dance of turning and driving rather than sliding around freely. Two wheels, steered by their speed difference, going forward at their average speed, unable to slide sideways. That's a differential-drive robot, and the simple math (average and difference) is the bridge between the wheel speeds you command and the motion you get.

Drive types & trade-offs: differential drive (2 independent wheels + caster; turn by speed difference; can spin in place; simple: most common), Ackermann/car-like (steered front wheels; fast/outdoor; can't spin in place; min radius), omnidirectional (special wheels; move any direction incl. sideways; complex), legged (terrain/stairs; complex). Broadly simplicity vs manoeuvrability vs terrain.

Differential-drive kinematics (wheel speeds vL, vR; separation L): v = (vR + vL)/2 (average -> forward speed), omega = (vR: vL)/L (difference over separation -> turn rate). Equal wheels -> straight (omega = 0), opposite -> spin in place (v = 0), unequal -> arc of turning radius R = v/omega. Inverse: vR = v + omega*L/2, vL = v - omega*L/2.

Nonholonomic constraint: a differential drive ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍can't move sideways. At any instant it moves only along its heading and rotates. So control must turn to face a target before driving (manage heading as part of reaching a position) and planning must produce feasible paths (no sideways motion; smooth/turn-then-drive). It can still reach any (x, y, heading), by composing turning and driving.

Why the wheel-speeds-to-(v,omega) bridge matters: the hardware accepts only wheel speeds, but control/planning think in (v, omega) (intuitive motion). The kinematics translates: forward (wheels -> motion) for odometry/ simulation, inverse (desired motion -> wheels) for control. Without it the motion-thinking layers couldn't drive the motors. It recurs as manipulator FK/IK (Turn 2): there actuators are joint angles and the task is the end-effector pose: forward kinematics maps joints -> pose, inverse maps pose -> joints, exactly analogous‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍. Generally there's a task space (motion you care about) and an actuator space (what motors control), and kinematics (forward/inverse) is always the bridge: this is your first, simplest instance.

Connections: the math behind the C++ diff-drive project and the Gazebo robot; the autonomy stack's control layer (the autonomy-stack lesson) commands v and omega which this converts to wheel speeds; odometry (next) runs it backwards to estimate motion from wheel encoders. Where motors meet motion.