Doxygen documentation used to be produced by the codyco-superbuild doxygen, but for some reason it is not working anymore.

Currently urdf2dh couples of iCub frames. A comprensive test reported the following results:

urdf2dh report: 
total frame couples tested : 2756
total frame couples failed : 1260
total frame couples success : 1496

Just tried compiling the head of iDynTree and I get the following error:

-- Build files have been written to: /home/ryan/Code/iCub_Software/codyco-superbuild/build/libraries/iDynTree
[ 43%] Performing build step for 'iDynTree'
[ 27%] Built target idyntree-core-exp
[ 60%] Built target idyntree-core
[ 62%] Built target idyntree-sensors
[ 66%] Built target idyntree-modelio-urdf
[ 71%] Built target expression-parser
[ 73%] Built target idyntree-modelio-symoro
[ 75%] Built target idyntree-modelio-ikin
[ 90%] Built target idyntree-regressors
[ 97%] Built target idyntree-yarp
Linking CXX executable par2urdf
../sensors/libidyntree-sensors.so: undefined reference to `iDynTree::SpatialForceVectorRaw::operator-() const'
collect2: ld returned 1 exit status
make[5]: *** [tools/par2urdf] Error 1
make[4]: *** [tools/CMakeFiles/par2urdf.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [libraries/iDynTree/CMakeFiles/YCMStamp/iDynTree-build] Error 2
make[1]: *** [CMakeFiles/iDynTree.dir/all] Error 2
make: *** [all] Error 2
ryan@ISIR2014057:~/Code/iCub_Software/codyco-superbuild/build$ 

Apparently, SWIG is not really static linking friendly.. thus even on Windows we should properly export DLL.

However in a lot of methods (for example in the API describing an instance of a sensor) we want to expose a function that returns (in a clearly not-real time safe fashion, unless you use a O(1) allocator) a string, as in

std::string getName();

The problem is that apparently [1] returning std containers in DLL is not supported. You should then find an alternative solution.

Solution 1: Use C-style interfaces

A possible C-Style interface is

void getName(char * name)

or

char * getName();

I would avoid using this solution, because it would be really cumbersome and error prone for the C++ user (and for SWIG bindings) to manually deal with char array buffers.

Solution 2: Wrap std::string as YARP does

It is not really clear to me, but I guess that having a class similar to yarp::os::ConstString should solve this problem. This would probably cost some performance overhead when dealing with strings, but given that in performance-intensive loops you should not deal with strings anyway, I guess it is acceptable.

Solution 3: Always build as static on Windows

I really did not understand what are the problems of SWIG with static compilation. Perhaps is just a "global" variables issue and we can ignore them. (CASADI, that has a really used Python SWIG interface, does just that [2]).

[1] : http://stackoverflow.com/questions/3564985/returning-stdstring-stdlist-from-dll
[2] : https://github.com/casadi/casadi/blob/master/CMakeLists.txt#L87

As part of the estimation roadmap, we need to create an library in iDynTree related to Estimation, to collect all estimation algorithms implemented using iDynTree .

This can be created in a estimation directory, and we can copy the CMake structure from another recent component, such as high-level.

Code that I think should be moved or implemented in iDynTree_Estimation includes:

• The simpleLeggedOdometry class , that should be ported to avoid the dependency on YARP, for example using the DynamicsComputations class.
• The TorqueEstimationTree class that should be again ported to avoid the dependency on YARP. In this case it involves more work because we need to create an iDynTree-compatible data structure to store the informations classically contained in a dynContactList.
• The new class that wiil be implemented by @nunoguedelha to compute the quantities required in the Berdy algorithm. For this class we will probably need to expose in the headers classes of type Eigen::SparseMatrix.

While compiling iDynTree with the codyco-superbuild I am getting the following error:

6>C:\Users\Bastien\Documents\GitHub\codyco-superbuild\build\install\include\urdf_model/pose.h(52): fatal error C1083: Cannot open include file: 'boost/algorithm/string.hpp': No such file or directory

It seems like boost is not properly found by cmake despite envirnoment variables (BOOST_DIR, BOOST_LIBRARYDIR and BOOST_INCLUDEDIR) were properly defined. This is also suggested by the inlude directories list:

c:\Program Files\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\build\install\include" /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\libraries\iDynTree\model_io\urdf\external\urdfdom..\urdfdom_headers\urdf_model\include" /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\libraries\iDynTree\model_io\urdf\external\urdfdom..\urdfdom_headers\urdf_exception\include" /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\libraries\iDynTree\model_io\urdf\external\urdfdom..\urdfdom_headers\urdf_sensor\include" /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\libraries\iDynTree\model_io\urdf\external\urdfdom..\urdfdom_headers\urdf_world\include" /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\libraries\iDynTree\model_io\urdf\external\urdfdom..\urdfdom_headers\urdf_model_state\include" /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\libraries\iDynTree\model_io\urdf\external\urdfdom\urdf_parser\include" /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\libraries\iDynTree\core-experimental\include" /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\libraries\iDynTree\core\include" /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\libraries\iDynTree\sensors\include" /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\libraries\iDynTree\include" /Zi /nologo /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D URDF_USE_PLAIN_POINTERS /D IDYNTREE_USE_INTERNAL_URDFDOM /D YARP_NO_DEPRECATED_WARNINGS /D OROCOS_KDL_VERSION_MAJOR=1 /D OROCOS_KDL_VERSION_MINOR=2 /D OROCOS_KDL_VERSION_PATCH=3 /D URDFDOM_DO_NOT_USE_CONSOLEBRIDGE /D "CMAKE_INTDIR="Debug"" /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /GR /Fo"iDynTree_priv_urdfdom_model.dir\Debug" /Fd"iDynTree_priv_urdfdom_model.dir\Debug\vc100.pdb" /Gd /TP /analyze- /errorReport:queue ................\libraries\iDynTree\model_io\urdf\external\urdfdom\urdf_parser\src\pose.cpp ................\libraries\iDynTree\model_io\urdf\external\urdfdom\urdf_parser\src\model.cpp ................\libraries\iDynTree\model_io\urdf\external\urdfdom\urdf_parser\src\link.cpp ................\libraries\iDynTree\model_io\urdf\external\urdfdom\urdf_parser\src\joint.cpp
6> pose.cpp

Other projects (like urdfdom) properly configure boost (only after defining BOOST_DIR, BOOST_LIBRARYDIR and BOOST_INCLUDEDIR):

29> ClCompile:
29> c:\Program Files\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\build\install\include" /IC:\boost /I"C:\Users\Bastien\Documents\GitHub\codyco-superbuild\external\urdfdom\urdf_parser\include" /nologo /W3 /WX- /O2 /Ob2 /Oy- /D WIN32 /D _WINDOWS /D NDEBUG /D URDFDOM_DO_NOT_USE_CONSOLEBRIDGE /D "CMAKE_INTDIR="Release"" /D urdfdom_model_EXPORTS /D _WINDLL /D _MBCS /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /GR /Fo"urdfdom_model.dir\Release" /Fd"urdfdom_model.dir\Release\vc100.pdb" /Gd /TP /analyze- /errorReport:queue ........\external\urdfdom\urdf_parser\src\pose.cpp ........\external\urdfdom\urdf_parser\src\model.cpp ........\external\urdfdom\urdf_parser\src\link.cpp ........\external\urdfdom\urdf_parser\src\joint.cpp ........\external\urdfdom\urdf_parser\src\urdf_sensor.cpp ........\external\urdfdom\urdf_parser\src\urdf_model_state.cpp ........\external\urdfdom\urdf_parser\src\twist.cpp

We have to prepare a cleanup of the dynamicsRegressorsGenerator cleanup, to enable wrapping it with SWIG.

Key points:

• Eliminate KDL dependency (initially just from headers, pimpling the actual implementation)
• Load regressor structure and parameters from file, instead of hardcoding configuration at the C++ level. This seem really a JSON job, but for the time being I would avoid adding dependencies and I would go for a basic xml-based format.
• Use the sensors classes to set/get sensors readings.
• Use VectorDynSize and MatrixDynSize to wrap Eigen data structures to enable the use of SWIG.

For the future:

• Encode the difference between links and frames at the iDynTree data structure level, so we can avoid hardcoding in the configuration the "fake" links.

The robots should be provided by a model (for example urdf) and the user should provide a configuration file with:

• the links in the "subtree" for which we want to extract the inertial parameters
• the position of the joints in the "subtree"
• the orientation and the point with respect to which we want to get the inertial parameters.

Hi,

I'm trying to compile the python bindings of iDynTree using the iDynTree-superbuild.
I updated the superbuild (git pull), updated all the repos (make update-all), re-built (cmake+make) and everything worked fine.
Then I went to build/lib/iDynTree to check that the flag IDYN_TREE_USES_PYTHON was ON, and it was, but it didn't generate the python bindings (in build/install/lib there is no directory python).
Then I tried compiling directly inside build/lib/iDynTree and it looks like it's trying to compile the python bindings, but it fails with this error:

make[2]: *** No rule to make target `/usr/lib/python3.2/config/libpython3.2.so', needed by `lib/python/_iDynTree.so'.  Stop.

