stack-of-tasks/pinocchio

A fast and flexible implementation of Rigid Body Dynamics algorithms and their analytical derivatives

Pinocchio instantiates the state-of-the-art Rigid Body Algorithms for poly-articulated systems based on revisited Roy Featherstone's algorithms. Besides, Pinocchio provides the analytical derivatives of the main Rigid-Body Algorithms like the Recursive Newton-Euler Algorithm or the Articulated-Body Algorithm.

Pinocchio was first tailored for robotics applications, but it can be used in other contexts (biomechanics, computer graphics, vision, etc.). It is built upon Eigen for linear algebra and FCL for collision detection. Pinocchio comes with a Python interface for fast code prototyping, directly accessible through Conda.

Pinocchio is now at the heart of various robotics software as Crocoddyl, an open-source and efficient Differential Dynamic Programming solver for robotics, the Stack-of-Tasks, an open-source and versatile hierarchical controller framework or the Humanoid Path Planner, open-source software for Motion and Manipulation Planning.

If you want to learn more about Pinocchio internal behaviors and main features, we invite you to read the related paper and the online documentation.

If you want to dive into Pinocchio directly, only one single line is sufficient (assuming you have Conda):

conda install pinocchio -c conda-forge

or via pip (currently only available on Linux):

pip install pin

Table of contents

• Pinocchio main features
• Documentation
• Examples
• Tutorials
• Performances
• Ongoing developments
• Visualization
• Citing Pinocchio
• Questions and Issues
• Credits
• Open-source projects relying on Pinocchio
• Acknowledgments

Pinocchio main features

Pinocchio is fast:

• C++ template library,
• cache friendly,
• automatic code generation support is available via CppADCodeGen.

Pinocchio is versatile, implementing basic and more advanced rigid body dynamics algorithms:

• forward kinematics and its analytical derivatives,
• forward/inverse dynamics and their analytical derivatives,
• centroidal dynamics and its analytical derivatives,
• support multiple precision arithmetic via Boost.Multiprecision or any similar framework,
• computations of kinematic and dynamic regressors for system identification and more,
• and much more with the support of modern and open-source Automatic Differentiation frameworks like CppAD or CasADi.

Pinocchio is flexible:

• header only,
• C++ 98/03/11/14/17/20 compliant.

Pinocchio is extensible. Pinocchio is multi-thread friendly. Pinocchio is reliable and extensively tested (unit-tests, simulations, and real-world robotics applications). Pinocchio is supported and tested on Windows, Mac OS X, Unix, and Linux (see build status here).

Documentation

The online Pinocchio documentation of the last release is available here. A cheat sheet pdf with the main functions and algorithms can be found here.

Examples

We provide some basic examples of using Pinocchio in Python in the examples directory. Additional examples introducing Pinocchio are also available in the documentation.

Tutorials

Pinocchio comes with a large bunch of tutorials aiming at introducing the basic tools for robot control. Tutorial and training documents are listed here. You can also consider the interactive Jupyter notebook set of tutorials developed by Nicolas Mansard and Yann de Mont-Marin.

Pinocchio continuous integrations

Pinocchio is constantly tested for several platforms and distributions, as reported below:

CI on ROS
CI on Linux via APT
CI on OSX via Conda
CI on Windows via Conda
CI on Linux via Robotpkg

Performances

Pinocchio exploits, at best, the sparsity induced by the kinematic tree of robotics systems. Thanks to modern programming language paradigms, Pinocchio can unroll most of the computations directly at compile time, allowing to achieve impressive performances for a large range of robots, as illustrated by the plot below, obtained on a standard laptop equipped with an Intel Core i7 CPU @ 2.4 GHz.

For other benchmarks, and mainly the capacity of Pinocchio to exploit, at best, your CPU capacities using advanced code generation techniques, we refer to the technical paper. In addition, the introspection may also help you to understand and compare the performances of the modern rigid body dynamics libraries.

Ongoing developments

If you want to follow the current developments, you can directly refer to the devel branch. The master branch only contains the latest release. Any new Pull Request should then be submitted on the devel branch.

Installation

Pinocchio can be easily installed on various Linux (Ubuntu, Fedora, etc.) and Unix distributions (Mac OS X, BSD, etc.). Please refer to the installation procedure.

