Update ergocub models to latest ergocub-software version (v0.7.7) and latest ergoCub model (ergoCubSN002)

[traversaro]

This PR updates the version of ergoCub model contained in robot_descriptions.py in two ways:

• Bumps the tag of ergocub-software (the repo that hosts the ergocub URDF models) to the latest tag https://github.com/icub-tech-iit/ergocub-software/releases/tag/v0.7.7 (if you prefer to use the corresponding commit to avoid tag invalidation, I can also do that).
• Change the model of ergoCub used from ergoCubSN000 (the first revision of the robot) to ergoCubSN002 (the latest one).

If you are a user interested in the latest and more close to the ergoCub reality model I always suggest to refer to https://github.com/icub-tech-iit/ergocub-software/, but this PR at least make sure that robot_descriptions.py users will not get a critically outdated ergoCub URDF model, thanks!

fyi @GiulioRomualdi @Nicogene @hany606

[traversaro]

As a bit of context: the robot_descriptions.py library is so nice that also many IIT/ergoCub users started using it to use it, thanks for all the work on it! The problem we experience is that then it is a bit hidden/not clear to them that they use an old version of the ergoCub robot model. So this PR is not a definite solution, but at least an improvement w.r.t. to the status quo.

[coveralls]

Pull Request Test Coverage Report for Build 14330953399

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 97.89%

---

Totals
Change from base Build 14329110846:	0.0%
Covered Lines:	1067
Relevant Lines:	1090

---

💛 - Coveralls

[stephane-caron]

Thank you, the update is most welcome 👍

(if you prefer to use the corresponding commit to avoid tag invalidation, I can also do that).

So far I thought it's better to use a commit than a tag for this reason (that's why it says to put a commit ID in CONTRIBUTING.md for instance), but perhaps for you the tag is more convenient for some reason? (Re-tagging after a fix to the same version?)

If you prefer a tag go for it 👌

The problem we experience is that then it is a bit hidden/not clear to them that they use an old version of the ergoCub robot model.

Yes, currently there is only one version/variant of each description. I guess this problem would be reduced if there were a notion of variants of each description, so that users are informed by the API that there are different versions of each description (and if they don't want to look into the details they will just get a default one as currently). Variants will require reworking the internals a bit though, so I'm thinking this will happen when the library switches to v2.

[traversaro]

(if you prefer to use the corresponding commit to avoid tag invalidation, I can also do that).

So far I thought it's better to use a commit than a tag for this reason (that's why it says to put a commit ID in CONTRIBUTING.md for instance), but perhaps for you the tag is more convenient for some reason? (Re-tagging after a fix to the same version?)

If you prefer a tag go for it 👌

Ah sorry, I was not able to reply in time! I just used a tag as it is easier to read, and because I found a tag was already used in icub-models, talos-data and baxter_description. However, probably my concern would be mitigated if we used a commit with a tag listed in a comment, let me know if it is ok to open a PR for that, thanks.

[stephane-caron]

Sorry I just saw your message after releasing v1.16.0 🙈 Sure thing! Feel free to open a follow-up PR anytime.

The other tags are legacy, I will update the Baxter and TALOS ones.