Introduce universal CAN/serial motor control devices

[PeterBowman]

Issue #234 led to a short discussion on future plans regarding firmwares and their wrapping YARP devices. Short summary at #234 (comment) (points at WIP apocanlypse branch):

• DextraCanControlboard: position-controlled CAN device, inherits from DextraRawControlboardLib

• DextraSerialControlboard: position-controlled serial device, uses DextraRawControlboardLib via class composition

• LacqueyFetch: PWM-controlled CAN device, implementation ready at Clean CAN raw subdevice interfaces #211

• TextilesHand: position-controlled serial device, will be repurposed as a control board on its own in the scope of the present issue

Things could go a bit further. Work with low-level firmware usually flows upstream: first, a protocol is established for device-to-PC comms and coded into the firmware, i.e. everything that needs to go on whatever board you decided to use (e.g. Arduino, Teensy, Raspi..., see #234 (comment)); then, you wrap the same protocol in a YARP device named after the specific hardware you are going to command. That's why we have a LacqueyFetch YARP device to interface with the Mbed onboard the Lacquey hand, a TextilesHand YARP device to communicate with the Arduino that governs both servomotors of the Textiles hand, and so on. This leads to a proliferation of devices which share a similar funcionality, yet cannot understand each other since a different protocol is implemented.

The opposite, "downstream" approach is disclosed here. Let's make a generic, master YARP device that implements PWM, torque, velocity, position, etc. interfaces (yet to be decided). The goal here is to cover the wide range of motor command types that can be issued on different boards, such as PWM commands (Lacquey), position commands (Textiles), etc. Alternative interfaces are allowed, i.e. some devices might map position commands to PWM commands if supported and expose them to the YARP user, whereas the same protocol is enforced on the device-to-firmware dataflow. This protocol is key for generalizing said master device and developing specific firmware that adheres to it. In consequence: one YARP device capable of ruling all (usual) firmwares out there in the wild.

Actually, two such devices are probably needed for this purpose plus a helper library, given that we want to enforce this protocol both in CAN raw subdevices (orchestrated by CanBusControlboard) and serial, stand-alone control boards. The Dextra device referenced above shows the right path to follow: a common DextraRawControlboardLib library is either inherited from or reused by composition in the actual devices, DextraCanControlboard and DextraSerialControlboard respectively. Since the Synapse protocol is quite Dextra-specific and alien to us, these Dextra devices should be kept.

[jgvictores]

Regarding Serial comms, it would be great to unify. In DextraSerialControlboard we are using YARP serialport (

yarp-devices/libraries/YarpPlugins/DextraSerialControlboard/DeviceDriverImpl.cpp

Line 20 in cfd8d88

serialOptions.put("device", "serialport");

) and this is a good option as it is multi-platform (this is achieved via ACE; at robotology/yarp#2087 (comment) https://github.com/wjwwood/serial is mentioned as an alternative from which we would benefit). Note that in RD we rely on libserial-dev (asrob-uc3m/robotDevastation-user-manual@90acc70) which requires a POSIX system.