If you only need the Python bindings of Pinocchio, you may prefer to install it through Conda. Please follow the procedure described here.

ROS

Pinocchio is also deployed on ROS. You may follow its deployment status below. If you're interested in using Pinocchio on systems and/or with packages that integrate with the ROS ecosystem, we recommend the installation of Pinocchio via the binaries distributed via the ROS PPA. Here, you can install Pinocchio using sudo apt install ros-$ROS_DISTRO-pinocchio. This installs Pinocchio with HPP-FCL support and with Python bindings. You can then depend on Pinocchio in your package.xml config (<depend>pinocchio</depend>) and include it via CMake (find_package(pinocchio REQUIRED)) -- we include support and hooks to discover the package for both ROS1 and ROS2. An example can be found here. Please note that we always advise including the pinocchio/fwd.hpp header as the first include to avoid compilation errors from differing Boost-variant sizes.

ROS1			ROS2
Melodic			Foxy
Noetic			Galactic
			Humble
			Rolling

Visualization

Pinocchio provides support for many open-source and free visualizers:

• Gepetto Viewer: a C++ viewer based on OpenSceneGraph with Python bindings and Blender export. See here for a C++ example on mixing Pinocchio and Gepetto Viewer.
• Meshcat: supporting visualization in Python and which can be embedded inside any browser.
• Panda3d: supporting visualization in Python and which can be embedded inside any browser.
• RViz: supporting visualization in Python and which can interact with other ROS packages.

Many external viewers can also be integrated. See the example here for more information.

Citing Pinocchio

To cite Pinocchio in your academic research, please use the following bibtex entry:

@inproceedings{carpentier2019pinocchio,
   title={The Pinocchio C++ library -- A fast and flexible implementation of rigid body dynamics algorithms and their analytical derivatives},
   author={Carpentier, Justin and Saurel, Guilhem and Buondonno, Gabriele and Mirabel, Joseph and Lamiraux, Florent and Stasse, Olivier and Mansard, Nicolas},
   booktitle={IEEE International Symposium on System Integrations (SII)},
   year={2019}
}

and the following one for the link to the GitHub codebase:

