[Explainer] What Is Model Predictive Control? Why Robots Execute Only the First Move

Key takeaways

  • MPC uses a robot model to predict states over a finite horizon and optimize a sequence of control inputs.
  • The controller executes only the first input, measures the new state and solves a shifted problem again.
  • Joint, torque, contact, balance and collision limits can be included alongside tracking objectives.
  • In legged robots, MPC can select body motion and ground-reaction forces before lower-level control maps them to joints.
  • Model mismatch and missed compute deadlines degrade performance, and MPC alone is not a functional-safety guarantee.

MPC controls a robot by looking a short distance ahead

Imagine a robot crossing a row of low platforms. If it reacts only to the platform directly under its foot, the next step may push its body off balance or drive a joint into its limit. If it computes one complete motion before starting, a small change in the terrain can make that plan stale. Model predictive control (MPC) sits between those extremes by repeatedly looking ahead over a limited slice of the future.

The controller receives an estimate of the current position, velocity and orientation. It evaluates candidate control inputs through a mathematical model and predicts where the body, feet or wheels would be several steps later. An objective function scores tracking error, energy use and abrupt motion. The finite interval being predicted is called the horizon. It may cover milliseconds or seconds depending on the robot, model and available computing power.

Mobile robot predicting several future poses from its current state
The receding-horizon principle: predict a trajectory, apply the first input and solve again.

Why execute only the first move

The defining trick is that MPC does not replay the entire optimized input sequence. It applies only the first input, waits for the next measurement and solves a shifted problem from the new state. This is why the approach is also called receding-horizon control. An imperfect prediction can be corrected at the next update instead of contaminating the remainder of a long open-loop plan.

Suppose a foot slips two centimeters farther than expected. A controller that blindly finishes the original sequence carries that error forward. MPC treats the slipped pose as the next initial state and recomputes the following force or foothold. Replanning is not magic, however. A delayed sensor, a poor state estimate or an optimizer that misses its deadline can produce an answer that is already out of date.

Objectives and constraints share one optimization problem

MPC differs from a simple path search because it can include physical constraints directly in the optimization. These may include motor-torque bounds, joint angles and speeds, steering limits, friction at each foot, a stable support region and distance from obstacles. Within those limits, the controller searches for motion that tracks the command, conserves energy and remains smooth. Cost weights express which objective matters more when goals conflict.

Writing a constraint in software does not eliminate every real-world hazard. A continuous motion is usually discretized into sample points, so a limit checked at those points may still be violated between them. Unexpected objects and unmodeled contacts require separate detection. Engineers must also define what happens when the optimization is infeasible: reuse a previous solution briefly, slow down, switch controllers or enter a verified safe stop.

Humanoid optimizing balance, joint limits and obstacle avoidance while carrying a box
MPC compares tracking objectives and physical constraints inside one optimization problem.

How a legged robot selects contact forces

A legged-robot MPC often predicts a few steps using a reduced model that treats the torso as a rigid body. Given a desired velocity and a schedule describing which feet are in contact, it chooses body motion and ground-reaction forces. A whole-body or joint controller underneath converts those desired forces and poses into actuator commands. This hierarchy avoids optimizing every mechanical detail inside the highest-rate loop.

A 2018 MIT Cheetah 3 paper presented convex MPC for determining ground-reaction forces during dynamic locomotion. OCS2, an optimal-control toolbox initiated at ETH Zurich, provides algorithms and interfaces for robot dynamics, costs and path constraints and has supported legged-locomotion and mobile-manipulation research. These examples show real robotic use, but a result on one machine is not a performance guarantee for a different robot, model or processor.

Quadruped replanning footholds after an unexpected platform tilt
Feedback updates the state after prediction error and computes a fresh motion.

Different jobs from behavior trees, world models and CBFs

MPC operates at a different layer from a behavior tree. A behavior tree can decide to navigate, recover or hand control to a person. MPC continuously chooses motion and force while executing that request. A practical stack may use a behavior tree for mission flow, MPC for body and contact planning, and a faster motor controller for the actuator loop. One does not replace the others.

MPC is also not synonymous with a learned world model. A world model may learn future observations from video and action data; MPC is the procedure that optimizes control inputs using an explicit physics model or a learned model. A control barrier function focuses on keeping the state inside a safety set, whereas MPC optimizes performance and constraints over a finite future. Some systems combine MPC and barrier functions as separate layers.

Deployment depends on deadlines and failure handling

Computation is the central tradeoff. A longer horizon and a richer model can expose more future consequences, but the optimization grows. A model that is too simple or a horizon that is too short may miss important effects. TinyMPC targets convex MPC on resource-constrained microcontrollers, illustrating why solver speed and memory footprint matter when the control answer must arrive before a hard deadline.

For deployment, ask for timing and failure evidence instead of accepting the label MPC. Measure end-to-end latency from state estimation through optimization to the actuator command. Check worst-case solve time, infeasibility handling, sensitivity to friction and payload changes, and the state entered after a process or communication failure. MPC is valuable not because it predicts the future perfectly, but because it formalizes a disciplined cycle: predict briefly, act once, measure reality and solve again.

Sources reviewed

Related reading

About the author

ITTimes.net writer Sean Woo
Sean Woo, ITTimes.net

Sean Woo — I have spent more than 15 years shaping robotics technology and business direction. Drawing on public technical documents, research papers and company announcements, I explain changes in robotics and AI in accessible terms. The interpretations in this publication do not represent the official position of any company or organization.

Leave a Comment