TinyMPC: a convex model-predictive control solver built for microcontrollers

A convex MPC solver written for small targets

TinyMPC exists because model-predictive control normally assumes a machine with memory and compute to spare. This is a solver written for the other case. It is C++, it targets microcontrollers, and the repository tags list model-predictive control, solver, embedded and the ADMM algorithm as the subject areas, which tells you the family of numerical method the implementation belongs to. The project came out of academic work and carries an ICRA 2024 Best Paper Award in its description, with three papers cited for citation: the original conference paper, a follow-up on robust and efficient embedded convex optimization through first-order adaptive caching, and a 2026 paper on code generation and conic constraints. The documentation lives on its own site, and questions about the solver are routed to the GitHub Discussions page of the organisation rather than to an issue tracker.

Building is four commands with CMake

There is no package manager step here. The build is a clone, a build directory, a CMake configure and a CMake build, and on Windows the documentation asks you to enable wsl first so the same terminal steps work.

git clone https://github.com/TinyMPC/TinyMPC.git

cd TinyMPC && mkdir build && cd build

cmake ..

cmake --build .

The repository root holds a CMakeLists.txt, an include directory, a src directory, an examples directory and a binaries directory, so the layout is a conventional C++ library with public headers separated from implementation. Because the build is plain CMake, integrating the solver into an existing embedded project is a matter of adding the sources rather than fighting a build system, which matters for the target audience of firmware teams who already have their own toolchain set up.

The examples span hovering, tracking, landing and code generation

The examples directory shows how much of the control space the project expects to cover, and the file names are more informative than any marketing copy. There is a quadrotor hovering example, a quadrotor tracking example, two examples that add linear and total variation linear constraints to the quadrotor, a rocket landing example, a cart pole example, and two code generation examples, one for the cart pole and one for a random problem. The documentation points at two of them directly. The hovering example is a binary you run from the build directory, and the code generation example is followed by repeating the same build steps inside that example's own directory, because what it produces is C code you then compile yourself.

./examples/quadrotor_hovering

./examples/codegen_cartpole

Two separate binaries for the same concept, one solved at runtime and one solved ahead of time into generated code, is the clearest statement of what this library is for.

Code generation is the path that reaches real hardware

The difference between the two example styles matters more than the example names suggest. Running the hovering example solves the problem on the machine you built it on, which is fine for a desktop. The code generation example instead writes out the solution as code, and the documentation tells you to follow the same building steps inside that directory afterwards, which is the sign that the generated artefact becomes a compile-time input for your own firmware. This is the pattern that lets a controller that would be too slow to optimise at runtime be solved once, offline, and then executed on a target with no solver present. The 2026 paper in the citation list is specifically about code generation and conic constraints, so the direction of travel in the project is toward making that offline path cover more kinds of constraint.

Python, Julia and MATLAB interfaces sit in their own repositories

High level language interfaces with examples and code generation are offered, but they are not part of this repository. The README links to separate projects for Python, Julia and MATLAB, each under the same organisation. The split is sensible for a firmware library: the C++ core has to stay small and dependency free, while the Python interface is a convenience wrapper with tooling that a microcontroller build never needs. The practical consequence for a user is that the interface you will experiment in is not the same artefact you will ship, so a team that prototypes in Python should expect to move the resulting model and code generation step into the C++ project before the hardware is involved.

Nonlinear dynamics live in a separate, unoptimised project

The boundary of the solver is stated plainly in the README. TinyMPC-AL is described as an earlier version which is not optimized, and which can deal with nonlinear dynamics, with bicycle models given as the example. It lives in a different repository under the Robotic Exploration Lab organisation. So if your plant has nonlinearity that matters, the current optimised solver is the wrong tool and the alternative is explicitly the slower and earlier design, not a configuration flag in this one. Two other related artefacts point the same way. Firmware integrating TinyMPC on the Crazyflie nano quadrotor is published separately, and numerical benchmarks against other solvers on microcontrollers are kept in a separate mcu-solver-benchmarks repository, so the comparative numbers are somewhere other than the documentation you read while installing.

MIT terms, an academic lineage and an open issue tracker

The licence is MIT, which for an embedded solver matters more than it does for a web library, because the solver usually ends up compiled into firmware that a team ships. The work was supported by the National Science Foundation under award 2411369, and the README carries the standard disclaimer that opinions and findings are the authors'. The repository is not archived and the last push was on 2026-09-02, so the code is still moving, though there are no tagged GitHub releases, so the version you build is whatever the default branch holds at the moment you clone it. Bug reports go through the GitHub issue tracker, which accepts not only defects but documentation typos and feature requests.

Editorial conclusion

Choose TinyMPC when the control loop runs on a microcontroller and a desktop solver will not fit, and when your model is convex enough for the solver's scope, since the nonlinear case is delegated to a separate earlier project that the documentation itself describes as not optimized. Check first that your dynamics fit that scope, then build the CMake project, run the code generation example and read the generated output before wiring it to flight hardware. The MIT licence lets you embed the solver in a product without copyleft obligations.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. TinyMPC/TinyMPC on GitHub