Making the integration specific to each control variable

[olivier-stasse]

With some recent changes related to roscontrol-sot, there is a need to make the integration specific to each value of the control vector. For instance with Talos, the gripper are only control on position, where we can control the other actuator either in position or in effort. This changes the way the state vector needs to be handled.

[olivier-stasse]

Dear all,
I propose a fix to this issue in branch topic/device. This a kind request for feedback.

• The device Class is now reading a URDF file and is waiting for information to map the SoT and the hardware. The unit test shows how to do that with a YAML file. With roscontrol-sot this could be automatize according to the robot interface.
• Each device can have a separate control variable (position,velocity,torque,current) and a hardware interface (position,velocity,torque,current). velocity (SoT) -> position (HW) is fine, velocity/acceleration (SoT) -> position/velocity (HW) should also be fine. current/torque (SoT)-> current/torque (HW) should not be a problem. current/torque (SoT) -> position (HW) although possible would imply an actuator model.
• There is the need to provide an explicit mapping to the control vector (currently only one mixing every joints), the position vector, the velocity vector and the acceleration vector. The seperation between the two laters might be overkilled.
• The implementation of joints is redundant with pinocchio. There is already a dependence to pinocchio.
  We can keep that way, or fully integrate pinocchio. But this will push for a wider integration of sot-dynamic-pinocchio. Personnally pinocchio comes with a full set of dependencies which might not be needed for sot-core. Another possibility is to move this device to sot-dynamic-pinocchio. Again remarks, comments are welcome.

Let me know what you think about all those points.

[jmirabel]

Another possibility is to move this device to sot-dynamic-pinocchio.

I think it is a good idea.

The implementation of joints is redundant with pinocchio.

So we should probably remove the redundancy. I guess you still need a way of storing some data for each joint. Given the architecture of Pinocchio, I would say the simplest is to develop a algo in Pinocchio style for this. There will be the tricky issue of RPY / Quaternion conversions.

Otherwise, it is a good thing that robot dependent data are read from text files.

[olivier-stasse]

Thank you very much Joseph for your comments.
Therefore I think I will probably move this new version of device in sot-dynamic-pinocchio.