do-mpc for nonlinear model predictive control in Python
Model predictive control python toolbox
At a glance
- What is it?
- do-mpc is a Python toolbox for nonlinear and economic MPC, moving horizon estimation, and simulation. It suits engineers who can define the model, objective, constraints, and numerical solver dependencies for their control problem.
- Who is it for?
- do-mpc fits engineers who need a modular Python workflow for nonlinear MPC or moving horizon estimation and can prepare a validated process model. It is a poor choice for a ready-made controller with little application-specific modeling.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 31 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
do-mpc targets nonlinear MPC and moving horizon estimation
do-mpc addresses repeated control decisions based on a model of a dynamic system. The README identifies nonlinear and economic model predictive control, moving horizon state and parameter estimation, differential algebraic equations, time discretization, and robust multi-stage MPC as supported areas. It is intended for engineers, researchers, and developers who formulate control or estimation problems in Python rather than merely apply a fixed feedback law.
The toolbox is more relevant when a project needs several connected capabilities. Moving horizon estimation can supplement control when measurements do not reveal the complete state. Economic MPC can represent an economic objective. DAE support matters when the system includes algebraic relationships alongside differential dynamics. The README also states that do-mpc includes tools for uncertainty and time discretization.
This breadth does not remove engineering work. An application still needs a process model, decision variables, an objective, constraints, horizon settings, and a suitable optimization backend. The repository organizes examples for chemical reactors, vehicle dynamics, industrial systems, oscillation models, and state estimation. Those directories show the range of examples, but they do not show that every example uses the same model structure, solver, or numerical settings.
The project is not archived. The last push was on 2026-09-22. Releases include v5.1.2 on 2026-09-03, v5.1.1 on 2025-10-31, and v5.1.0 on 2025-10-31. Those dates show recent repository and release activity. They do not, by themselves, establish compatibility with a specific Python environment, solver, or control system.
do-mpc separates models, controllers, estimators, and utilities
The repository layout and `setup.py` show that do-mpc is a Python package with separate components for controllers, estimators, models, sampling, system identification, tools, OPC UA, differentiators, and approximate MPC. This package structure matches the README's claim that simulation, estimation, and control can be combined. It also tells adopters where project-specific extensions would fit.
This modular arrangement is useful when several workflows share a model or need similar optimization behavior. Controllers and estimators remain separate from the model package, while additional functionality lives in focused subpackages. That can make the organization easier to inspect than a single script containing model equations, estimation logic, and solver calls together.
The abstraction has a cost. Developers need to learn the interfaces and conventions of do-mpc before they can change model structure, objective terms, constraints, or estimator components. The README does not document a complete minimal API sequence, and the repository's `setup.py` identifies package names rather than usage calls. A first implementation should therefore follow the matching section of the online documentation and a relevant repository example instead of guessing API names.
Runtime dependencies are declared in `requirements.txt`: `casadi>=3.6.0`, `scipy`, `numpy`, `matplotlib`, and `pandas`. The README also mentions CasADi and IPOPT when discussing citation of related software. It does not list IPOPT in `requirements.txt`, so its presence in a working setup depends on the solver choices made for the application.
do-mpc installation depends on the documented Python stack
The README does not contain a self-contained installation command. Instead, it directs users to the installation page at https://www.do-mpc.com/en/latest/installation.html. The repository includes `setup.py`, `requirements.txt`, and an optional `full` package group in `extras_require`, but those files do not state an exact platform-specific installation command. Supplying one here would go beyond the documented commands.
The README says do-mpc is Python based and works on any operating system with a Python 3.x distribution. The dependency list makes that statement more specific: a working installation also needs CasADi, SciPy, NumPy, Matplotlib, and pandas. Because the project formulates and solves optimization problems, the application will likely need a compatible numerical solver as well. The README mentions IPOPT as an example of other software used with do-mpc, but it does not give a solver installation command.
For a first real use, open the installation instructions and then choose the example closest to the intended plant. Relevant directories include `examples/CSTR/`, `examples/double_inverted_pendulum/`, `examples/dynamic_bicycle_model/`, `examples/industrial_poly/`, `examples/rotating_oscillating_masses_mhe_mpc/`, and `examples/triple_tank_ekf/`.
There is no designated quick-start example in the README. The CSTR directory is relevant to process control, while the vehicle examples concern dynamic and kinematic bicycle models. The combined MHE and MPC example is more relevant when state estimation is part of the task. Choose based on system structure, then check the example's declared dependencies and solver configuration before adapting it.
do-mpc supports DAE models and numerical discretization
The README lists differential algebraic equations and time discretization with orthogonal collocation on finite elements. These are substantive modeling features rather than convenience wrappers. A DAE representation can express differential and algebraic relationships in one model, while discretization converts a continuous model into a form that can be handled within repeated finite-horizon optimization.
Orthogonal collocation introduces choices about the time grid and finite elements. The README does not document default element counts, accuracy settings, or convergence behavior. Those omissions matter because a simulation that solves successfully is not necessarily an accurate representation of a physical process. An engineer still needs to compare discretization choices against the model and validation data.
The examples provide several concrete starting points. `examples/oscillating_masses_discrete/` covers a discrete oscillation model, while `examples/oscillating_masses_discrete_dae/` includes a DAE-oriented case. Their existence confirms that discrete and DAE example projects are included. The README does not explain every equation or parameter in those directories, so selecting a discretization method based only on the directory name would be premature.
do-mpc is therefore not the right tool when the application needs only a fixed linear controller. Its features become relevant when the control law must repeatedly solve an optimization problem and the system is nonlinear, constrained, uncertain, or coupled through algebraic variables. A team that cannot validate the dynamic model or numerical discretization should address that gap before relying on the controller formulation.
The framework leaves solver and production operations open
do-mpc provides the modeling structure, but an application remains responsible for its numerical backend. The repository requires CasADi and lists SciPy and NumPy, while the README mentions IPOPT as associated software. It does not publish a complete solver compatibility table, a universal solver configuration, or a documented fallback policy. A project team must confirm how its chosen backend handles its particular model and constraints.
Production control also raises requirements that the README does not cover. It does not document runtime monitoring, redundant controller instances, alarm management, fail-safe transitions, controller rollback, or hardware interfaces. The presence of an OPC UA package suggests a possible integration path, but the README does not describe its deployment model. It would be a mistake to treat package inclusion as proof of a production-ready control node.
That route may be easier to inspect for a small application, but it requires implementing more surrounding structure. do-mpc becomes more attractive when a team values shared components across simulation, MPC, and MHE work.
Neither route removes the need for numerical validation. If the plant model, objective, or discretization is wrong, a correctly solved optimization can still produce unsuitable control behavior.
LGPL-3.0 and releases require an adoption check
The repository identifies `do-mpc` as licensed under GNU Lesser General Public License version 3. `setup.py` records the license as GNU Lesser General Public License version 3 as well. A team planning to distribute an application or modified library should review the license obligations for its distribution arrangement. This is an engineering compliance checkpoint, not legal advice.
The recent release list includes v5.1.0 and v5.1.1 on 2025-10-31, followed by v5.1.2 on 2026-09-03. The repository was not archived, and the last push was on 2026-09-22. Upgrading can therefore involve changes to APIs, dependencies, examples, or solver behavior. The README does not publish a migration guide for these versions, so an adopter should compare the relevant documentation and example before changing a working installation.
The first verification pass should stay narrow: follow the linked installation page, inspect `requirements.txt`, select one matching example, and confirm which optimization backend that example expects. Then check the LGPL-3.0 terms against the intended distribution model and assess whether the target environment has the numerical and timing behavior required for the control loop. This sequence tests the actual adoption boundary before application code is written.
Editorial conclusion
do-mpc fits engineers who need a modular Python workflow for nonlinear MPC or moving horizon estimation and can prepare a validated process model. It is a poor choice for a ready-made controller with little application-specific modeling. Before adoption, verify the installation requirements, chosen example, optimization backend, numerical settings, deployment needs, and LGPL-3.0 obligations for the intended distribution.
Frequently asked questions
What is do-mpc used for?
do-mpc is a Python toolbox for nonlinear and economic model predictive control and moving horizon estimation. The README also lists DAE support, time discretization, and robust multi-stage MPC as documented features.
How do I install do-mpc?
The README directs users to https://www.do-mpc.com/en/latest/installation.html. `requirements.txt` lists `casadi>=3.6.0`, `scipy`, `numpy`, `matplotlib`, and `pandas`, but the repository files do not provide an exact installation command.
Does do-mpc support nonlinear systems and moving horizon estimation?
Yes. The README identifies nonlinear MPC and moving horizon state and parameter estimation as supported capabilities. The repository also includes `examples/rotating_oscillating_masses_mhe_mpc/` for a combined estimation and control example.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/do-mpc-do-mpc)