Skip to content
AI360Xpert
Beta

Model Predictive Control for Robots

Model Predictive Control (MPC) optimizes robot commands across a future time horizon using a dynamic model, executes only the immediate first step, and replans at the next cycle with updated state feedback to handle constraints gracefully.

Model Predictive Control optimizes trajectories across a receding horizon, executing only the first action before replanning
Model Predictive Control optimizes trajectories across a receding horizon, executing only the first action before replanning

Why Does This Exist?

Standard PID feedback control is purely reactive: it looks at present error e(t)e(t) and past accumulated error to calculate motor torque. It cannot anticipate an upcoming sharp bend in a path, cannot look ahead to decelerate before hitting a hard joint limit, and cannot enforce complex inequality constraints (like maximum torque or obstacle boundaries).

Global motion planners (like A* or RRT) solve for long collision-free paths, but take hundreds of milliseconds to compute and assume a static world: if a human steps in front of the robot, the global planner stalls.

Model Predictive Control (MPC), also called receding horizon control, fills the vital middle tier between high-level global planning and low-level joint reflexes. By using a predictive mathematical model of robot physics over a short future window (such as 0.50.5 to 2.0 seconds2.0\text{ seconds}), MPC optimizes candidate control sequences subject to hard physical constraints, executes only the first commanded step, and replans continuously with fresh sensor feedback.

Basics first: the low-level PID loops that track MPC setpoints live in robot-feedback-control. Global path planning across configuration space lives in robot-motion-planning. Learning action-conditioned predictive dynamics from data lives in robot-world-models.

Think of It Like This

Sprinting through a crowded train station while looking five paces ahead

Imagine rushing through a crowded train concourse to catch your departure. You do not stare straight down at your toes (purely reactive PID), nor do you freeze to calculate a rigid, fixed route across the entire building (global planning).

Instead, you focus your gaze five paces ahead (the prediction horizon). As you run, you predict where walking passengers will be in two seconds, steer smoothly around them, and avoid brushing against luggage carts (constraint handling).

Crucially, you only execute your very next stride. As your foot hits the ground, you shift your gaze forward another five paces and adjust your heading based on what actually moved.

Where it stops: human runners have vast situational awareness and peripheral vision. Robot MPC must solve a numerical mathematical optimization problem (such as a quadratic program) within strict real-time deadlines (e.g. every 10 to 20 milliseconds10\text{ to }20\text{ milliseconds}). If the solver fails to converge before the deadline, the robot has no command to send to its motors.

How It Actually Works

The receding horizon optimization problem

At discrete time tt, given current measured state xt\mathbf{x}_t, MPC solves a constrained finite-horizon optimal control problem over a prediction horizon of NN steps:

min⁡u0,u1,…,uN−1∑k=0N−1(∥xk−x∗∥Q2+∥uk∥R2)+∥xN−x∗∥Qf2\min_{\mathbf{u}_0, \mathbf{u}_1, \dots, \mathbf{u}_{N-1}} \sum_{k=0}^{N-1} \left( \|\mathbf{x}_k - \mathbf{x}^*\|_{\mathbf{Q}}^2 + \|\mathbf{u}_k\|_{\mathbf{R}}^2 \right) + \|\mathbf{x}_N - \mathbf{x}^*\|_{\mathbf{Q}_f}^2

subject to:

  1. Dynamic model: xk+1=f(xk,uk)\mathbf{x}_{k+1} = f(\mathbf{x}_k, \mathbf{u}_k) with x0=xt\mathbf{x}_0 = \mathbf{x}_t.
  2. State constraints: xmin⁡≤xk≤xmax⁡\mathbf{x}_{\min} \le \mathbf{x}_k \le \mathbf{x}_{\max} (e.g. maximum velocity, position boundaries).
  3. Actuator constraints: umin⁡≤uk≤umax⁡\mathbf{u}_{\min} \le \mathbf{u}_k \le \mathbf{u}_{\max} (e.g. motor torque limits, acceleration bounds).

where Q\mathbf{Q} penalizes state tracking errors, R\mathbf{R} penalizes control effort, and Qf\mathbf{Q}_f is the terminal cost.

The receding horizon loop

  1. Measure current state xt\mathbf{x}_t from robot state estimation.
  2. Solve the optimization problem over horizon [t,t+N][t, t+N] to obtain optimal sequence U∗=[u0∗,u1∗,…,uN−1∗]\mathbf{U}^* = [\mathbf{u}_0^*, \mathbf{u}_1^*, \dots, \mathbf{u}_{N-1}^*].
  3. Apply only the first control action u0∗\mathbf{u}_0^* to the robot motor controllers.
  4. Discard the remaining planned actions [u1∗,…,uN−1∗][\mathbf{u}_1^*, \dots, \mathbf{u}_{N-1}^*].
  5. Advance the clock to t+1t+1, obtain fresh sensor feedback, and repeat the optimization.

Because the optimization repeats every cycle with real-world state feedback, MPC continuously corrects for model inaccuracies, wheel slip, and unexpected disturbances.

Worked example: 1D cart regulation over a 3-step horizon

Consider a 1D robotic delivery cart tracking a target position x∗=1.0 mx^* = 1.0\text{ m}.

  • Discrete state dynamics: xk+1=xk+vkΔtx_{k+1} = x_k + v_k \Delta t, vk+1=vk+ukΔtv_{k+1} = v_k + u_k \Delta t, with Δt=0.1 s\Delta t = 0.1\text{ s}.
  • Initial state at tt: position x0=0.0 mx_0 = 0.0\text{ m}, velocity v0=0.0 m/sv_0 = 0.0\text{ m/s}.
  • Horizon length: N=3N = 3 steps (0.3 seconds0.3\text{ seconds}).
  • Actuator constraint: acceleration ∣uk∣≤2.0 m/s2|u_k| \le 2.0\text{ m/s}^2.
  • Velocity constraint: 0.0≤vk≤1.0 m/s0.0 \le v_k \le 1.0\text{ m/s}.
  • Cost function weights: Q=1.0Q = 1.0 (tracking error), Qv=0.5Q_v = 0.5 (velocity damping), R=0.1R = 0.1 (control effort).

Evaluate candidate control sequence U=[1.2,1.2,0.0] m/s2\mathbf{U} = [1.2, 1.2, 0.0]\text{ m/s}^2:

  1. Step k=0→1k=0 \to 1 (u0=1.2 m/s2u_0 = 1.2\text{ m/s}^2): x1=0.0+0.0⋅0.1=0.000 m,v1=0.0+1.2⋅0.1=0.120 m/sx_1 = 0.0 + 0.0 \cdot 0.1 = 0.000\text{ m}, \quad v_1 = 0.0 + 1.2 \cdot 0.1 = 0.120\text{ m/s} J1=(0.0−1.0)2+0.5⋅(0.12)2+0.1⋅(1.2)2=1.000+0.0072+0.144=1.1512J_1 = (0.0 - 1.0)^2 + 0.5 \cdot (0.12)^2 + 0.1 \cdot (1.2)^2 = 1.000 + 0.0072 + 0.144 = 1.1512

  2. Step k=1→2k=1 \to 2 (u1=1.2 m/s2u_1 = 1.2\text{ m/s}^2): x2=0.000+0.12⋅0.1=0.012 m,v2=0.12+1.2⋅0.1=0.240 m/sx_2 = 0.000 + 0.12 \cdot 0.1 = 0.012\text{ m}, \quad v_2 = 0.12 + 1.2 \cdot 0.1 = 0.240\text{ m/s} J2=(0.012−1.0)2+0.5⋅(0.24)2+0.1⋅(1.2)2=0.9761+0.0288+0.144=1.1489J_2 = (0.012 - 1.0)^2 + 0.5 \cdot (0.24)^2 + 0.1 \cdot (1.2)^2 = 0.9761 + 0.0288 + 0.144 = 1.1489

  3. Step k=2→3k=2 \to 3 (u2=0.0 m/s2u_2 = 0.0\text{ m/s}^2): x3=0.012+0.24⋅0.1=0.036 m,v3=0.24+0.0⋅0.1=0.240 m/sx_3 = 0.012 + 0.24 \cdot 0.1 = 0.036\text{ m}, \quad v_3 = 0.24 + 0.0 \cdot 0.1 = 0.240\text{ m/s} J3=(0.036−1.0)2+0.5⋅(0.24)2+0.1⋅(0.0)2=0.9293+0.0288+0.0=0.9581J_3 = (0.036 - 1.0)^2 + 0.5 \cdot (0.24)^2 + 0.1 \cdot (0.0)^2 = 0.9293 + 0.0288 + 0.0 = 0.9581

