A model predictive controller needs a model of the system it controls. That does not mean the controller and the simulator should share all their code or use identical coordinates.
In my CasMuMPC project, CasADi defines the prediction model and optimization problem. MuJoCo runs the plant. At each control step, the simulator provides a state, the controller computes an input, and the simulator advances.
The interface between them matters:
- State mapping. The controller may use fewer states or a different ordering than MuJoCo. Convert the measured state into the controller's coordinates explicitly.
- Control mapping. Convert the controller's decision variables into the actuator inputs expected by the simulated plant.
- Time stepping. The control update period and the simulation step are not necessarily identical. Decide when to hold an input and when to solve again.
- Model mismatch. The prediction model can be deliberately simpler than the plant. A closed-loop simulation is useful partly because the two models are not the same implementation.
Separating these responsibilities keeps the optimizer readable and makes mistakes at the interface easier to find. It also makes the examples easier to compare: a pendulum, cart-pole, acrobot, and double inverted pendulum use the same overall controller/plant idea but have different dynamics and state mappings.
This is an implementation note, not an MPC tutorial. The project repository contains the actual examples and their simulation scripts.