MPC Lab — re-solve a curvature sequence within a horizon and steering limits

Run while watching the predicted path

Run "Straight · 1 m offset" and play it back. The green dashes at each moment are the predicted path solved at that time. MPC decides the whole curvature sequence over the horizon, but applies only the first value to the vehicle and re-solves everything in the next cycle (0.05 s later). The predicted and actual paths differ both because the prediction model is an approximation and because later cycles update the plan.

Save the result as A, then run "Short horizon (3 steps)" or "Long horizon (30 × 0.2 s)". With the same weights, how far ahead the controller looks changes how steering builds up. The horizon length in seconds is the number of steps N times the step Δt.

Prediction model and optimisation problem

The states are the lateral error e_y relative to the path (left positive) and the heading error e_ψ. Prediction uses a linear model simplified for MPC.

u_k is the commanded path curvature [1/m], κ_k the path curvature at the predicted position, and v_k the speed predicted with the same speed servo as the vehicle. Steering is δ=atan(L u), so the steering limit |δ|≤δ_max is exactly the curvature bound |u|≤tan(δ_max)/L. The cost

gives a quadratic program with only curvature bounds. u_{-1} is the curvature actually applied in the previous cycle. r weights deviation from the path curvature and r_Δ weights fast curvature changes. The prediction is a small-angle linear model, while the vehicle is the nonlinear shared bicycle model. That difference is part of what the experiment shows.

Solver, and what happens when it does not converge

The quadratic program is solved with a projected Newton method (Bertsekas 1982). Variables held at a bound are fixed, a Newton direction is computed for the rest, and a line search follows the projection onto the bounds. The solve counts as converged when the projected-gradient residual is at most 1e-6 [1/m]. The previous cycle's solution is the starting point, so it normally converges within a few iterations.

If the iteration limit is reached without convergence, you can choose one of three behaviours. "Use feasible iterate" applies the iterate, which respects the bounds, and records the cycle as unconverged. "Hold previous command" keeps the previous steering and records the cycle as held. "Stop" ends the run as a failure (controller_failed) and shows the reason. Compare them with the three presets that use a one-iteration limit. With bounds as the only constraints this problem is never infeasible (a solution always exists). Infeasibility from hard state constraints is outside the scope of this Lab.

Constraints, weights and speed

"8 m/s · default weights" completes, but "8 m/s · small rate weight (diverges)" leaves the path. The vehicle limits the steering rate to 0.8 rad/s, but this optimisation problem does not include that limit as a constraint. With a small rate weight r_Δ the plan assumes fast steering changes that the vehicle cannot follow, and the oscillation grows. It is an example of a constraint missing from the model breaking the closed loop. "High lateral weight" also shows abrupt corrections running into the steering-rate limit.

"Tight curve (cannot follow)" is a 5 m radius path the vehicle cannot follow. Under the same conditions the Stanley Lab also leaves the path. Changing the control law cannot exceed the limits set by the vehicle and its constraints.

Shared vehicle and comparison metrics

The vehicle is the rear-axle, forward-only kinematic bicycle model shared with PP, APP, RPP and Stanley: 0.05 s steps up to 30 s, 8 m/s speed limit, ±2 m/s² acceleration, 0.8 rad/s steering rate. Speed is not optimised by the MPC; it comes from the same speed servo a=2(target speed−actual speed) as the other Labs. This Lab's MPC handles steering only.

Lateral error, heading error, RMS and the endpoint test use the definitions shared with the other Labs, on the rear axle. Passing the endpoint does not mean stopping or parking. Do not rank runs with different elapsed times or completion states by RMS alone.

About computation time

Solver time is wall-clock time of Python (Pyodide) in this browser. It changes with the device, the browser and whatever else is running, and says nothing about computation time on an in-vehicle computer or whether a control deadline would be met. Performance evaluation requires measuring worst-case solve time on the target hardware and implementation (for example a dedicated solver such as OSQP).

Suggested order

1. Play back the nominal run and compare the predicted path with the actual path.
2. Change the number of horizon steps and the step size, and compare steering build-up and lateral error.
3. Use the two 8 m/s presets to see how the rate weight relates to the steering-rate limit.
4. Use the three one-iteration presets to compare how unconverged cycles are handled.

Everything runs in your browser, with playback, frame stepping, A/B comparison, reset, sharing and JSON download.

References and related Labs

• Bertsekas (1982), Projected Newton Methods for Optimization Problems with Simple Constraints, SIAM J. Control Optim. 20(2), 221–246
• OSQP
• Control Engineering Primer: Model Predictive Control
• Stanley Lab
• PP Lab
• Source and model notes