A seven-jointed robot arm wants to push its gripper one centimeter forward. The motors do not understand “forward.” They understand “spin.” The bridge between them is a small matrix, recomputed about a thousand times per second, that translates “move my hand this way” into “turn each motor by this much.” Then the arm shifts one degree, the matrix loses rank, and the same one-centimeter request demands motor speeds that approach infinity. The arm twitches, the safety stop fires, the demo dies. That cliff edge has a name. It is a singularity, and most of the code in a forty-year-old industry is still spent avoiding one.
Last Friday’s issue mapped two directions of the kinematics problem. Forward kinematics is the easy direction: given joint angles, return where the hand is. Inverse kinematics is the hard direction: given where you want the hand, return the joint angles. Today goes inside that hard direction, because the surprising fact is that you almost never have to solve it globally. You only have to solve it locally, at every instant, and that turns the problem from algebra into geometry.
The matrix is called the Jacobian. Its job is small and specific: at the robot’s current pose, it tells you how a tiny change in each joint angle moves the hand by a tiny amount in each direction in space. Multiply the Jacobian by joint velocities, you get a hand velocity. Plain-language gloss: the Jacobian is an instantaneous translator from joint-speak to hand-speak.
The interesting fact about this translator is that you can use it backwards. If you know where you want the hand to go, and the Jacobian is well-behaved, you can run the translation in reverse and read out joint velocities. For a six-jointed arm at a comfortable pose, the math is a clean matrix inverse. For a seven-jointed arm (the Franka Panda, the KUKA LBR iiwa), the math is a pseudo-inverse, the closest thing to an inverse when the matrix isn’t square. The seventh joint lets the elbow drift around an obstacle while the hand stays put. The cost is that the math is a little messier.
Then comes the singularity. A singularity is a configuration where the geometry of the arm collapses to a lower dimension. The elbow is fully extended; two wrist axes line up; the arm physically cannot move the hand in some direction without spinning two motors against each other infinitely fast. Mathematically, the Jacobian loses rank and the pseudo-inverse tries to divide by zero. In real hardware, you get a fire.
The fix is forty years old. Two researchers (Wampler 1986, Nakamura and Hanafusa 1986) independently proposed adding a tiny “damping” term to the matrix before inverting it. The damping makes the inversion safe at the cost of a small tracking error: the hand arrives close to where you asked, not exactly. The whole engineering art is choosing the size of the damping term as a smooth function of how close the arm is to a singular configuration. Too much and the arm tracks poorly. Too little and it oscillates. Get it right and the singularity becomes a soft cushion the arm slides past instead of a wall it crashes into. Trying to understand Jacobian matrix and how this 6 joints move and try to solve the instruction to action problem, my brain start hurting. I need to go back and watch lot of videos and use pen paper to understand what is happening.
A second trick is parallelism. TRAC-IK, the de facto open-source motion library in robotics today, runs two different solvers at once on different threads and accepts whichever finishes first. NVIDIA’s Isaac Lab uses a similar idea, framed as a stack of weighted tasks (hand-pose first, comfortable elbow second), all resolved through a damped pseudo-inverse every simulation step. The math underneath is forty years old. The harness around it is what 2026 has changed.
Three pieces of fresh evidence that the field is still working hard on this same forty-year-old problem.
A unified-treatment paper from Stanford (arXiv 2604.13405, April 2026) benchmarks twelve different IK solvers on the Franka Panda, comparing classical damping-based methods against the new wave of generative neural-network solvers. The takeaway is taxonomic, not triumphalist: the two camps have complementary failure modes, and the field is converging on hybrid solvers.
You can watch this to understand IK in robotics -
A second paper from April (arXiv 2604.02021) builds a high-performing pick-and-place system for seven-jointed arms by pairing classical task-priority damped least squares with a discrete LLM-style high-level planner. The classical math, it turns out, still has runway when the layer above it is rewritten.
NVIDIA’s Isaac Lab 2.3 release updated its production IK controller (called Pink IK) for two-armed humanoids. The new version improves the way robots hold their elbows, reducing the visibly awkward “elbow flare” of earlier humanoid demos. The same Python motion code now runs identically in simulation and on the physical robot, which is the more important news than the elbow cosmetics.
Above visual plots three curves along one trajectory of a seven-jointed arm walking toward a singular configuration. The horizontal axis is the smallest singular value of the Jacobian, shrinking left to right (so the singularity is on the right edge of the chart). The vertical axis is required motor speed. The undamped curve rises smoothly until it goes vertical at the singularity. The constant-damping curve stays bounded but lags the request. The adaptive-damping curve hugs the undamped curve in the easy region and the constant-damping curve in the hard region, which is the whole industrial trick in one picture.
Look at that adaptive curve and you are looking at forty years of classical-robotics tribal knowledge encoded as a one-page algorithm. Every cobot in a factory today is using some version of it. Every humanoid demo where the elbow does not visibly tremble is using some version of it. The reason this matters for the next layer of the conversation is that the wave of foundation-model controllers (RT-2, π₀, NVIDIA GR00T, TRI’s Large Behavior Models) is trying to learn the same curve, end-to-end, from pixels and language to motor torques, without writing the algorithm down at all. Whether they succeed is the architectural fight of 2026, and the answer will be visible long before it is settled, in whether the safety layer underneath the policy is still classical IK or finally is not.
Tomorrow we move to the missing half of the motion problem. Inverse kinematics gives you joint angles. Inverse dynamics gives you joint torques. They are not the same answer, and the difference is the reason a robot arm cannot move as fast holding a coffee mug as it can holding nothing at all. We will unpack the equation that connects motion to force, and explain why “carrying your own batteries” is the cost-curve line item that the humanoid spreadsheet people keep underestimating.
Subscribe for tomorrow’s read, we’re walking the robotics supply chain from atoms to algorithms, one weekday at a time.
Sources: