Yarp: Provide a wrapper device to write data read from the Multiple Analog Sensors Interfaces to a vector

[traversaro]

Given that several YARP workflows (such as using the yarpscope) rely on reading data from a port in which data is published in a port as yarp::sig::Vector, it would be great to have a configurable wrapper YARP device that attaches to a device exposing Multiple Analog Sensor Interfaces and publishes them as a vector.

Note that this wrapper device would not have any associated client, as the network transparency would be always implemented with the yarp::dev::MultipleAnalogSensorsServer
and the yarp::dev::MultipleAnalogSensorsClient

Describe alternatives you've considered
A possible alternative is to have a YARP Module that opens a multipleanalogsensorsclientand publish the necessary info on a port, but implementing this logic in a device gives us more flexibility, as the device could be added directly in the yarprobointerface to reduce delays. If the external solution is needed, it can still be implemented using a yarprobotinterface that contains multipleanalogsensorsclient and the new device.

cc @hu-yue @fjandrad

[barbalberto]

What about a portmonitor plugin that strips away the unnecessary header/data and formats the output as a vector?

[DanielePucci]

CC
@diegoferigo

[DanielePucci]

CC
@lucaTagliapietra

[jgvictores]

Hi! Here's 1 solution from our repos, and 2 questions regarding a possible future solution contained within this repo. :smile:

Solution: We identified this issue at https://github.com/roboticslab-uc3m/teo-configuration-files/issues/27, unaware of this duplicate. As a result, we developed a BottleExtract YARP portmonitor, which is functional and can be used with a format such as tcp+recv.portmonitor+type.dll+file.BottleExtract+index.5+subindex.0+subsubindex.0 (example for plotting FT on yarpscope).

Questions: Some questions I'd ask if we were interested in providing a more formal version in this repository:

1. The fact that recv.portmonitor works (Thing can be cast into a Bottle) but send.portmonitor does not (Thing cannot be cast into a Bottle nor a Vector) feels kind of risky/hacky. Would this be acceptable, or would we really have to make a MAS-specific device with, e.g. access to SensorStreamingData header created by Thrift IDL?
2. There is some prop1.val1+prop2.val2->(prop1 val1) (prop2 val2) logic at BottleExtract that is a kind of re-implementation of what is already done at YARP's Protocol.cpp#L149-L175. The parsing logic is accessed by PortMonitor here but not passed on to the loaded .dll (obtains a good Property here but instead of passing it directly it only passes parts of it on a new Property here, where the carrier string is again unparsed). Knowing this would be helpful to not duplicate the code for the create() method of any plugin of CATEGORY portmonitor (e.g. I'd like to avoid hard-coded initial values in depth_image_portmonitor in the future), would it be okay to touch the PortMonitor even if it is to pass, say, both the unparsed carrier string as well as the parsed version e.g. as a nested Property?

[traversaro]

Thanks @jgvictores for the interesting links. I am not a PortMonitor expert so I am not sure how to answers your questions. However, I think there are a few users who could be interested in your comment: @Yeshasvitvs @lrapetti @diegoferigo @prashanthr05 @HosameldinMohamed @MiladShafiee .