Section 5.2: Holonomic vs. non-holonomic motion

"A holonomic robot forgets its history; it can always step sideways. A non-holonomic robot is a prisoner of its own path."

A Differential Geometer on Wheels

Ask a parallel-parking driver to slide their car straight sideways into the curb, and they will laugh: the tires forbid it, yet the same driver routinely ends up parked there anyway, by chaining forward and reverse arcs. That single gap, between what a robot can do in the next instant and where it can eventually arrive, is the entire subject of this section, and getting it wrong is the difference between a planner that works on paper and one that works on pavement.

The holonomic-versus-non-holonomic distinction is a practical question, not a taxonomy exercise: 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?

Consider a warehouse robot that must slot itself into a narrow bay directly to its right. A holonomic platform (such as a mecanum-wheeled base or a quadrotor) commands a rightward velocity and arrives. A differential-drive robot cannot. It must execute a multi-step maneuver: forward motion, rotation, then forward motion again, even though the target sits centimeters away laterally. A mecanum base typically reaches the goal in one motion segment; a differential-drive base needs at least three, and in a tight corridor that three-segment arc may cover several times the path length. Figure 5.2A captures exactly this gap: the drone's reachable set fans out in every direction, while the car-like robot's does not. In illustrative aisle-docking comparisons of this kind, swapping a holonomic AMR for a differential-drive one in the same layout typically inflates docking time by an order of magnitude, since the planner must chain several legal moves to reach a slot that is only tens of centimeters to the side. This is not a software limitation; it is a consequence of the robot's physical constraint structure, and every layer of the planning stack must respect it or produce trajectories the robot cannot follow.

Theory

Before reading on, guess a number. Among sim-to-real trajectory-tracking failures on wheeled mobile robots, a substantial fraction typically trace back to one cause: planners that silently ignore the non-holonomic velocity constraint and command lateral velocities the hardware cannot produce. In practice this class of failure is common enough that respecting the Pfaffian form derived below removes it as a source of error, rather than merely reducing it.

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.

Throughout this section \(q\) denotes the robot's configuration, the full vector of position and orientation variables needed to specify its pose (for a planar mobile robot, \(q=[x,y,\theta]^T\)), and \(\dot q\) its time derivative, the instantaneous velocity of that configuration. A holonomic constraint removes reachable configurations. It can be written as \(g(q)=0\), such as a gripper fingertip constrained to remain on a rail. A non-holonomic constraint removes instantaneous velocities without reducing the same number of configurations; this is called a velocity-level restriction on reachability, and it is usually written as \(A(q)\dot q=0\), where this linear-in-velocity form \(A(q)\dot q=0\) is called the Pfaffian form and \(A(q)\) is the constraint matrix whose rows list the forbidden velocity directions, and must be handled during motion planning. Figure 5.2B contrasts the two cases side by side: every velocity arrow is admissible for the holonomic platform, while the non-holonomic platform has its lateral arrows crossed out.

The Pfaffian form matters in embodied AI because a robot's wheels enforce it physically: rubber on pavement cannot slide sideways without wheel spin or tire damage. Ignoring it means a planner commands motions the actuators cannot produce, causing the real robot to slip, overshoot, or stall in narrow spaces where recovery is costly.

Reading the constraint matrix

Mechanically, \(A(q)\) is a row vector whose entries depend on the robot's current heading \(\theta\). For a unicycle it is \([-\sin\theta,\;\cos\theta,\;0]\), extracting the lateral component of \(\dot{q}=[\dot x,\dot y,\dot\theta]^T\). The product \(A(q)\dot{q}=0\) enforces zero sideways velocity at every instant, while forward velocity and rotation remain free, which is why curved arcs can still reach any reachable pose.

The difference is practical, not semantic. A mobile robot with wheels cannot move sideways instantaneously, but it can still reach a sideways parking spot by combining forward motion and turning. A planner that treats that constraint as a simple position bound will generate paths the robot cannot execute.

Worked Example

Having established the Pfaffian form abstractly and seen why a planner must enforce it, the fastest way to trust it is to watch the residual stay at zero in a few lines of code.

