Section 5.6: Inverse kinematics: analytic, numerical (Jacobian), and learned

"The arm can reach the cup from the left or the right, over or under. Inverse kinematics must choose, and the choice is never free."

A Grasp Planner With Too Many Solutions

Point at a coffee cup and your shoulder, elbow, and wrist settle into the right angles before you have finished the thought; ask a robot arm to do the same and you have to solve, explicitly and in under a millisecond, for joint angles that no equation hands you directly. That backward jump, from a point in space to the joint angles that reach it, is the inverse kinematics problem, and this section develops it through three solver families: closed-form analytic geometry, an iterative Jacobian update, and a learned predictor. The Jacobian update repeatedly nudges a guessed joint vector toward the target using the Jacobian, a matrix of partial derivatives describing how a small joint change moves the end-effector; it is defined precisely, with the full update rule, later in this section and derived in depth in section 5.7. Figure 5.6A sketches the same arm reaching one target through all three.

Inverse kinematics turns on four practical questions: 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.

Inverse kinematics asks the harder direction: given a desired tool pose, which joint vector should produce it? The answer may be unique, absent, or one of many valid configurations. That is why every inverse-kinematics result must report the target frame, seed (the starting joint vector the iterative solver refines from), residual (the leftover distance between the pose the solver reached and the pose it was asked for), joint-limit margin, and whether the solver proved feasibility or merely stopped improving. A solver that returns a joint vector without reporting its residual has not solved the problem: it has just stopped working on it.

Analytic IK uses closed-form geometry when the arm structure permits it. Numerical IK iteratively reduces pose error with a Jacobian update. Learned IK uses data to predict candidate joint values, but still needs forward-kinematics and constraint checks because a confident prediction is not a feasible one, and a neural network will never tell you it went past a joint limit.

Choosing Among the Three Approaches

Before reading the list below, guess: if you pick the wrong IK method for your arm and your control loop runs at 1 kHz, how many milliseconds do you have before the controller misses its real-time deadline and triggers an emergency stop?

The three approaches occupy different points in a speed-accuracy-generality trade-off:

• Analytic IK is fastest and most reliable for arms with a specific structure, typically six-degrees-of-freedom (DOF) arms with a spherical wrist such as the UR5 or KUKA iiwa. The wrist center decouples position from orientation, and each configuration branch has a closed-form expression. This decoupling matters in embodied AI because any solver that cannot separate position from orientation must search a coupled six-dimensional space at every control tick. On a 1 kHz real-time loop there is no time for that search. A spherical wrist (three revolute joints whose axes intersect at one point) makes position and orientation independently solvable: the first three joints place the wrist center, and the last three joints rotate the tool without moving that center. Given a desired end-effector pose, the solver first computes the wrist center position by subtracting the tool-offset vector along the approach axis. It then solves the shoulder-elbow-wrist triangle with the law of cosines, yielding at most two elbow branches (elbow-up, elbow-down). Finally it reads the wrist Euler angles from the remaining rotation matrix by inspection.

• Numerical IK generalizes to arbitrary kinematic structures and task-space constraints, but can converge to the wrong branch depending on the seed, slow down near singularities, or fail to converge at all when the target is just inside the workspace boundary.
• Learned IK (IKFlow, IKNet, diffusion-based samplers) is fast at inference and can propose diverse solutions for redundant arms (arms with more joints than the minimum needed to reach an arbitrary pose, so many joint vectors reach the same target), but requires training data that covers the relevant workspace and cannot enforce hard joint limits without a post-hoc feasibility check.

Concretely, a learned IK model is trained on pairs of (target pose, joint vector) generated by sampling joint configurations and running them through forward kinematics; the network then learns the reverse map, from pose back to joints, directly from that dataset rather than from the arm's geometry. IKNet-style models regress a single joint vector per pose. IKFlow and diffusion-based samplers instead learn a distribution over joint vectors conditioned on the target pose, so a single forward pass can return several candidate branches (elbow-up, elbow-down, shoulder-flip) at once for a redundant arm. At inference the model never touches the URDF or the kinematic chain: it has memorized a statistical approximation of the inverse map from training data, which is exactly why its output must be replayed through forward kinematics and checked against joint limits before use, the same discipline the worked example below applies to the numerical solver.

The practical pattern is to use analytic IK when the structure allows it, numerical IK (damped least-squares or sequential quadratic programming) when constraints or redundancy matter, and learned IK as a seed generator for numerical refinement rather than as a standalone solver. The latency gap is striking. Analytic IK on a UR5 solves in roughly 0.01 ms. A Jacobian solver converges in 1-5 ms over 20-50 iterations. A learned network infers in about 0.3 ms but then needs a forward-kinematics verification pass that adds another 0.05 ms per candidate. To put the cost in perspective: in the time a Jacobian solver spends on a single 5 ms solve, an analytic solver running at 1 kHz has already computed 5 independent solutions, verified each one, and still has budget left over for the controller update. Choose wrong and your real-time controller misses its 1 ms deadline.

