qpOASES solves dense quadratic programs with an online active set

A QP solver aimed at problems that are solved again and again

qpOASES is described in the README as an open-source C++ implementation of the recently proposed online active set strategy, which was inspired by important observations from the field of parametric quadratic programming. It has several theoretical features that make it particularly suited for model predictive control applications.

The word parametric is the one to hold onto. In an MPC loop the same quadratic program structure is re-solved at every control step with slightly different data, and an online active set method exploits that: it keeps track of which constraints are active and reuses that knowledge rather than starting each solve from scratch. The README goes on to say that further numerical modifications have made qpOASES a reliable QP solver, even when tackling semi-definite, ill-posed or degenerated QP problems.

That last clause is the practical selling point. Dense QP solvers are notoriously fragile on the problems that real control models produce, where the Hessian may not be positive definite, the constraints may be linearly dependent, or the problem may be feasible only on a lower dimensional set. A solver that survives those is worth more than one that is fast on well-conditioned academic examples.

The authorship is stated in the file headers as Hans Joachim Ferreau, Andreas Potschka and Christian Kirches, with copyright 2007-2017.

The user manual, not the readme, is the documentation

The getting started section is two numbered items, and the first one is the important one.

It says that for installation, usage and additional information on this software package you should see the qpOASES User's Manual located at doc/manual.pdf, or check its source code documentation. The manual is in the repository at doc/manual.pdf, and the top level of the repository confirms it with a doc/ directory.

The second item is the licence, and it is phrased as a warning. The file LICENSE.txt contains a copy of the GNU Lesser General Public License v2.1, and the instruction is to read it carefully before using qpOASES.

That is an unusually direct statement from a numerical library, and it reflects the nature of the software. A QP solver is a piece of infrastructure that ends up inside a control loop, where a wrong answer is not a stack trace but a bad actuator command. A manual that specifies the problem classes the solver handles, the tolerances, the scaling behaviour and the meaning of every return code is doing real work, and the README says so rather than pretending the header comments are enough.

The package itself is obtained from qpOASES.org or from the GitHub repository, and the webpage also carries a support section with a list of questions posed by other users.

Building from source, and the optional MUMPS path

The repository is a classic C++ library tree with build support for several platforms. At the root there are CMakeLists.txt, a qpOASESConfig.cmake.in for CMake package configuration, make.mk, and per-platform makefiles named make_linux.mk, make_osx.mk, make_windows.mk and make_cygwin.mk, plus a plain Makefile, an INSTALL file and a VERSIONS file.

The Makefile is where the build options become visible, and there is one decision that changes the dependency set. The DEF_SOLVER variable selects the solver backend, and the conditional is `ifeq ($(DEF_SOLVER), SOLVER_MUMPS)`, in which case an external MUMPS directory is added to the build. The mumps target cd's into external/ThirdParty-Mumps, looks for a MUMPS source directory, and if it is not there it fetches it with get.Mumps and configures it with a prefix pointing at external/mumps_installation before building and installing it.

Everything else is a straightforward fan-out. The all target depends on the optional external dependency plus bin, src and examples. The src target recurses into the source directory, examples depends on src, and there are separate targets for doc, testing and debugging. The test target runs the C++ test suite in testing/cpp through a runTests target, and the testing target itself depends on src.

The repository layout also shows the scope of the package. There is src/ for the implementation, include/ for headers, examples/ with a Makefile and numbered programs such as example1.cpp, example1a.cpp, example2.cpp, example3.cpp, example4.cpp, example5.cpp, plus qrecipe.cpp and qrecipeSchur.cpp, and a generate_sparse_qp/ directory for producing sparse test problems. The interfaces/ directory holds the bindings to third-party software, and external/ is where a third-party dependency such as MUMPS would be placed. The .coin-or/ directory is the package metadata for the COIN-OR project, of which qpOASES is a part.

Interfaces to Matlab and Simulink, for people who do not write C++

The README makes a point about who the library is for, and it is stated in the introduction rather than buried.

Several interfaces to third-party software like Matlab or Simulink are provided that make qpOASES easy-to-use even for users without knowledge of C/C++. The interfaces/ directory in the repository is where those live, and the topic of the whole project being a COIN-OR module sits alongside it, since the .coin-or/ directory at the root holds the package metadata.

This matters because the alternative to embedding a C++ QP solver in a control stack is either writing your own solver or exporting to a tool you then have to call across a process boundary, and both are worse for a real-time loop. A Simulink or Matlab interface lets a control engineer prototype and tune the same solver that will run embedded, which is the whole argument for a mature library like this rather than a general purpose one.

The example set supports the same claim from the C++ side. qrecipe.cpp and qrecipeSchur.cpp are recipe-style programs, and qrecipe_data.hpp holds their data, while the numbered example1 through example5 files cover increasing levels of complexity, and the exampleLP and example4CP variants show the same problem solved through different routes. The examples directory also has its own Makefile, so examples are built with the same system as the library rather than as a separate project.

The testing/ directory at the root holds the C++ test suite that the test target drives, and the repository keeps a .gitmodules file, so some components are pulled in as submodules.

Where it is the wrong tool, and how to reach the maintainers

The limits are worth stating plainly, since a QP solver is often evaluated as if it were a general optimiser.

First, the scope. The README describes a solver for quadratic programs, and the online active set strategy is the mechanism. It is not a nonlinear solver, not a conic solver, and not a general purpose modelling tool, and choosing it for a mixed integer or nonlinear problem is a category error rather than a configuration mistake.

Second, the interface complexity. A library aimed at MPC applications, with a manual that must be read carefully, with a QP recipe structure and Schur complement variants, has a real learning curve. The examples help, and there are many of them, but the density of the problem classes and the solver settings is high.

Third, the maintenance profile. The copyright headers in both the README and the Makefile say 2007-2017, and the Makefile itself carries version 3.2 with a date range of 2007-2017. The last push to the master branch was on 2026-05-12, and the repository publishes no GitHub releases at all, so the version history you would rely on is the VERSIONS file and the changelog rather than a tag list.

For support, the README is direct. Questions, remarks and comments should be reported by creating a new ticket on the qpOASES webpage, and if you would rather not disclose feedback publicly you may email [email protected]. The three main authors are listed with their addresses at ABB and the University of Heidelberg, and bug reports, source code enhancements and success stories are explicitly welcome.

Editorial conclusion

Adopt qpOASES if your application re-solves a dense quadratic program at every step and you need the warm-start behaviour of an online active set method, particularly for model predictive control, and you are prepared to read the User's Manual in doc/manual.pdf before touching it. Do not adopt it as a general purpose nonlinear or conic optimiser, because the scope is quadratic programs and the interfaces assume that. Before you commit, confirm that your problem is a QP the active set strategy can handle, check the licensing, since the library is LGPL 2.1 or later and the manual asks you to read LICENSE.txt carefully, and note the maintenance picture, with the last push on 2026-05-12 and no GitHub releases published.

Frequently asked questions

Official sources

1. coin-or/qpOASES on GitHub
2. Issues
3. License: LGPL-2.1
4. README