Expose actuator commands in gripper-like subdevices

[PeterBowman]

Stemming from https://github.com/roboticslab-uc3m/yarp-devices/issues/211, it would be nice to enable some sort of self-description behavior to grippers: LacqueyFetch, TextilesHand and Dextra+CAN (https://github.com/roboticslab-uc3m/yarp-devices/issues/227).

PR https://github.com/roboticslab-uc3m/kinematics-dynamics/pull/181 introduced an actuator command to our cartesian controller interface. This command accepts a vocab describing one of several possible action. In https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/115#issuecomment-518304080, I propose that gripper devices could expose their supported actions, and act upon them when requested, via IRemoteVariables.

For simpler devices, the vocab list could live in a header. Cons: might easily become out-dated from time to time, it's virtually impossible to cover all possible use cases for actuators - not just mere grippers. Also, not sure what to do with AMOR, whose gripper implementation is embedded in the cartesian controller itself.

For Dextra, keep in mind the forthcoming translator device/tool (what I used to call IK).

[PeterBowman]

Robot tools of all kinds, especially grippers and more complex hands, could be interfaced on the YARP network through a dedicate port in which the only motor nodes exposed are the ones used by the tool itself: https://github.com/roboticslab-uc3m/yarp-devices/issues/211#issuecomment-532196134. In contrast, we currently control six joint motors and one Lacquey motor via the same /teo/leftArm port, for instance.

This separation clears the path for wrapping complex behavior in dedicated client devices which implement the specific behavior for the gripper type it is meant for. In other words, to illustrate this:

• CanBusControlboard handles the YARP-motor-id-to-CAN-node-id association, manages all CAN traffic and instantiates the raw subdevice.

• The raw subdevice (e.g. LacqueryFetch or DextraCan) assings all motor ids it needs per CAN id (Dextra is a multi-joint device in that one CAN node controls six motors) and forwards motor commands to the physical device.

• The YARP controlboard wrapper maps motor ids to YARP ports. For the sake of this example, let's say that we configure our launcher app via .ini to create a controlboardwrapper2 per hand, that is, it will open a /teo/leftHand with six motor joints (same for the right hand).

• A new client device could connect to these YARP ports and expose a gripper-specific C++ interface in which handy commands are available, say, openHand(), makeGesture() and so on. Regarding the Dextra hand, this same device could properly handle the subactuation problem: translate motor commands to finger joint angles and vice versa.

• This additional client layer would help us abstracting the higher-level control of devices which are managed differently on the lower-level layer: the real Dextra exposes six motor ids versus the OpenRAVE controller exposes fifteen joints.

Since the physical implementation is transparent to this client layer, the IRemoteVariables interface would render useful in identifying whether the remote device is actually the gripper type the client device is trying to connect to.

[PeterBowman]

• A new client device could connect to these YARP ports and expose a gripper-specific C++ interface in which handy commands are available, say, openHand(), makeGesture() and so on.

This can be nicely done with Thrift, e.g. see our SpeechIDL and its server implementation.