Control, from current loop to planner

Every modern robot runs the same shape of software: fast, dumb, certifiable loops at the bottom and slow, clever, learned models at the top, each layer handing targets down and reading state back up. The bottom of the stack is solved and nearly free. The middle, whole-body balance and contact, is where learned networks replaced hand-written code in 2026. Knowing which layer a company actually built tells you what it's worth and what will break.

The stack of clocks

A controller is any piece of code or circuitry that compares what you want with what you measured and decides what to do next. The thing you want is the setpoint: 90 degrees at the elbow, 1.2 m/s forward, "put the cup in the sink". When the controller measures the result and corrects, you have a closed loop. When it fires a command without checking, you have an open loop.

A robot stacks these loops. Each layer runs 5 to 10 times faster than the layer above it verified, because a loop only behaves if the loop inside it looks instantaneous. The rate each layer runs at is its control frequency. Chinese engineers split the stack into the "big brain" (大脑 dànǎo), the slow planning model, and the "little brain" (小脑 xiǎonǎo), the fast motion control layer that keeps the body upright. That split is the brain and cerebellum architecture.

Read the stack from the bottom. The current loop lives on the motor driver inside each joint module and runs field-oriented control at 10 to 40 kHz verified. The velocity loop runs at 1 to 4 kHz and the position loop at 100 Hz to 1 kHz. Above them, a whole-body controller balances the robot at 500 Hz to 1 kHz. A learned policy or a model predictive controller decides the next second of motion at 25 to 200 Hz, and a reasoning model plans the task at 1 to 10 Hz verified. The actuators chapter covers the bottom three loops in hardware; this chapter covers the logic.

PID, the loop inside every joint

The workhorse is the PID controller. It watches one number, the error, and adds up three reactions to it. About 97% of the controllers running the world's factories and process plants are still PID estimate, because it's free, certifiable and good enough whenever one input drives one output.

Try it. The toy below is a 1 kg weight on a 0.5 m arm, hanging straight down, told to swing up and hold horizontal. Holding it level against gravity takes 4.9 N·m, and the motor can give at most 10 N·m. The simulation runs at 1 kHz, like a real joint loop.

Three things the toy teaches that you'll see on real robots. First, turn Kp up past 30 and the arm hits the 10 N·m limit: the motor saturates and more gain buys nothing. Second, the I term has a trap called integral windup. When the motor is saturated and the error stays big, a naive integrator keeps piling up error, then overshoots wildly once the arm arrives. The toy freezes the integrator while the motor is at its limit, which is one of the two standard fixes. Third, tuning is a craft. The classic recipe, Ziegler and Nichols from 1942, raises Kp until the loop oscillates and derives the rest from that; it gives 25 to 60% overshoot verified, so treat it as a starting point.

Joints rarely run one PID. They run a cascade: a position loop commands a velocity loop, which commands the current loop, and engineers tune from the inside out. On a humanoid the position loop usually drops the I term and becomes a PD controller with two numbers per joint, stiffness kp and damping kd. Those two numbers matter more than they look, as the next section shows.

Feedforward and gravity compensation

Good motion control computes most of the command before any error appears. That's feedforward: use a model to predict the torque the motion needs (mass times planned acceleration, plus friction, plus gravity), send it, and let feedback clean up the few percent the model got wrong. Engineers say "a good servo is 90% feedforward" folklore. The most common piece is gravity compensation: at every joint angle the controller knows how much torque holding the arm against gravity takes and adds it automatically.

Here's why this matters for money. Owner reports on the Unitree G1 show that most of its hardware failures start in software. When NVIDIA's open-source whole-body controller ran on a G1, both ankle motors hit their 90 °C warning in 5 to 10 minutes while the robot stood still; Unitree's stock controller keeps the same ankles at 30 to 45 °C owner report, Jun 2026. Another owner fitted a heavier dexterous hand, kept the gains at kp 40 and kd 1.5, and the shoulder motor overheated within minutes owner report, Jan 2026. Heat comes from current, current comes from torque, and torque demand comes from the controller. Same hardware, a 45 to 60 °C difference at the ankle, decided entirely by control code.

Kinematics: joint angles to hand position and back

Forward kinematics answers "if every joint is at these angles, where's the hand?" It's easy: multiply out the geometry of the kinematic chain link by link. Inverse kinematics answers the question you actually care about: "I want the hand here, so what angles do I need?" It's harder, because there may be two answers, infinitely many, or none.

A two-link arm has a clean formula. A 7-joint arm reaching a point in 3D space has one joint more than it needs, so it has infinitely many solutions and can move its elbow out of the way while its hand stays still. A humanoid with 23 to 56 degrees of freedom (a base Unitree G1 has 23, Atlas has 56 verified Sep 2026) has dozens more than any one task needs. Real robots solve inverse kinematics numerically, many times a second, picking the solution that also keeps joints away from their limits and the body balanced.

The Jacobian and singularities

The numerical method runs on one object: the Jacobian. It's a table that says, for the current pose, how fast the hand moves in each direction when each joint turns a little. Turn it around and it tells you which small joint moves produce the hand motion you want. It also converts in the other direction for force: the torques each joint must apply to push with a given force at the hand.

Dynamics in words

Kinematics is geometry with no forces. Dynamics adds the forces. The whole of robot dynamics fits in one equation, usually written M(q)q̈ + C(q, q̇)q̇ + g(q) = τ. In words, the torque at the joints pays for four things:

