The loop that just nudges
Picture a robot arm holding a screwdriver, and you ask its elbow joint to move to 90 degrees. The simplest way to make that happen is feedback control: keep measuring where the joint actually is, compare it to where you want it (the set-point), and drive a motor in the direction that shrinks the gap. The gap itself is the error signal, and the whole loop's job is to push that error toward zero.
The workhorse version of this is PID control. It blends three views of the error: the P term reacts to how big the error is right now, the I term remembers how long the error has lingered, and the D term watches how fast the error is changing. Mix those three proportional, integral, and derivative terms and you get a controller that is simple, cheap, and astonishingly effective for a single, well-behaved motor.
Here is the catch worth sitting with: a PID loop knows nothing about the machine it is steering. It does not know the arm is heavy. It does not know gravity is pulling on the link. It does not know that swinging the shoulder throws a sideways force onto the elbow. It only ever sees one number — the error — and nudges. Most of this guide is about what happens when that blindness meets real, fast, heavy motion.
Three things that break a naive loop
Physics tells us exactly what a PID loop is up against. The robot equation of motion is the bookkeeping that says how much joint torque you must apply to produce a given acceleration. In words it reads: torque = (inertia times acceleration) + (velocity-dependent coupling) + (gravity). Each of those three pieces is a separate way to defeat a controller that ignores them.
tau = M(q) * q_ddot + C(q, q_dot) * q_dot + g(q) tau joint torques you command M(q) inertia matrix -> changes with the arm's pose q C(...) Coriolis/centrifugal -> couples joint to joint via speed g(q) gravity load -> pulls even when standing still
First, gravity. Even when the arm is perfectly still, gravity pulls the links down, so a joint needs torque just to hold its place. A plain position loop only produces torque when there is error, so it must first sag, build up error, and only then push back — the arm droops and never quite reaches the target. The fix has a name we will meet again: gravity compensation, a feed-forward torque that holds the weight up before the error ever appears.
Second, varying inertia. The same joint feels light when the arm is folded in and heavy when the arm is stretched out — the inertia matrix M(q) changes with the pose. A PID gain that is calm and stable for a folded arm can turn sluggish or even unstable when the arm extends, because the controller is effectively pushing a different mass without knowing it.
Third, joint-to-joint coupling. When the shoulder accelerates, it flings sideways forces onto the elbow and wrist — these are the Coriolis and centrifugal terms C(q, q_dot). To an elbow PID loop, those forces look like a mysterious disturbance that arrives exactly when the robot moves fast. Each joint's controller is fighting a tug-of-war it cannot see, set off by every other joint's motion.
The big idea: let the loop use a model
Here is the pivot that the whole chapter turns on. A naive PID loop is purely reactive — it waits for error, then corrects. But we already wrote down the equation of motion, which means we can predict roughly how much torque the robot needs before it falls behind. Model-based control feeds that prediction in as a head start, and leaves the feedback loop with only the small leftover error to clean up.
Concretely, you run the equation of motion backwards: given the motion you want, compute the torque it demands. That backwards calculation is inverse dynamics. Hand its answer to the motors as a feed-forward term, and the heavy, gravity-loaded, coupled parts of the problem are mostly cancelled out before they ever become error. What remains for the feedback loop is a light, almost linear system — exactly the well-behaved case where a modest PID shines.
This is the unifying theme of advanced robot control: a model carries the predictable burden, and feedback handles the surprises. The model is never perfect — masses are estimated, friction is messy, payloads change — so feedback never goes away. But splitting the work this way turns an impossible single loop into a tractable pair: predict, then correct.
The toolbox this chapter unpacks
Every tool ahead is a different answer to the three troubles above, plus the questions they raise. Think of this list as a map of where we are going.
- Cancel the dynamics directly — computed-torque control and feedback linearization use inverse dynamics to wipe out gravity, inertia, and coupling, leaving a clean linear loop to tune.
- Control how the robot feels, not just where it is — impedance control, admittance control, and force control let the arm be soft or stiff and push with a chosen force when it touches the world.
- Make the trade-offs optimal — the linear-quadratic regulator (LQR) and model predictive control (MPC) choose torques that balance accuracy against effort, and MPC even plans a few steps into the future under limits.
- Cope when the model is wrong — adaptive control tunes itself to an unknown payload, while robust control and sliding-mode control stay stable despite the model's errors.
- Recover what you can't measure, and coordinate the whole body — a state observer reconstructs hidden quantities like velocity from noisy sensors, and whole-body control juggles many goals at once across a legged or humanoid robot.
Notice the thread: almost every tool either uses a model to do better, or guards against the model being imperfect. Keep that lens and the rest of the chapter will feel less like a parade of acronyms and more like a single conversation about how much to trust your model.