search

roboticslab-uc3m / yarp-devices

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

Bind multiple CAN channels to raw subdevices #226

Closed PeterBowman closed 4 years ago

PeterBowman commented 5 years ago

The CanBusControlboard device handles one single CAN channel. The specific CAN board implementation is requested on runtime via YARP interfaces (since https://github.com/roboticslab-uc3m/yarp-devices/pull/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 commented 5 years ago

Could an alternative approach be taken via ControlBoardRemapper as commented at https://github.com/roboticslab-uc3m/yarp-devices/issues/20#issuecomment-371225766?

PeterBowman commented 5 years ago

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 https://github.com/roboticslab-uc3m/yarp-devices/issues/20#issuecomment-350469935 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 commented 4 years ago

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 commented 4 years ago

Ready at https://github.com/roboticslab-uc3m/yarp-devices/commit/187a2385134796d99b8ee3c51f4a5b2a9c4a7e6d in conjunction with https://github.com/roboticslab-uc3m/teo-configuration-files/commit/d6c28b2438160227263b9eb74e3e7ea9ac58a212.