The Core Idea: Cancel What You Can Predict
A robot arm is a difficult thing to control because it fights back in complicated ways. Gravity pulls each link down differently depending on how the arm is folded. When one joint swings fast, it flings the others around through coupling forces. And a heavy forearm is harder to accelerate than a light wrist. A plain PID controller sees all of this as messy, ever-changing disturbance and is forever a step behind it.
Here is the liberating insight: almost none of that is truly unpredictable. Gravity, the coupling forces, the varying effective mass — all of it follows from physics we can write down. The robot's equation of motion is a known formula. So instead of treating physics as the enemy and reacting to it, why not compute exactly what it will do and pay for it in advance?
That is the whole trick behind feedback linearization. You wrap the robot in a layer of math that computes the torque needed to exactly cancel gravity, the coupling terms, and the changing inertia. What is left over — the system as seen from the outside — is no longer a tangled nonlinear mechanism. It behaves like the simplest object in all of control theory: a free mass you can push directly. The robot's own physics has been subtracted away.
The Computed-Torque Law, Term by Term
The robot's equation of motion has a standard shape, and reading it is the whole game. Written for the joint angles, it says: required torque equals (effective mass) times (acceleration), plus (velocity-coupling forces), plus (gravity). Each piece has a name and a clear physical job.
tau = M(q) * qddot + C(q, qdot) * qdot + g(q) q = joint angles (where the arm is) qdot = joint velocities (how fast it moves) qddot = joint accelerations (how fast that changes) M(q) = mass / inertia matrix -> resistance to acceleration C(...) = Coriolis & centrifugal -> forces that arise from the joint velocities g(q) = gravity vector -> pull of gravity in this pose tau = joint torques you command the motors to produce
The first term uses the mass (inertia) matrix M(q). It captures how hard each joint is to accelerate and, crucially, how accelerating one joint pushes on its neighbors. It depends on the pose q because a stretched-out arm has very different inertia from a folded one. The middle term is the Coriolis and centrifugal terms: the whirling, sling-like forces that appear only when joints are already moving. The last term g(q) is plain gravity compensation — the steady torque each motor must hold just to keep the arm from drooping.
Computing the torque you need from a desired motion (q, qdot, qddot) is exactly the problem called inverse dynamics: given where you want the arm to go, work backward to the forces that get it there. In practice, robots evaluate it with the fast recursive Newton–Euler algorithm, which sweeps outward and then back inward along the arm to produce every joint torque in one efficient pass — fast enough to redo at every control tick.
After Cancellation, a Simple Loop Just Works
Here is how the cancellation is actually wired. Instead of commanding a final torque directly, you first decide a desired acceleration — call it the maneuver you want — and then ask the inverse-dynamics formula for the torque that produces it. The mass matrix and the gravity and Coriolis terms are all evaluated at the current pose and speed. The output is a torque command that, when the model is right, makes the joints accelerate exactly as you asked.
Step 1 - outer loop picks a desired acceleration:
a = qddot_des + Kd*(qdot_des - qdot) + Kp*(q_des - q)
\__feedforward__/ \______ PD on the tracking error ______/
Step 2 - inner loop turns that into real torque:
tau = M(q)*a + C(q,qdot)*qdot + g(q)
Result, if the model is exact, the error e = q_des - q obeys:
eddot + Kd*edot + Kp*e = 0 (a clean, tunable spring-damper)Now look at what the controller sees from the outside. With the physics cancelled, the leftover relationship between your command a and the actual acceleration is just "acceleration equals command" — that promised double-integrator. On top of that clean system, an ordinary proportional–derivative loop on the error behaves beautifully: the error equation becomes a textbook spring-damper. You choose Kp like a spring stiffness and Kd like a shock absorber, and you get the exact settling behavior you want, identically at every joint and in every pose.
The Catch: You Only Cancel as Well as You Model
Everything above assumed the model is exact. It never is. The mass of each link, the location of its center of gravity, the friction in every joint, an unknown payload in the gripper — all of these enter the cancellation formula, and all of them are known only approximately. Whatever the model gets wrong does not vanish; it leaks straight through as a leftover force the clean double-integrator was supposed to be free of.
The good news is that the outer PD loop still mops up small residuals — a slightly wrong gravity term just looks like a mild disturbance it can push against. The bad news is that big or systematic errors degrade the very thing that made the method attractive: the perfect, pose-independent decoupling falls apart, and tracking suffers most exactly when the arm moves fast and the dynamics matter most. The cancellation is only ever as good as your knowledge of the robot.
This single weakness is what motivates much of the rest of the chapter. Adaptive control tunes the uncertain model parameters online, learning the true link masses and friction while it runs. Robust control instead designs a controller that stays stable across a whole band of model error without needing to identify it. And sliding-mode control adds an aggressive corrective term that forcibly drives the error to zero in spite of whatever the model missed. Computed torque is the clean ideal; these are the tools for living with an imperfect model of reality.