Section 5.7: Jacobians, singularities, manipulability

"The Jacobian is the arm's local language; a singularity is the moment it goes silent mid-sentence."

Section 5.7

Picture a surgical arm holding its angle steady inside a patient when, with no warning and no joint anywhere near its limit, the tool refuses to move sideways and a 0.1 mm command demands a joint speed no motor can deliver: the arm has not broken; it has slid into a singular posture where its own velocity map went rank-deficient. The motor limits are irrelevant because the geometry, not the actuators, has lost a direction. Understanding why that happens, and catching it one control tick before it does, is the whole job of the Jacobian. 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 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.

To see why that inspectable interface matters, ground it in a concrete control loop that has no time to look anywhere but at the Jacobian.

Consider a 6-DOF industrial arm (six degrees of freedom, meaning six independently actuated joints, such as a KUKA iiwa or Universal Robots UR5) asked to polish a curved surface at constant contact force. The controller needs to command small Cartesian corrections at 1 kHz. It cannot rerun full inverse kinematics at that rate; instead it needs a lightweight local map from "how fast should the tool move?" to "how fast should each joint move?" That map is precisely what the Jacobian provides, and the quality of that map determines whether the polishing stays on the surface or overshoots at a bad posture.

From loop to local map

The Jacobian is the local translator between joint velocity and task velocity: \(\dot x=J(q)\dot q\). This relationship is called the arm's instantaneous motion budget, and it says what the arm can do in the next instant, not what it can reach eventually. This relationship is built on forward kinematics, which maps a joint configuration to the end-effector pose. That local nature is why a robot can be far from a joint limit yet still be temporarily unable to move the tool in one direction.

Singularities appear when \(J(q)\) loses rank, where rank is the number of independent task-space directions the arm can instantaneously move in. In that posture, some task-space direction requires unbounded or very large joint velocity. Manipulability summarizes the same issue as a safety margin: large singular values mean easy motion in the corresponding direction, while tiny singular values warn that control authority is collapsing.

That collapsing safety margin is not an abstract numerical curiosity; it decides whether a robot in physical contact stays in control or trips its own safety stop.

Why manipulability matters for embodied AI. A robot performing contact-rich tasks, such as inserting a connector or wiping a surface, must maintain force and velocity in specific directions throughout the motion. When manipulability collapses, the controller typically either saturates joint motors trying to follow a modest Cartesian command, or the safety firmware halts the arm entirely. Both outcomes are generally undesirable, and often unacceptable, during physical interaction with people or fragile objects. Monitoring \(w\) at every control tick gives the planner an early-warning signal to replan or slow down before a hardware fault occurs.

How manipulability works mechanically. The singular value decomposition (SVD) of \(J\) produces singular values \(\sigma_1 \geq \sigma_2 \geq \ldots \geq \sigma_m\). Each \(\sigma_i\) is the ratio of achievable task-space speed to the unit joint-speed that produces it in one direction. The product \(\prod_i \sigma_i = \sqrt{\det(JJ^\top)}\) measures the volume of the reachable velocity ellipsoid. A large volume lets the arm move freely in all directions. A flat ellipsoid makes motion easy along one axis but nearly impossible perpendicular to it. As the elbow straightens, the ellipsoid collapses to a line, and \(w\) reaches zero at the exact singular configuration. Figure 5.7B shows this collapse directly, contrasting the near-circular ellipsoid of a healthy posture with the flattened sliver of a near-singular one. To make the collapse concrete, consider moving the elbow from 90 degrees to just 2 degrees. This drops the minimum singular value by a factor of roughly 28. A Cartesian command that once required 1 rad/s of joint effort now demands nearly 28 rad/s for the same tool motion, far above the 2.175 rad/s hardware limit of a Franka Panda joint.

Everything above describes the velocity ellipsoid, but manipulability has a force-domain dual that a contact-rich task cannot ignore: the achievable end-effector force ellipsoid scales with \(J^{-\top}\) (for a square, invertible \(J\); the non-square case uses the pseudoinverse introduced in the numerical IK discussion of section 5.6), so it is large exactly where the velocity ellipsoid is small, and vice versa. A near-singular posture that struggles to move the tool in one direction can, in that same direction, resist or apply force with very little joint torque; this is why fine insertion tasks are sometimes deliberately staged near partial singularities, while free-space reaching avoids them. Reading manipulability correctly means asking whether the task at hand needs velocity freedom, force authority, or both, not just checking whether \(w(q)\) is large.

