OCP Croco Class

[ArthurH91]

Hello,

Intro

Here's a draft PR on the OCP base class.

After a discussion with @MaximilienNaveau , we agreed that having only crocoddyl might restrict some users. So we decided to have the OCPBase class staying as it is right now, and having a daughter class OCPCrocoBase, which is a simple task to reach a target with the end effector, as a baseline.

In this draft, I'd like to discuss this with y'all. Do you agree with this reasoning?

What's in the PR

• changes on absolute paths for files relative to mpc
• modification of the input of solve of the ocpbase (because it takes x_init and x_0, which is already given in x_init)
• the OCPCrocoBaseClass, as mentionned earlier
• an OCP Param Base class, that can "generalize" the input of the OCP (ie number of iterations of the solver, qp iters if SQP, error, termination condition ...) after the parsing.
• a draft on the testing, because i have several issues, especially with the data classes not taking none as input

What I'd like to discuss

• OCP Param Base class, I believe that's a valid option as output to the parser (be it from ros, yaml or whatever)

[Kotochleb]

Generally, you should avoid introduction of new public function to the abstract class. It was meant to be somewhat fixed so that no one is confused, and we do not end up with compatibility issues like those between for example, default Crocoddyl objects and MiM Solvers.

Additionally your implementation of OCPCrocoBase is not generic at all. It is very specific and you should introduce another class like OCPCrocoReaching where you can impose use of CSQP and your costs. OCPCrocoBase should only implement basic interaction with Crocoddyl and expose maybe new private abstract functions that allow user to choose which solver they want to use and how they want to set up shooting problem object.

Additionally please add docstrigns to OCPBase as you are the first person to extend it, so we will not have to document it later on.

[MedericFourmy]

My main concern is the function solve: maybe creating croco objects everytime would be too costly.

[MedericFourmy]

In general, I wonder if this is reasonable (in terms of time) to create croco objects (running/terminal costs, Action models etc.) from scratch every time we solve? It's simpler than going through through the croco ocp structure to only but might be a bit slow.
I just checked on a personal codebase a similar function and got:
T = 20 -> 0.7 ms
T = 40 -> 1.5 ms
T = 60 -> 2.7 ms
T = 80 -> 3.8 ms
T = 100 -> 4.5 ms

So it seems that the _state/_actuation creation is negligeable (I'd still put it in __init__ or a setup function) compared to the running cost creation.

[ArthurH91]

My main concern is the function solve: maybe creating croco objects everytime would be too costly.

i totally agree with this, thank you all for the reviews, i'm gonna start working on it tmrw !

[Kotochleb]

Those are not defined in __init__ with value None and why are they public?

[Kotochleb]

I think this would be better. Or even save a pickle with a dict with the numpy objects like so:

results = {
   "states": ' self.ocp.ocp_results.states.tolist(),
   "ricatti_gains": ' self.ocp.ocp_results.ricatti_gains.tolist(),
   "feed_forward_terms": ' self.ocp.ocp_results.feed_forward_terms.tolist(),
}

with open("ressources/simple_ocp_croco_results.pkl", 'wb') as handle:
    pickle.dump(results, handle, protocol=pickle.HIGHEST_PROTOCOL)

Maybe this way if someone loads it, it will be more obvious what is inside of this object

[MaximilienNaveau]

Just a minor comment on the initial value of the running and terminal model and I am happy.

[MaximilienNaveau]

@MedericFourmy @Kotochleb @TheoMF Are you happy with the current state?
If yes please approve the PR.