iCubNancy01 not importing

[jbmouret]

Hi

It seems that we are not using the icub-gazebo models anymore... I am therefore trying to install a fresh environment based on conda + gazebo + icus-models (on mac for now).

I compiled ICUB_MODELS_INSTALL_ALL_GAZEBO_MODELS and I see iCubNancy01 in the list.

... but when I click on it to insert it, nothing happens. It works for all the iCubGenova* and the iCubGazeboV* (which all have a backpack, therefore they are very different from our iCub).

I do not see any error message in the terminal, but maybe Gazebo writes errors somewhere else.

[jbmouret]

Update: I found some errors in Gazebo in --verbose:

[Err] [SdfFrameSemantics.cc:99] Error Code 23 Msg: FrameAttachedToGraph error, Non-LINK vertex with name [fixed_left] is disconnected; it should have 1 outgoing edge in MODEL attached_to graph.
[Err] [SdfFrameSemantics.cc:99] Error Code 23 Msg: FrameAttachedToGraph error, Non-LINK vertex with name [fixed_right] is disconnected; it should have 1 outgoing edge in MODEL attached_to graph.
[Err] [SdfFrameSemantics.cc:99] Error Code 23 Msg: Graph has __model__ scope but sink vertex named [fixed_left] does not have FrameType LINK OR MODEL when starting from vertex with name [fixed_left].
[Err] [SdfFrameSemantics.cc:99] Error Code 23 Msg: Graph has __model__ scope but sink vertex named [fixed_right] does not have FrameType LINK OR MODEL when starting from vertex with name [fixed_right].
[Err] [SdfFrameSemantics.cc:99] Error Code 26 Msg: PoseRelativeToGraph error, Vertex with name [fixed_left] is disconnected; it should have 1 incoming edge in MODEL relative_to graph.
[Err] [SdfFrameSemantics.cc:99] Error Code 26 Msg: PoseRelativeToGraph error, Vertex with name [fixed_right] is disconnected; it should have 1 incoming edge in MODEL relative_to graph.
[Err] [SdfFrameSemantics.cc:99] Error Code 26 Msg: PoseRelativeToGraph frame with name [fixed_left] is disconnected; its source vertex has name [fixed_left], but its source name should be __model__.
[Err] [SdfFrameSemantics.cc:99] Error Code 26 Msg: PoseRelativeToGraph frame with name [fixed_right] is disconnected; its source vertex has name [fixed_right], but its source name should be __model__.

[traversaro]

Thanks @jbmouret ! I will first do some checks internally to make sure that the current state of the physical iCubNancy01 actually match the generated iCubNancy01, then I will report back in this issue.

[jbmouret]

Thank you for your reply. Any news on this topic?

Thank you

[traversaro]

Hi @jbmouret, thanks to @Fabrizio69 I have some precise info on iCubNancy01:

• Head: ver.2
• Upper: ver.1 (with BLL/BLP)
• Hands+Forearms: ver. 1 (with fingertip sensors, MC4)
• SubLower: ver.1
• SubLegs: ver.2.5 (SEAS legs Eth. based)
• textile skin full body

Indeed it is coherent with the version produced for iCubNancy01 in https://github.com/robotology/icub-models-generator/blob/d0a98d8cbb11ab362d320089b4daec35ff56f057/dh/CMakeLists.txt#L22 . Note that unfortunatly for the iCub that have parts version 1 we did not generate those meshes/inertial parameters directly from CAD, so we are not 100% sure about those models. However, they should at least spawn correctly in gazebo, let me check.

[traversaro]

I quickly debugged the problem, that can be easily reproduced by running:

gz sdf -p ./icub-models/iCub/robots/iCubNancy01/model.urdf

or

ign sdf -p ./icub-models/iCub/robots/iCubNancy01/model.urdf

The problem is that the links:

• torso_1
• torso_2
• l_hip_3
• r_hip_3

Are massless, and sdformat stop the conversion at those links without any error (in this sense, this could also be considered a sdformat problem).

Why those links are zero? To explain why those links are zero, I need to briefly explain how the models for iCub with parts <= 1 were generated. Those were generated back in 2013/2014 by combining two different sources of information:

• For kinematics and dynamics, the model hardcoded in the iDyn library (in particular the iCubWholeBody class)
• For meshes, the meshes that were manually extracted from an unknown version of the CAD from ISIR's Joseph Salini

These information were merged to generate a URDF file by some C++ code that I wrote during shortly after my master thesis (again ~2013). This code can be found in https://github.com/robotology/icub-models-generator/tree/last-call-for-dh-generator/dh/generator, but in robotology/icub-models-generator#171 we just removed it and substituted it with all its possible outputs.

So, the masses are 0 because they were 0 in the old iDyn library models.

At the moment, the main focus is on the models for the iCub 2.* that are automatically extracted from the CAD models, while the models for the iCub with v1 part are provided just as a convenience to whom was still using them. As a hotfix, we could just use for the torso_1, torso_2, l_hip_3 and r_hip_3 links in v1 part the same mass of the corresponding links in v2 parts, but note that this would be just a guess.

[traversaro]

Note that even if we set non-zero masses, the unmodified model will probably do not run correctly out of the box with the default physics solver setting of Gazebo with ODE, mainly due to the small inertia that make the system quite stiff from the point of view of numerical integration, see #33 .

[jbmouret]

Hi

Thank you for the detailed reply. So, what should we do? For now, we at least need a working Gazebo to test our code before deploying on the robot. We can deal with a possibly inaccurate simulation (provided that it is numerically stable enough).

=> Can you (should we?) set the masses to the same value as v2?
=> longer term, we do not plan to stop using iCub (we just paid a large sum to keep it...), so how should we simulate it? should we plan to develop our own URDF model of our iCub?

thank you

[traversaro]

=> Can you (should we?) set the masses to the same value as v2?

I am happy to do that, but I think it is important to understand what is your goal in using this model (see next question).

=> longer term, we do not plan to stop using iCub (we just paid a large sum to keep it...), so how should we simulate it? should we plan to develop our own URDF model of our iCub?

If you just need to simulate the robot on Gazebo for software integration (i.e., check that the software will run correctly on the real robot, i.e. opening the correct YARP ports, etc etc), what I can suggest is to use the iCubGazeboV2_5 (if you are not interested in hands and eyes) or iCubGazeboV2_5_visuomanip (if you are interested in also using hands and eyes, see https://github.com/robotology/icub-gazebo-grasping-sandbox for an example of its use). Those models have been explicitly meant to be run in Gazebo simulation.

If instead you want to have a precise model of your physical robot for things like sim2real, then I think that working on your own URDF model, via calibration of inertial parameters and of friction may be the way to go in any case, as anyhow even the CAD model is not perfect, or because the iCub model has been modified since it has been built. Anyhow, if you want we can have a Team/Zoom/Slack/WhateverYouLile chat to understand for what you need to use the iCubNancy01 model!

[jbmouret]

Hi

Thank you for the prompt response. The problem with iCubGazeboV2_5 and iCubGazeboV2_5_visuomanip is that they have the backpack, which probably shifts the center of mass significantly. We do not use the Gazebo simulation for complex sim2real developments (we have our own simulation, for which the old URDF works but is probably not accurate), but it would be nice to have a "decently realistic simulation" to check that the behavior makes sense.

So, I think the best would be to "set the masses to the same value as v2", which would be "a bit more realistic than the backpack version" (especially in term of balancing) but not perfect. At any rate, I would say that it is not worse than what we had before (in the old icub-gazebo-models, with 0 masses, apparently), right?