Add yarprobotinterface plugin

[traversaro]

At the moment, all the plugins contained in this repo create both the actual yarp hardware device exposing the Gazebo sensor/actuator using C++ YARP interfaces, and also the relative wrapper to expose those information on the YARP port network.

To simulate complex device that typically run inside the yarprobotinterface, such as the iCub's cartesian controller or the iCub's external forces estimation device wholebodydynamics, it would be nice to have a yarprobotinterface plugin that could run this device as part of the Gazebo process, and ideally would have access to all YARP devices created using the existing plugins. Note that this would probably require a bit of refactoring on the YARP to make sure to expose the relevant logic contained in the yarprobotinterface executable in a separate library. The refactoring on the YARP side was done in robotology/yarp#2168 .

[traversaro]

I just realized a super-cool use case for this feature. If we could move all the wrapper-related devices to a yarprobotinterface-like configuration, it would be trivial to disable all the wrappers, while keeping all the "simulated-hardware" devices. This could be used to wrap the gazebo+yarp plugins simulation inside a WB-Toolbox block, and if we found a way to pass the "database" of YARP devices of the simulation to the WholeBodySingleton class, we could have a Gazebo simulation running completely inside Simulink and without a YARP server, while still using the exact same YARP interfaces/WB-Toolbox blocks we use on the real robot.

To be totally honest, I think it is possible to do what I described in the previous sentence even with the plugins as they are (using the "device database" available in the GazeboYarpPlugins::Handler singleton class: https://github.com/robotology/gazebo-yarp-plugins/blob/master/libraries/singleton/include/GazeboYarpPlugins/Handler.hh#L117), but the usage of a yarprobotinterface plugin would drastically simplify the process of removing the wrappers.

[traversaro]

cc @diegoferigo

[diegoferigo]

@traversaro Let me figure out if I understood what you proposed. Assuming you are talking about Gazebo < 11, are you proposing to execute gazebo in a new thread spawned by Simulink? In this way, it would be possible to get the pointers of the plugins that expose the YARP interfaces (e.g. the controlboards) allowing attaching directly to them.

It would be very cool for what concern the simulations and I don't think it would require a massive amount of work. However this might not be compatible to the usage of the real robots. How should the block behave in such a way that the simulated robot exposes the same interfaces and communicates in the same way of the real one? Right now, always in the case of the controlboards, we read the same ports with different prefixes, but going in this direction we would loose this interchangeability, is this right?

For what concerns the yarprobotinterface, yes, it would simplify the wrappers configuration. Since this issue is about yarprobotinterface, should we open another issue (maybe in WB-Toolbox)?

P.s. Bonus point: starting with Gazebo >= 11, we can even embed gazebo directly inside a block ;) Yes, we can do it also right now but it would be more involved.

[traversaro]

For what concerns the yarprobotinterface, yes, it would simplify the wrappers configuration. Since this issue is about yarprobotinterface, should we open another issue (maybe in WB-Toolbox)?

Let's spin a new issue in WB-Toolbox to avoid polluting gazebo-yarp-plugins: robotology/wb-toolbox#164 .

[traversaro]

cc @prashanthr05

[traversaro]

The changes in YARP necessary for developing the plugin discussed in this issue are now being tracked in robotology/yarp#2005 .

[traversaro]

The first modification in YARP has landed in robotology/yarp#2168 , so in theory prototyping work on this plugin could start, even if probably it would just highlight lacks in the libYARP_robotinterface library that would need to be fixed. For example, one existing problem is that on XML processing errors, the whole processes exits with fatal error, instead of correctly propagating the error to the API caller.

[traversaro]

The second necessary modification in YARP is currently being reviewed in robotology/yarp#2288 .

[traversaro]

This was fixed in #532 .