Discussion: remove implicitly created Network Wrapper Servers (NWSs) by gazebo-yarp-plugins in the future

[traversaro]

Since the beginning of gazebo-yarp-plugins, the general pattern of each plugin that exposed a given Gazebo functionality in YARP (at least the one that exposed functionalities available on real robots, see http://robotology.github.io/gazebo-yarp-plugins/master/embed_plugins.html) as always have been to create two YARP devices for each plugin:

• One YARP device exposing the simulation capabilities (motor control, sensors measurements) via YARP device C++ interfaces (this is what on real robot are sometimes called "physical devices")
• One YARP device that was interacting with the aforementioned YARP device to expose its functionalities over the YARP network using ports (a so-called "Network Wrapper Server" (NWS), see https://www.yarp.it/git-master/nws_and_nwc_architecture.html)

This was done because back at the time (~2013/2014) the common workflow was to have only one time of NWS for type of device exposed. After that, several things changed:

• NWS for different robotics framework such as ROS and ROS2 started to be developed
• A whole class of "remapper" devices have been developed, permitting to expose a combination of multiple (or a subset) of physical devices in the same NWS

Over the years, some solution were developed ad-hoc for each specific problem, but it was clear that just assuming that one NWS corresponded to one physical device was not going to be scalable for the future. That is the reason why the gazebo_yarp_robotinterface device was developed, see #391 and #532 . The next step is to actually port existing simulated robots to use NWS created by the gazebo_yarp_robotinteface, to permit users to eventually add any NEW that they need easily.

Once that will happen, the idea to simplify mantainance of gazebo-yarp-plugins is to eventually remove the implicitly created NWS from the gazebo plugins at some point of the future. The first step into that direction is being worked in #565 by @ste93, where a GAZEBO_YARP_PLUGINS_DISABLE_IMPLICIT_NETWORK_WRAPPERS option (that for now defaults to OFF) was added.

This issue is meant to get feedback on this plan.

[giodegas]

You should consider an OS-agnostic high performance message broker like Redis, which well supports publish-subscribe paradigm, so all networking could be delegated to it. I have already tested using Redis as a bridge between non-ROS2 robot and a ROS2 planner.
Open source, of course.

[traversaro]

Hi @giodegas ! Yes, the whole NWS/NWC architecture objective is that you want easily use the YARP device infrastructures with any middleware that you use, for example you could write a NWS for any custom Redis-based protocol you may like to use, that you can then load in the simulation via the gazebo_yarp_robotinterface .

[traversaro]

(A bit OT: If you are interested in easy to use multiplatform ROS2 binaries, feel free to check out https:/RoboStack/ros-galactic).

[traversaro]

Some related commits related to this change were recently added in the R1 model in robotology/cer-sim@ed680ba and earlier commits.