Externalize QP solver

[jmirabel]

This issue is to keep track of our discussion and let others know.

It would be interesting to create a repository containing the LP and QP solvers API developed in different packages. Some people (at least, me) would take advantage of such a repo. From the discussion with @andreadelprete , it seems there is not too much work to be done.

[jcarpent]

Indeed, we already discussed with @andreadelprete and @nmansard about that. I've already started such a project on my own but still work in progress.
And it seems pretty easy to do that. I think the main issue to discuss a bit about is a common interface for all these solvers.
Can we make a meeting next week @ LAAS to discuss all of that?

[proyan]

If it is any help, I think stephane caron did make a unified API in python for some of the available QP Solvers.
https://github.com/stephane-caron/qpsolvers

[olivier-stasse]

And then you get http://roboptim.net/

[andreadelprete]

@gabrielebndn has started working on this and he may update us on the status of that project here.

[gabrielebndn]

@andreadelprete, the externalized code can be found in repo eiquadprog.
In there, I copied eiquadprog_2011 (renamed eiquadprog.hpp, I don't think it's used a lot and I would not recommend it), eiquadprog-fast.hpp (which I turned to a header-only version) and eiquadprog-rt.hpp (which I reorganized so that it works by including eiquadprog-rt.hpp, not eiquadprog-rt.hxx, and where I fixed some minor Eigen compilation issues related to problems with less then two constraints).

The code is unit tested in folder unittest for many different cases.
The solvers seem to work perfectly well for all convex, bounded, feasible problems.
I sometimes get unexpected results for problems that do not respect these three conditions at the same time: sometimes I get a solution when there isn't one; sometimes I get a wrong solution; sometimes I do not get a solution when there technically is at lease one; sometimes I correctly get that there is no solution, but the specific error code is not correct.
I do not know how important this is, as I would expect that most of the problems we actually try to solve indeed do respect the above conditions. The above-listed cases are also documented in the unit tests: I am just using BOOST_WARN instead of BOOST_CHECK, so that the unit tests issue warnings when executed with -l warning, but they still technically pass.

I did not copy files solver-HQP-eiquadprog-fast.hpp and solver-HQP-eiquadprog-rt.hpp, as they seemed to me incomplete and non-essential.

Version 1.0.0 was released about a month ago. I've been using it on real problems for Talos and so far, it seems to do well. As far as I am concerned, work on it is more or less done and I am not planning to change anything. If you wish, I think you may remove the original files from tsid and depend on eiquadprog instead.

If you want to improve on existing algorithms, or help fixing the non-convex/unbonded/unfeasible cases (if you think it is desirable), or move solver-HQP-eiquadprog-fast.hpp and solver-HQP-eiquadprog-rt.hpp there, you are more than welcome to do so through a PR, which I can verify.

This is what concerns eiquadprog. But there is another point: in a recent issue (see stack-of-tasks/eiquadprog#2) @andreadelprete pointed out that QuadProg++ contains lots of the things we need. If we can confirm that QuadProg++ has everything we need, that it is stable, that it works well, that it is easy to integrate in our own systems, and that there are no problems with licences, then it is probably useless to have our own in-house solver and we could just rely on QuadProg++

[andreadelprete]

I think the main advantage of having our own package with a standard API (which is the one implemented by solver-HQP-...) is that we could easily switch solver if one day we need to.

[proyan]

It would also help with easily benchmarking different solvers.