Inverse Kinematics and the Jacobian It Iterates

Forward kinematics takes joint angles and produces the position of the hand. Inverse kinematics does the opposite, and the opposite is not a function. A target hand position usually has more than one set of joint angles that reach it, and sometimes none, so the problem is solved by iteration rather than by formula: start from the current pose, compute how the hand moves as each joint moves, and step toward the target. The matrix that encodes “how the hand moves per joint” is the Jacobian, and everything interesting about IK is a property of that matrix.

The Jacobian maps joint velocities to end-effector velocity

For a chain of joints acting on an end effector position $\mathbf{p}$, the Jacobian $J$ is the matrix of partial derivatives, one column per joint, one row per coordinate of $\mathbf{p}$. Column $i$ is the instantaneous velocity of the end effector caused by a unit angular velocity at joint $i$, which for a rotational joint is the cross product of the joint’s axis with the vector from the joint to the end effector:

$$\mathbf{v} = J,\dot{\theta}, \qquad J_i = \hat{a}_i \times (\mathbf{p} - \mathbf{r}_i).$$

The cross product makes the column zero when the end effector lies on the joint axis, which is the first hint of the singularity problem: at a configuration where the target is unreachable in some direction, the corresponding column of $J$ vanishes and that direction cannot be produced by any joint velocity.

The matrix is built by forward kinematics, which is why IK and FK are not alternatives but two halves of the same loop. Each iteration of an IK solver evaluates the current pose forward, forms $J$, solves a small linear system, and updates the angles. The loop is cheap because the chain is short: a human arm has a handful of joints, so $J$ is a 3-by-k matrix with k under ten, and the linear solve costs tens of operations. The forward pass that builds the pose is the same one the skinning pipeline uses, which is why an IK solver lives inside the pose evaluation rather than beside it.

Two cheap solves for the same underdetermined system

The system $J,\dot{\theta} = \mathbf{v}_{\text{target}}$ has k unknowns and three equations, and k exceeds three for any redundant arm, so it is underdetermined. The solutions form an affine subspace, and different solvers pick different points in it.

The Jacobian transpose method sets $\dot{\theta} = J^T \mathbf{e}$, where $\mathbf{e}$ is the error vector from end effector to target. It is not the solution of the linear system in the least-squares sense; it is a gradient-descent step in the sense that $J^T\mathbf{e}$ is the gradient of the squared error $\frac12|\mathbf{e}|^2$ with respect to the angles, scaled by the Jacobian. It is cheap because it needs no inverse, it never becomes undefined as long as $J^T$ exists, and it converges slowly when the end effector is far from the target and fast when near, which is the opposite of what a solver wants for a target that snaps to a new position.

The pseudoinverse method sets $\dot{\theta} = J^T (JJ^T)^{-1} \mathbf{e}$, the least-norm solution that exactly produces $\mathbf{e}$ when $\mathbf{e}$ is in the column space of $J$. It moves the end effector in a straight line toward the target at the chosen step, and it is undefined where $JJ^T$ is singular. That is the trade in one line: the transpose never fails but crawls, the pseudoinverse is exact but blows up.

/* One damped-least-squares IK step for a single target position.
   J is 3xk; the damping lambda stabilizes the solve near singularities. */
static void ik_step(const double J[3][K], const double e[3], double lambda,
                    double dtheta[K]) {
    double A[3][3] = {{0}}, b[3];
    for (int r = 0; r < 3; r++)
        for (int c = 0; c < 3; c++)
            for (int j = 0; j < K; j++)
                A[r][c] += J[r][j] * J[c][j];
    for (int r = 0; r < 3; r++) {
        A[r][r] += lambda * lambda;      /* damp the diagonal of JJ^T */
        b[r] = e[r];
    }
    /* Solve A y = b, then dtheta = J^T y. A is 3x3 symmetric positive definite. */
    double y[3];
    solve3x3(A, b, y);
    for (int j = 0; j < K; j++)
        dtheta[j] = J[0][j]*y[0] + J[1][j]*y[1] + J[2][j]*y[2];
}

