Yarp: Refactor part of yarprobotinterface functionalities in a libYARP_robotinterface library

[traversaro]

Is your feature request related to a problem? Please describe.

For some application, in particular simulators, it would be desirable to be able to open and attach a set off devices using the same xml configuration files used to launch devices via the yarprobotinterface. Furthermore, sometimes it would be convenient to open devices in other part of the process, and "pass" them to the yarprobotinterface to permit that devices opened by the yarprobotinterface can attach to them. See https://github.com/robotology/gazebo-yarp-plugins/issues/391 for an issue in gazebo-yarp-plugins discussing in detail how such functionality could be exploited for simplifying and permitting the execution of arbitrary YARP devices as part of a Gazebo simulation.

Describe the solution you'd like

I checked out the code, and I expect that a solution could be provided in the following steps (that could be provided as separate PRs):
1) Move the following headers files (and related implementations) in a new library libYARP_robotinterface (or eventually some other name, as the yarprobotinterface system can be used to run also group of devices that do not expose an interface for a robot):

• https://github.com/robotology/yarp/blob/v3.1.1/src/yarprobotinterface/Action.h
• https://github.com/robotology/yarp/blob/v3.1.1/src/yarprobotinterface/CalibratorThread.h
• https://github.com/robotology/yarp/blob/v3.1.1/src/yarprobotinterface/Device.h
• https://github.com/robotology/yarp/blob/v3.1.1/src/yarprobotinterface/Param.h
• https://github.com/robotology/yarp/blob/v3.1.1/src/yarprobotinterface/Robot.h
• https://github.com/robotology/yarp/blob/v3.1.1/src/yarprobotinterface/RobotInterfaceDTD.h
• https://github.com/robotology/yarp/blob/v3.1.1/src/yarprobotinterface/Types.h
• https://github.com/robotology/yarp/blob/v3.1.1/src/yarprobotinterface/XMLReader.h
  This should leave just leave Module.h/cpp, main.cpp and the thrift service as part of the yarprobotinterface, that will become rather simple executable that links libYARP_robotinterface. As part of this move, the namespace of these classes will probably need to be moved to yarp::robotinterface and their directory to yarp/robotinterface. To get an idea of how to structure a YARP subdirectory, see for example the libYARP_manager one.

2) Once the libYARP_robotinterface will be a standalone library, its API should be modified to permit to specify as devices in the networks parameter in the attach phase devices that are not spawned by the yarprobotinterface itself. Some relevant code is in https://github.com/robotology/yarp/blob/v3.1.1/src/yarprobotinterface/Robot.cpp#L240 .

Describe alternatives you've considered
A possible alternative is to re-implement the necessary functionality that are already contained in the yarprobotinterface executable, but this could create maintainability problems.

One possible drawback of moving the yarprobotinterface code to a separate library is that the requirement of keeping backward compatibility as documented in YARP guidelines could slow down development or changes in yarprobotinterface. If we think there is a risk of that kind, I think it could make sense to explicitly document that libYARP_robotinterface could have breaking changes between features releases, similar to what is the policy for LLVM libraries.

Additional context
Given the imminent release of YARP 3.2, this proposal targets YARP 3.3, or whatever the next feature release of YARP will be called.
The feature now targets YARP 3.4 .

[traversaro]

cc @prashanthr05 @nunoguedelha @lrapetti @Yeshasvitvs

[drdanz]

This was originally part of my plan, all the classes should be in a pretty good shape for becoming a library. The main issue was starting devices with static plugins. We never had the need to do that though, therefore it was never done.

[drdanz]

Part 1. was implemented in #2168
@traversaro Are you taking care of part 2 as well?

[traversaro]

@traversaro Are you taking care of part 2 as well?

Yes, I just don't have a precise schedule, but for sure in 1 or 2 months (hopefully that should be before YARP 3.4 release). If you already have a plan for YARP 3.4 release date, feel free to share so I am sure that the library get released in an actually usable form.

[drdanz]

We don't have plans yet, but I aim at making a release every 4 months, i.e. maybe April?

[traversaro]

2) Once the libYARP_robotinterface will be a standalone library, its API should be modified to permit to specify as devices in the networks parameter in the attach phase devices that are not spawned by the yarprobotinterface itself. Some relevant code is in https://github.com/robotology/yarp/blob/v3.1.1/src/yarprobotinterface/Robot.cpp#L240 .

The only missing is part is this one, the modifications required are quite minimal, and I think @diegoferigo is already experimenting with them. @drdanz do you think we are able to include these in the next release?

[drdanz]

As discussed, the libYARP_robotinterface library will be declared experimental in next release, with no API/ABI stability guarantee, therefore we can add that at the last moment.

[drdanz]

It would be great if, before the release, we could also port the library from yDebug to yCDebug, which will make it a lot easier to understand where the log messages are coming from.
Anyway this is a minor issue, since we can do it anytime without breaking anything

[diegoferigo]

Sure! Thanks for the reminder @drdanz. Do you mean the entire robotinterface library? I can add a new commit that updates the calls library-wise (since anyway there's already a commit for the style). Later, before merging, we can also discuss if we want to split this PR in two, I'll try to order commits to allow this use-case.