Quirks in qpOASES

qpOASES (paper, code, manual) is a solver for quadratic programs (QPs) that is designed to be particularly efficient for solving model predictive control problems, which typically involve solving a sequence of QPs with very similar parameters. I've had success using it for my research on control for mobile manipulation for a while now. In this post, however, I'll describe three issues I've run into with qpOASES that have caused me some confusion.

1 Not a number

The first issue was the result of a bug in my own code, and I offer it as a cautionary tale. It turns out that the qpOASES solver happily accepts matrices with NaN (not a number) values, and produces a solution vector saturated at one of the provided bounds and an optimal objective value of NaN. There is no error or other indication that the input is malformed in this way, so I'd recommend checking for a NaN objective value manually and raising an error so you know that your code has a bug to fix. In my case, I had an unintentional division by zero, and the result was some very unexpected control commands.

2 Working set recalculations

The next issue has to do with the number of working set recalculations (WSRs) performed by the solver, which is specified via the argument int_t& nWSR. Notice we're actually passing a reference int_t&, which is what tripped me up. The solver modifies this value to be the number of WSRs it actually performed. This behaviour is documented in the user manual, but I've still ended up confused when the solver initially succeeds but on subsequent solves begins to fail with the message

ERROR:  Maximum number of working set recalculations performed

This occurred because I was reusing the same nWSR variable for multiple calls to the solver, expecting it to be treated as constant. When a QP is easy for the solver, such as after a hotstart, the required number of WSRs may be very few or even zero. If one call to the solver sets nWSR = 0, then a subsequent call will fail if it needs any WSRs at all. To avoid the problem, I just make a new int_t for each call to the solver.

3 Equality constraints

The final issue has to do with the solver itself. For some reason it will refuse to solve certain equality-constrained problems with its default settings, as discussed in this GitHub issue. For example, I had a QP with an equality constraint $Ax=b$, where $A\in\mathbb{R}^{6\times9}$, that I knew to be feasible. However, qpOASES produced the error

ERROR:  Division by zero
->ERROR:  Abnormal termination due to TQ factorisation
  ->ERROR:  Determination of step direction failed
    ->ERROR:  Abnormal termination due to TQ factorisation
      ->ERROR:  Initialisation failed! QP could not be solved!

As I commented in the GitHub issue linked above, the solution is to set the solver to "reliable" mode:

qpOASES::Options options;
options.setToReliable();

// qp is my QProblem object
qp.setOptions(options);

For some reason, qpOASES is not able to handle all feasible problems with the default options, but at least the reliable options appear to live up their name.

Conclusion

While the issues I've described have caused me a couple of headaches, qpOASES has served me well: it is fast, free, and generally easy to use. Unfortunately, qpOASES no longer appears to be maintained, and there are many GitHub issues that have gone unresolved for a long while. I suspect it is time to at least consider switching to an alternative like OSQP.