crocoddyl issueshttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues2019-06-19T16:03:53Zhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/171Euclidean state2019-06-19T16:03:53ZMaximilien NaveauEuclidean state```
Summary
Problem in the euclidean state returned values and memory management
Steps to reproduce
See unit test of the cpp test_state.cpp
What is the current bug behavior?
The Euclidean state Jdiff and Jintegrate allocate memory.
The Euclidean state Jdiff and Jintegrate have bugs in the results (depending on the computation of the first, second or both)
What is the expected correct behavior?
The Euclidean state Jdiff and Jintegrate must NOT allocate memory.
Possible fixes
Modify the method from this file:
[https://gepgitlab.laas.fr/loco-3d/crocoddyl/blob/cpp_devel/src/core/states/state-euclidean.cpp](https://gepgitlab.laas.fr/loco-3d/crocoddyl/blob/cpp_devel/src/core/states/state-euclidean.cpp)
```Maximilien NaveauMaximilien Naveauhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/170c++ unittest of action models2019-06-23T10:31:30ZCarlos Mastallic++ unittest of action modelsCrocoddyl c++ implementationMaximilien NaveauMaximilien Naveauhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/169Unittest of of action model bindings2019-06-19T08:24:09ZCarlos MastalliUnittest of of action model bindingsCrocoddyl c++ implementationCarlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/168Python bindings of action abstract, unicycle and LQR classes2019-06-19T08:23:33ZCarlos MastalliPython bindings of action abstract, unicycle and LQR classesCrocoddyl c++ implementationCarlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/167c++ implementation of ActionModelNumDiff2019-06-19T08:22:42ZCarlos Mastallic++ implementation of ActionModelNumDiffPlenty of unit-test code used this class, it's a top priority. I suggest to code it in the following files:
- /include/crocoddyl/core/numdiff/action.hpp
- /src/core/numdiff/action.cppCrocoddyl c++ implementationCarlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/166c++ implementation of StateNumDiff class2019-06-19T08:20:57ZCarlos Mastallic++ implementation of StateNumDiff classThis is important to finish all the unit-test code regarding the state. I suggest to write the code in:
- /include/crocoddyl/core/numdiff/state.hpp
- /src/core/numdiff/state.cppCrocoddyl c++ implementationBilal HammoudBilal Hammoudhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/165Improve display in gepetto-viewer and create function for recording videos2019-04-18T10:08:33ZCarlos MastalliImprove display in gepetto-viewer and create function for recording videosThere is a list of things that we should improve:
1. Changed background from blue to white.
2. Create a function that saves properly the frame and make a video. Using the record button in GV gui renders videos that aren't consistent with time.
3. `displayTrajectory` might be use a stack of robots. This will render multiple robots and trajectories.Future directionshttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/164Check that he upper-triangular from chol_factor by doing np.triu(scl.cho_fac...2019-04-18T07:32:16ZCarlos MastalliCheck that he upper-triangular from chol_factor by doing np.triu(scl.cho_factor(Quu)) is the same as chol_solversThe chol_solvers could take the alternative decompositionFuture directionshttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/163Rewrite the Q and V updates equation (in backward pass) in square-root form2019-04-16T16:56:24ZCarlos MastalliRewrite the Q and V updates equation (in backward pass) in square-root formFuture directionshttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/162Don't use bare `assert` in unittests2019-04-15T14:59:34ZGuilhem SaurelDon't use bare `assert` in unittestsAnd prefer the `unittest` module, because if not configured properly, the python interpreter might juste ignore those asserts when we run unittests.Guilhem SaurelGuilhem Saurelhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/161Making quadprog and multicontact-api as optional dependencies2019-04-05T06:54:09ZCarlos MastalliMaking quadprog and multicontact-api as optional dependenciesThis requires the following actions:
- Do not export some Python submodule (__init__.py) if there aren't installed these dependencies.
- Describe in the README file that they're optional dependencies.Guilhem SaurelGuilhem Saurelhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/159Ensuring properly the Vxx symmetric2019-04-18T07:32:15ZCarlos MastalliEnsuring properly the Vxx symmetricFor more details see https://gepgitlab.laas.fr/loco-3d/crocoddyl/merge_requests/153#note_4221Crocoddyl c++ implementationhttps://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.DocumentationNicolas MansardNicolas Mansardhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/157Add a Q&A section in the wiki2019-04-03T07:54:07ZCarlos MastalliAdd a Q&A section in the wikiGuys, let's write down a list of questions. This is an especial request for non-crocoddyl developers. Then crocoddyl developers will answer each questionDocumentationhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/150Created tailored data for each activation model2019-03-20T15:17:54ZCarlos MastalliCreated tailored data for each activation modelhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/142Asserting examples2019-04-18T07:39:14ZNicolas MansardAsserting examplesExamples (in example folder) comes with log files in examples/log. It would be nice to check that any new commit keep these log files invariant. As it is likely that such a test would be very sensible, it might be better to add such a validation in the CI as warning (non mandatory test). @gsaurel is offering to implement that.Future directionsGuilhem SaurelGuilhem Saurelhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/141Rendering Jupyter notebooks inside crocoddyl2019-03-15T19:28:18ZCarlos MastalliRendering Jupyter notebooks inside crocoddylIn the README file, I added links to the Jupyter Notebooks. I expected that users often click there to have a look on these notebooks. The main problem with this, it's LaTeX code isn't rendered.Future directionsGuilhem SaurelGuilhem Saurelhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/130create unit test for loading joint limits2019-03-06T16:36:25ZRohan Budhirajacreate unit test for loading joint limitsThis follows from the discussion on !124https://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?Future directionshttps://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/111Logging the full data2019-02-18T08:12:17ZRohan BudhirajaLogging the full dataCurrently we are only saving the data.cost inside the logger.
I don't see why we can't save directly the shooting.datas after the iteration.
This would be really helpful for debugging purposes.