Inverse Kinematics

Point at something across the room. Your shoulder, elbow, and wrist all move at once — your brain solved inverse kinematics without a second thought. Ask a robot to do the same thing and you have a genuine algorithmic puzzle.

Forward kinematics is the easy direction: given the angle of every joint, compute where the hand ends up. You just chain together rotation matrices — a purely mechanical calculation with one unique answer.

Inverse kinematics runs the question backwards: given a target position for the hand, find the joint angles that put it there. That single reversal turns a mechanical formula into a search problem with infinitely many solutions, no solutions, or solutions that can only be approached numerically.

The difficulty is not just mathematical. It is the same tension that runs through all of computation: descriptions are easy to evaluate, hard to invert.

Drag the red target and watch the arm follow. Each link can rotate freely at its base joint. The solver uses Cyclic Coordinate Descent (CCD): it sweeps from the tip backwards, rotating each joint just enough to bring the end-effector closer to the target.

<!-- {{c_html_comment}} -->
<div class="toolbar">
  <label>{{label_links}} <input id="link-count" type="range" min="2" max="8" value="4"> <span id="link-val">4</span></label>
  <button id="reset-btn" type="button">{{btn_reset}}</button>
</div>
<canvas id="canvas" width="480" height="340"></canvas>
<div class="status" id="status">{{hint_drag}}</div>

* { box-sizing: border-box; }
body { font-family: system-ui, sans-serif; color: #222; margin: 0; background: #f5f7fa; }
.toolbar {
  display: flex; align-items: center; gap: 1rem; flex-wrap: wrap;
  padding: .45rem .6rem; background: #fff; border-bottom: 1px solid #dde3ea;
}
label { font-size: .85rem; display: flex; align-items: center; gap: .4rem; }
input[type=range] { width: 90px; cursor: pointer; accent-color: #1d3557; }
button {
  font: 600 13px system-ui; padding: .35rem .8rem;
  border: 1px solid #1d3557; background: #1d3557; color: #fff;
  border-radius: 6px; cursor: pointer;
}
canvas { display: block; background: #fff; border-top: none; touch-action: none; cursor: crosshair; }
.status { font-size: .85rem; color: #555; padding: .35rem .6rem; min-height: 1.6em; background: #fff; border-top: 1px solid #eee; }

// Code not found

Notice what happens with a long chain: there are infinitely many valid configurations, and CCD picks one by a greedy sweep. A short chain that can't quite reach the target will hover as close as it can — the solver converges on the nearest point, not failure. This asymmetry — easy to verify a solution, hard to find one globally optimal — is the heart of the inverse kinematics problem.

The gap between forward and inverse kinematics is not just an engineering nuisance — it is deep.

• Forward kinematics is $O(n)$: multiply $n$ rotation matrices in order, done.
• Inverse kinematics in general is NP-hard. When you add joint limits (each joint is constrained to an angular range), the problem of deciding whether any configuration can reach the target is NP-hard — proved by Reif (1979) for chains in three dimensions with obstacles, and by Hopcroft, Joseph, and Whitesides (1984, 1985) in related planning settings.
• Without limits, it is still underdetermined. A planar arm with $n \geq 2$ links almost always has infinitely many solutions — you need an extra criterion (minimize energy, avoid obstacles, stay near the current pose) to pick one.

The practical solvers all accept some compromise:

• Jacobian pseudoinverse: linearize the relationship between joint velocities and hand velocity; iteratively step in the direction that reduces error. Elegant, but can get stuck at singularities where the Jacobian loses rank.
• Jacobian transpose: even simpler — skip the matrix inverse altogether, use the transpose as a cheap approximation. Robust but slow to converge.
• CCD (Cyclic Coordinate Descent): sweep joint by joint, rotating each one greedily. Fast and easy to implement — the algorithm you just saw in the demo.
• FABRIK (Forward and Backward Reaching IK): purely geometric — no Jacobians, no matrix algebra, just pull the chain toward the target and push it back from the base. Often converges in one or two passes.

All of these are heuristics or local solvers. None guarantees the globally optimal configuration. For a chain with hundreds of joints, or with collision avoidance built in, finding the best pose remains one of the hardest problems in robot motion planning — related to the broader intractability explored in non-convex optimization.

"Move the end to this position" is one of the most universal problems in engineering and art:

• Industrial robots: welding arms, pick-and-place machines, surgical robots — all need real-time IK to follow a moving target or a programmed path precisely.
• Character animation: every animated character in a film or game uses an IK rig. When a foot must stay planted on the ground while the body sways, the IK solver adjusts the knee and hip angles automatically.
• Prosthetics and exoskeletons: a powered prosthetic arm reads muscle signals and runs IK hundreds of times per second to position the artificial wrist and fingers.
• Computer-aided surgery: robotic surgical tools must align instrument tips to sub-millimetre targets while a surgeon operates via remote handles — the IK chain connects the surgeon's motion to the tool tip inside the patient.
• Space robotics: the Canadarm on the International Space Station relies on IK to manoeuvre payloads around the station's exterior without human hands in the loop.

The same mathematics that lets a game character place its hand on a door handle is at work in a cancer-treatment beam aiming a radiation source at a tumour. In every case the question is the same: given the goal, what are the angles?

Forward kinematics is a single sweep through a chain of matrices — easy, deterministic, always unique. Inverse kinematics is its mirror: you know where you want the hand and you must work backwards. That reversal hides infinite solutions, unreachable targets, and a worst-case complexity that is NP-hard with joint limits.

The CCD algorithm you dragged in the demo is a greedy workaround: fast, practical, good enough for real-time use. The Jacobian methods add calculus-style refinement. FABRIK adds geometric intuition. None of them solves the general case optimally — they all trade global guarantees for the speed a robot or animation system needs.

Next time you watch a robot arm pick up a package, or a game character gracefully place its hand on a railing, remember: behind that smooth motion is a non-convex optimization running dozens of times per second, navigating a landscape with no guaranteed path to the best solution.