Cleanup ergocub configuration files using enable_by and disable_by yarprobotinterface tags

[traversaro]

(I opened an issue as to get everyone involved aligned).

Since YARP 3.8.0, the yarprobotinterface gain the feature of enabled_by and disable_by tags, that can be used to have a single main yarprobotinterface xml file, that can be configure at yarprobotinterface startupt to enable and/or disable groups of devices. This has been implemented by @randaz81 in robotology/yarp#2890 to avoid the proliferation of hard to maintain variants of the yarprobotinterface for the robot. See R1's configuration files for how to use this conf files: https://github.com/robotology/robots-configuration/blob/v2.6.1/R1SN003/CER.xml#L8 .

On ergoCub robots, I think it would be useful to use this feature. At least looking at ergoCubSN001, the current situation is the following:

• ergocub_all.xml : conf file of the robotinterface with wholebodydnamics disabled and ros2 disabled, not sure if is used by anone
• ergocub_wbd.xml : conf file of the robotinterface with wholebodydnamics enabled and ros2 disabled, used mainly by the AMI group and by anone that needs to use force estimation and torque control
• ergocub_all_ros2.xml: conf file of the robotinterface with wholebodydnamics disabled and ros2 enabled, according to @SimoneMic used by people that just test the grasping
• ergocub_wbd_ros2.xml: conf file of the robotinterface with wholebodydnamics enabled and ros2 enabled, I guess used mostly in experiments where both the walking and the navigation are used

The situation is quite chaotic, as it is quite common for a PR to update only a subset of those files, even if the modification is not related to ROS2 or wbd. So I think we could cleanup the situation as in the following (at first with ergoCubSN001, then the modification can be propagated to more robots):

Add a ergocub.xml file, that subsumes all the previous one, that by default has wholebodynamics enabled and ros2 disabled (please comment if you think that the default should be different). I would also modify yarprobotinterface.ini to point to ergocub.xml. Then, the previous configurations could be reproduced as the following:

Old invocation	New invocation
yarprobotinterface --config ergocub_all.xml	yarprobotinterface --disable_tags "(disable_wholebodynamics)"
yarprobotinterface --config ergocub_wbd.xml	yarprobotinterface
yarprobotinterface --config ergocub_all_ros2.xml	yarprobotinterface --enable_tags "(enable_ros2)" --disable_tags "(disable_wholebodynamics)"
yarprobotinterface --config ergocub_wbd_ros2.xml	yarprobotinterface --enable_tags "(enable_ros2)"

(note that --config does not need to be specified as it will default to ergocub.xml as it is specified in yarprobotinterface.ini, YARP_ROBOT_NAME is set appropriately)

Comments are welcome. If there is consensus, I can implement the change at least for ergoCub robots, as the modifications are trivial. To avoid regression, we can leave the old files around for ~1 month, and then delete all of them

[pattacini]

Thanks @traversaro 👍🏻

[SimoneMic]

Hello,

Could this also be implemented in the simulation/Gazebo models?
Like in:

<plugin name="robotinterface" filename="libgazebo_yarp_robotinterface.so">
      <yarpRobotInterfaceConfigurationFile>model://ergoCub/conf/ergocub.xml</yarpRobotInterfaceConfigurationFile>
    </plugin>

Could it be possible to pass these parameters and structure the .xml in the same manner?

Thanks

[pattacini]

Could this also be implemented in the simulation/Gazebo models?

Hi @SimoneMic

Probably, it'd be better to open a dedicated issue on https://github.com/robotology/gazebo-yarp-plugins/issues to track such an idea/request.

[traversaro]

Could this also be implemented in the simulation/Gazebo models?

Hi @SimoneMic

Probably, it'd be better to open a dedicated issue on https://github.com/robotology/gazebo-yarp-plugins/issues to track such an idea/request.

This required a modification in Gazebo plugins that is tracked in robotology/gazebo-yarp-plugins#672 . If anyone wants to work on this feel free to ask, I will be happy to provide guidance on how to implement this feature.

[traversaro]

As there were no comments, I opened a PR implementing the changes discussed in this issue in #645 .

[pattacini]

cc @SimoneMic