Derive from concrete YARP classes instead of providing custom implementation

[PeterBowman]

YARP's fakeMotionControl device inherits from several ImplementX concrete classes, e.g. ImplementVelocityControl2, a ready-to-use implementation of IVelocityControl2. See inheritance diagram in fakeMotionControl's docs. I wonder if we could use this in our CAN devices to spare a few lines of code.

[jgvictores]

Blocking #171

[PeterBowman]

Note to self: take a look at http://www.yarp.it/classyarp_1_1dev_1_1ControlBoardHelper.html (perhaps for internal use only).

[jgvictores]

Does not really block #171

[PeterBowman]

This WIP led to robotology/yarp#1867, another PR is coming.

[jgvictores]

Blocks #171.

[PeterBowman]

Might render invalid due to #211.

[PeterBowman]

For instance, if we take a look at ImplementControlLimits.h, there are two interfaces:

• StubImplControlLimitsRaw: targets a Raw device, provides a stub implementation that prints an error notice and returns false. The only place I could use these interfaces is CuiAbsolute, leaving here my abandoned commit for future reference: cc80172. Superseded by Clean CAN raw subdevice interfaces #211.

• ImplementControlLimits: comprises an cpp counterpart (ImplementControlLimits.cpp) that performs basic mapping and call forwarding to raw devices assuming a correct initialization. Could be implemented in:

  • FakeControlboard: probably going to be removed with Migrate FakeControlboard's JMC to FakeJoint #192.
  • CanBusControlboard: currently performs simple routing, but I have a major rework in mind involving CAN reads&writes (Reroute CAN write calls to controlboard device #209). Would require implementing currently omitted methods in the raw device implementations.

The CanBusControlboard thing could be revisited in the future if #209 cannot be done. Closing for now as WONTFIX.