crocoddyl issueshttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues2019-04-03T07:57:34Zhttps://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