crocoddyl issueshttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues2019-11-22T17:36:52Zhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/290Sharing data for force-based cost functions2019-11-22T17:36:52ZCarlos MastalliSharing data for force-based cost functionsCrocoddyl c++ implementationCarlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/289Handling systems with root joints as S03 or Euclidean groups (StateMultibody)2019-11-13T18:20:54ZCarlos MastalliHandling systems with root joints as S03 or Euclidean groups (StateMultibody)Crocoddyl c++ implementationCarlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/288Review solver unittest and add missing points2019-11-22T17:36:34ZCarlos MastalliReview solver unittest and add missing pointsHi @mnaveau,
I have included the DDP and FDDP unittest in this PR !224.
However, I didn't check that everything is there. Could you review it and add the missing points?
You might want to create factory for solvers and shooting problem...Hi @mnaveau,
I have included the DDP and FDDP unittest in this PR !224.
However, I didn't check that everything is there. Could you review it and add the missing points?
You might want to create factory for solvers and shooting problems too. Indeed, it would be great if you can handle it too.
And last thing, could you fix some segfaults in some jobs?. For more info see: https://gepgitlab.laas.fr/mnaveau/crocoddyl/pipelines/6784Crocoddyl c++ implementationMaximilien NaveauMaximilien Naveauhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/287Extend function to display contact forces in GV2019-11-22T17:36:25ZCarlos MastalliExtend function to display contact forces in GVCarlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/286Currently pinocchio::impulseDynamics allocates internally memory, do not use ...2019-11-22T17:35:59ZCarlos MastalliCurrently pinocchio::impulseDynamics allocates internally memory, do not use it for multithreadingI have been working on #271, and I noticed that part of the non-deterministic behavior of the solver is that `pinoccho::impulseDynamics` allocates internally memory, and I reported it few weeks ago: https://github.com/stack-of-tasks/pino...I have been working on #271, and I noticed that part of the non-deterministic behavior of the solver is that `pinoccho::impulseDynamics` allocates internally memory, and I reported it few weeks ago: https://github.com/stack-of-tasks/pinocchio/issues/881.
@wxmerkt and @proyan be aware of it, and do not waste your time.
For more elaborate discussion, I suggest to use the Pinocchio issue.Crocoddyl c++ implementationhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/285Added EIGEN_MAKE_ALIGNED_OPERATOR_NEW to all model classes2019-11-09T15:25:25ZCarlos MastalliAdded EIGEN_MAKE_ALIGNED_OPERATOR_NEW to all model classesCrocoddyl c++ implementationCarlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/284Added the heightmap and its cost model (Python)2019-11-22T17:35:54ZCarlos MastalliAdded the heightmap and its cost model (Python)@mfocchi - @gfadini is handling this task. It will start from this work !230 @mfocchi - @gfadini is handling this task. It will start from this work !230 Crocoddyl c++ implementationGabriele FadiniGabriele Fadinihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/283Integrating actuation model in free-forward dynamics2019-11-13T18:20:51ZCarlos MastalliIntegrating actuation model in free-forward dynamicsCrocoddyl c++ implementationPep Marti SaumellPep Marti Saumellhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/282[Numdiff bindings] std::vector of datas needs to be exposed in python2019-11-08T00:57:59ZRohan Budhiraja[Numdiff bindings] std::vector of datas needs to be exposed in pythonCurrently, the bindings for numdiff/diff-action do not contain an exposure for std::vector<DiffActionData>.
Thus, when I try to access DiffActionNumdiffData.data_x, which is a vector of datas, I get the following error:
```
In [3]: dnum....Currently, the bindings for numdiff/diff-action do not contain an exposure for std::vector<DiffActionData>.
Thus, when I try to access DiffActionNumdiffData.data_x, which is a vector of datas, I get the following error:
```
In [3]: dnum.data_x
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-3-9ebbe2eabe85> in <module>()
----> 1 dnum.data_x
TypeError: No to_python (by-value) converter found for C++ type: std::vector<boost::shared_ptr<crocoddyl::DifferentialActionDataAbstract>, std::allocator<boost::shared_ptr<crocoddyl::DifferentialActionDataAbstract> > >
```Carlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/281Fix bindings for contact-6d2019-11-07T20:04:42ZRohan BudhirajaFix bindings for contact-6dCurrently I receive following as the docstring of ContactModel6d in python
```
In [1]: from crocoddyl import ContactModel6D
In [2]: ContactModel6D?
Docstring:
Rigid 6D contact model.
It defines a rigid 6D contact models based on ...Currently I receive following as the docstring of ContactModel6d in python
```
In [1]: from crocoddyl import ContactModel6D
In [2]: ContactModel6D?
Docstring:
Rigid 6D contact model.
It defines a rigid 6D contact models based on acceleration-based holonomic constraints.
The calc and calcDiff functions compute the contact Jacobian and drift (holonomic constraint) or
the derivatives of the holonomic constraint, respectively.
Init docstring:
__init__( (object) self, (StateMultibody) state, (FramePlacement) Mref, (int) nu=state.nv [, (object) gains=np.matrix([ [0.],[0.] ]]) -> None :
Initialize the contact model.
:param state: state of the multibody system
:param Mref: reference frame placement
:param nu: dimension of control vector
:param gains: gains of the contact model
C++ signature :
void __init__(_object*,boost::shared_ptr<crocoddyl::StateMultibody>,crocoddyl::FramePlacement,int [,Eigen::Matrix<double, 2, 1, 0, 2, 1>])
__init__( (object)arg1, (StateMultibody) self, (FramePlacement) state [, (object) Mref]) -> None :
Initialize the state cost model.
:param state: state of the multibody system
:param Mref: reference frame placement
:param nu = dimension of control vector
C++ signature :
void __init__(_object*,boost::shared_ptr<crocoddyl::StateMultibody>,crocoddyl::FramePlacement [,Eigen::Matrix<double, 2, 1, 0, 2, 1>])
```
If you see:
1) The second init mentions state cost model.
2) The argument list for the second init model is (StateMultibody) self, (FramePlacement) state [, (object) Mref]). This is not right.DocumentationCarlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/280Impulse cost com2019-11-22T17:36:16ZRohan BudhirajaImpulse cost comcreate a impact com costcreate a impact com costCrocoddyl c++ implementationhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/279Cost Model Momentum2019-11-15T15:13:58ZRohan BudhirajaCost Model MomentumCreate a cost which tracks the centroidal momentumCreate a cost which tracks the centroidal momentumCrocoddyl c++ implementationRohan BudhirajaRohan Budhirajahttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/278Standardize cost references2019-11-22T17:35:37ZRohan BudhirajaStandardize cost referencesStandardize the naming and type for cost.ref elements to: ref, Eigen::Vector.
Currently, the names and types are different based on different classes.Standardize the naming and type for cost.ref elements to: ref, Eigen::Vector.
Currently, the names and types are different based on different classes.Crocoddyl c++ implementationhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/277Replace asssert with if + throw exception2019-11-22T17:35:33ZWolfgang MerktReplace asssert with if + throw exceptionAs in Pinocchio - function argument and sanity checks should not be `assert`.As in Pinocchio - function argument and sanity checks should not be `assert`.Crocoddyl c++ implementationhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/276Moving to GitHub (prior to Nov 12th)2019-11-22T17:36:48ZWolfgang MerktMoving to GitHub (prior to Nov 12th)As per the last meeting, we have decided to move the main development to GitHub prior to **November 12th**. This is in line with the agreement at the March Paris meeting. All development going forward will be on GitHub, with a mirror to ...As per the last meeting, we have decided to move the main development to GitHub prior to **November 12th**. This is in line with the agreement at the March Paris meeting. All development going forward will be on GitHub, with a mirror to this repository on Gepgitlab.
Here are the steps that are required:
**Critical:**
1. Move issues, wiki, etc.: There is an automated tool here: https://github.com/piceaTech/node-gitlab-2-github
2. Set up webhook from GitHub to Gitlab CI: Step by step here: https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html [this is for Gitlab.com not self-hosted but should be similar; Pinocchio has it set up]
3. Flip mirror from Gepgitlab->GitHub to GitHub->Gepgitlab
4. Mirror all open PRs over to GitHub and reopen
**Nice to have later on:**
1. Additional GitHub Actions / Travis CI
Is there any other step I forgot?
@gsaurel Can you do (2) and (3) since none of us have the permissions?
I am happy to pick up (1) and (4), but also happy for you to jump in if you have bandwidth.Documentationhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/275MemoryError when calling calcDiff on CostModel2019-10-23T21:16:59ZWolfgang MerktMemoryError when calling calcDiff on CostModelI am developing and debugging cost models right now. I noticed that the memory for an object retrieved from Pinocchio is broken (Jcom, the number of columns equal "overflow" so it runs out of memory).
I may have a mistake in how I am co...I am developing and debugging cost models right now. I noticed that the memory for an object retrieved from Pinocchio is broken (Jcom, the number of columns equal "overflow" so it runs out of memory).
I may have a mistake in how I am compiling the script - can you please have a look to check?
This is the script I am using to reproduce on the latest devel with the latest devel of eigenpy and pinocchio:
```python
from __future__ import print_function
import numpy as np
import eigenpy
eigenpy.switchToNumpyMatrix()
import crocoddyl
import pinocchio
# print(pinocchio.__file__)
import example_robot_data
robot = example_robot_data.loadANYmal()
robot_model = robot.model
pinocchio_data = robot_model.createData()
state = crocoddyl.StateMultibody(robot_model)
actuation = crocoddyl.ActuationModelFloatingBase(state)
com_position = crocoddyl.CostModelCoMPosition(state, np.matrix([0.,0.,0.5]).T)
com_position_data = com_position.createData(pinocchio_data)
q0 = robot_model.referenceConfigurations['half_sitting']
v0 = np.asmatrix([0.] * robot_model.nv).T
x0 = np.concatenate([q0, v0])
pinocchio.forwardKinematics(robot_model, com_position_data.pinocchio, q0)
com = pinocchio.centerOfMass(robot_model, com_position_data.pinocchio, q0)
Jcom = pinocchio.jacobianCenterOfMass(robot_model, com_position_data.pinocchio, q0)
com_position.calc(com_position_data, x0)
print("calc done")
com_position.calcDiff(com_position_data, x0, np.asmatrix([0.] * robot_model.nv).T) # <-- MemoryError here
print("calcDiff done")
```
Inspecting the dimensions of `pinocchio->Jcom` inside the cost model shows `3 x (super huge number that is overflowing unsigned int)`.https://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/274Generate and install CMake config2019-11-22T17:35:29ZWolfgang MerktGenerate and install CMake configAnalot to https://github.com/stack-of-tasks/eigenpy/issues/98, https://github.com/stack-of-tasks/pinocchio/issues/914Analot to https://github.com/stack-of-tasks/eigenpy/issues/98, https://github.com/stack-of-tasks/pinocchio/issues/914Crocoddyl c++ implementationhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/273Add proper virtual keyword2019-11-22T17:35:24ZWolfgang MerktAdd proper virtual keywordCurrently, the implementations of (pure) virtual functions do not carry the `virtual` keyword. This is prone to introduce bugs and also requires copy-paste/duplication in the bindings. We should add the `virtual` (C++98) or `override/fin...Currently, the implementations of (pure) virtual functions do not carry the `virtual` keyword. This is prone to introduce bugs and also requires copy-paste/duplication in the bindings. We should add the `virtual` (C++98) or `override/final` (C++11, once switch confirmed) keywords.Crocoddyl c++ implementationhttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/272CostModelForce2019-11-13T18:20:43ZRohan BudhirajaCostModelForceImplement in c++Implement in c++Crocoddyl c++ implementationCarlos MastalliCarlos Mastallihttps://gepgitlab.laas.fr/loco-3d/crocoddyl/-/issues/271Multithreading in Python doesn't work (GIL)2019-11-09T14:59:15ZCarlos MastalliMultithreading in Python doesn't work (GIL)This issue was reported in #254. @proyan fixed an issue in the implementation of the `StateMultibody` class. It used to contain internal data that was producing errors in a multi-threads setup. This issue is solved here: !248.
However, ...This issue was reported in #254. @proyan fixed an issue in the implementation of the `StateMultibody` class. It used to contain internal data that was producing errors in a multi-threads setup. This issue is solved here: !248.
However, we still have problems when we run multi-threads in Python interpreter, i.e. GIL (https://gepgitlab.laas.fr/loco-3d/crocoddyl/issues/256#note_6760).
I created another issue to decoupled both problems from #254.Carlos MastalliCarlos Mastalli