robotology-legacy / kdl_codyco Goto Github PK

References:

• http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=531387&tag=1
• http://www.ece.uvic.ca/~wslu/Publications/Lu-Journal/Paper114.pdf
• http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6696688
• http://www.intechopen.com/download/get/type/pdfs/id/11048

The data structure used for nearly all the algorithms in kdl_codyco is named "TreeGraph", that does not mean anything .
To avoid generating confusion in the users it should be renamed UndirectedTree, that make immediately clear the main difference between KDL::CoDyCo::UndirectedTree and KDL::Tree (which instead is a directed tree).

Within the iCub users, some people do not "make install". Binaries and include are copied by the default compilation config in the "current build" directory. The associated directory "bin" is added to the path. Include files are resolved thanks to the environment variable $ICUB_DIR. kdl_codyco and orocors_kdl are instead included thanks to the EXPORT_PACKAGE functionality of cmake. This second option is not compatible with shared home-directories (currently used in certain iCub setup) and this poses issues to be solved if we want to maintain shared home-directories.

Currently all the implementation of subtree related algorithms (subtree regressors, iDynTreeContact) are implemented using custom (and thus error-prone) code. We should migrate them to using SubTreeTraversal and appropriate loops.

If CMAKE_INSTALL_PREFIX is local it is necessary to manually specify kdl_codyco_DIR .

Handling parts should be done with subTree traversal or in other ways, but without polluting data structures (UndirectedTree) or solver/loops (getCOM related loops) with stuff related to partitioning.

Add subtree specific version of the KDL::CoDyCo::Traversal class to execute the same loops on the full tree (using an UndirectedTree and a "complete" KDL::CoDyCo::Traversal) and on the subtree (using an UndirectedTree and a "subtree" KDL::CoDyCo::Traversal) .

There is a bug in dynamicRegressorGenerator that has en effect on the regressor for the estimation of a torque from the internal F/T sensors.

The concept of "proper" acceleration is not clear among the average user.

Document the design choice of Serialization, employed in all the Solvers and that are based on TreeSerialization and TreeSerialSolver.

Currently, UndirectedTree cannot be obtained from KDL::Tree objects that do not have a proper first link (i.e. that have a first link without inertia. Fix this.

The library is not correctly linked in Windows in Debug mode.

The algorithm current implemented seems to be suboptimal. Find or elaborate a more efficient algorithm.

10>C:\Program Files\kdl_codyco\include\kdl_codyco/ftsensor.hpp(266): warning C4018: '<' : signed/unsigned mismatch

A good strategy could be refactoring existing test to execute with arbitrary models loaded with kdl_format_io library.

Currently no information about the position/orientation of the base link with respect to the world is considered in the solver/loops.
While not necessary for dynamics (if initial velocity/acceleration and residual wrench is expressed in base link reference frame), this is a common requirement for a lot of tasks (floating base jacobians, floating base mass matrix) and is actually implemented as a workaround in iDynTree (and consequently in the yarp implementation of the iWholeBodyModel interface.
To avoid errors, improve efficiency and expose base_world functionality also in kdl_codyco solvers is would make sense to move this base world position/orientation logic in kdl_codyco solvers/loops.
Current functionality would be preserved by setting input world_base transformation to the identity.
To avoid the explosion of the number of input parameters it could make sense to define a "FloatingBasePosition := KDL::Frame X KDL::JntArray" object and a "FloatingBaseMotion := KDL::Twist X KDL::JntArray" .

The subtree regressor equation can be written in an arbitrary (plucker) reference frame. While the formulation is equivalent from the dynamics point of view, it is not equivalent from the identification point of view, because the relation between the noise of the sensors and the noise in the equation is affected by the frame placement.
In the meanwhile that this ambiguity is solved from the scientific point of view, leave to the user the possibility do define the plucker frame for the subtree regressor (currently it is fixed to the base of the robot tree). The choice should be given between sensor frames or link frames (eventually with an additional fixed transformation).

Issue to track the implementation of the Operational-Space Inertia matrix.
Useful reference of a recent paper on a new algorithm to compute the Operational-Space Inertia Matrix, with pointers to previous algorithms: http://www2.ece.ohio-state.edu/~wensingp/Papers/WensingFeatherstoneOrin12-ICRA.pdf .

Probably also a less elaborate algorithm (as the Rodriguez or the old Featherstone one) with respect to the one presented in the paper is ok to implement.

Unit test to write: check implemented algorithm output with OSI calculated with the classical formula JH^{-1}J^T .

cc @EnricoMingo

Note to self: probably a good example to start introducing interfaces also on low level loop functions.