A robot that can reach any pose but cannot move freely in any direction is not dexterous; it is merely positioned.

Consider a specific case. A UR5 arm with the elbow fully extended (shoulder, elbow, and wrist centers collinear) encounters a wrist singularity, so named because it is the wrist's last two rotational axes, not the elbow joint itself, that align and become indistinguishable to the controller once the arm is stretched straight. The Jacobian drops to rank 5 for a 6-DOF arm, losing one task-space direction entirely. MoveIt 2's default Jacobian-based IK solver then clamps joint velocities, so the tool slows or stops rather than following the commanded path. Two fixes work in practice. You can add damped least-squares (Levenberg-Marquardt regularization, covered in the numerical IK section, with a damping factor around 0.01 to 0.1), or you can replan the path to avoid the singular configuration altogether. Pinocchio's computeJointJacobians plus an SVD call can detect this condition in under a millisecond on a standard CPU, making real-time avoidance feasible.

Worked Example

The example computes the Jacobian of the planar two-link arm two ways, by finite differences of forward kinematics and analytically, confirms they agree, then sweeps the elbow toward full extension to watch the manipulability \(w=\sqrt{\det(JJ^\top)}\) and smallest singular value collapse at the singularity.

import numpy as np

l1, l2 = 0.5, 0.4

def fk(q):
    x = l1*np.cos(q[0]) + l2*np.cos(q[0]+q[1])
    y = l1*np.sin(q[0]) + l2*np.sin(q[0]+q[1])
    return np.array([x, y])

def jac_analytic(q):
    s1, s12 = np.sin(q[0]), np.sin(q[0]+q[1])
    c1, c12 = np.cos(q[0]), np.cos(q[0]+q[1])
    return np.array([[-l1*s1 - l2*s12, -l2*s12],
                     [ l1*c1 + l2*c12,  l2*c12]])

def jac_finite_diff(q, eps=1e-6):
    J = np.zeros((2, 2))
    for i in range(2):
        dq = np.zeros(2); dq[i] = eps
        J[:, i] = (fk(q + dq) - fk(q - dq)) / (2*eps)
    return J

q = np.deg2rad([35.0, 60.0])
print("max |analytic - finite diff|:",
      f"{np.max(np.abs(jac_analytic(q) - jac_finite_diff(q))):.2e}")

def manipulability(q):
    J = jac_analytic(q)
    return np.sqrt(max(np.linalg.det(J @ J.T), 0.0))

print(" elbow(deg)  w=sqrt(det(JJ^T))  sigma_min")
for q2_deg in [90, 30, 10, 2, 0]:
    q = np.deg2rad([35.0, q2_deg])
    sigma = np.linalg.svd(jac_analytic(q), compute_uv=False)
    print(f"   {q2_deg:4d}        {manipulability(q):.5f}        {sigma.min():.5f}")
# As the elbow straightens (q2 -> 0), w and sigma_min -> 0: a singularity.

The finite-difference cross-check certifies the analytic Jacobian; the sweep illustrates, on this one toy posture path, why manipulability is a usable early-warning signal (a single planar sweep is a demonstration, not a proof of generality across arm geometries). At a healthy 90-degree elbow, \(\sigma_{\min}\approx 0.40\) and \(w\approx 0.20\). By 2 degrees both collapse below 0.014, a 28-fold loss of control authority from one postural change. Near \(q_2\approx 0\), fast Cartesian motion demands near-infinite joint velocity, so damping or task relaxation must engage before \(\sigma_{\min}\) crosses the configured margin.

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

Jacobians, singularities, manipulability 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.

Track Jacobian rank, singular values, and manipulability before asking a controller for high task-space speed. 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 Jacobians, singularities, manipulability 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.

Before you read the steps below: which of these do you think causes more real-world arm faults: a genuinely singular configuration where the math is undefined, or a near-singular configuration where the math is well-defined but the required joint velocities are 50x the hardware limit? The answer shapes every decision in the recipe.

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 Jacobian rank, singular values, task frame, joint velocity limits, and whether the task has fewer or more dimensions than the joints before blaming the planner. For this section, first reproduce one small Jacobian by finite differences, then rerun it through Pinocchio, Robotics Toolbox for Python, MoveIt 2, or Drake. If the two disagree, inspect conventions and timing before changing the model.