iCubGazeboV* doesn't work with YARP 3.8 (YARP master as of October 2022) NWS/NWC

[pattacini]

The model iCubGazeboV2_5_visuomanip fails to work as expected.

Watch the video below recorded via https://github.com/vvv-school/tutorial_cartesian-interface:

2022-09-05.14-08-58.mp4

cc @traversaro @Nicogene @xEnVrE

[pattacini]

Forgot to mention that I was testing it against the Distro 2022.08.0 using this docker image: https://github.com/vvv-school/vvv-school.github.io/pkgs/container/gitpod/40436674?tag=latest.

[pattacini]

I'm going to check also against https://github.com/robotology/icub-gazebo-grasping-sandbox.

[pattacini]

The grasping sandbox works like a charm ✅

2022-09-05.14-34-44.mp4

The difference between the two docker images is that:

• ✅ icub-gazebo-grasping-sandbox makes use of v2022.08.0 and thus relies on icub-models@v1.25.0 tagged 13 days ago.
• ❌ tutorial_cartesian-interface relies on the vvv-school image that in turn was built today against icub-models@master.

[pattacini]

Both icub-model@v1.25.0 and icub-model@master point to 74cbcda.
Further checking is required.

[pattacini]

I think I got it! It depends on which version of YARP is compiled.

• yarp@v3.7.2 (which belongs to Distro 2022.08.0) still provides controlboardwrapper2, although it's deprecated and it seems that the iCub model makes use of such a device.
• yarp@master doesn't provide the controlboardwrapper2 any longer causing the problem.

---

This essentially means that we should update icub-models (at least the models that are manually handled) to remove any reference to controlboardwrapper2.

cc @traversaro @Nicogene @xEnVrE

[Nicogene]

I changed the title since this is an issue regarding all the models, we can keep it for the activity for porting them from controlboardwrapper2 to controlboard_nws_yarp

(Keep in mind to make explicit the period for robotology/robots-configuration#378)

[traversaro]

Thanks @pattacini for the debug! This is related to robotology/icub-models-generator#215 (that was tracking the migration of iCub v2.5 to gazebo_yarp_robotinterface). The first PR on this is robotology/icub-models-generator#222 that was migrating iCub3 models.

[pattacini]

Super, @traversaro 👍🏻
Do those PRs cover the case of manually handled models as well, like the visuomanip?

[traversaro]

Super, @traversaro 👍🏻
Do those PRs cover the case of manually handled models as well, like the visuomanip?

There is no iCub 2.5 PR at the moment.

[traversaro]

I think I got it! It depends on which version of YARP is compiled.

* `yarp@v3.7.2` (which belongs to Distro 2022.08.0) still provides `controlboardwrapper2`, although it's deprecated and it seems that the iCub model makes use of such a device.

* `yarp@master` doesn't provide the `controlboardwrapper2` any longer causing the problem.

This essentially means that we should update icub-models (at least the models that are manually handled) to remove any reference to controlboardwrapper2.

cc @traversaro @Nicogene @xEnVrE

I updated the title to cover this.

[xEnVrE]

I saw that the automatically generated models should be now compatible with latest YARP after robotology/icub-models-generator#231.

For the manually generated models, at least we have now the diff due to the automatic build in icub-models as a sort of guidance.

Is anybody planning to update such models already? If not, I might take the duty to update iCubGazeboV2_5_visuomanip. Of course, in the long run it would useful to abandon these models and generate them automatically with the hands as done in https://github.com/icub-tech-iit/ergocub-software.

@pattacini @traversaro

[pattacini]

Thanks for your offer @xEnVrE
Actually, there's no plan to work on this soon.

Of course, in the long run it would useful to abandon these models and generate them automatically with the hands as done in https://github.com/icub-tech-iit/ergocub-software.

Definitely agree with this 👍🏻
@Nicogene and I were discussing this yesterday. However, the first point we'll need to attack is to restore our URDF generation pipeline, which is now broken because of an incompatibility between MATLAB and CREO.

[xEnVrE]

Actually, there's no plan to work on this soon.

I will dedicate some time to it and open a PR when ready!

our URDF generation pipeline, which is now broken

Thanks for the update on this.

[traversaro]

Thanks @xEnVrE !

[xEnVrE]

I will dedicate some time to it and open a PR when ready!

I opened the PR as discussed above.

I think that iCubGazeboV3_visuomanip would need a similar treatment. Can you confirm @mebbaid?

[mebbaid]

I think that iCubGazeboV3_visuomanip would need the same treatment. Can you confirm @mebbaid?

That is indeed the case, thanks @xEnVrE for noting me. I will open a corresponding PR.

[pattacini]

Thanks heaps @xEnVrE 🚀

[traversaro]

The last problems were fixed in #188 .