• Inertia: accelerating the links, where the effective mass changes with the pose. An arm stretched out is harder to swing than one tucked in.
• Coupling: the forces one moving link puts on the others, like the pull you feel in your shoulder when you swing your forearm fast.
• Gravity: holding everything up, the g(q) term that gravity compensation cancels.
• Everything outside: contact with the floor, a box, a person, which enters through the Jacobian.

Solve it forward and you have a simulator: torques in, motion out. Solve it backward, which engineers call inverse dynamics, and you have the feedforward term: motion you want in, torques you need out. Every whole-body controller and every physics simulator in the locomotion chapter is built on this equation.

Position control versus torque control

There are two ways to command a joint. Position control says "go to 42 degrees and stay there, whatever it takes". An industrial arm with a 100:1 harmonic drive works this way: stiff, precise, and blind to what it hits. Force control says "push with 5 N·m" and lets the position be whatever results. It needs a joint that can feel torque, either from a torque sensor or from motor current in a low-friction quasi-direct-drive joint.

Most humanoids blend the two. The policy sends a target angle plus two gains, and the joint computes torque = kp × (target angle minus actual angle) + kd × (target speed minus actual speed). Low gains make the joint soft; high gains make it stiff. That's why the gains on the G1 owner report above caused the overheating: kp 40 on a shoulder carrying a heavier hand kept the motor pushing hard against every small error.

Impedance and admittance: choosing how stiff to feel

The useful middle ground is to control the relationship between force and motion. Impedance control makes the hand behave like a spring and a damper you choose: push it 5 cm and it pushes back with exactly the force a spring of that stiffness would, then returns. Admittance control is the mirror image for stiff position-controlled arms: a force sensor at the wrist measures the push and the controller moves the arm away by a matching amount.

This is how a robot wipes a table with steady pressure, inserts a plug without jamming, or survives a person bumping into it. Pick a soft spring for contact with people and a stiff one for precise placement. Figure 02 placed parts to a 5 mm tolerance in about 2 seconds at BMW verified Nov 2025, which is precision territory; wiping and plugging are compliance territory. The same arm switches between them in software.

Whole-body control: many goals, one body

A humanoid carrying a box has several goals at once: don't fall, keep both feet planted, hold the box level, keep the elbows off the torso, stay within every joint's torque limit. Whole-body control solves all of them together, up to 1,000 times a second, with strict priorities.

1. Balance: keep the centre of mass over the feet (see balance).
2. Contacts: planted feet don't slip; forces stay inside friction limits.
3. Task: the hand follows the box trajectory.
4. Posture: joints stay near comfortable angles, away from limits and singularities.

This is the layer that learning took over in 2026. Figure's Helix 02, announced 27 Jan 2026, replaced 109,504 lines of hand-written C++ balance and whole-body code with a 10-million-parameter neural network, called S0, that runs at 1 kHz verified. It was trained entirely in simulation on more than 1,000 hours of retargeted human motion, across more than 200,000 parallel simulated environments with randomised physics verified. Boston Dynamics took the other route with Atlas: it writes the low-level control itself and buys the reasoning layer from Google DeepMind verified.

Model predictive control: plan ahead, commit to one step

PID only looks at the error right now. Model predictive control, or MPC, looks ahead. At every tick it simulates the next half second with a model of the robot, finds the best sequence of commands that respects every limit, sends only the first command, then throws the plan away and does it again.

MPC earns its compute, roughly 100 times PID's, in three situations: when limits matter (it plans inside them instead of hitting them), when many inputs interact, and when you know what's coming (the next footstep, the stairs ahead). Its costs are equally real. It needs a decent model, because it turns model error into confident wrong plans, and a solver that is guaranteed to finish inside every tick. As of 2026 many quadruped and humanoid stacks replace MPC with a learned policy, or keep MPC as a safety layer under one contested.

Motion planning: finding a path that hits nothing

Control follows a path. Planning finds one. Motion planning searches for a collision-free route from here to there through the space of joint angles. Trajectory planning then puts timing on that route, speeds and accelerations the motors can deliver without shaking the arm.

• RRT (rapidly exploring random tree) grows a tree of random collision-free poses outward from the start until a branch reaches the goal, then smooths the path. It works well in the high-dimensional joint space of a 7-joint arm, where a grid search would never finish.
• Collision checking is where most of the compute goes. The planner tests thousands of candidate poses against simplified 3D shapes of the robot and the scene, often from a depth camera or LiDAR map.
• MoveIt is the open-source motion planning framework built on ROS 2. Most research arms and many integrators start there.
• Time parametrisation turns the path into a trajectory, using smooth S-curve profiles so the arm never asks for an acceleration that excites its resonances, which usually sit somewhere between 20 and 500 Hz verified.

Classical planners are exact and slow to adapt: they need a geometric model of the scene. That's why a learned policy that goes straight from camera pixels to motion, the VLA covered in the brains chapter, is eating planning for cluttered, changing scenes such as homes and kitchens.

Where learning replaces classical control, and where it doesn't

The pattern: learning wins where the world is too messy to model (vision, contact-rich motion, balance over rough ground) and loses where certification, determinism and microsecond timing rule. The bottom three rows won't be learned in this decade, because a regulator can audit a PID loop and can't audit a network estimate. Watch the whole-body row. When a company says its "little brain" is learned end to end, ask how it was validated, what the joint temperatures look like after an hour, and what classical safety layer sits under it.

Terms in this chapter