Pass shared handle from AmorControlboard to AmorCartesianControl

[PeterBowman]

Split from https://github.com/roboticslab-uc3m/yarp-devices/issues/150:

This device would take care of joint space control, whereas cartesian space-related commands have been already split to a AmorCartesianControl device at kinematics-dynamics. The point here is that the AMOR API requires all of its methods to accept a robot handle as a parameter, which means that it's not possible to issue commands to the remote control board like it's carried out by BasicCartesianControl. In contrast to usual remotecontrolboard/controlboardwrapper2 client/server pair implementations, both devices (joint and cartesian space controllers) must be launched on the same machine that is physically connected to the robot. As commented in https://github.com/roboticslab-uc3m/yarp-devices/issues/74#issuecomment-302581336, we could sort this out by passing a handle pointer via YARP properties, using the blob data type. I wonder if I should pass a mutex to lock that handle, too.

The pointer is already passed on in this way:

https://github.com/roboticslab-uc3m/yarp-devices/blob/bedcf3d414d0ee8d6f5353427d018f8745c49f7b/libraries/YarpPlugins/AmorControlboard/DeviceDriverImpl.cpp#L82-L91

Here is the remote part. I recall not being able to start the cartesian controller successfully. Testing required.

[PeterBowman]

I wonder if I should pass a mutex to lock that handle, too.

Note to self, the scope of this issue might go beyond simple testing.

[PeterBowman]

Device initialization fixed at https://github.com/roboticslab-uc3m/yarp-devices/commit/2a7459a7f695752c98e0334fbeafca3a86aae41c. We control this with the cartesianControllerName parameter, i.e. no such param = AmorCartesianControl is not opened. Also, parameters to AmorControlboard are propagated to AmorCartesianControl, such as kinematics file and other options. Example invocation:

yarpdev --device AmorControlboard \
        --name /amor \
        --cartesianControllerName /amor/CartesianControl \
        --kinematics /usr/local/share/amor/contexts/kinematics/armKinematics.ini \
        --angleRepr RPY \
        --fkPeriod 0 \
        --period 500

Note that AToW we need to disable the FK stream port due to persistent timeouts (--fkStream 0). For the same reason, it's best to reduce the interval between state calls issued by YARP's control board wrapper (--period <random high number>). Therefore, I'm marking this issue as blocked by #150. Once unblocked, care must be taken to avoid race conditions.

[PeterBowman]

Done, see linked commits. I did not test this. Some C++17 magic was used to avoid excessive code bloat due to mutex locking blocks.