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" .
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" .