Total horizon cost:

Jtotal=1.1512+1.1489+0.9581=3.2582J_{\text{total}} = 1.1512 + 1.1489 + 0.9581 = 3.2582

All constraints are satisfied (vk≤1.0 m/sv_k \le 1.0\text{ m/s}, uk≤2.0 m/s2u_k \le 2.0\text{ m/s}^2). The controller executes only the immediate action u0=1.2 m/s2u_0 = 1.2\text{ m/s}^2, commands the motor drive, and re-evaluates the optimization at t=0.1 st = 0.1\text{ s} from the newly measured position and velocity.

Code

This Python snippet defines a discrete MPC forward simulator, computes state rollouts, evaluates cost functions, and verifies the receding horizon first-step selection.

def evaluate_mpc_candidate(    u_seq: list[float],    x_init: float = 0.0,    v_init: float = 0.0,    x_target: float = 1.0,    dt: float = 0.1,) -> tuple[float, float, float]:    """Simulate candidate control sequence over horizon and return (cost, final_x, final_v)."""    x: float = x_init    v: float = v_init    total_cost: float = 0.0
    for u in u_seq:        x_next: float = x + v * dt        v_next: float = v + u * dt        # Cost: tracking error + velocity penalty + control effort        stage_cost: float = (x_next - x_target) ** 2 + 0.5 * (v_next ** 2) + 0.1 * (u ** 2)        total_cost += stage_cost        x, v = x_next, v_next
    return round(total_cost, 4), round(x, 4), round(v, 4)

cost, x_end, v_end = evaluate_mpc_candidate(u_seq=[1.2, 1.2, 0.0])print(cost)   # -> 3.2582print(x_end)  # -> 0.036print(v_end)  # -> 0.24

Watch Out For

Optimization solver exceeding real-time loop deadlines

If your robot's control loop runs at 50 Hz50\text{ Hz} (20 ms20\text{ ms} period), an MPC solver (such as a nonlinear interior-point optimizer) must guarantee completion in well under 15 ms15\text{ ms}. If the optimizer gets stuck resolving non-convex obstacles, it misses its compute deadline.

The symptom is the robot stuttering, hesitating, or executing outdated commands while the control loop stalls. Fix it by using warm-starting (seeding the solver with the shifted solution from the previous cycle), setting strict maximum iteration caps, or using high-speed convex quadratic programming (OSQP, qpOASES).

Model mismatch inducing high-frequency chatter

If the internal predictive model assumes an idealized frictionless surface while the real robot operates on thick carpet, the predicted state trajectory diverges from physical reality within two steps.

The symptom is aggressive command chattering: at step tt the solver commands large positive torque expecting rapid motion, but at t+1t+1 discovers the robot moved only half as far, causing it to command erratic corrections. Fix it by adding state-dependent disturbance estimators or learning data-driven robot world models that predict physical dynamics under complex contacts.

The Quick Version

  • Model Predictive Control optimizes control sequences across a finite future time horizon using a dynamic system model.
  • At each cycle, MPC solves a constrained optimization problem, executes only the first action (u0u_0), and replans with fresh feedback.
  • For a 1D cart tracking x∗=1.0 mx^* = 1.0\text{ m} over a 3-step horizon (Δt=0.1 s\Delta t = 0.1\text{ s}), candidate sequence [1.2,1.2,0.0] m/s2[1.2, 1.2, 0.0]\text{ m/s}^2 yields a cost of 3.25823.2582.
  • MPC inherently respects physical inequality constraints, such as motor torque limits, maximum velocity envelopes, and obstacle clearance margins.
  • Real-time feasibility requires fast convex quadratic solvers and warm-starting to ensure the optimizer consistently finishes within its strict loop deadline.