Make iCubGazeboV2_5_visuomanip yarp_nws compatible

[xEnVrE]

This PR makes the manually generated model iCubGazeboV2_5_visuomanip compatible with the latest yarp nws architecture.

Specifically:

• it adds the yarprobotinterface plugin within the URDF model
• it updates ini files within iCub_manual/conf_manual/iCubGazeboV2_5_visuomanip such that the gazebo plugins do not use the implicit network wrappers anymore
• it removes ini files that are not required anymore (as using the yarprobotinerface plugin allows using networks in the motor control remapper xmls)
• it adds xml files for the yarprobotinterface plugin for motor control remappers (wrappers are inherited from the automatically generated models), and cameras
• it makes sure that if this model uses files from the iCub/conf folder, these are only files that are currently used by the automatically generated models, hence files that can be shared so that future changes can be inherited automatically
• it does not add any functionality w.r.t. the previous iCubGazeboV2_5_visuomanip, i.e., we still get:
  • motor control for arms, hands, torso, head, eyes but not for the legs (using nws)
  • an rgb camera on the right (using nws)
  • an rgbd camera on the left (using nws)
  • analog readings of the fingers encoders (without nws as the analogServer is still not nws-enabled)
  • head IMU readings (using nws)

Note: For some reason git thinks that I have renamed iCub_manual/conf_manual/iCubGazeboV2_5_visuomanip/gazebo_icub_torso.ini into iCub_manual/conf_manual/iCubGazeboV2_5_visuomanip/gazebo_icub_eyes.ini. However, I just deleted the former in a commit and added the latter in the next commit.

fixes #171 (at least partially as iCubGazeboV3_visuomanip should be updated as well)

cc @pattacini @traversaro

[xEnVrE]

I had to push force to correct a wrong path in one of the xml.

[xEnVrE]

I tried this PR after rebasing on top of the latest #186 and something is not working for the manually generated models as I get the following error when trying to insert either iCubGazeboV2_5_visuomanip or iCubGazeboV3_visuomanip:

terminate called after throwing an instance of 'std::invalid_argument'
  what():  stoi

cc @traversaro

[traversaro]

I tried this PR after rebasing on top of the latest #186 and something is not working for the manually generated models as I get the following error when trying to insert either iCubGazeboV2_5_visuomanip or iCubGazeboV3_visuomanip:

terminate called after throwing an instance of 'std::invalid_argument'
  what():  stoi

cc @traversaro

Which version of gazebo and gazebo-yarp-plugins are you using?

[traversaro]

I tried to search for:

• gazebo-yarp-plugins
• gazebo-classic
• yarp

source code for stoi instances, but I could not find anything specific.

[xEnVrE]

Which version of gazebo and gazebo-yarp-plugins are you using?

I am using the robotology-superbuild with ROBOTOLOGY_PROJECT_TAGS = Unstable as I wanted to test in a scenario where deprectated devices have been already removed. Then I just uninstalled icub-models, switched to my branch, rebased onto the latest devel and run make install from robotology-superbuild/build/src/icub-models.

gazebo --version
Gazebo multi-robot simulator, version 11.12.0
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.

cd robotology-superbuild/src/GazeboYARPPlugins
git log
commit fe7a39e932f35488ee292ee77f7d9853b4ac57a6 (HEAD -> devel, origin/devel)
Merge: b9c18f46 9982ab1d
Author: Silvio Traversaro <silvio@traversaro.it>
Date:   Fri Jan 13 15:15:27 2023 +0100

    Merge pull request #641 from robotology/feat/addHandMK5Coupling

    ControlBoardDriverCoupling: add couplings for hand mk5

[xEnVrE]

After #190, this works again properly. My guess is that since I am using some of the files from the automatically generated robots, and with #186 they were not detected properly by Gazebo, this robot was failing too while trying to fetch the configuration files.

[traversaro]

After #190, this works again properly. My guess is that since I am using some of the files from the automatically generated robots, and with #186 they were not detected properly by Gazebo, this robot was failing too while trying to fetch the configuration files.

Ok, great! Having better error would be desirable, but is probably a different issue. So, we can proceed with the merge?

[xEnVrE]

So, we can proceed with the merge?

I would say so.

[traversaro]

Thanks @xEnVrE !