Damped least squares, with the $\lambda^2$ added to the diagonal of $JJ^T$, is the standard fix for the blow-up. It trades exactness for boundedness: at a singularity the solve returns a small step rather than an enormous one, and away from the singularity the damping is a negligible bias. The damping constant is a tuning parameter with units that sit between angle and distance, and it is set by trial; too large damps the reachable motion, too small lets the singular directions dominate again.

Singularities are configurations, not bugs

A singularity is a configuration where the end effector cannot move in some direction, and the arm has three of them worth knowing by name. When the arm is fully extended, the end effector cannot move radially outward, so the Jacobian loses rank and any solver that inverts $JJ^T$ produces an unbounded step; the damping caps it, and the visual result is a joint that jitters near full extension as the solver repeatedly overshoots the singularity. When the end effector sits on a joint axis, that joint contributes a zero column and the solver cannot tell what it should do, leaving it at its current value. When two joint axes become parallel, one degree of freedom is lost and the two joints fight over it, which is the wrist-flip artefact where a small target motion causes a large rotation of a joint that contributes nothing to the end effector.

The jitter near full extension is not a numerical failure. It is the correct behaviour of an exact solver on a problem whose solution jumps discontinuously as the target crosses the reach boundary, and the way to make it visually acceptable is to damp it, to limit the per-step angular change, and to accept that a target beyond reach can only be approached in direction, not reached. Any solver that claims to reach it exactly is adding energy somewhere.

Joint limits are the second constraint that pure IK ignores. A solution that bends an elbow backwards is mathematically a solution and anatomically impossible, so the solver must clamp angles to ranges after each step and then re-solve, which is a projection onto the constraint box. The projection breaks the exactness of the step and can stall the solver at a corner of the box, which is the standard reason a clamped arm sometimes fails to reach a target it can reach in the unconstrained problem: the constrained minimum sits at a limit, not at the target.

Multiple effectors turn the solve into a priority problem

A hand holding a bar while the elbow must avoid an obstacle gives two objectives on the same joints, and the objectives conflict. The Jacobian grows to six rows, one block per effector, and the single solve now weights both blocks equally. That is rarely what is wanted: the obstacle is a hard constraint and the reach is soft, or vice versa. The standard structure is a priority order, where a secondary objective is solved in the null space of the primary, meaning it moves the joints only in directions that do not disturb the primary target. The null space projector is $I - J^+J$, and applying it to the secondary gradient yields a step that is orthogonal to the primary’s columns.

Null-space projection is also where natural-looking motion is bought. A redundant arm has free directions that reach the same target, and filling them with a secondary objective such as “keep the elbow low” produces poses that look like a human choosing a comfortable configuration rather than an arbitrary one. The projector is the mechanism that separates the free directions from the used ones, and it costs one pseudoinverse per iteration, which is why cheaper solvers skip it and accept whatever pose the primary solve finds.

Full-body IK generalizes the same idea to a whole skeleton with dozens of targets, and the Jacobian becomes a large sparse matrix. The sparsity matters because the solve is otherwise cubic in the joint count; exploiting the tree structure of the joint hierarchy keeps it near-linear. That is a different problem in scale from the per-limb IK used for hands and feet, and the two are often layered: a whole-body solve produces the root and spine pose, and per-limb solves refine the hands and feet on top.

Why IK is a producer, not a consumer

An IK solver writes joint rotations into the hierarchy, and everything downstream reads them. The rotations it produces have no temporal smoothness of their own: a target that jumps produces a solution that jumps, and feeding that directly into the curve evaluator produces a pose with discontinuities in velocity that read as pops. The usual arrangement is to run IK per frame and filter the output, or to run it at a fixed rate and interpolate, so that the discontinuity introduced by the target’s motion is smoothed at the same place other animation discontinuities are smoothed.

The solver also inherits the orientation conventions of the hierarchy, which is where IK and rotation representation collide. A solver that treats angles as Euler triplets and clamps them independently clamps in the wrong coordinate frame, and a solver that composes quaternions without normalizing accumulates error that makes the forward pass drift from the inverse pass. The Jacobian is derived from the forward model, so any mismatch between the model the solver assumes and the model the renderer uses appears as a systematic offset between the reached pose and the rendered one, largest at the end of long chains.