robotology
Provide a block for reading multiple analog sensors devices
Since YARP has added support for a structured system of devices for reading multiple analog sensors interfaces (http://yarp.it/devel/group__dev__iface__multiple__analog.html and https://github.com/robotology/yarp/pull/1586 ) , it would be great to have support for reading this sensors at the wb-toolbox level.
Instead of manually wrapping YARP C++ devices, it would be cool if we could automatically generated YARP Read/Write-like blocks for messages described by an IDL. This is similar to what Simulink official support for ROS does in the Publisher and Subscriber blocks, see https://it.mathworks.com/help/robotics/examples/get-started-with-ros-in-simulink.html#d120e3206 . However, I am not sure if they support arbitrary message types or just a fixed set.
On the other hand, providing explicit support for wrapping the C++ YARP devices permits some cools integration such as https://github.com/robotology/wb-toolbox/issues/164 .
Instead of manually wrapping YARP C++ devices, it would be cool if we could automatically generated YARP Read/Write-like blocks for messages described by an IDL.
It would be a very useful feature, I concur, but I think it would be a very difficult task. In short, this would translate to an autogenerated plugin library associated to a generic (templated) class that reads custom thrift objects. The autogenerated thrift class and the autogenerated plugin library must be compiled during runtime. Furthermore, in order to set the output ports we should parse all the fields (at least type and size) of the thrift file and set BlockInformation accordingly.
Do you have any other ideas? This is just a draft that does not take into account all possible problems, and it already seems overly complex.
On the other hand, providing explicit support for wrapping the C++ YARP devices
This is definitely more reasonable. We can load the plugins that contains the devices seamlessly since they are already compatible with shlibpp and then map the APIs of a DeviceDriver that implements also a PeriodicThread to the blockfactory::core::Block APIs. I have doubts on how to extend this to attached devices, this would be way more challenging.
permits some cools integration such as #164 .
I didn't get how it would help it, I am missing something. Do you mean that if we would wrap Gazebo inside a YARP DeviceDriver, that idea would come for free?
It would be a very useful feature, I concur, but I think it would be a very difficult task. In short, this would translate to an autogenerated plugin library associated to a generic (templated) class that reads custom thrift objects. The autogenerated thrift class and the autogenerated plugin library must be compiled during runtime. Do you have any other ideas? This is just a draft that does not take into account all possible problems, and it already seems overly complex.
To be honest, I was thinking that all of this would happen at configuration/compilation time, in which you specify a new block and type in CMake and you get the resulting block.
Ok now I got it. In this case, it will be easier since CMake can avoid to mess with templates. Here below some more detailed comments:
- CMake should substitute the name of the autogenerated thrift class in the generic block code.
- CMake should provide a custom function / macro to set the number / type / dimension of output ports.
- If we want to avoid a thrift parser, CMake should set the name of the variables in order to get the right fields out from the received message.
- Not all thrift fields can be transformed to Simulink signals (e.g. strings).
- What about generic composed types (e.g. list of structs)?
- Dynamically sized fields might create problems since this block would be an input block. It is possible to propagate sizes backwards in some cases, but often it does not work. We should use the mask to get this information from the user, but I suspect that developing this kind of generic mask will not be as straightforward.
We can talk f2f on this and decide if it is worth the effort.
We can talk f2f on this and decide if it is worth the effort.
I agree. Probably it is not worth the effort, but it was nice to point it out. In the official ROS support for simulink, I see they are using a bus as the only output signal, but I have no experience with it.
I didn't get how it would help it, I am missing something. Do you mean that if we would wrap Gazebo inside a YARP DeviceDriver, that idea would come for free?
I meant that wrapping devices providing the MultipleAnalogSensors interfaces as we do for the controlboard interfaces (so the original proposal in https://github.com/robotology/wb-toolbox/issues/116#issue-324837914, not the suggestion in https://github.com/robotology/wb-toolbox/issues/116#issuecomment-450636346) will permit to properly access them even if Gazebo is embedded in the simulation master as described in https://github.com/robotology/wb-toolbox/issues/164 .
I meant that wrapping devices providing the MultipleAnalogSensors interfaces as we do for the controlboard interfaces will permit to properly access them even if Gazebo is embedded in the simulation master
If here we are talking specifically about the MultipleAnalogSensors interface, I can now maybe see what you meant. Let me know if it is not:
- One block for every MAS source.
- No input, no output. The block reads the data and stores it somewhere.
- This somewhere can be something similar to a singleton, e.g.
wbt::base::RobotInterface, such that we can gather also sensor data from within other blocks. - Provide a block that can output a signal for a single sensor (accessed by its name) that gets this data from the
RobotInterface(since it will have the pointers to the MAS interfaces).
Long term (off topic)
If we can achieve:
- This MAS support
- Embedding gazebo
- Running generic yarp devices (e.g. whole body dynamics) from within the same simulink model
We would greatly simplify the execution of our controllers since we should not need to operate anymore on external processes in other terminals.
Exactly, you got it correctly.
We would greatly simplify the execution of our controllers since we should not need to operate anymore on external processes in other terminals.
Or running it as a part of an RL training process. : )
Related comment: https://github.com/robotology/yarp/issues/1693#issuecomment-574683563 .