even if I specified through the variable IDYN_TREE_USE_PYTHON_VERSION that I want to use python 2.7. Any idea what is going wrong?

Thanks,
Andrea

• Set sensor measures values [1]
• Compute identifiable subspace [2]
• Don't consider frames as links (i.e. don't include inertial parameters for frames in the regressor) [3]
• Get a regressor with only the relevant parameters [4]

Nice to have: proper typemaps

save/load is not supported.

As a first step, overload saveobj / loadobj to produce a clear warning message explaining the problem (this probably should be done at swig level).

In theory this should be possible by just modifyng the SwigRef.m that is the base class for all the SWIG Matlab classes, see the upstream issue at jaeandersson/swig#59 .

cc @naveenoid @francesco-romano

@prashanthr05 and @naveenoid are planning to use the new classes for spatial algebra.
While we are finishing to implement them, I would ask them to do the following:

• Try to compile the matlab bindings, following the instruction on the README
• Try to play with the bindings, following the tutorial at https://github.com/robotology/idyntree/blob/master/doc/geometric_classes.md
• Comment this issue with desired features
• Write some "unit-test" in matlab, for checking that the new datastructure are sound.

@nunoguedelha They used to be printed in the Matlab terminal, right?

With @naveenoid we started refactoring the sensor part of iDynTree, and the "core" part (as discussed in #29 ) is taking form. Hi will try to brainstorm all the different components in which we can structure iDynTree:

Core (currently core-experimental)

• Public Dependencies : C++ STL ? (subject to #33 )
• Private Dependencies : Eigen3
• Namespace : iDynTree

This is the component is containing the base classes of iDynTree, as discussed in #29 and #32 ). It was recently introduced to slowly replace the use of KDL structure.
It will contain classes for geometric quantities (Transform, Position, Wrenches, Mass Matrices, etc etc), and eventually data structures describing the robot (KDL::CoDyCo::UndirectedTree).

Sensors

• Public Dependencies : Core (currently KDL)
• Namespace: iDynTree::Sensors

This component will contain classes useful for representing and process sensor measurements.

KDL (currently core)

• Public Dependencies : KDL, Eigen3
• Namespace: currently KDL::CoDyCo, eventually iDynTree::KDL

This is the old "core" of iDynTree. Data structures here depend heavily on KDL. We will migrate most of them to Core to gain SWIG support. In the meanwhile, we will rely on conversion functions between iDynTree datastructures and KDL provided in iDynTree/KDL/iDynTreeKDLConversions.h . This function will also be useful in the future to maintain a degree of interoperability with

ModelIO

• Public Dependencies : KDL, urdfdom
• Namespace: currently kdl_format_io, eventually iDynTree::ModelIO
  This component contains all the logic for loading or saving the model structure (kinematics and dynamics parameters, sensors information) from and to external file formats, most notably URDF.
  This will be probably the component from which migration will be particularly tricky.

YARP

• Public Dependencies : Core, KDL, Eigen3, YARP (currently also ICUB)
• Namespace: currently: iCub::iDynTree, eventually iDynTree::yarp

This component is made of all the classes related to YARP interoperability, and also the DynTree legacy class. This component is also providing interoperability between iDynTree classes and YARP classes, useful for YARP modules that use iDynTree for computation and YARP for communication .

ICUB

• Public Dependencies : Core, KDL, Eigen3, YARP, ICUB

This component (currently not existing) will contain the conversion function between iDynTree classes and classes defined in ICUB libraries (such as skinDynLib).

cc @francesco-romano @nunoguedelha

iDynTree makes an intensive use of methods returning references to compose different classes
such as SensorsMeasurements or *Semantics. A recent commit in matlab swig broke this
behaviour, until we fix this issue we can rollback to the latest matlab swig version working ( jaeandersson/swig@e435cba ).

@nunoguedelha currently I am generating bindings with this swig-matlab commit : jaeandersson/swig@e435cba . So if you checkout to that commit (git checkout e435cba21e33c664e8ee75f5f9bd17b245aeb0b7) in the swig directory we will be in synch.

Upstream issue: jaeandersson/swig#28

Calling setFloatingBaseLink corrupts some internal buffer because getCOM berfore and after change the results. Should we consider to change the world base coherently when setFloatingBaseLink is called?

We should add more tests.
This should be done also in https://github.com/robotology-playground/yarp-wholebodyinterface and https://github.com/robotology-playground/wholebodyinterface.

cc
@traversaro @claudia-lat

Ref: #50 (comment)

Currently the regressors are generated assuming a rigid ordering of the parameters, as it is possible to see for example in https://github.com/robotology-playground/idyntree/blob/master/regressors/src/dynamicRegressorGenerator.cpp#L192 .
To enable a more flexible methods, I propose to extend the current interfaces with some methods that manipulate DynamicParameter. A dynamic parameter can be described by a type and a integer. The semantics of the integer is given by the dynamic parameter type.
Every subregressor can expose a list of Dynamic parameters that it uses. The generator can then get this list from all the subregressors, and thus get a total list of parameters that it uses. It can then decide an ordering, that is then passed to the subregressors to specifying the ordering of the parameters.

-rwxr-xr-x  1 makaveli  staff  2593556 31 Mar 18:38 libidyntree-core.dylib
-rwxr-xr-x  1 makaveli  staff   708212 31 Mar 18:38 libidyntree-model-io..dylib
lrwxr-xr-x  1 makaveli  staff       27 31 Mar 18:37 libidyntree-model-io.dylib -> libidyntree-model-io..dylib
lrwxr-xr-x  1 makaveli  staff       29 31 Mar 18:37 libidyntree-regressors...dylib -> libidyntree-regressors..dylib
-rwxr-xr-x  1 makaveli  staff  2558372 31 Mar 18:38 libidyntree-regressors..dylib
lrwxr-xr-x  1 makaveli  staff       30 31 Mar 18:37 libidyntree-regressors.dylib -> libidyntree-regressors...dylib
-rwxr-xr-x  1 makaveli  staff  2926336 31 Mar 18:38 libidyntree-yarp.0.3.2.dylib
lrwxr-xr-x  1 makaveli  staff       28 31 Mar 18:37 libidyntree-yarp.dylib -> libidyntree-yarp.0.3.2.dylib

Note the "empty" dots (where the version should be present).

@traversaro

If in the urdf it is present a continuous joints it is taken in consideration in the tree while I think should not since normally this kind of joints are used to model wheels. In particular in our case we have a continuous joints in the head to rotate the laser.

In order to compile bindings to iDynTree in Matlab (my Matlab version is Matlab R2015a) I tried to enable IDYNTREE_USES_MATLAB CMake options, but I got this error:

Add library idyntree
src/DynTree.cppsrc/yarp_kdl.cppsrc/TorqueEstimationTree.cppsrc/iDyn2KDL.cppsrc
/yarp_iDynTree.cppsrc/idyn2kdl_icub.cppinclude/iCub/iDynTree/DynTree.hinclude/
iCub/iDynTree/yarp_kdl.hinclude/iCub/iDynTree/yarp_iDynTree.hinclude/iCub/iDyn
Tree/iDyn2KDL.hinclude/iCub/iDynTree/TorqueEstimationTree.hinclude/iCub/iDynTr
ee/idyn2kdl_icub.h

CMake Error at
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108
(message):
Could NOT find Matlab (missing: Matlab_INCLUDE_DIRS Matlab_MEX_LIBRARY
Matlab_MEX_EXTENSION) (found version "8.5")
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315
(_FPHSA_FAILURE_MESSAGE)
cmake/FindMatlab.cmake:1432 (find_package_handle_standard_args)
bindings/matlab/CMakeLists.txt:35 (find_package)

so it seems that Matlab cannot be found. What can I try?

Diego

There are some tasks necessary to finish the cleanup of the sensors iDynTree system.

Things necessary for this week, to produce the regressor bindings for @ommac and @DiegoRomeres :

• Remove Sensors dependency on KDL, to enable the use of SWIG to produce bindings
  • Substitute references to KDL::Wrench with iDynTree::Wrench. The code that uses SensorsMeasurements but is still using KDL::Wrench can be still supported using the functions in https://github.com/robotology-playground/idyntree/blob/master/core/include/kdl_codyco/KDLConversions.h
  • Substitute references to KDL::Frame with iDynTree::Transform .
  • Move the simulateMeasurement method, that dependes on a lot of stuff from the core/kdl library, in a separated files as a stand-alone function.

(relatively) Low priority:

• Rename SensorsTree in something more meaningful
• Add a Gyroscope sensor type & class (this will require adding a AngularVelocity class to Core.
• Add an Accelerometer sensor type & class (this will require adding an LinearAcceleration or LinearProperAcceleration (to be discussed) to Core
• Add Sensors headers to swig bindings compilation, and clean up anything that is not working.

cc @naveenoid can you look into this?

@iron76 reported crashes related to save/load of iDynTree variables in Matlab 2012b .
It would be probably worth to add some save/load related unit tests to https://github.com/robotology/idyntree/blob/master/bindings/matlab/tests/runiDynTreeTests.m .

We need a:

• Documentation on how to install iDynTree without the codyco-superbuild but still retaining all the dependencies. iDynTree-superbuild could be a nice solution.
• tutorial to cover:
  • Load a URDF model to a class
  • Compute the gravity terms for a fixed base robot, given the joint positions.
    Nice to have:
• Migrate to robotology/iDynTree

Matlab crashes on quit

This is the log:

------------------------------------------------------------------------
       Segmentation violation detected at Fri Jul 10 14:24:12 2015
------------------------------------------------------------------------

Configuration:
  Crash Decoding     : Disabled
  Current Visual     : Quartz
  Default Encoding   : US-ASCII
  MATLAB Architecture: maci64
  MATLAB Root        : /Applications/MATLAB_R2014b.app
  MATLAB Version     : 8.4.0.150421 (R2014b)
  Operating System   : Darwin 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64
  Processor ID       : x86 Family 6 Model 69 Stepping 1, GenuineIntel
  Software OpenGL    : 0
  Virtual Machine    : Java 1.7.0_55-b13 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
  Window System      : Quartz

Fault Count: 1


Abnormal termination:
Segmentation violation

Register State (from fault):
  RAX = 00007fa052ee9140  RBX = 0000000000000000
  RCX = 000000010e5aa4b0  RDX = 00000001014c1e2d
  RSP = 000000010e5aac60  RBP = fb00e6f00d267d26
  RSI = 000000010e5aa484  RDI = 0000000000000001

   R8 = 0000000000000001   R9 = 0000000000000000
  R10 = 0000000000000051  R11 = 0000000000000001
  R12 = 000000010e5aa4b0  R13 = 0000000118a6628f
  R14 = 00007fa0601bd7f0  R15 = 000000010e5aac60

  RIP = 000000010e5aa620  RFL = 0000000118a8f3d4

   CS = 0000000000000000   FS = 000000010e5aab98   GS = 0000000000000000

Stack Trace (from fault):
[  0] 0x0000000101244e64 /Applications/MATLAB_R2014b.app/bin/maci64/libmwfl.dylib+00028260 _ZN2fl4diag15stacktrace_base7captureERKNS0_14thread_contextEm+00000052
[  1] 0x0000000101248a2a /Applications/MATLAB_R2014b.app/bin/maci64/libmwfl.dylib+00043562 _ZN2fl4test17terminate_handledEv+00000906
[  2] 0x0000000101248477 /Applications/MATLAB_R2014b.app/bin/maci64/libmwfl.dylib+00042103 _ZN2fl4diag13terminate_logEPKcPK17__darwin_ucontext+00000119
[  3] 0x0000000100c9ab7a /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00387962 _Z32mnRunPathDependentInitializationv+00003146
[  4] 0x0000000100c9ae58 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00388696 _Z32mnRunPathDependentInitializationv+00003880
[  5] 0x0000000100c98733 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00378675 mnFatalSignalHandler+00000275
[  6] 0x00007fff82d74f1a           /usr/lib/system/libsystem_platform.dylib+00020250 _sigtramp+00000026
[  7] 0x00007fa0600e58f0                                   <unknown-module>+00000000
[  8] 0x0000000118a8f3d4 /Users/makaveli/Projects/src/codyco-superbuild/build/install/mex/iDynTreeMATLAB_wrap.mexmaci64+00246740 mexFunction+00005204
[  9] 0x0000000105d1beeb /Applications/MATLAB_R2014b.app/bin/maci64/libmex.dylib+00069355 mexRunMexFile+00000091
[ 10] 0x0000000105d17f41 /Applications/MATLAB_R2014b.app/bin/maci64/libmex.dylib+00053057 _ZN7Mfh_mex30runMexFileWithSignalProtectionEiPP11mxArray_tagiS2_+00000113
[ 11] 0x0000000105d18130 /Applications/MATLAB_R2014b.app/bin/maci64/libmex.dylib+00053552 _ZN7Mfh_mex13dispatch_fileEiPP11mxArray_tagiS2_+00000304
[ 12] 0x0000000105da5c28 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_dispatcher.dylib+00400424 _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+00000600
[ 13] 0x0000000106705d62 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01523042 _Z19inDispatchFromStackiPKcii+00001650
[ 14] 0x00000001066a7dd8 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01138136 inPcodeWalker+00022552
[ 15] 0x00000001066a4917 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01124631 inPcodeWalker+00009047
[ 16] 0x000000010669ffb7 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01105847 inInterPcode+00000935
[ 17] 0x00000001066a11c6 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01110470 _Z26inExecuteMFunctionOrScriptP6Mfh_mpb+00000886
[ 18] 0x00000001067431f1 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01774065 _Z10inRunMfileiPP11mxArray_tagiS1_P6Mfh_mpP15inWorkSpace_tag+00002337
[ 19] 0x0000000105da5c28 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_dispatcher.dylib+00400424 _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+00000600
[ 20] 0x0000000105f89e8e /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcos.dylib+01093262 _ZNK4mcos17MScopedMethodInfo6invokeEPKNS_9COSClientERiPNS_8COSValueEiPKS5_+00000606
[ 21] 0x0000000105fa4387 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcos.dylib+01201031 _ZNK4mcos13MDestructorMI6invokeEPKNS_9COSClientERiPNS_8COSValueEiPKS5_+00000551
[ 22] 0x0000000105e8c8c3 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcos.dylib+00055491 _ZN4mcos9COSClassI14callDestructorENS_15COSInterfacePtrE+00000179
[ 23] 0x0000000105e98299 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcos.dylib+00103065 _ZN4mcos9COSClassI15destroyInstanceENS_15COSInterfacePtrE+00000073
[ 24] 0x0000000105edd28f /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcos.dylib+00385679 _ZN4mcos13COSInterfaceI13destroyObjectEv+00000095
[ 25] 0x0000000105ed45e2 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcos.dylib+00349666 _ZN4mcos13COSInterfaceI10destroyRefEv+00000258
[ 26] 0x0000000105ed88d0 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcos.dylib+00366800 _ZN4mcos15COSInterfacePtr7releaseEv+00000112
[ 27] 0x0000000105fa6ce6 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcos.dylib+01211622 _Z24omDestroyElementListenerPvPK11mxArray_tag+00000166
[ 28] 0x00000001014c5a25 /Applications/MATLAB_R2014b.app/bin/maci64/libmx.dylib+00059941 _ZN6matrix6detail10noninlined12mx_array_api21postdestroy_containerEP11mxArray_tag+00002021
[ 29] 0x00000001014c125f /Applications/MATLAB_R2014b.app/bin/maci64/libmx.dylib+00041567 _ZN6matrix6detail10noninlined12mx_array_api22mxDestroyArrayContentsEP11mxArray_tag+00000191
[ 30] 0x0000000101585ee3 /Applications/MATLAB_R2014b.app/bin/maci64/libmx.dylib+00847587 _ZN6matrix6detail10noninlined12mx_array_api20mxClearArrayContentsEP11mxArray_tag+00000019
[ 31] 0x00000001069601fe /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+03990014 _ZN12InterpBridge22ClearArraysInDesiredWSEP15inWorkSpace_tag+00000638
[ 32] 0x0000000106960178 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+03989880 _ZN12InterpBridge22ClearArraysInDesiredWSEP15inWorkSpace_tag+00000504
[ 33] 0x00000001069605e5 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+03991013 _Z33inClearArraysInCurrentAndGlobalWSPFP15inWorkSpace_tagiE+00000021
[ 34] 0x000000010667924b /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+00946763 _ZN12InterpBridge12FullClearFcnEiPP11mxArray_tagiS2_+00003115
[ 35] 0x0000000106678d0d /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+00945421 _ZN12InterpBridge12FullClearFcnEiPP11mxArray_tagiS2_+00001773
[ 36] 0x0000000105d60cc6 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_dispatcher.dylib+00117958 _ZN11Mfh_builtin11dispatch_mfEiPP11mxArray_tagiS2_+00000086
[ 37] 0x0000000105d4912d /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_dispatcher.dylib+00020781 _ZN13Mfh_MATLAB_fn11dispatch_fhEiPP11mxArray_tagiS2_+00000333
[ 38] 0x0000000106705d62 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01523042 _Z19inDispatchFromStackiPKcii+00001650
[ 39] 0x00000001066a7dd8 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01138136 inPcodeWalker+00022552
[ 40] 0x00000001066a4702 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01124098 inPcodeWalker+00008514
[ 41] 0x000000010669ffb7 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01105847 inInterPcode+00000935
[ 42] 0x000000010669fcad /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01105069 inInterPcode+00000157
[ 43] 0x0000000106696b9f /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01067935 _ZN12InterpBridge33DoMatlabFcnCallInDesiredWorkspaceEiPP11mxArray_tagiPPKS0_P13Mfh_MATLAB_fnP15inWorkSpace_tag+00004015
[ 44] 0x0000000106698adb /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01075931 _Z25in_local_call_with_setjmpIN5boost3_bi6bind_tIvPFvPiP12_pcodeheaderS3_PP11mxArray_tag12inDebugCheckENS1_5list5INS1_5valueIS3_EENSD_IS5_EENS0_3argILi1EEENSG_ILi2EEENSD_IS9_EEEEEEEN6mlutil14cmddistributor17inExecutionStatusET_S3_S8_b+00000171
[ 45] 0x000000010669428d /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01057421 _Z12inEvalStringP15_memory_contextRKSbItSt11char_traitsItESaItEE8EvalTypeiPP11mxArray_tag12inDebugCheckP12_pcodeheaderPib+00002877
[ 46] 0x0000000106694655 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01058389 _Z19inEvalStringOnStackP15_memory_contextRKSbItSt11char_traitsItESaItEE8EvalTypeiPP11mxArray_tag12inDebugCheckP12_pcodeheaderPib+00000085
[ 47] 0x0000000106691836 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01046582 _ZN12InterpBridge11FullEvalFcnEiPP11mxArray_tagiS2_+00000278
[ 48] 0x0000000105d60cc6 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_dispatcher.dylib+00117958 _ZN11Mfh_builtin11dispatch_mfEiPP11mxArray_tagiS2_+00000086
[ 49] 0x0000000105d4912d /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_dispatcher.dylib+00020781 _ZN13Mfh_MATLAB_fn11dispatch_fhEiPP11mxArray_tagiS2_+00000333
[ 50] 0x00000001066d4d83 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01322371 _ZN12InterpBridge7CallFcnEiPP11mxArray_tagiS2_PKc+00000275
[ 51] 0x0000000100c8141e /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00283678 _ZN11mcrInstance27feval_on_interpreter_threadEPKciPP11mxArray_tagiS4_+00000094
[ 52] 0x0000000100c816fd /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00284413 _ZN11mcrInstance18CallMATLABFunctionEPKciPP11mxArray_tagiS4_+00000077
[ 53] 0x0000000100c8277a /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00288634 _ZN11mcrInstance10EvalStringERKSbItSt11char_traitsItESaItEEiPP11mxArray_tag+00000122
[ 54] 0x0000000100c82a93 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00289427 _ZN11mcrInstance14clearAllOnExitEv+00000099
[ 55] 0x0000000100c96a67 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00371303 _Z28mnShutdownMatlabInternalImplbbRKN5boost8optionalIiEEPibb+00000503
[ 56] 0x0000000100c967ae /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00370606 _Z34mnShutdownMatlabInternalWithSetJmpbbRKN5boost8optionalIiEEPibb+00000142
[ 57] 0x0000000100c96f92 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00372626 _Z24mnShutdownMatlabInternalbbRKN5boost8optionalIiEEPibb+00000050
[ 58] 0x0000000100c97443 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00373827 _Z13mnFullExitFcniPP11mxArray_tagiS1_+00000323
[ 59] 0x0000000105d60cc6 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_dispatcher.dylib+00117958 _ZN11Mfh_builtin11dispatch_mfEiPP11mxArray_tagiS2_+00000086
[ 60] 0x0000000105d4912d /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_dispatcher.dylib+00020781 _ZN13Mfh_MATLAB_fn11dispatch_fhEiPP11mxArray_tagiS2_+00000333
[ 61] 0x0000000106705d62 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01523042 _Z19inDispatchFromStackiPKcii+00001650
[ 62] 0x000000010665b59e /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+00824734 inCallFcnFromReference+00000110
[ 63] 0x00000001066a4003 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01122307 inPcodeWalker+00006723
[ 64] 0x000000010669ffb7 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01105847 inInterPcode+00000935
[ 65] 0x00000001066a11c6 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01110470 _Z26inExecuteMFunctionOrScriptP6Mfh_mpb+00000886
[ 66] 0x00000001067431f1 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01774065 _Z10inRunMfileiPP11mxArray_tagiS1_P6Mfh_mpP15inWorkSpace_tag+00002337
[ 67] 0x0000000105da5c55 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_dispatcher.dylib+00400469 _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+00000645
[ 68] 0x00000001066e648b /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01393803 _Z23inEvalPcodeHeaderToWordP15_memory_contextiPP11mxArray_tagP12_pcodeheaderP6Mfh_mpj+00000219
[ 69] 0x0000000106698f4b /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01077067 _Z25in_local_call_with_setjmpIN5boost3_bi6bind_tIvPFvP15_memory_contextPiPP11mxArray_tagP12_pcodeheaderjENS1_5list5INS1_5valueIS4_EENS0_3argILi1EEENSG_ILi2EEENSE_ISA_EENSE_IiEEEEEEEN6mlutil14cmddistributor17inExecutionStatusET_S5_S8_b+00000171
[ 70] 0x0000000106694221 /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01057313 _Z12inEvalStringP15_memory_contextRKSbItSt11char_traitsItESaItEE8EvalTypeiPP11mxArray_tag12inDebugCheckP12_pcodeheaderPib+00002769
[ 71] 0x00000001066947cd /Applications/MATLAB_R2014b.app/bin/maci64/libmwm_interpreter.dylib+01058765 _ZN12InterpBridge22EvalCmdWithLocalReturnERKSbItSt11char_traitsItESaItEEPibb+00000141
[ 72] 0x0000000105caf11d /Applications/MATLAB_R2014b.app/bin/maci64/libmwbridge.dylib+00061725 _Z28evalCommandWithLongjmpSafetyRKSbItSt11char_traitsItESaItEE+00000093
[ 73] 0x0000000105caf804 /Applications/MATLAB_R2014b.app/bin/maci64/libmwbridge.dylib+00063492 _Z8mnParserv+00000772
[ 74] 0x0000000100c82832 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00288818 _ZN11mcrInstance30mnParser_on_interpreter_threadEv+00000034
[ 75] 0x0000000100c5d0d1 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00135377 _ZN3mcr7runtime17InterpreterThread4Impl22TypedInvocationRequestIvE29doNotRethrowMxArrayExceptionsERKN5boost8functionIFvvEEE+00000033
[ 76] 0x0000000100c5dd89 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00138633 _ZN5boost6detail11task_objectIvNS_3_bi6bind_tIvPFvRKNS_8functionIFvvEEEENS2_5list1INS2_5valueIS6_EEEEEEE6do_runEv+00000025
[ 77] 0x0000000100c5d586 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00136582 _ZN5boost6detail9task_baseIvE3runEv+00000166
[ 78] 0x0000000100c5d377 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00136055 _ZN3mcr7runtime17InterpreterThread4Impl22TypedInvocationRequestIvE3runEv+00000023
[ 79] 0x0000000100c58f90 /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00118672 _ZN3mcr7runtime17InterpreterThread4Impl26invocation_request_handlerEl+00000032
[ 80] 0x000000010079a005 /Applications/MATLAB_R2014b.app/bin/maci64/libmwservices.dylib+00196613 _ZN10eventqueue18UserEventQueueImpl5flushEv+00001205
[ 81] 0x0000000107167a65 /Applications/MATLAB_R2014b.app/bin/maci64/libmwuix.dylib+00043621 _Z25isHandleUserEventCallbackPFvPvE+00000501
[ 82] 0x0000000100869a45 /Applications/MATLAB_R2014b.app/bin/maci64/libmwservices.dylib+01047109 _Z21svWS_ProcessCallbacksv+00016693
[ 83] 0x0000000100865152 /Applications/MATLAB_R2014b.app/bin/maci64/libmwservices.dylib+01028434 _Z25svWS_ProcessPendingEventsiib+00000834
[ 84] 0x0000000100864e5e /Applications/MATLAB_R2014b.app/bin/maci64/libmwservices.dylib+01027678 _Z25svWS_ProcessPendingEventsiib+00000078
[ 85] 0x0000000100c5918f /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00119183 _ZN3mcr7runtime17InterpreterThread4Impl14process_eventsERKN5boost10shared_ptrIS2_EE+00000095
[ 86] 0x0000000100c5949f /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00119967 _ZN3mcr7runtime17InterpreterThread4Impl3runERKN5boost10shared_ptrIS2_EEPNS2_12init_contextE+00000335
[ 87] 0x0000000100c3fd1b /Applications/MATLAB_R2014b.app/bin/maci64/libmwmcr.dylib+00015643 _Z26run_init_and_handle_eventsPv+00000059
[ 88] 0x00007fff8b4e4268            /usr/lib/system/libsystem_pthread.dylib+00012904 _pthread_body+00000131
[ 89] 0x00007fff8b4e41e5            /usr/lib/system/libsystem_pthread.dylib+00012773 _pthread_body+00000000
[ 90] 0x00007fff8b4e241d            /usr/lib/system/libsystem_pthread.dylib+00005149 thread_start+00000013

I got the problem playing with the Matlab regressor example in:

https://github.com/robotology-playground/idyntree/tree/master/examples/matlab/iCubLeftArmDynamicRegressors

In the specifc case, calling:
regrGen.getDescriptionOfDegreesOfFreedom()

I got as result:
Empty string: 1-by-0

when instead there are 32 degree of freedom.

A clean up is currently undergoing in development branch (v0.3) to facilitate development, maintenance and dissemination (and to finally merge the new "floating position/velocity/acceleration/torque" logic.

• Get a basic example (compiled out of the superbuild and of iDynTree source tree) to work
• Get the codyco-superbuild to build and work with v0.3 (check that all test pass)
• Get the walkman superbuild to build and check that all tests are passing
• Restore the iDyn / iDynTree consistency checks, use them also for check urdf export.
• Correctly compile and install useful tools:
  • urdf2dh
  • par2urdf
  • urdf_get_mass

Issue to discuss what was introduced in PR #68, i.e. a joint system native to iDynTree (i.e. that can be easily wrapped by SWIG to Matlab/Python/Lua/..).

Rough feature list is:

• Support joints with an arbitrary number of DOFs (from 0 to 6).
• Support joints with a configuration spaces that is a non-euclidean manifold (not implemented by now, but the interface was designed to eventually support them).
• Provide a undirected interface, i.e. the API providing information for a joint connecting linkA to linkB should be simmetric in the information that it can provides with respect to the two links.

Inspirations for the design:

• KDL Joints, the one that we used until now.
• RBDL Joints
• Simbody Joints, probably the design from which I took more inspiration, look at http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3002261/ for a more scientific discussion of the topic.
• DART joints
• The upcoming implementation of the C++ Joint system in Drake ( RobotLocomotion/drake#1199 ) that support automatic differentiation.

Something (perhaps in the updated dependencies in urdfdom/urdfdom_headers) broke URDF support in a subtle way (only tests are failing, compilation is fine: https://travis-ci.org/robotology/idyntree/jobs/83429307 ).
This is super problematic because it then breaks all the codyco software, I will investigate it later this afternoon, in the meanwhile pay attention.
cc @robotology/codyco-developers

As I was looking at the use cases provided by @MirkoFerrati it emerged the necessity of a clean way to define sub chains in the tree (something that emerges if you don't want to do whole-body control).
A possible solution is to reuse some elements from the SRDF format as originally proposed by @EnricoMingo .
Initially I was against use of SRDF because I was more oriented on a view of "parts" of a robot as opposed to unrelated "chains", but I guess it is possible to express this "parts" concept just as special instance of a more general "chain" concept.
Supporting the loading of this chains from SRDF would be convenient because it is a format already defined and we could just built on the top of it.

I am building iDynTree via codyco-superbuild, by setting CODYCO_USES_MATLAB ON, and the MATLAB mex files are not generated as expected in SUPERBUILD_BUILD_DIRECTORY/install/mex.

What's the right way to configure it?

Moreover, it is not clear how to configure the bindings using iDynTree-superbuild

For flexibility, it should be possible to perform the estimation only on a subset of the dofs of the URDF.

Ref : robotology/icub-main#165

It would be desirable to have semantics aware classes for covering all the algorithms implemented in iDynTree, I will list some of them to keep track.

For integration work with @DiegoRomeres and @occam , we need to expose at least a subset of this classes, that I marked in the list with [priority] .

(cc @DanielePucci All the iDynTree::?? still needs a proper name.)

At the raw (coordinates) level we will need:

• iDynTree::SpatialMotionRaw [priority]
• iDynTree::SpatialForceRaw [priority]
• iDynTree::SpatialMotionToForceDyadicRaw
• iDynTree::JntPositionRaw [priority]
• iDynTree::JntMotionRaw [priority]
• iDynTree::JntForceRaw
• iDynTree::JntMotionToForceDyadicRaw
• iDynTree::?? Free floating robot configuration
• iDynTree::?? Free floating robot Motion
• iDynTree::?? Free floating robot force
• iDynTree::?? Free floating robot Motion to force dyadic

@traversaro @DiegoRomeres

I have followed the simple steps outlined in https://github.com/robotology-playground/idyntree#bindings to generate the iDynTree MATLAB bindings.

Then, I have started MATLAB r2014b (UNIX version), and added iDynTree/bindings/matlab/* to the MATLAB path.

Later on, I have tried the two example scripts proposed in https://github.com/robotology-playground/idyntree/blob/master/doc/geometric_classes.md

The outputs were:

Undefined function 'iDynTreeMATLAB_wrap' for input arguments of type 'double'.

Error in iDynTree.Position (line 9)
        tmp = iDynTreeMATLAB_wrap(80,'new_Position',varargin{:}); % FIXME

Error in test1 (line 4)
origin_A_B = iDynTree.Position(1,2,3)

Undefined function 'iDynTreeMATLAB_wrap' for input arguments of type 'double'.

Error in iDynTree.Position (line 9)
        tmp = iDynTreeMATLAB_wrap(80,'new_Position',varargin{:}); % FIXME

Error in test2 (line 9)
origin_A_B = iDynTree.Position(1,2,3)

Long things short: class iDynTreeMATLAB_wrap does not seem to be defined.

Note: In folder iDynTree/bindings/matlab there is a file called iDynTreeMATLAB_wrap.cxx. I do not know what is it for, but I would expect to also have a MATLAB version of it, which I don't.

Maybe some options for generating the bindings are wrong?

Thanks.

Write a/some class(es) to support the following use cases:

• Print in more & less human readable form the identifiable parameters
• Given a covariance matrix, print relative variance of identifiable parameters (for example starting from total mass)

We currently have a SensorsList data structure that is meant to represent the information about the sensors available on the kinematic tree, and provide some helpers function (for example for translating a measurement from the sensors frame to the link frame).

C++ sensors to add

This was added in #24, and for now the only implemented sensors are the six axis F/T sensors.

For implementing BERDY, we need to add several sensors, starting from:

• Accelerometer,
• Gyroscope,
• Orientation sensor (not actually a sensor, but normally an output of a lower level estimate coming from an IMU/MPU).

In the future we may need also joint torque sensors, camera, skin.. but I guess that we can start from this three ones.

Sensor model loading

Once we define a C++ class for representing this sensors, we need a way of loading this information from file. For model input/output, currently we are mostly relying on the URDF format. [1] [2] [3] The URDF spec has several problems (not clearly defined, do not provide explicit support for extensions, mix the concept of frames and links, does not support closed loop structures) but its use is fairly widespread, so for dissemination is a force choice.

Current state of Sensors spec in URDF

Currently the "official" spec for Sensors in URDF [4] supports only laser sensors and camera sensors. A new proposal is open for adding new sensors to the URDF spec [5], but there is clearly a lack of interest in the community. In the meanwhile, several software such as Phobos [6] and Drake [7] are adding mutually incompatible sensors information.

Then, my proposal is:

ref: https://xkcd.com/927/

Jokes aside, the quickest solution for now is that we defined our own sensors URDF extension, and we can take part (but without waiting for the conclusion of the discussion) to ros/urdfdom#28 .

Roadmap

An outline of possible steps are:

• We prepare a draft of URDF extensions that covers our use cases
• We extend the xsd spec in https://github.com/ros/urdfdom/blob/master/xsd/urdf.xsd
• We write a parser for our modified xsd, either extending urdfdom (not suggested, it is a terrible codebase), writing our own (probably the sanest solution) or by experimenting with some fancy tool for xsd --> C++ dom conversion ( @francesco-romano can help in this)
• We write a function that takes a C++ dom for our URDF sensor extension and output a SensorsList

[1] http://wiki.ros.org/urdf
[2] https://github.com/ros/urdfdom_headers
[3] https://github.com/ros/urdfdom
[4] http://drake002.csail.mit.edu/drake/urdf/drakeURDF.html
[5] ros/urdfdom#28
[6] dfki-ric/phobos#11
[7] http://drake002.csail.mit.edu/drake/urdf/drakeURDF.html

@prashanthr05 suggested that for the use of iDynTree data types in scripting languages, it is convenient to support constructor for native vector/matrix datatypes, as in:

pos = iDynTree.Position([1,2,3])

This can be easily done by providing appropriate constructors for the iDynTree class, as described in http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html .

Preamble

Since when we started writing iDynTree, one of the core ideas was to rely on KDL data structures (such as KDL::Vector, KDL::Twist, KDL::Wrench, KDL::Joint, KDL::Tree, etc, etc, .. ) to increase interoperability with existing software (such as URDF parser) and to rely on an already existing and tested codebase of realtime safe data structures.

However, once we started working on floating base algorithms, we started realizing that some KDL data structures were not specifically designed for the floating base case in mind.
In particular, KDL::Tree and KDL::Segment were designed with a strong assumption on the fact that the Kinematic Tree describing the robot is a directed Tree. This make sense for classical fixed-base robots, where a specific body is fixed to the ground (the so-called "base"). For floating-based robots,however, it sometimes makes sense to have a different base for different types of algorithms. For example, in the original use case of iDynTree described in Fumagalli, Ivaldi et al. [1] the base for the kinematic phase of the RNEA (the "black triangle" following the formalism in [1]) can be different from the base for the dynamic phase of the RNEA (the "black rhombus"). This leads us to develop our own data structures for modeling a Tree, grouped in the KDL::CoDyCo::UndirectedTree (soon to be migrated in iDynTree::UndirectedTree) class.
Similarly, several other data structures were not suited for floating base robots, so we then ended up in the uncomfortable situation where, for basic manipulation of geometric quantities, we are using a mix of KDL data structures and iDynTree ones. This leads (together with a general lack of documentation : ( ) to a situation where the design of the library is quite hard to understand for, with a lot of "lasagna code".

Bindings to other languages

Recently there have been several needs of using iDynTree data structures in several high level languages:

• For developing a basis stepping coordinator in Lua using rFSM, we needed some basic geometric classes. We ended up developing some custom classes in Lua [2] wasting time developing and debugging classes that are in general less robust and less efficient then the C++ one used in iDynTree, even if functionally equivalent.
• For doing data analysis (for example for inertial parameter identification) we always used the classes of iDynTree directly from C++. However for dataset loading, preprocessing and plot/analysis is highly desirable to use a proper high level language, such as Matlab or Python.
• @iron76 developed a prototype in Matlab of the new dynamics estimator that we plan to use on iCub. He did that using the spatialv2 matlab native dynamics library. If he had the possibility of directly using iDynTree function and classes, the transition to C++ would be much simpler.
• @ommac and @DiegoRomeres are really interested to work with dynamics regressors provided by iDynTree, but for several reason they need to do their offline processing in Matlab.

Considering this, it would make sense to provide bindings to several high level language for iDynTree classes. The language the community is more interested in at the moment are Lua, Python and Matlab. The easiest solution for providing these bindings is to use the SWIG tool [4] that recently has gained experimental Matlab support, thanks to the casadi project [5] [12].

SWIG and KDL use

However, SWIG is designed to wrap a library, but the usage of a lot of KDL types (that do not currently support SWIG) in the core headers could be a problem. Providing SWIG support itself to KDL would be a problem and would probably need some API breakage in KDL basic classes. In particular KDL includes Eigen headers in its own headers, and Eigen is an highly templated library that would probably cause a lot of issues if we try to wrap it with SWIG.
Even if we wanted to do this work to do the necessary changes to provide SWIG support in KDL, the KDL upstream maintainers have demonstrated to be a lot more concerned to preserve backward compatibility, so our patches would probably be rejected.

Providing our own basic classes

Considering the complication provided by using KDL, I think it could make sense to start implementing our own classes for the basic geometric entities such as point, vectors, wrenches, momentum, etc etc as we already did for more high level concept such as the UndirectedTree.
We can still provide KDL compatibility with appropriate conversion function such as toiDynTree and toKDL, for converting from KDL types to iDynTree types. In this way we can (slowly) move away from KDL dependency, while still maintaining all the legacy code.

List of Requirements

Given what we wrote in the previous sections, a possible list of desirable features for the iDynTree basic classes are:

1. They should be easily wrapped by SWIG, in any language.
2. They should be realtime safe, avoiding memory allocation unless in creation of structure with unknown size at compile time.
3. They should be easy to integrate with existing software.
4. They should be designed to avoid misuse, as much as possible.
5. They should be easy to use.

Design guidelines

Considering the features that we want for iDynTree classes, as a consequence we have the following design choices:

1. No external headers should be included in iDynTree classes public headers, perhaps except for basic STL datatypes (std::string ?). This type of encapsulation is usually done with the pimpl idiom, but requirement 2 (no malloc unless strictly necessary) is preventing us from using it, so data storage should be provided in private raw double arrays. Still depending on Eigen as PRIVATE header dependency [7] is ok, so operation on these arrays can be done efficiently in the implementation using the Eigen::Map [6] facilities.
2. As in 1., this means that we should avoid pimpl. For classes whose size is not known at compile time, constructors, destructors and resize methods should be the only non-realtime safe methods. Eigen provides several facilities to make sure to avoid memory allocation while manipulating matrices [8] [9].
3. Conversion function should be provided from and to Eigen, yarp and KDL datatypes.
4. This is the more critical point. The most basic way of ensuring this is at the algebraic level, by providing strictly defined classes and related operations. For example, if you express in your code a force f using the same Class that you use for representing a point vector, and you define the homogeneous transformation as a affine matrix transformation T = (R,p), a possible bug is that a user wants to rotate the force by the rotation provided in the homogeneous transformation, but if he simply computes T*f he will obtain as a result R*f+p, that is a sum of a force and a point. This kind of syntactical checks can be enforced by defining separated data types for point,force,torques,linear velocities, etc etc. However even if you ensure syntactical correctness, we can still do semantical errors in our code. For this reason, I think we should slowly insert also semantical checks in our basic data structures.
5. b another possible misuse is the use of overloaded operators for operations that allocate dynamical memory (that was the error done in yarp::sig::Vector). This operator overloading give to the user the false assumption that something is a "cheap" operation, even if it is an expensive one.

Semantics check

A good overview of the concept of semantical checks in geometric software is provided in
De Laet T, Bellens S, Smits R, Aertbeliën E, Bruyninckx H, and De Schutter J (2013), Geometric Relations between Rigid Bodies: Semantics for Standardization, IEEE Robotics & Automation Magazine, Vol. 20, No. 1, pp. 84-93. [10]
In that paper, the authors propose also a semantic model for the kinematic concepts (coordinates of points, velocities, twist) used in robotics software. Even if that model has some limitations and do not described dynamic quantities, I think it is a valuable starting point.

Unfortunately, their software implementation, described in:

De Laet T, Bellens S, Bruyninckx H, and De Schutter J (2013), Geometric Relations between Rigid Bodies: From Semantics to Software, IEEE Robotics & Automation Magazine, Vol. 20, No. 2, pp. 91-102. [11]

relies completely on templates and is not really user friendly, given that it does not provide the operator overloading for geometric operation that most user expect while manipulating geometric quantities. This is done for avoiding confusion in the use of the various operation, but it reduces the usability of the library. Given that programmers are lazy, and researcher programmers are even more lazy, we should try to incorporate semantics checking in the most not intrusive possible way.

Proof of concept

In pull request #28 I tried to implement the Position class (name taken from the Semantics for Standardization paper) following the requirements that I listed in the previous sections. A working Lua and Matlab interface, provided by SWIG, is also present in the proof of concept. Feedback are more than welcome.
If we are able to provide also a Orientation and Pose classes with some additional operation, we are already able to remove the custom class in Lua and use directly iDynTree classes.

[1] http://people.liralab.it/iron/Papers/journal/IvaldiFumagallietAl.pdf
[2] https://github.com/robotology/codyco-modules/blob/master/src/modules/graspAndStepDemo/lua/gas_funcs.lua
[3] https://github.com/iron76/bnt_time_varying
[4] https://github.com/swig/swig
[5] https://github.com/casadi/casadi/wiki/matlab
[6] http://eigen.tuxfamily.org/dox/group__TutorialMapClass.html
[7] http://www.cmake.org/cmake/help/v3.0/command/target_include_directories.html
[8] http://eigen.tuxfamily.org/dox/TopicWritingEfficientProductExpression.html
[9] http://eigen.tuxfamily.org/index.php?title=FAQ#Where_in_my_program_are_temporary_objects_created.3F
[10] http://people.mech.kuleuven.be/~tdelaet/geometric_relations_semantics/geometric_relations_semantics_theory.pdf
[11] http://people.mech.kuleuven.be/~tdelaet/geometric_relations_semantics/geometric_relations_semantics_software.pdf
[12] casadi/casadi#176

We have test at least for Python bindings (geometry.py) .. we should run them on Travis to catch regressions such as #47 (comment) .

• .ReverseSign
• .operator+=

Error encountered while running the new MATLAB bindings example with identifiable subspace computation:

Error using iDynTreeMATLAB_wrap
No function id 299.

Error in iDynTree.DynamicsRegressorGenerator/computeFixedBaseIdentifiableSubspace
(line 85)
      [varargout{1:max(1,nargout)}] =
      iDynTreeMATLAB_wrap(299,'DynamicsRegressorGenerator_computeFixedBaseIdentifiableSubspace',self,varargin{:});

Error in SwigRef/subsref (line 26)
      [varargout{1:nargout}] = builtin('subsref',self,S);

Error in parametric_id_subs_example (line 90)
regrGen.computeFixedBaseIdentifiableSubspace(identifiableSubspacesBasis);

Issue to be filled as a todo - feature request for matlab bindings (maybe also c++ / other bindings)

• cross operator (which returns a matrix)

@fiorisi reported a case in which a URDF Chain was converted to a DH with a non-identity H0, even if the DH chain could be expressed with a identity H0.