Bind multiple CAN channels to raw subdevices

[PeterBowman]

The CanBusControlboard device handles one single CAN channel. The specific CAN board implementation is requested on runtime via YARP interfaces (since #158). This CAN channel is exposed in the YARP network thanks to a X-bus-devices-to-Y-wrappers architecture (currently 1-to-1 via OneCanBusOneWrapper and 2-to-3 via TwoCanBusThreeWrappers). However, if we ever wanted to launch this device locally (instantiate this one instead of remote_controlboard), YARP would not help us reaching other available channels.

Immediate use case: gait/bimanipulation apps, cartesian controllers which need to command a tree-structured kinematic chain simultaneously and in a local fashion.

[jgvictores]

Could an alternative approach be taken via ControlBoardRemapper as commented at #20 (comment)?

[PeterBowman]

Could an alternative approach be taken via ControlBoardRemapper as commented at #20 (comment)?

We can do this already, i.e. launch as many CanBusControlboard's (CBC) network wrappers as we need and then proxy motor interface calls through ControlBoardRemapper so that commands such as positionMove() range 0-n (where n = 27 for whole body joint control, not accounting for grippers) instead of 0-5.

Immediate use case: gait/bimanipulation apps, cartesian controllers which need to command a tree-structured kinematic chain simultaneously and in a local fashion.

I stemmed this issue from #20 (comment) precisely concerning a locally instantiated CBC. Unless you open as many CBCs as CAN buses you are going to use, your application will not be able to behave as it would by means of the ControlboardRemapper.

[jgvictores]

The CanBusControlboard device handles one single CAN channel. The specific CAN board implementation is requested on runtime via YARP interfaces (since #158). This CAN channel is exposed in the YARP network thanks to a X-bus-devices-to-Y-wrappers architecture (currently 1-to-1 via OneCanBusOneWrapper and 2-to-3 via TwoCanBusThreeWrappers). However, if we ever wanted to launch this device locally (instantiate this one insted of remote_controlboard), YARP would not help us reaching other available channels.

F*-genius. If this does what I'm currently understanding, it renders most of my previous comments regarding ControlBoardRemapper obsolete.

[PeterBowman]

Ready at 187a238 in conjunction with roboticslab-uc3m/teo-configuration-files@d6c28b2.