Six Axis Force Torque sensor considers the translation of the sensor, but this is not documented

[traversaro]

While reviewing the FT code for https://github.com/robotology/codyco-modules/issues/200 , I noticed several issues in the code handling six axis F/T sensors in iDynTree. Note: this issue only focuses on new KDL-free classes.

• The docs on how to load sensors from URDF files say that only the orientation part of the pose of a F/T sensor is actually considered, similarly to what it is done in SDF (see https://github.com/robotology/idyntree/blob/master/doc/model_loading.md). Apparently in the code also the translational part is considered (see https://github.com/robotology/idyntree/blob/master/src/model_io/urdf/src/URDFGenericSensorsImport.cpp#L193 and https://github.com/robotology/idyntree/blob/master/src/model_io/urdf/src/URDFGenericSensorsImport.cpp#L423). While that may be convenient, we need to take a decision on which format support and properly document it.
• The API of the SixAxisForceTorqueSensor class has been designed with the assumption that the transforms between the sensor frame and the frame of the link to which the sensorized joint are attached do not depend on the joint state, i.e. the joint is fixed. At the moment this requirement is not properly enforced in the parser. We can fix this issue in two ways:
  • Modify the SixAxisForceTorqueSensor to account for the joint pose, and correctly work for non-fixed joint. This involves a bit of work, as the SixAxisForceTorqueSensor is quite used in the iDynTree source. However strictly speaking is the only way of being compatibly with the SDF spec, and unfortunately a lot of robot humanoid models out there actually model F/T sensors as attached to a moving joint.
  • Modify the parser to enforce the fact that a SixAxisForceTorqueSensor can only be attached to a fixed joint. This is much easier, but then to get the estimation to work on the Walkman model we would need to modify the model to model the F/T sensors as a fixed joint, or to manually modify ourself the model. The second option is quite undesirable as it is brittle.

cc @DanielePucci @gabrielenava

[diegoferigo]

Related sdformat issue: https://bitbucket.org/osrf/sdformat/issues/130/position-part-of-force_torque-sensor-pose .

[gabrielenava]

FYI @ahmadgazar

[traversaro]

Related sdformat issue: https://bitbucket.org/osrf/sdformat/issues/130/position-part-of-force_torque-sensor-pose .

Related issue after GitHub migration: https://github.com/gazebosim/sdformat/issues/130 . This affected us in https://github.com/icub-tech-iit/ergocub-software/issues/146 .