Discuss wearable actuators implementation

[yeshasvitirupachuri]

Currently the wearable library provides a means of encapsulation of sensor data through various sensor interfaces that can be packaged nicely into a wearable data format. This served us well in developing wearable devices such as xsens suit.

As we recently started working on development of other wearable devices such as the adaptive Paexo exoskeleton from Ottobock, we realized that we need to have actuation related infrastructure too, e.g. setting the motor position for the adaptive Paexo. Another example case if the haptic device actuation, such as the mode of actuation that indicates the duration and vibration pattern as indicated in #100 (comment).

So, given these recent example applications we came across, it would be nice to add the actuators implementation to the wearable library, that provides the high level interface to the client devices that connect to a wearable device and sends the actuation command as needed. An example case for such a scenario is the Paexo wearable device. At the moment it provides the data from the Paexo system as a wearable library sensor interface implementation #81. This information will be consumed by client devices such as HumanStateProvider, that in turn would like to send an actuation command to the Paexo actuator based on the adaptive control algorithms we implement.

[yeshasvitirupachuri]

I realize that a template for the implementation for handling actuation is already available in the wearables library.

IXsensMVNControl interface provides the template for the utility functions that are implemented in XsensSuit wearable device, and IXsensMVNControlWrapper wrapper that opens a yarp rpc port to received calibration related commands.

Along the same lines, one possible implementation for actuators is IActuators which is on top of actuators like IHaptic. A wrapper like IActuatorsWrapper opens a rpc port to receive inputs for the actuation.

[lrapetti]

A consideration here is, why those actuators should communicate via rpc? I guess the main reason is that we want a feedback from the actuators to make sure the command is received.

But what if the actuators should be set continuously, at high frequency? In this case what we already have for WearableData would work as well for sending the actuator command

[yeshasvitirupachuri]

A consideration here is, why those actuators should communicate via rpc?

In some of the use cases we have now e,g, Paexo wearable device, the actuation commends will be generated probable by another process e.g. at the consumer layer of the architecture https://github.com/robotology/human-dynamics-estimation/blob/master/misc/hde_scheme.png. Assuming the actuation can be asynchronous, unlike the sensor data streaming done through IWear interface and IWearWrapper, yarp rpc is the choice.

But what if the actuators should be set continuously, at high frequency? In this case what we already have for WearableData would work as well for sending the actuator command

Can you please explain this further.

One important consideration we need to account for here is, any change in the update of wearable structure (by adding new actuators commands as part of wearableData structure) will render the wearableData datasets we have unusable, as we experienced when adding new sensors with iCub wearable device #25. So, we need to make the actuators part optional.

[yeshasvitirupachuri]

Update from meeting on 11th Jan 2020

Participants: @diegoferigo @lrapetti @evalli-iit @traversaro

Action Points

• Decide on the interface methods for the actuators and implement them
• Use streaming port over rpc for the actuators wrapper
• A remapper is not strictly necessary, and the client device (e.g. adaptive control algorithm application for Paexo) can connect to the actuators wrapper and send commands
• As thrift does not allow to optional data for WearableData, it is better to keep the actuators implementation separate from IWear interface