Pass shared handle from AmorControlboard to AmorCartesianControl

[PeterBowman]

Split from #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 #74 (comment), 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:

yarp-devices/libraries/YarpPlugins/AmorControlboard/DeviceDriverImpl.cpp

Lines 82 to 91 in bedcf3d

	std::string subdevice = "AmorCartesianControl";
	yarp::os::Value vHandle(handle, sizeof handle);
	yarp::os::Property cartesianControllerOptions;
	cartesianControllerOptions.put("device", "CartesianControlServer");
	cartesianControllerOptions.put("subdevice", subdevice);
	cartesianControllerOptions.put("handle", vHandle);
	cartesianControllerOptions.setMonitor(config.getMonitor(), subdevice.c_str());
	cartesianControllerDevice.open(cartesianControllerOptions);

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 2a7459a. 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.