stack-of-tasks/sot-dynamic

jrl-dynamics bindings for dynamic-graph

sot-dynamic

This software provides robot dynamic computation for dynamic-graph by using jrl-dynamics.

Setup

To compile this package, it is recommended to create a separate build directory:

mkdir _build
cd _build
cmake [OPTIONS] ..
make install

Please note that CMake produces a CMakeCache.txt file which should be deleted to reconfigure a package from scratch.

Dependencies

The matrix abstract layer depends on several packages which have to be available on your machine.

• Libraries:
  • jrl-dynamics (>= 1.16.1)
  • dynamic-graph (>= 1.0.0)
  • sot-core (>= 1.0.0)
  • jrl-mal (>= 1.8.0)
• Closed source libraries:
  • hrp2Dynamics (>= 1.3.0)
  • hrp2-10-optimized (>= 1.3.0) [optional]
• System tools:
  • CMake (>=2.6)
  • pkg-config
  • usual compilation tools (GCC/G++, make, etc.)

sot-dynamic's Issues

leftHand / rightHand frames and grippers

Hello

I have a question regarding the additional frames created in the method initializeRobot (in humanoid_robots.py)
https://github.com/stack-of-tasks/sot-dynamic/blob/master/src/dynamic_graph/sot/dynamics/humanoid_robot.py#L298-L313
The two frames created, leftHand and rightHand, correspond to the "geometric parameters of hand"
For the robot hrp2, these frames are the same than the r_gripper and l_gripper frames in the urdf files.
(cf http://www.ros.org/reps/rep-0120.html#l-gripper-and-r-gripper)
Is this a coincidence or are those two frames (LeftHand / l_gripper) identical?

Is it possible to replace (or create an alias in the latter case) the frames "Left/Right Hand" by the frames "Left/RightGripper" (in order to be closer to the REP120 specifications)?

Crash of python when exiting the interface ("python: double free or corruption")

Hello all,

Since the merge #4, there is a problem at the destruction of the python interface used to interact with the SoT in some cases.

To reproduce the error, create the file test.py with the following content:

from dynamic_graph.sot.core.matrix_util import matrixToTuple
from dynamic_graph.sot.dynamics.angle_estimator  import AngleEstimator

Running python ./test.py
Returns the following error:

*** glibc detected *** python: double free or corruption (fasttop): 0x00000000028b5870 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f964559db96]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNSsD1Ev+0x1f)[0x7f96433f751f]
/lib/x86_64-linux-gnu/libc.so.6(+0x3b901)[0x7f964555a901]
/lib/x86_64-linux-gnu/libc.so.6(+0x3b985)[0x7f964555a985]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf4)[0x7f9645540774]
python[0x41bb31]
======= Memory map: ========
00400000-00670000 r-xp 00000000 08:06 4066903                            /usr/bin/python2.7
00870000-00871000 r--p 00270000 08:06 4066903                            /usr/bin/python2.7
00871000-008da000 rw-p 00271000 08:06 4066903                            /usr/bin/python2.7
008da000-008ec000 rw-p 00000000 00:00 0 
00951000-0100d000 rw-p 00000000 00:00 0                                  [heap]
...
(then there is the list of loaded libraries.)

This crash occurs because the library libsot-dynamic.so is loaded after the library libsot-core.so.
At the opposite, the following code will properly exit:

from dynamic_graph.sot.dynamics.angle_estimator  import AngleEstimator
from dynamic_graph.sot.core.matrix_util import matrixToTuple

Note that this is only due to the fact that in dynamic_graph/sot/dynamics/__init__.py, the Dynamic entity is the first one loaded. With this

from angle_estimator import AngleEstimator
from dynamic import Dynamic

the test would also crash.

Is there a way to correct this?
For now, I have to use a workaround that consists in systematically importing

from dynamic_graph.sot.dynamics.dynamic import Dynamic

first, so as to avoid this issue.

dynamicDrift computation -> seg fault

I do not manage to understand why this code results in segmentation fault

from dynamic_graph.sot.hrp2_14 import robot
r = robot.Robot("hrp2");
r.dynamic.dynamicDrift.recompute(1);

Is there something wrong I am doing?

Pre-defined name of the operational points.

Hello all,

In the script humanoid.py, some operational points are predefined

    OperationalPoints = ['left-wrist', 'right-wrist',
                         'left-ankle', 'right-ankle',
                         'gaze']

Using dashes in the name of the signals prevents calling them directly in python:

robot.dynamics.left-wrist

will return an error, rather than display the value of the homogeneous matrix.
I regret the loss of this functionality. Wouldn't it be better to use underscores instead?

Regards

François

Add missing dependency toward numpy

The Python scripts required python-numpy to be installed on the system.
We should enforce this through CMake.