roboticslab-uc3m / yarp-devices

A place for YARP devices
https://robots.uc3m.es/yarp-devices/
9 stars 7 forks source link

Develop CAN Dextra device #227

Closed PeterBowman closed 4 years ago

PeterBowman commented 5 years ago

Follow-up to https://github.com/roboticslab-uc3m/yarp-devices/issues/176. Currently implemented as a serial device at DextraSerialControlboard, most code should be refactored and reused in its CAN-counterpart device. In fact, serial comms take a role in the Synapse class only, in which the protocol is enforced and the messages are actually formed and sent away using a handle to the locally instantiated serial device.

First, the CAN device would have to re-implement the Synapse class to handle CAN comms. Same protocol, 8-byte messages, a handle to a CAN TX broker class (the CAN device might be created externally, see https://github.com/roboticslab-uc3m/yarp-devices/issues/209).

This device should consider the proposed role system: https://github.com/roboticslab-uc3m/yarp-devices/issues/211. A board role implies that the device implements raw motor interfaces (e.g. IPositionControlRaw, contrary to IPositionControl as currently used in the serial device).

For refactorization purposes, I might consider moving the serial implementation to raw interfaces and expose it through a new wrapper. Reminds me of the TextilesHand device: you can only launch it by means of the CanBusControlboard device, same as the hereby proposed Dextra CAN device, but no CAN comms are involved (it is, in fact, another serial device). Should the CanBusControlboard be able to launch the Dextra serial device?

PeterBowman commented 5 years ago

For refactorization purposes, I might consider moving the serial implementation to raw interfaces and expose it through a new wrapper. Reminds me of the TextilesHand device: you can only launch it by means of the CanBusControlboard device, same as the hereby proposed Dextra CAN device, but no CAN comms are involved (it is, in fact, another serial device). Should the CanBusControlboard be able to launch the Dextra serial device?

I'm prone to restrict usage of "raw" devices so that they can only be instantiated by a master device - our CanBusControlboard. This latter is responsible for managing CAN (real or fake) comms, therefore all CAN-enabled raw subdevices may not perform any reads/writes without its enclosing wrapper and standalone instantiation is forbidden.

This approach would enforce several changes in certain apps, for instance, exampleTechnosoftIpos.cpp.

PeterBowman commented 5 years ago

Device implementation ready at https://github.com/roboticslab-uc3m/yarp-devices/commit/ce83d80f30c2d5946049e565bfaef21883c7c2d9. I did not implement CAN reads, though, since there is no data being published by the Dextra firmware AToW. Still waiting for https://github.com/roboticslab-uc3m/yarp-devices/issues/171 to make this usable on a CanBusControlboard setup.