@misc{pinocchioweb,
   author = {Justin Carpentier and Florian Valenza and Nicolas Mansard and others},
   title = {Pinocchio: fast forward and inverse dynamics for poly-articulated systems},
   howpublished = {https://stack-of-tasks.github.io/pinocchio},
   year = {2015--2021}
}

The algorithms for the analytical derivatives of rigid-body dynamics algorithms are detailed here:

@inproceedings{carpentier2018analytical,
  title = {Analytical Derivatives of Rigid Body Dynamics Algorithms},
  author = {Carpentier, Justin and Mansard, Nicolas},
  booktitle = {Robotics: Science and Systems},
  year = {2018}
}

Questions and Issues

Do you have a question or an issue? You may either directly open a new question or a new issue or, directly contact us via the mailing list [email protected].

Credits

The following people have been involved in the development of Pinocchio and are warmly thanked for their contributions:

• Justin Carpentier (Inria): main developer and manager of the project
• Nicolas Mansard (LAAS-CNRS): initial project instructor
• Guilhem Saurel (LAAS-CNRS): continuous integration and deployment
• Joseph Mirabel (Eureka Robotics): Lie groups and hpp-fcl implementation
• Antonio El Khoury (Wandercraft): bug fixes
• Gabriele Buondono (LAAS-CNRS): features extension, bug fixes, and Python bindings
• Florian Valenza (Astek): core developments and hpp-fcl support
• Wolfgang Merkt (University of Oxford): ROS integration and support
• Rohan Budhiraja (LAAS-CNRS): features extension
• Loïc Estève (Inria): Conda integration and support
• Igor Kalevatykh (Inria): Panda3d viewer support
• Matthieu Vigne (Wandercraft): MeshCat viewer support
• Robin Strudel (Inria): features extension
• François Keith (CEA): Windows support
• Sarah El Kazdadi (Inria): multi-precision arithmetic support
• Nicolas Torres Alberto (Inria): features extension
• Etienne Arlaud (Inria): RViz viewer support
• Wilson Jallet (LAAS-CNRS/Inria): extension of Python bindings
• Fabian Schramm (Inria): core developper
• Shubham Singh (UT Austin): second-order inverse dynamics derivatives
• Stéphane Caron (Inria): core developper
• Joris Vaillant (Inria): core developer and manager of the project
• Sebastian Castro (PickNik Robotics): MeshCat viewer features extension

If you have participated in the development of Pinocchio, please add your name and contribution to this list.

Open-source projects relying on Pinocchio

• Crocoddyl A software to realize model predictive control for complex robotics platforms.
• TSID A software that implements a Task Space Inverse Dynamics QP.
• HPP A SDK that implements motion planners for humanoids and other robots.
• Jiminy A simulator based on Pinocchio.
• ocs2 A toolbox for Optimal Control for Switched Systems (OCS2)
• TriFingerSimulation TriFinger Robot Simulation (a Robot to perform RL on manipulation).
• Casadi_Kin_Dyn IIT Package for generation of symbolic (SX) expressions of robot kinematics and dynamics.

Acknowledgments

The development of Pinocchio is actively supported by the Gepetto team @LAAS-CNRS and the Willow team @INRIA.

pinocchio's Issues

Joint model lack of documentation

1D joints are simple to understand in terms of relationship between the degrees of freedom and the joint transform and velocity.

This is however not the case for more complex joints such as planar and freeflyer. For instance, a freeflyer transform can be computed such that the linear dof transform is applied before the rotation dof transform, or the opposite. According to Featherstone's Rigid Body Dynamics, Section 4.4, Example 4.5, the orders in which the transforms are applied can be decorrelated in the joint transform and velocity computations.

It would be thus nice to have a doxygen description of each model, without having to look in the code.

Documenting C++ Pinocchio

We need to start to a general framework to produce the documentation of Pinocchio. Two documentations would be useful: one for the C++ API; a second one for the Python interface.

I open the discussion here about the C++ documentation. The best candidate for documentation is Doxygen. Then main issue is to hide the CRTP complexity in the documentation. Right now, I consider that the Doxygen HTML is not usable by novice.

I take a look at Eigen documentation.
http://eigen.tuxfamily.org/dox/index.html
The documentation is organized by "modules". See for example the modules "QR", "LLT", etc for the dense solvers of Eigen:
http://eigen.tuxfamily.org/dox/group__DenseLinearSolvers__Reference.html

In addition, the modules are wrapped in a tutorial-style chapter organization. Finally, the class are listed (while hiding internal classes).

I like the organization by modules. We could have the following modules:

• spatial
• multibody model
• joints
• algorithms
• python interface ===> maybe not to document

I think that it would also be important to accurately select which C++ objects, types, classes and namespaces we want to expose to the documentation. If we reason module by module, it should be pretty evident to chose which to hide.

The bad point is that I do not understand (yet) how the documentation of Eigen is generated. They used advance doxygen features that I do not fully catch.

From the exposition in the doc of the main classes organized by modules, we can complete the doc with presentation pages, tutorials, etc.

Parse fixed joints from URDF

Some robot URDF files contain semantic information (wrist, ankle, sole, etc.) which is stored as a pair (fixed joint, empty link). For now, it seems such joints are not parsed in the robot structure, and thus cannot be used in control and/or planning.
Is there any computational limitation that would prevent storing the fixed joints, and computing their positions and jacobians whenever needed?

se3 <-> XYZQUAT conversion

The se3 <-> XYZQUAT conversion functions in src/python/utils.py seem to be bugged, but I'm not sure where.

If I run the following script in v1.0.0:

from pinocchio.utils import *

xyzquat = [0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]
print xyzquat
M = XYZQUATToSe3(xyzquat)
xyzquat_2 = se3ToXYZQUAT(M)
print xyzquat_2

I get:

[0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]
[0.0, 0.0, 1.0, 1.0, 0.0, 0.0, 0.0]

Handle several collision and visual objects when parsing URDF files

Momentum output

Hello all

Could you add functions returning angular and linear momentums to the present algorithms?

Python unittest on travis with hpp-fcl

When travis will run with hpp-fcl, do not forget to include bindings_frame and bindings_geometry_objects in python unittests.
Note to check that it does not raise exception when creating a robot ( relative paths of hint_directory and romeo model in concerned unittest)

Trying to install pinocchio in Ubuntu 14.04

There was no issues while installation (Using installation instruction given). When I try to open it via python in command prompt while trying out the initial examples I get the following error.

from pinocchio.utils import *
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named pinocchio.utils

I guess it is not able find the path. But my sys.path has following registered:

echo $PYTHONPATH
/home/ad/pinocchio/src/python:/usr/local/lib/python2.7/site-packages:/home/ad/pinocchio/install/lib64:/home/ad/pinocchio/install/lib/python2.7/site-packages

Could any body please tell me what I have done wrong?

URDF parser: Spatial inertia set to Identity for inertial-less URDF links

This is partally solved by #60, but the case (non-fixed joint, inertial-less link) still needs to be properly handled.

14.04 LTS breaking

The type CoeffBaseProduct is breaking in 14.04 LTS. This is specific to joint-spherical-ZYX and was introduced by commit dac4a60.
See for instance line 175
I do not advice to revert but instead to fix it asap.
I'll try to propose a patch in the next following days.

Documenting Python Pinocchio

Python objects are yet documented by using strings as arguments of boost::python calls. Indeed, the python code already contains a lot of document, available through help(object) in the python shell.

Next, we need to gather all this documentation into a nice interface. I think that Sphinx is the best tool to do that, but I am not sure. What do you think?

The best would be to keep all the doc at the same place, in the C++ python module. Sphinx should then automatically use boost::python to generate the html python doc.
I found that question, explaining (somehow) how to do it.
http://stackoverflow.com/questions/9375175/generate-a-boost-python-reference

Check if data is still valid regarding to model

Algorithms can crash if a model is modified after creation of data struct. Add a method to check if a data is still valid regarding to model.

Add integrate and differentiate methods in JointModel

Model joint limits

Currently, joint limits are implemented as an algorithm and we consider that joint limits may depend on the current configuration.
But this option is not satisfying.
One option is to put joint limit quantities in model and to read them when parsing.

What do you think?

Add path of meshes file in collision Object

Coverage - Needs of more unit tests

Dear all,
To have a better view of the code state so that we can improve the release process,
I made the link to coveralls. I apologize for the rough process.
According https://coveralls.io/builds/4952648 they are three files which are not tested at all:
joint_planar.hpp joint_dense.hpp constraint.hpp.
It would be nice to have unit test related to those files.

Set model root link

Currently, the model root link is the same as the one in the model tree in URDF or Lua.
In some applications, it can be useful to change the root link on-the-fly (e.g. from pelvis to left foot to right foot ...)

Does the current code structure allow developing an api for setting the root link?

Enforcement of One Definiton Rule

While trying to use the C++ API, I encoutered several build errors related to multiple definitions.
This happens mainly:

• in the operators of the joint classes. As pinocchio is header only, all templated functions must be inline to avoid multiple definitions. I can make a PR for that if you agree.
• in model.hpp, with the definition of static const member se3::model::gravity981 in the header file. One solution would be to move the definiton to a .cpp file, forcing the client code to link against libpinocchio. Another solution would be to remove the definition and force the client code to define it when needed, which is not very nice. Other propositions are more than welcome.

Update python viewer

Since we are now able to save the current visual info, we need to move forward by loading directly the visual geometries inside the gepetto viewer. And then, the URDF module inside the gepetto viewer will become deprecated.

RNEA with floating base and contact forces

Currently I can call se3::rnea(model, data, q,v,a) to compute the torques, but the external forces are not taken into account AFAIK.
If I want to run the RNEA for a floating base robot with external contact forces, is there currently a workaround, or do I have to implement a new function passing the forces as an argument?

Matlab interface

A Matlab interface similar to the Python interface could be useful to Matlab developers.
Potential users:

• Control engineers who develop controllers in Matlab
• Mechanical engineers who have a limited programming experience besides Matlab

CRBA produces wrong results

The joint-space inertia matrix computed using pinocchio.crba is inconsistent with pinocchio.rnea.
To check whether the Composite Rigid Body Algorithm produces the correct results one can leverage the Recursive Newton-Euler Algorithm to compute the joint-space inertia matrix column by column.

I created the following gist:

https://gist.github.com/martinfelis/ea8a9fc30d24d2968274

which computes the inertia matrix both using crba and multiple calls to rnea.

When calling with the simple_humanoid.urdf model I get the following output:

Model: simple_humanoid.urdf
--
Stats      |  #q | #qdot 
 Pinocchio |  29 |  29
--
Error M[0:6,0:6]
[[  7.85e-001  -1.94e-003  -1.67e-002   0.00e+000   0.00e+000   2.22e-016]
 [ -1.94e-003  -4.49e-001  -2.78e-017  -4.32e-002   8.88e-016   0.00e+000]
 [ -1.67e-002  -2.78e-017   0.00e+000   0.00e+000   1.15e-321   1.80e-016]
 [  0.00e+000  -4.32e-002   0.00e+000  -4.32e-002   8.88e-016   0.00e+000]
 [  0.00e+000   4.44e-016   1.15e-321   0.00e+000   8.88e-016   0.00e+000]
 [  0.00e+000   0.00e+000  -4.16e-017   0.00e+000   0.00e+000   0.00e+000]]
Error M[0:6,6:12]
[[ 0.  0.  0.  0.  0.  0.]
 [ 0.  0.  0.  0.  0.  0.]
 [ 0.  0.  0.  0.  0.  0.]
 [ 0.  0.  0.  0.  0.  0.]
 [ 0.  0.  0.  0.  0.  0.]
 [ 0.  0.  0.  0.  0.  0.]]

Note the errors in the first two diagonal elements with an order of magnitude of 10^-1. Possibly off-diagonal elements are okay.

However when running with the -f flag to use a free-flyer joint I get

Model: simple_humanoid.urdf
--
Stats      |  #q | #qdot 
 Pinocchio |  36 |  35
--
Error M[0:6,0:6]
[[  0.00e+00   0.00e+00   0.00e+00  -0.00e+00   1.24e-14  -0.00e+00]
 [  0.00e+00   0.00e+00   0.00e+00   1.78e-15  -0.00e+00  -1.42e-14]
 [  0.00e+00   0.00e+00  -1.71e-13   0.00e+00  -2.13e-13  -0.00e+00]
 [ -0.00e+00   1.78e-15   1.42e-14   3.83e+00  -1.39e-17  -3.22e-01]
 [ -5.33e-15  -0.00e+00  -1.07e-14  -3.57e-15  -3.83e+00  -7.33e-15]
 [ -3.55e-15   0.00e+00  -0.00e+00  -3.22e-01  -3.77e-15  -7.11e-15]]
Error M[0:6,6:12]
[[  0.00e+00   1.24e-14   6.38e-16   4.44e-15   2.50e-15   0.00e+00]
 [  0.00e+00   0.00e+00  -3.52e-15   0.00e+00   0.00e+00  -2.55e-15]
 [ -1.78e-13  -7.46e-14   0.00e+00  -7.46e-14  -7.46e-14   0.00e+00]
 [  7.85e-01  -1.94e-03  -1.67e-02  -5.58e-15  -5.58e-15  -3.33e-15]
 [ -1.73e-03  -4.49e-01  -2.69e-15  -4.32e-02  -4.88e-15   0.00e+00]
 [ -3.14e-02   9.40e-02   1.78e-15   1.22e-15   1.55e-15  -7.08e-16]]

Where also in the off-diagonal blocks are large errors.

setting joint limits

Hello all,
It is currently difficult to write to Joint limits. I suppose the only way available is if I change the Eigen::VectorXd elements available in Model class (lowerPositionLimit, upperPositionLimit ...), though it doesn't feel clean to do that

Is it possible to get a writable expression in these? Currently the visitor in joint-visitor.hpp returns only a readable value.

Thanks,
Rohan

Check jointDense for all the joints

Update EigenPy

Move some codes from Pinocchio to EigenPy (mostly eigen container part)

Add Python interpreter to load directly models from Python script

Parser urdf

In its current version, the urdf parser is not able to understand url starting by "package://"
Moreover, it seems that srdf files are not parsed.

Add unbounded revolute joint

Add unit tests on Planar Joint

Planar Joint is not tested at all and it will be mandatory for the integration of Pinocchio in HPP.
For kinematics checking, one idea is to create a serial chain with same one DOF joints than in the planar one.

For dynamics computation, we can check against RBDL.

Parse more info from SRDF

There are more information available in SRDF that are required by HPP and SoT:

• end effectors info
• default configuration

License

File LICENSE seems to indicate that the software is released under BSD license, whereas file COPYING.LESSER indicates LGPL-v3.

Choose root joint type

The URDF parser currently gives the user the choice of adding a free-flyer joint to the root link.
It would be interesting to allow adding other types of joints (prismatic, revolute, etc.)

missing joint limit parsing

I think we have to implement the join limit parsing in the URDF to integrate Pinocchio-dynamic in the SoT.
We could simply add an attribute list in the Model class for movable join only.

Release process

It has been some time since a new version pinocchio has been released. As a result most of us rely on the devel branch, where then API is broken from time to time (and this is normal on dev branch).

I don't know what the release planning is, but it would be nice to provide "stable" versions a bit more frequently, especially when new features are provided or API is broken.

Clean Model

Currently a model is build from concatenation of bodies that are linked one to each other by joints. We need to rethink this strategy by appending bodies to a joint tree.

This new factorisation should help the merge of two models for example, it should simplify the URDF parsers, etc.

Travis build "not passing" randomly

Since Pull Request on dynamic dense joints, travis has troubles to build AND check successfully.

In fact there are two major problems that occur alternatively:
1/ When compiling the unittest urdf, there is an error in the flags ( there is a "urdf_CFLAGS-NOTFOUND " instead of "-I/usr/include/eigen3 -I/opt/openrobots/include" in the travis log).
I do not understand where this comes from* given that:

• there are no changes in the travis build configuration
• there are (almost) no changes in the CmakeLists : just one file added at a certain commit
• urdfdom is found when generating the Makefile

2/ When error #1 does not occur, travis seem to "freeze" at the end of the build and then abort the procedure. The typical error message at the end of log is:
" No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.
The build has been terminated "
If you go on https://travis-ci.org/stack-of-tasks/pinocchio/jobs/83854014 , you will see that it occured after all the test passed.

Note that it can happens only on gcc build, or clang build, or both.

• I don't know why the flags are -NOTFOUND but i suppose it happens in the unittest/CMakeLists.txt at line 35
  GET_TARGET_PROPERTY(${target}_CFLAGS ${target} COMPILE_FLAGS)
  SET_PROPERTY(TARGET ${target} PROPERTY COMPILE_FLAGS "${${target}_CFLAGS} ${flag}")

Edit : When pushing to my own repository and running travis I have some "strange" behaviour. If you take a look at https://travis-ci.org/fvalenza/pinocchio/builds the build #7 and #9.
The number 7 passed and number 9 did not whereas the only difference between them is the synchronization of travis and cmake submodule as suggested by @olivier-stasse

[Python] Overwritting of robot.q0

I am testing python scripts (to record for a video) and I have a very weird behavior.
I don't remember having this problem before but even when i come back to v1.0.0, I have this same issue.
Is it happening just to me ? ( may be due to my computer) or are you able to reproduce this bug ?

import numpy as np
from pinocchio.romeo_wrapper import RomeoWrapper

robot = RomeoWrapper("/path/to/pinocchio/models/romeo.urdf")
print robot.q0

q=robot.q0
x_rw_des = 3
k = 0.05

for i in range(100):
    Mrw = robot.position(q,32)
    e = Mrw.translation.item(0) - x_rw_des
    J = Mrw.rotation * robot.Jrh(q)[:3,:]
    J = J[0,:]
    qdot = -J.T*e
    qdot = qdot*k
    robot.increment(q,qdot)

print robot.q0

with outputs:

[[ 0.         0.         0.840252   0.         0.         0.         1.         0.
   0.        -0.3490658  0.6981317 -0.3490658  0.         0.         0.
  -0.3490658  0.6981317 -0.3490658  0.         0.         1.5        0.6
  -0.5       -1.05      -0.4       -0.3       -0.2        0.         0.         0.
   0.         1.5       -0.6        0.5        1.05      -0.4       -0.3
  -0.2      ]]

[[ 2.53137626  0.01812421  0.84399951  0.00609353 -0.01829379  0.20671735
   0.97821069  0.          0.         -0.3490658   0.6981317  -0.3490658
   0.          0.          0.         -0.3490658   0.6981317  -0.3490658
   0.          0.41576846  1.5         0.6        -0.5        -1.05       -0.4
  -0.3        -0.2         0.          0.          0.          0.
   1.16517659 -0.97272307  0.72214912  0.79606203 -0.4        -0.3        -0.2       ]]

Eigenpy version mismatch

Pinocchio cannot be built with eigenpy 1.2.0 on the devel branch (tested on f2fdcdc). The minimal version must be set to 1.3.0.

Add Travis test case if HPP-FCL is not found.

Related to #73.

Floating joint in URDF file

Hi,
Why the urdf parser is not able to handle floating joint ?

They are inside the pinocchio package.
From http://wiki.ros.org/urdf/XML/joint it looks like this is still valid from the urdf specification viewpoint.

Is it because the case never occurred or is there a rational behind it ?

Best,
Olivier.

Export tags in github

Dear Florian,
It seems that you did not push the tags in github.
When I do

git tag

nothing appear in the fresh clone I pulled on my computer.
Could you fix the matter please ?
The drawback of this situation lies in the fact that the generated pinocchio.pc does
not include the version number and has UNKNOWN.
This is a bit problematic to test the version from another package.
Thanks a lot in advance for your help.

Best Regards,
Florent.

Robot Wrapper

Create a robot wrapper similar to the existing python class containing a model and several data store in a vector achieving the interface between (model,data) and the main algorithms.

@aelkhour Do you have some precise requests?

undefined reference to boost::system::system_category() when compiling

Dear all,
I had an issue with system_category() despite the fact that libboost_system was in the compiling option and was in the proper order.
It worked after specifying :
-DBOOST_SYSTEM_NO_DEPRECATED
in CMAKE_CXX_FLAGS

That was on 14.04.4 LTS 64 bits
Best,
Olivier.

Refactoring unit testing

Currently, the matrix comparisons in unit test are done with a specific function. This process does not allow to precisely locate where the unit test fail.

We need to refactor all the unit test similarly to 8deb921

Check Symmetric3 class

It seems that Eigen symmetric matrix offers computation times lesser than Symmetric3. A strong benchmark must be done to check this remark.

eigen compiltation issue

Hi,

I am trying to compile pinocchio, with eigen 3.2.0 (install from ubuntu packages) and I got
the following error :

/usr/local/include/eigen3/Eigen/src/Core/Matrix.h:243:33: error: no matching function for call to ‘Eigen::Matrix<double, 3, 3>::_init1(const se3::Symmetric3Tpl<double, 0>&)’
Base::template _init1(x);

and I got several candidates as presented in the attached file

make_log.txt

Maybe I need to install earlier version of Eigen ?

Can you help me ?

acces to optimized code

Hi,

I succeed to make the benchmark work.

Is it possible to have access to the optimized code that is generated by pinocchio
(not the generated library, but the c/c++ code that is generated) ?

I cannot find any *.c or *.cpp files that are generated.

Thanks

Use Eigen Ref for quaternions

According to http://eigen.tuxfamily.org/dox/classEigen_1_1Map_3_01Quaternion_3_01__Scalar_01_4_00_01__Options_01_4.html, it is possible to map directly quaternions from vectors or segments.

It must be worth to instantiate such mapping in joint Free Flyer and joint Spherical.

FCL - error

Dear all,
Pulling pinocchio from the repo master:master, I have an error with FCL when compiling:

include/pinocchio/multibody/geometry.hpp:144:36: error: no match for ‘operator==’ (operand types are ‘const fcl::CollisionResult’ and ‘const fcl::CollisionResult’) return (fcl_collision_result == other.fcl_collision_result

README.md does not specify which fcl version to take and the dependency.

Best,
Olivier.

Create a JointGeneric accessor

Create a struct containing a joint variant and expose joint visitor.