Worked Example

Because every one of the three approaches can return a joint vector that is confident but infeasible, the only honest test is to push the returned configuration back through forward kinematics and measure what pose it actually reaches; the example below builds exactly that check into the smallest numerical solver.

The example solves position IK for the planar two-link arm from Section 5.5 with the damped least-squares update \(\Delta q=J^\top(JJ^\top+\lambda^2 I)^{-1}\Delta x\), then replays the solution through forward kinematics to confirm the reached pose. Damping keeps the step bounded when the arm stretches toward a near-singular reach.

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 jacobian(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 ik_dls(target, q0, lam=0.05, iters=200, tol=1e-6):
    q = q0.astype(float).copy()
    for k in range(iters):
        dx = target - fk(q)
        if np.linalg.norm(dx) < tol:
            return q, k, np.linalg.norm(dx), True
        J = jacobian(q)
        dq = J.T @ np.linalg.solve(J @ J.T + lam**2*np.eye(2), dx)
        q += np.clip(dq, -0.2, 0.2)          # clamp per-step joint increment
    return q, iters, np.linalg.norm(target - fk(q)), False

target = np.array([0.6, 0.3])
q_sol, iters, res, ok = ik_dls(target, q0=np.deg2rad([10.0, 10.0]))
print("converged:", ok, "iters:", iters, "residual:", f"{res:.2e}")
print("solution (deg):", np.round(np.rad2deg(q_sol), 3))
print("FK replay      :", np.round(fk(q_sol), 6), "target:", target)

# Unreachable target (beyond l1+l2 = 0.9 m): solver must NOT report success
_, _, res_far, ok_far = ik_dls(np.array([1.5, 0.0]), q0=np.deg2rad([10.0, 10.0]))
print("far target -> converged:", ok_far, "residual:", f"{res_far:.3f} m")

The FK replay closes the loop: a solver that returns its last iterate without checking the residual would silently pass the unreachable target. Reporting convergence flag, residual, and an FK replay together is what separates a usable IK result from a stopped optimizer.

Practical Recipe

The same discipline that the FK replay enforces on a single solve scales up into a checklist for deploying any IK solver on real hardware, where the seed, the joint limits, and the frame all have to be right before the first query.

1. Verify the URDF joint limits match the physical hardware before running a single IK query. On the Franka Panda, joint 4 has an asymmetric limit of [-3.0748, -0.0698] rad; solvers initialized outside this range silently clamp the seed and return a configuration the physical arm refuses.
2. Choose a seed from the current joint state, not from zero or a fixed home posture. Zero-seeding a 7-DOF arm like the Franka Panda typically converges to the elbow-up branch even when the arm is physically in an elbow-down posture; when it does, the resulting discontinuous jump can trigger the joint-velocity limit (2.175 rad/s on joints 1-4) and an emergency stop.
3. Test reachability at the workspace boundary before committing to a trajectory. In MuJoCo or Isaac Sim, sweep the target along a line approaching the boundary and log residual vs. distance; a residual that grows from 0.001 m to 0.01 m over the last 5 cm of travel is the warning that the solver is about to fail mid-trajectory in hardware deployment.
4. After any contact event (a grasp close, a push, a surface touch) re-seed the IK solver from the post-contact joint encoder values, not from the pre-contact solution. Contact forces produce 0.5-2 mm of Cartesian deflection on a compliant arm such as the Panda, and the stale seed produces a 5-10 iteration penalty on the next solve that can violate a 1 ms real-time budget.
5. When using a learned IK model (IKFlow or a diffusion sampler) in a sim-to-real pipeline, validate candidate joint vectors with a forward-kinematics pass inside the same physics model used for training. A candidate that passes FK in MuJoCo may violate self-collision constraints on the physical arm because the collision mesh in the URDF includes rubber bumpers that were omitted from the simplified sim geometry.

Production Pattern

Inverse kinematics sits inside the Part II robotics contract: geometry fixes where things are, kinematics fixes what motion is possible, dynamics fixes what motion costs, control corrects errors, and sensing fixes what the agent can know on time.

Treat inverse kinematics as constrained search, with residuals, limits, seeds, and infeasibility explicitly logged. 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 Inverse kinematics: analytic, numerical (Jacobian), and learned 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 target reachability, seed choice, residual definition, joint limits, damping, and frame convention before blaming the planner. For this section, first reproduce one planar inverse-kinematics target by hand, then rerun it through Pinocchio, Robotics Toolbox for Python, MoveIt 2, Drake, or a learned candidate generator with a forward-kinematics verifier. If the two disagree, inspect conventions and timing before changing the model.