Yarp: Make sure that all ControlBoardRemapper methods exploit all the multi-joint capabilities of the underlying devices

[valegagge]

In ControlBoardRemapper, each API is implemented invoking the equivalent single joint API of motion control device. In case the motion control device (such as EmbObjMotionControl) is able to parallelize the requests for multiple joints, the controlBoardRemapper doesn't benefit of this feature.

Therefore I suggest to improve theControlBoardRemapper in order to benefit of parallelization.
If this improvements is not possible (or currently is not possible), I suggest to add a note to ControlBoardRemapper about this metter.

cc @traversaro

[traversaro]

In ControlBoardRemapper, each API is implemented invoking the equivalent single joint API of motion control device.

I think this actually depends on the method: methods such as setPositions or setRefTorques do properly use all the multi-joint capabilities of the underlying devices, while methods such as setPids indeed need to be updated.

[traversaro]

cc @DanielePucci this can affect the gain scheduling latency in walking and whole body control related code.

[traversaro]

@valegagge I edited the title to be a bit more descriptive, feel free to edit it back!

[PeterBowman]

This gist was used in https://github.com/robotology/yarp/pull/2473 to demonstrate joint mapping between a wrapper and its subdevice as of YARP 3.4.2, be it a ControlBoardWrapper+subdevice, a ControlBoardWrapper+ControlBoardRemapper+subdevice, or a ControlBoardRemapper+subdevice arquitecture. The latter might be of interest for the subject under discussion in this issue.

Is this request oriented towards e.g. making wrapper's setPids(const PidControlTypeEnum&, const Pid*) call the wrapped subdevice's setPids(const PidControlTypeEnum&, const Pid*) method instead of iterating over individual joints with setPid(const PidControlTypeEnum&, int, const Pid&)? Having https://github.com/robotology/yarp/pull/2473 in mind, I would vote against this proposal because of the rationale described in https://github.com/robotology/yarp/pull/2473, in case a joint remapper of this kind shall be a solution for targeting too many joints on the subdevice side.

PS I'm aware it sounds pretty tedious, but what about adding more multi-joint methods in the motor control interfaces? For instance, there is no such signature for setPids nor many others.