Add a Q&A section in the wiki

[wxmerkt]

In GitLab by @cmastalli on Mar 29, 2019, 10:36

Guys, let's write down a list of questions. This is an especial request for non-crocoddyl developers. Then crocoddyl developers will answer each question

[wxmerkt]

In GitLab by @andreadelprete on Apr 2, 2019, 13:00

I report here all the questions that came up during an email exchange between me, @nmansard @cmastalli and @proyan

• Is the API compatible with the use of polynomials for the control trajectory? I think it’s important to have a very general API that won’t break backward compatibility when you’ll need to extend the library.
• If you decide to work with 3d forces then you could directly use the quadratic friction cones. If instead you wanna use 6d wrenches, then you need to linearize the friction cone constraints in order to project from 3d to 6d (or at least I have no idea how to do that projection with the quadratic cones). Both approaches have clearly pros and cons, so it’s a nontrivial choice. I think the key point here is to think of an API that is compatible with both options.
• What about soft contact models? Would the current API be compatible with those?
• What about handling different representations for the motion constraint and the associated contact forces (as in TSID)? That would allow for keeping the motion constraints 6d, even if we use a 12d vector for the contact forces.
• About the contact constraint API, is it compatible with line contacts, point contacts and surface contacts?
• I don’t like “shooting problem”, I suggest e.g. “optimal control problem” instead. Nicolas said that OCP is too generic as we only offer one particular class of OCP: shooting, so OCP is not an acceptable name. For Andrea “shooting” means “single shooting”, which is a transcription method, not a class of OCP. Probably Nicolas means something different with that.

[wxmerkt]

In GitLab by @cmastalli on Apr 2, 2019, 13:06

@andreadelprete thanks a lot for reporting this here. I was indeed tackling some of these points. You can see them here: https://gepgitlab.laas.fr/loco-3d/crocoddyl/wikis/Frequently-Asked-Questions

Some of your questions remain for me sort of raised points in this discussion. When they have been solved, I will add them inside FAQs section.

@nmansard you might want to reply Andreas' feedback here.

[wxmerkt]

In GitLab by @andreadelprete on Apr 2, 2019, 18:44

@nmansard answered to my questions by email, so I report his answers here.

• If we want to put 3d quadratic cones as a penalty, we need to find a penalty function that is negative when outside of the cone and positive inside, and ideally would have a kind of homogeneous increase when going deeper inside the cone. Any idea of such a function?

• What about soft contact models? Would the current API be compatible with those? Yes, but the part of the API dedicated to rigid contact would not be, you have to replace a bunch of code for that.

• What about handling different representations for the motion constraint and the associated contact forces (as in TSID)? That would allow for keeping the motion constraints 6d, even if we use a 12d vector for the contact forces. This would break the symmetry of the KKT matrix for the dynamics, and make it more difficult to solve the problem. We cannot do that.

• About the contact constraint API, is it compatible with line contacts, point contacts and surface contacts? Yes, but not implemented for line contacts. We could have rolling contact as well

• Just another note: I don’t like “shooting problem”. It could be MarkovOCP, but who would understand that?

[wxmerkt]

In GitLab by @andreadelprete on Apr 2, 2019, 18:59

• For the 3d quadratic cone, what about using the function measuring the distance to the cone boundaries? This is not exactly the distance function, but I guess it should work well anyway as it is the distance on the plane orthogonal to the normal direction: mu*fz - sqrt(fx^2 + fy^2)
• Breaking the symmetry of the KKT matrix seems bad at a first sight, but are you really sure it is? Is it better to invert a singular and bigger symmetric matrix, or a smaller and full-row rank rectangular matrix?
• Now that you said "MarkovOCP" I think I understand what you meant with "shooting": an OCP where all constraints are functions of only state and control at time t and state at time t+1 (as the dynamic constraints). Anyway I think that most OCP are MarkovOCP; the only constraint I can think of that violates this condition is a priority constraint in case of multi-task scenarios. Can you think of other cases of non-Markov OCP?

[wxmerkt]

In GitLab by @nmansard on Apr 3, 2019, 08:54

• Cone: for 3d cone, this is a good idea, let's try. Can you extend that to 6d cone for square-plannar contact?
• asymetry force/motion contact constraint: this surely requires additional work. @jcarpent already made a clean work for solving the KKT matrix (that we are still waiting to see released, btw :) ), that should be completely changed if we go for an asymmetrical model.
• OCP name. Manipulation problems (put a first cube on the table, and a second cube on top of it) would break the markov hypothesis. For locomotion, cyclic gait would break it as well (important for WAN). Additionally to this answer, I think we can use the current action-models for defining a collocation solver. But this cannot be done (or I dont see it) with the shooting-problem class. I this that the "problem" class that we introduced indeed is a transcription, or at least half of the transcription. Indeed, transforming the shooting-problem data into a plain NLP problem to be input in an off-the-shelf solver is a trivial task, which means that most of the transcription difficulty is done in the problem class, not in the solver class.