control//controller design//trajectory tracking

Trajectory tracking is the control problem of making a system follow a reference that moves in time, \(x_{\text{ref}}(t)\), rather than hold a fixed point, and its standard solution combines a nominal input computed from the model with feedback on the deviation. A drone inspecting a façade, a robot arm laying a weld bead and a CNC spindle following a toolpath all solve it. (It is a different problem from following targets in sensor data, which is multi-target tracking; the word *tracking* serves both.)

Trajectory tracking is the control problem of making a system follow a reference that moves in time, xref(t)x_{\text{ref}}(t)xref​(t), rather than hold a fixed point, and its standard solution combines a nominal input computed from the model with feedback on the deviation. A drone inspecting a façade, a robot arm laying a weld bead and a CNC spindle following a toolpath all solve it. (It is a different problem from following targets in sensor data, which is multi-target tracking; the word tracking serves both.)

If the reference comes with the input that would produce it in a perfect world, uref(t)u_{\text{ref}}(t)uref​(t), the law is

u=uref(t)−K(x−xref(t)).u=u_{\text{ref}}(t)-K\big(x-x_{\text{ref}}(t)\big).u=uref​(t)−K(x−xref​(t)).

The first term is feedforward: it does the work the model predicts, without waiting for an error. The second is state feedback on the deviation, with KKK from an LQR designed around the trajectory or an MPC with the reference in its cost; it only corrects what the model missed (wind, a heavier payload, a lazy motor). The model handles what is known and the measurement handles what is not, the two-degree-of-freedom split that runs through all of control.

The hard question is where urefu_{\text{ref}}uref​ comes from. For quadrotors there is an elegant answer: positions determine attitude and thrust in closed form (differential flatness), so a smooth position trajectory yields the exact feedforward, and polynomial trajectories that minimize snap keep it gentle on the motors (minimum-snap trajectory).

A good feedforward lets the feedback be gentle. With exact feedforward the feedback gains can stay low, which keeps noise out of the motors and margins wide; without it, high gains are the only way to follow fast references, and they bring the costs of high gains.

The trajectory must be feasible before it is flown. If the feedforward computed from it exceeds thrust or tilt limits anywhere along the path, no feedback will follow it; checking this before takeoff is cheap and catches most failures of aggressive plans.

Upward, imperfect tracking becomes error in what the planner asked for (motion planning); downward, it becomes actuator effort and wear. Feedback around a reference inherits the linearization's limits, so for very aggressive paths the linearization is redone along the trajectory.