Check how to stream position data if the device can provide it

[HosameldinMohamed]

In this YARP device, we are implementing multipleAnalogSensor and IGenericSensor interfaces.

At the moment we are streaming the orientation (RPY), and accelerometer, gyroscope, and magnetometer data.

Some devices, such as MTi-680G can also stream position data.

Following discussion in #38 (comment)

@traversaro:

Also, how to handle the position data, in case the device has this capability, and if it's available.
The update seems straightforward when using mulitpleAnalogSensor interfaces, but with IGenericSensor, it will introduce a breaking change, because the structure of the YARP port may change.

In general, I would develop a custom Network Wrapper Server YARP devices that exposes the required information in the desired form in a YARP port that publishes yarp::sig::Vector-like. In this way, we can just re-use it across different devices, for example both here and for the realsense devices, see robotology/yarp-device-realsense2#7 . The alternative solution is to modify every hardware device to stream the data as you prefer, but as you imagine this is not scalable.

#38 (comment)

As a starting point, you can copy the code of the multipleanalogsensorsserver YARP device ( https://github.com/robotology/yarp/tree/master/src/devices/multipleanalogsensorsserver ) and just modify the publishing logic to write the data as you prefer.

[HosameldinMohamed]

In general, I would develop a custom Network Wrapper Server YARP devices that exposes the required information in the desired form in a YARP port that publishes yarp::sig::Vector-like. In this way, we can just re-use it across different devices, for example both here and for the realsense devices, see robotology/yarp-device-realsense2#7 . The alternative solution is to modify every hardware device to stream the data as you prefer, but as you imagine this is not scalable.

Not sure I understood what you meant by "The alternative solution is to modify every hardware device to stream the data as you prefer".

What I meant regarding the IGenericSensor interface that's currently implemented, it streams the port as follows (if I remember well):

Roll pitch yaw acc_x acc_y acc_z gyro_x gyro_y gyro_z mag_x mag_y mag_z

So if I add position data, either I append it to the beginning of the port, and in this case, everyone using the device needs to update their dependency, or append the position at the end of the port and so the port size changes. Further, the sensor will not provide position data if no proper GNSS signal is available (or if it's tested indoors for instance). In this case, we will be streaming dummy values in the port.

While in the case of multipleAnalogSensor interfaces, it's convenient to just implement IPositionSensors, and use a proper MAS_status value in case no data is available.

[traversaro]

Let's discuss face to face, are you in the lab? In a nutshell, the proble you are describing is the reason we developed the multipleanalogsensor interfaces in the first place. The use of IGenericSensor implemented is just a legacy behaviour that we would like to get rid of, as different users may have different needs: for example, you need to read IPositionSensors, while someone else could be interested in reading ISkinPatches. How can we agree on the correct serialization on the vector that satisfy everyone?

[HosameldinMohamed]

Let's discuss face to face, are you in the lab? In a nutshell, the proble you are describing is the reason we developed the multipleanalogsensor interfaces in the first place. The use of IGenericSensor implemented is just a legacy behaviour that we would like to get rid of, as different users may have different needs: for example, you need to read IPositionSensors, while someone else could be interested in reading ISkinPatches. How can we agree on the correct serialization on the vector that satisfy everyone?

That makes total sense!

One option is to keep the behavior of IGenericSenor as it is for now, and add the position to as IPositionSensors to MAS!

[traversaro]

Yes!