The example rolls out a unicycle (differential-drive) base and checks the no-side-slip Pfaffian constraint \(-\sin\theta\,\dot x+\cos\theta\,\dot y=0\) at every step. The robot never moves sideways instantaneously, yet a forward-then-turn-then-forward maneuver still lands it at a laterally displaced pose, which is the operational signature of a non-holonomic constraint.

import numpy as np

def step(state, v, omega, dt):
    x, y, th = state
    return np.array([x + v*np.cos(th)*dt,
                     y + v*np.sin(th)*dt,
                     th + omega*dt])

def slip(state, v, omega):
    """Pfaffian residual A(q) q_dot; must stay ~0 for a non-holonomic base."""
    x, y, th = state
    xdot, ydot = v*np.cos(th), v*np.sin(th)
    return -np.sin(th)*xdot + np.cos(th)*ydot

dt = 0.01
# Command sequence: drive, turn in place, drive, turn back -> net sideways shift
commands = [(1.0, 0.0, 1.0),     # forward 1 s
            (0.0, np.pi/2, 1.0), # rotate +90 deg
            (1.0, 0.0, 1.0),     # forward 1 s
            (0.0, -np.pi/2, 1.0)]# rotate -90 deg

state = np.array([0.0, 0.0, 0.0])
max_slip = 0.0
for v, omega, T in commands:
    for _ in range(int(T/dt)):
        max_slip = max(max_slip, abs(slip(state, v, omega)))
        state = step(state, v, omega, dt)

print("max instantaneous side-slip:", f"{max_slip:.2e}")  # ~0: constraint holds
print("final pose (x, y, theta)   :", np.round(state, 3))
# Net y-displacement is reached WITHOUT ever commanding lateral velocity.

A planner that treats "cannot slip sideways" as a position bound would reject the goal; the rollout shows the goal is reachable through a legal velocity sequence, which is exactly why a velocity-level constraint must live inside the local planner, not in the configuration test.

Practical Recipe

The toy rollout proves the constraint holds in isolation; turning that confidence into a robot that docks without scuffing the shelf takes the following deployment steps.

1. Classify the platform's constraint before writing a single line of planner code. A TurtleBot 3 Burger is non-holonomic (differential drive, \(A(q)\dot q=0\) applies); a KUKA youBot base is holonomic (mecanum wheels, all lateral velocities are admissible). Getting this wrong causes the planner to generate infeasible trajectories silently.
2. Build the unicycle or Ackermann (car-like front-steered) kinematic model by hand first and verify that the Pfaffian residual stays below \(10^{-6}\) across a 30-second rollout before connecting any library. A residual that drifts above \(10^{-4}\) indicates a frame or timestep bug that OMPL or MoveIt 2 will inherit and amplify.
3. Integrate the constraint into the state propagator, not into the cost function. In OMPL, set SimpleSetup::setStatePropagator with the unicycle equations; in Nav2, configure the DWB (Dynamic Window approach for Base motion, Nav2's default local trajectory planner) local planner's kinematic model with the robot's actual wheelbase (0.16 m for TurtleBot 3, 0.67 m for Clearpath Husky) and max angular velocity limits.
4. Record constraint violations as a separate channel in every logged episode: the number of timesteps where \(|A(q)\dot q| > 0.01\) m/s reveals whether the controller is actually enforcing non-holonomy or relying on physics to absorb lateral slip.
5. Perturb the heading by \(\pm 15\) degrees at the start of each test run. A correct non-holonomic planner replans; a geometric planner that is secretly ignoring the velocity constraint will execute the original arc and crash into the obstacle it rotated toward.

Production Pattern

Holonomic vs. non-holonomic motion 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.

State non-holonomic constraints as forbidden instantaneous velocities, not as vague limits on motion. That framing gives the idea an intuitive picture, a formal interface, a runnable check, and a reproducible failure mode, so both theorist and practitioner work from the same object.

Use this recipe when turning Holonomic vs. non-holonomic motion 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 whether the constraint is configuration-level or velocity-level before blaming the planner. For this section, first reproduce one tiny motion primitive by hand, then rerun it through Robotics Toolbox for Python, Drake, ROS 2 navigation tools, or a custom NumPy integration. If the two disagree, inspect conventions and timing before changing the model.