search

roboticslab-uc3m / yarp-devices

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

Map controlled joints to motor ids in raw subdevices #171

Closed jgvictores closed 4 years ago

jgvictores commented 6 years ago

Maybe enforcing passing index 0 to raw wasn't a great idea, and passing the actual int was a good idea for debugging.

Possibly related: #162 ...or not. What I refer to is that looking at fakeMotionControl implementation, there was a template mechanism, etc. We should look at this for inspiration before doing anything there.

Marking as blocked by #162 for now, but not sure.

jgvictores commented 5 years ago

Not really blocked by #162.

Raising priority, can perhaps be a real solution to DextraHand semi-tracked at #176

PeterBowman commented 5 years ago

Not really blocked by #162.

On a bigger picture, IMHO it'd preferable having https://github.com/roboticslab-uc3m/yarp-devices/issues/162, https://github.com/roboticslab-uc3m/yarp-devices/issues/20 and https://github.com/roboticslab-uc3m/yarp-devices/issues/74 solved prior to starting the CAN-enabled version of https://github.com/roboticslab-uc3m/yarp-devices/issues/176. Not sure yet how these parts will play together and I'm sorry that it's taking so long at #162 (a YARP upstream PR originated from that); as spoken 🎅2🎅, I'm interested in the overall goal and willing to work on it.

jgvictores commented 5 years ago

On a bigger picture, IMHO it'd preferable having https://github.com/roboticslab-uc3m/yarp-devices/issues/162, https://github.com/roboticslab-uc3m/yarp-devices/issues/20 and https://github.com/roboticslab-uc3m/yarp-devices/issues/74 solved prior to starting the CAN-enabled version of https://github.com/roboticslab-uc3m/yarp-devices/issues/176. Not sure yet how these parts will play together and I'm sorry that it's taking so long at #162 (a YARP upstream PR originated from that); as spoken 🎅2🎅, I'm interested in the overall goal and willing to work on it.

Agreed, I've updated their priority labels and marking as blocked by them.

PeterBowman commented 5 years ago

Switching block status and updating title. This issue aims to enable single CanBusControlboard subdevices as control boards on their own that wrap another set of subdevices. Such case arised with https://github.com/roboticslab-uc3m/yarp-devices/issues/176: the Dextra hand would act as a single CAN node, but up to six embedded motor joints need to be individually controlled. Considering the approach detailed in https://github.com/roboticslab-uc3m/yarp-devices/issues/211, such parent device would be given the board role. Our current FakeControlboard shall become the fake counterpart of the future DextraControlboard device (https://github.com/roboticslab-uc3m/yarp-devices/issues/192).

PeterBowman commented 4 years ago

This issue aims to enable single CanBusControlboard subdevices as control boards on their own that wrap another set of subdevices

Not sure this was my original intention - CanBusControlboard's subdevices might be indeed control boards on their own (see DextraCanControlboard at https://github.com/roboticslab-uc3m/yarp-devices/issues/227), but they are not intended for hosting an additional layer of raw devices (well, they tecnically can do that, but this fact should not be known to the wrapping CanBusControlboard).

I'm dropping the board role proposal in favor of exploiting the most from standard YARP motor intefaces. Per the original intention expressed by OP, this issue should aim to enhance the id mapping mechanism, see https://github.com/roboticslab-uc3m/yarp-devices/issues/211#issuecomment-532196134 and https://github.com/roboticslab-uc3m/yarp-devices/issues/211#issuecomment-533285551:

Next (and probably last) big step here: implement some sort of LUT within CanBusControlboard to map exposed joint indexes (e.g. like the j in positionMove(j, ref)) to motor ids controlled by raw subdevices. For instance, if we open three raw devices A, B and C, where A controls two joints, B three, and C one joint respectively, then CanBusControlboard::positionMove(4) should map to B::positionMoveRaw(2). For comparison, check the subdevice mechanism at ControlBoardWrapper.

PeterBowman commented 4 years ago

Ready at https://github.com/roboticslab-uc3m/yarp-devices/commit/de805265a89fb86e4b5defe7727cbb5849645336. Now, CanBusControlboard maps all known motor interfaces understood by ControlBoardWrapper (see inheritance diagram) , whereas raw CAN subdevices use all group commands (previously not implemented, e.g. positionMove(double *) or positionMove(int, const int *, double *)).

PeterBowman commented 4 years ago

Follow-up: this helper tool has been refactored into its own library, DeviceMapperLib, and thoroughly covered by unit tests in testDeviceMapperLib.cpp. See also https://github.com/roboticslab-uc3m/yarp-devices/issues/230 regarding parallelization.