crocoddyl issueshttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues2019-09-24T15:27:21Zhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/252Numerical quasi-static torque computation doesn't convergence when we regular...2019-09-24T15:27:21ZCarlos MastalliNumerical quasi-static torque computation doesn't convergence when we regulariza Cholesky decomposition in contact dynamicsThe contact dynamics is solved using Cholesky decomposition as explained in the following [PDF](https://cmastalli.github.io/publications/crocoddyl20unpub.pdf), and details of the code can be seen here: https://gepgitlab.laas.fr/loco-3d/crocoddyl/blob/master/src/multibody/actions/contact-fwddyn.cpp#L64.
The quasi-static torques are computed through a numerical optimization using Newton step, details of the algorithm are here:
https://gepgitlab.laas.fr/loco-3d/crocoddyl/blob/master/src/core/action-base.cpp#L30
The problem arises when I used a damping factor in the Cholesky decomposition performed by the forward dynamics. In this case, the algorithm for quasi-static torque computation doesn't convergence.
@nmansard and @jcarpent do you have any clue about this issue?The contact dynamics is solved using Cholesky decomposition as explained in the following [PDF](https://cmastalli.github.io/publications/crocoddyl20unpub.pdf), and details of the code can be seen here: https://gepgitlab.laas.fr/loco-3d/crocoddyl/blob/master/src/multibody/actions/contact-fwddyn.cpp#L64.
The quasi-static torques are computed through a numerical optimization using Newton step, details of the algorithm are here:
https://gepgitlab.laas.fr/loco-3d/crocoddyl/blob/master/src/core/action-base.cpp#L30
The problem arises when I used a damping factor in the Cholesky decomposition performed by the forward dynamics. In this case, the algorithm for quasi-static torque computation doesn't convergence.
@nmansard and @jcarpent do you have any clue about this issue?Crocoddyl c++ implementationhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/197Python bindings with Eigen::Ref2019-07-26T12:33:52ZCarlos MastalliPython bindings with Eigen::RefI have created extra code inside the c++ abstract classes in order to overload the `Eigen::Ref` functions. The main reason is that Crocoddyl needs to deal with pointers of this classes, e.g.
1. `ShootingProblem` with action models and datas.
2. `ActionModelAbstract` with states.
3. `IntegratedActionModelEuler` with action models, etc.
And with a wrapper class (or `eigen::ref`) in boost python is not possible to retrieve these pointers, e.g.
1. `runningModels`, `terminalModel`, `runningDatas` and `terminalData` from shooting problem.
2. `State` from action models.
3. `differential` from Euler integrator, etc.
I agree with @jcarpent (https://gepgitlab.laas.fr/loco-3d/crocoddyl/commit/fc5a6e740b25f912d16b9af38375430bb583988a#note_5552) that this is not a very elegant solution. However EigenPy is not compatible with `Eigen::Ref`.
The solution will be delivered whenever Eigen::Ref feature of EigenPy are available in robotpkg.
I have created extra code inside the c++ abstract classes in order to overload the `Eigen::Ref` functions. The main reason is that Crocoddyl needs to deal with pointers of this classes, e.g.
1. `ShootingProblem` with action models and datas.
2. `ActionModelAbstract` with states.
3. `IntegratedActionModelEuler` with action models, etc.
And with a wrapper class (or `eigen::ref`) in boost python is not possible to retrieve these pointers, e.g.
1. `runningModels`, `terminalModel`, `runningDatas` and `terminalData` from shooting problem.
2. `State` from action models.
3. `differential` from Euler integrator, etc.
I agree with @jcarpent (https://gepgitlab.laas.fr/loco-3d/crocoddyl/commit/fc5a6e740b25f912d16b9af38375430bb583988a#note_5552) that this is not a very elegant solution. However EigenPy is not compatible with `Eigen::Ref`.
The solution will be delivered whenever Eigen::Ref feature of EigenPy are available in robotpkg.
Crocoddyl c++ implementationCarlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/158Defining a structure for the wiki2019-04-03T07:57:34ZCarlos MastalliDefining a structure for the wikiI have added few files that define a tentative structure for the wiki. Please see them here:
https://gepgitlab.laas.fr/loco-3d/crocoddyl/wikis/home
The structure has the form:
```
Home
Developer Guide
Frequently Asked Questions
Action/
Floating in Contact Systems
Unconstrained Forward Dynamics
Cost/
CoM Cost
Force based Cost
Frame base Cost
State and Control Cost
```
Most of these files are empty, with the exception of `Home` and `Floating in Contact Systems`. @nmansard have a look and let's decide about this structure.I have added few files that define a tentative structure for the wiki. Please see them here:
https://gepgitlab.laas.fr/loco-3d/crocoddyl/wikis/home
The structure has the form:
```
Home
Developer Guide
Frequently Asked Questions
Action/
Floating in Contact Systems
Unconstrained Forward Dynamics
Cost/
CoM Cost
Force based Cost
Frame base Cost
State and Control Cost
```
Most of these files are empty, with the exception of `Home` and `Floating in Contact Systems`. @nmansard have a look and let's decide about this structure.DocumentationNicolas MansardNicolas Mansardhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/114Single shooting limitations2019-02-28T15:25:24ZCarlos MastalliSingle shooting limitationsI have been playing significantly with the bipedal and walking examples. For these examples, I just defined a foot desired tracking along with hight penalization in the impact velocities and positions. Furthermore there isn't smart warm point here.
I encountered that our DDP solver is able to solve a solution for a limited number of contact phases: around 5 phases and 3 phases for the biped and quadruped, respectively. I heart similar issues from @nmansard about the Jumping task, I believe the reason of this issue is the single shooting formulation. Lets me explain here:
First I want to introduce the integrator function:
$`\mathbf{x}(t)=\mathbf{F}(\mathbf{u}_0,\cdots,\mathbf{u}_{N-1},\mathbf{x}_0,t)`$ and this function can be also described as $`\mathbf{x}(t)=\mathbf{f}(\cdots\mathbf{f}(\mathbf{f}(\mathbf{f}(\mathbf{x}_0,\mathbf{u}_0),\mathbf{u}_1),\mathbf{u}_2)\cdots, \mathbf{u}_{N-1})=\mathbf{F}(\mathbf{u}_0,\cdots,\mathbf{u}_{N-1},\mathbf{x}_0)`$.
One might notice that the non-linearity of $`\mathbf{F}()`$ depends on the $`N`$ recursive calls of $`\mathbf{f}()`$. Indeed, this non-linearities tends to be worse as $`N`$ is increases. For the OC solver this means that it's harder to figure out initial control action that properly affects the final states of your problem. This is exactly what it's happening in the above examples. Of course, the DDP uses feedback gains that makes the problem easier that typical transcription-based OC.
In the literature this problems is well known, and the main motivation for multiple-shooting solvers. I really believe we are facing this limitations and I sustain that we need to work on it. I have mature an idea that I would like to develop asap.
Furthermore, I support the idea of defining shoots in the contact transitions. This will removes soft-cost functions, they will be defined as terminal constraints (which helps our solver to link with the another shoot). Having shoots in these contact transition allows us also to properly warm-start it. And finally but not least, we could parallelize each shoot computation.
@nmansard is this makes sense to you? If so, when do you think I could use my time for such task? or do we want to do it for v1.0.0?I have been playing significantly with the bipedal and walking examples. For these examples, I just defined a foot desired tracking along with hight penalization in the impact velocities and positions. Furthermore there isn't smart warm point here.
I encountered that our DDP solver is able to solve a solution for a limited number of contact phases: around 5 phases and 3 phases for the biped and quadruped, respectively. I heart similar issues from @nmansard about the Jumping task, I believe the reason of this issue is the single shooting formulation. Lets me explain here:
First I want to introduce the integrator function:
$`\mathbf{x}(t)=\mathbf{F}(\mathbf{u}_0,\cdots,\mathbf{u}_{N-1},\mathbf{x}_0,t)`$ and this function can be also described as $`\mathbf{x}(t)=\mathbf{f}(\cdots\mathbf{f}(\mathbf{f}(\mathbf{f}(\mathbf{x}_0,\mathbf{u}_0),\mathbf{u}_1),\mathbf{u}_2)\cdots, \mathbf{u}_{N-1})=\mathbf{F}(\mathbf{u}_0,\cdots,\mathbf{u}_{N-1},\mathbf{x}_0)`$.
One might notice that the non-linearity of $`\mathbf{F}()`$ depends on the $`N`$ recursive calls of $`\mathbf{f}()`$. Indeed, this non-linearities tends to be worse as $`N`$ is increases. For the OC solver this means that it's harder to figure out initial control action that properly affects the final states of your problem. This is exactly what it's happening in the above examples. Of course, the DDP uses feedback gains that makes the problem easier that typical transcription-based OC.
In the literature this problems is well known, and the main motivation for multiple-shooting solvers. I really believe we are facing this limitations and I sustain that we need to work on it. I have mature an idea that I would like to develop asap.
Furthermore, I support the idea of defining shoots in the contact transitions. This will removes soft-cost functions, they will be defined as terminal constraints (which helps our solver to link with the another shoot). Having shoots in these contact transition allows us also to properly warm-start it. And finally but not least, we could parallelize each shoot computation.
@nmansard is this makes sense to you? If so, when do you think I could use my time for such task? or do we want to do it for v1.0.0?Future directions