Add different target and sensors type in HumanStateProvider

[lrapetti]

This PR implement the possibility of using different type of wearable sensors and associate them with different sensors type (https://github.com/robotology/human-dynamics-estimation/issues/273).

Currently the following sensor/targets type have been implemented:

• wearable sensors (see https://github.com/robotology/human-dynamics-estimation/pull/274/commits/9ee3ff1475946c1a446d19209b50ad3c6aec41a0#diff-3daa57ee2a77e48985ef2075ff08d8b318f9e9c67fd813230473f4492cf19fd1R1571-R1650)
  • PoseSensor
  • VirtualLinkKinSensor
• target types (https://github.com/robotology/human-dynamics-estimation/pull/274/commits/8848414d6498dc8147235ae31c91f956078715f6#diff-3daa57ee2a77e48985ef2075ff08d8b318f9e9c67fd813230473f4492cf19fd1R119-R127)
  • pose,
  • poseAndVelocity,
  • position,
  • positionAndVelocity,
  • orientation,
  • orientationAndVelocity

Before merging:

• [x] Fix and test the calibration methods
• [ ] Fix global IK
• [ ] Fix Pairwised IK
• [ ] Final clean-up and remove deprecated code

After merging:

• Align configuration files in other repos
  • component_ifeel

[lrapetti]

With https://github.com/robotology/human-dynamics-estimation/pull/274/commits/2d9da1112a027ae522935780bb74f4012054784e I am adding to this PR the possibility to pass from configuration file both a left and a right rotation transform to apply to the measurements. Those can be defined using the following group parameters name:

• MEASUREMENT_TO_LINK_ROTATIONS is the right rotation (that is replacing the already existing option FIXED_SENSOR_ROTATION)
• WORLD_TO_MEASUREMENT_ROTATIONS is the left rotation

[lrapetti]

• [x] Fix and test the calibration methods

This point have been addressed. Note that, however, in https://github.com/robotology/human-dynamics-estimation/pull/274/commits/c1b03635943422e5f23def005a00b11fe7262fa3 I have removed two calibration methods that currently were not used:

• calibrate <linkName> (this method is basically equivalent to calibrateRelativeLink, the difference is that you have to specify the parent link rather then having it automatically chosen from end-effector pairs)
• calibrateSubTree (note also that this method is still not properly working for all the models, see https://github.com/robotology/human-dynamics-estimation/issues/208#issuecomment-666505443)

[lrapetti]

• [ ] Fix Pairwised IK

Since we are now enabling the possibility of having multiple targets for the same links and we are adding also position sensors (that can not be taken into account by using reduced models only), I think we can think of deprecating the pairwise IK methods since it is not straightforward to align it with the new changes.

What do you think @S-Dafarra @kouroshD?

A similar problem exists for the Global IK, we can not define multiple targets for the same link, but in this case I would try to maintain it for the case in which multiple targets are not defined for the same link.

[S-Dafarra]

• [ ] Fix Pairwised IK

Since we are now enabling the possibility of having multiple targets for the same links and we are adding also position sensors (that can not be taken into account by using reduced models only), I think we can think of deprecating the pairwise IK methods since it is not straightforward to align it with the new changes.

What do you think @S-Dafarra @kouroshD?

A similar problem exists for the Global IK, we can not define multiple targets for the same link, but in this case I would try to maintain it for the case in which multiple targets are not defined for the same link.

I think that's ok to deprecate it, also because until now we did not find a case where it was working better

[lrapetti]

Closing this PR for the time being. To be reopened once all the required changes are completed.