Map controlled joints to motor ids in raw subdevices

[jgvictores]

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]

Not really blocked by #162.

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

[PeterBowman]

Not really blocked by #162.

On a bigger picture, IMHO it'd preferable having #162, #20 and #74 solved prior to starting the CAN-enabled version of #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]

On a bigger picture, IMHO it'd preferable having #162, #20 and #74 solved prior to starting the CAN-enabled version of #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]

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 #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 #211, such parent device would be given the board role. Our current FakeControlboard shall become the fake counterpart of the future DextraControlboard device (#192).

[PeterBowman]

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 #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 #211 (comment) and #211 (comment):

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]

Ready at de80526. 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]

Follow-up: this helper tool has been refactored into its own library, DeviceMapperLib, and thoroughly covered by unit tests in testDeviceMapperLib.cpp. See also #230 regarding parallelization.