humanoidsdata.com

Search

Search companies, datasets, articles, and glossary terms for humanoids and embodied AI.

← All glossary terms

Hardware & control

Model predictive control

Model predictive control is a feedback-control method that uses a dynamics model to optimise a sequence of future actions, applies the first action or short part of that sequence, and replans from an updated state estimate. In receding-horizon MPC, the planning window moves forward at each update.

Also known as: MPC, model-predictive control, receding-horizon model predictive control

Updated

Replanning turns a predicted trajectory into feedback

The basic loop is to estimate the current state, optimise a future trajectory, execute its first action and repeat. Tedrake's treatment of MPC explains why this is a feedback policy even when the policy has no compact formula: the optimisation is solved again using the current state, rather than blindly replaying an earlier plan.

The optimisation needs a model of robot dynamics, a cost describing the desired behaviour, a planning horizon and any imposed constraints. A humanoid walking formulation might penalise deviation from a desired body velocity while constraining contact forces. That example describes a possible formulation, not a requirement that every MPC controller use the same state or contact model.

MPC is not synonymous with whole-body control

MPC describes how future decisions are planned and refreshed. Whole-body control describes coordination across the robot's joints, tasks and contacts. A system can use MPC on a reduced model and let a separate whole-body controller produce joint commands; another design can optimise a more detailed model directly. The two labels therefore answer different questions.

Similarly, using a model does not require learning that model with a neural network. Linear, nonlinear and learned dynamics can support different MPC formulations. The model and solver determine what can be predicted and computed within the available time.

Constraints in a solver are not a blanket safety guarantee

Tedrake distinguishes a feasible solution now from recursive feasibility: whether a feasible solution will still exist after the horizon shifts. His discussion of terminal conditions and stability shows that these properties require suitable assumptions and design; they do not follow from the name MPC alone. Model error, disturbances and computation deadlines also matter on hardware.

For demonstrations generated by MPC, preserve the state estimate available at each decision, model version, costs, constraints, horizon, replan interval and solver status. Record the action actually sent to the robot separately from the full predicted sequence. A planned future action that was replaced at the next update is not an executed training target, and control latency can make a timely-looking plan stale before execution.

Sources