Section 5.2: Holonomic vs. non-holonomic motion

A Careful Control Loop

This section develops the technical contract for Holonomic vs. non-holonomic motion 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 Holonomic vs. non-holonomic motion 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 Holonomic vs. non-holonomic motion, 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.

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, so it is usually written as $A(q)\dot q=0$ and must be handled during motion planning.

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

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

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

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