Hierarchy for external solvers

[alaurenzi]

While integrating the ILQR solver into Horizon, I found it easier to create an external class that, given an horizon.Problem, sets up the internal CXX-based ILQR solver class, and then provides a basic API to solve the problem and retrieve the solution.

Later on, to make simple comparisons between ILQR, SQP, and Ipopt, I came up with a simple hierarchy that you can find here. Usage example here.

What do you think about having external solvers as opposed to storing their logic inside horizon.Problem? @EnricoMingo @FrancescoRuscelli

[EnricoMingo]

You know that I always preferred the external solver than the internal one. This makes things easier for the horizon.Problem handling.

We have a similar problem indeed with the SQP implementation which internally stores a qp solver (as conic function) to solve the quadratic approximation.

In that case, my solution was to pass directly the options in input to the internal solver together with the qp solver string. However, I would keep the problem separated from the solver.

[FrancescoRuscelli]

At this point, since the mechanics behind each solver is structurally different from the others, separating the problem from the solver is a very tempting alternative.

If we decide upon this path, I would simplify horizon.state_variables and horizon.function removing all the parts regarding problem construction and update.

I still have to sort out the details, but those classes would be left as general interfaces to easily retrieve abstract variables/functions and their implementation at each node (so that a future horizon.Solver has less to unravel and unknot).

[FrancescoRuscelli]

You can find a tentative implementation in branch separate_probsol.