Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for using icub-models out of the box with PyBullet #12

Open
1 of 3 tasks
anqingd opened this issue Apr 30, 2018 · 19 comments
Open
1 of 3 tasks

Add support for using icub-models out of the box with PyBullet #12

anqingd opened this issue Apr 30, 2018 · 19 comments

Comments

@anqingd
Copy link

anqingd commented Apr 30, 2018

To use iCubGenova04 urdf model in pybullet simulator, I deleted all the lines containing the keyword Gazebo in the urdf file and relocated the meshes folder directory. I'm not sure if the model is still reliable but at least by doing so I can load the model. In view of the simulation, there are some problems:

  • iCub hands have collision with the body.
  • I received many warnings and most of them are complaining about no inertial data and skin such as
b3Printf: No inertial data for link, using mass=1, localinertiadiagonal = 1,1,1, identity local inertial frame
b3Printf: b3Warning[examples/Importers/ImportURDFDemo/BulletUrdfImporter.cpp,115]:
b3Printf: r_lower_leg_skin_10
b3Printf: b3Warning[examples/Importers/ImportURDFDemo/BulletUrdfImporter.cpp,115]:
  • there are in total 138 joints(is this the correct number?)
@traversaro
Copy link
Member

traversaro commented Apr 30, 2018

iCub hands have collision with the body.

This is the problem of how joints zero position are defined for the iCub: if all the joints are set to zero, the arms are colliding for the body. This is typically not a problem because the initial position of the arm joints in simulations is the one defined in the initialConfiguration tag, see https://github.com/robotology-playground/icub-models/blob/master/iCub/robots/iCubGenova04/model.urdf#L1866 .
There is any support in PyBullet for loading the model in a specified joint configuration?

I received many warnings and most of them are complaining about no inertial data and skin such as

Unfortunately this seems to be related of the impossibilities of expressing multiple frames for a single link in URDF. See https://discourse.ros.org/t/urdf-ng-link-and-frame-concepts/56 . In a nutshell, we represent "additional frames" as zero-mass links attached to their parent with a fixed joint. This has been working well because by default in Gazebo links attached to fixed joints are automatically lumped to their parent and the fixed joint removed, while in iDynTree this kind of frame is automatically recognized by our URDF parser: https://github.com/robotology/idyntree/blob/master/src/model_io/urdf/src/URDFModelImport.cpp#L751 . However, the handling of this links seems to be different in PyBullet. As a solution, have you considered loading directly the SDF of the robot using the loadSDF method? See bulletphysics/bullet3#1251 (comment) for details on how to use the loadSDF method.

there are in total 138 joints(is this the correct number?)

For the reason outlined before, all the "additional frames" are modeled as links with zero attached to the actual link with a fixed joint. The most interesting quantity for control I think are the "internal non-fixed joints", i.e. the joints on which you can exert a torque through a motor. How many there are of them?

I deleted all the lines containing the keyword Gazebo in the urdf file and relocated the meshes folder directory. I'm not sure if the model is still reliable but at least by doing so I can load the model.

For the meshes, the problem is that meshes URI in URDF are properly defined only when used together with the ROS packages, see robotology/icub-models-generator#28 . However, I hope that this problem is solved if you use loadSDF.

@anqingd
Copy link
Author

anqingd commented Apr 30, 2018

After trying sdf (with yarp plugin contained and excluded) , the simulation cannot even render. I received warnings as follows

ven = Intel Open Source Technology Center
Workaround for some crash in the Intel OpenGL driver on Linux/Ubuntu
b3Printf: b3Warning[examples/Importers/ImportURDFDemo/BulletUrdfImporter.cpp,115]:

b3Printf: expected a world element, continuing without it.
Warning: b3Error[examples/Importers/ImportURDFDemo/BulletUrdfImporter.cpp,110]:

Warning: joint dynamics element specified with no damping and no friction
Warning: b3Error[examples/Importers/ImportURDFDemo/BulletUrdfImporter.cpp,110]:

Warning: Could not parse dynamics element for joint:
Warning: b3Error[examples/Importers/ImportURDFDemo/BulletUrdfImporter.cpp,110]:

Warning: l_arm_ft_sensor
Warning: b3Error[examples/Importers/ImportURDFDemo/BulletUrdfImporter.cpp,110]:

Warning: joint xml is not initialized correctly
Traceback (most recent call last):
  File "icubsdf.py", line 12, in <module>
    p.loadSDF("icub_with_hands02.sdf") 
pybullet.error: Cannot load SDF file.

I also tried loading leg and hand sdf files separately and hand can render but not leg.

@diegoferigo
Copy link
Member

Can you try loading the sdf model without hands? @anqingd

@traversaro
Copy link
Member

If you are using the sdf models in icub-gazebo, I suggest you to try instead the SDF files contained in icub-models .

@anqingd
Copy link
Author

anqingd commented May 20, 2018

If you are using the sdf models in icub-gazebo, I suggest you to try instead the SDF files contained in icub-models

@traversaro is this icub-models the icub-models you were referring to? It seems urdf is the only model type... Or should I turn to somewhere else for sdf?

@traversaro
Copy link
Member

Sorry, I thought we were committing directly the SDF files in that repo.
You can convert those urdf to sdf using the command gz sdf -p model.urdf > model.sdf (this is exactly what Gazebo does internally when loading a URDF file).

@anqingd
Copy link
Author

anqingd commented May 20, 2018

Thanks @traversaro
Now the SDF model is loadable without fake links complaining.

@traversaro
Copy link
Member

traversaro commented May 24, 2018

Issue in bullet related to loading SDF files converted from URDF files: bulletphysics/bullet3#1707 .
Issue in sdformat related to produce SDF models without <use_parent_model_frame>1</use_parent_model_frame> :
https://bitbucket.org/osrf/sdformat/issues/189/convert-urdf-files-to-sdf-with .

@traversaro
Copy link
Member

traversaro commented Sep 1, 2018

Relatively to the problem on how to have kinematic frames in URDF/SDF models, see also RobotLocomotion/drake#9350 .

@fiorisi
Copy link
Member

fiorisi commented Sep 7, 2018

@anqingd can we close this issue? In case, feel free to close.

@erwincoumans
Copy link

erwincoumans commented Sep 18, 2018

You could explicitly add inertia in each link with mass zero, instead of leaving out the inertia completely for those links?

<inertial>
      <mass value="0"/>
      <inertia ixx="0.0" ixy="0.0" ixz="0.0" iyy="0.0" iyz="0.0" izz="0.0"/>
    </inertial>

There is any support in PyBullet for loading the model in a specified joint configuration?

You can simply reset the joint state, after loading the URDF:

robot = pybullet.loadURDF("robot.urdf")
for joint in range(pybullet.getNumJoints(robot)):
    p.resetJointState(robot,joint,initialJointAngle[joint])

@anqingd anqingd closed this as completed Sep 18, 2018
@traversaro traversaro reopened this Sep 18, 2018
@traversaro
Copy link
Member

traversaro commented Sep 18, 2018

Thanks @erwincoumans for chiming in!

You could explicitly add inertia in each link with mass zero, instead of leaving out the inertia completely for those links?

Indeed this may be the safest option, as the semantics of URDF link without inertia is not really defined in http://wiki.ros.org/urdf/XML/link , even if historically a lot of URDF produced by OSRF ( such as https://bitbucket.org/osrf/drcsim/src/194be8500fef81593f79607a21ee2badd9700a0e/atlas_description/urdf/atlas_v5.urdf?at=default&fileviewer=file-view-default#atlas_v5.urdf-788 ) suggested the use of link without inertia element to represent purely kinematic frames, that is the interpretation used in the kdl_parser and in the Gazebo URDF --> SDF converted.

I remember having a detailed comment on this in https://bitbucket.org/osrf/sdformat/issues/199/urdf-to-sdf-conversion-ignores-links , but for some reason it disappeared, probably I accidentally deleted it.

You can simply reset the joint state, after loading the URDF:

Great, thanks. cc @anqingd @diegoferigo

@traversaro
Copy link
Member

I remember having a detailed comment on this in https://bitbucket.org/osrf/sdformat/issues/199/urdf-to-sdf-conversion-ignores-links , but for some reason it disappeared, probably I accidentally deleted it.

Apparently the comment is still available at https://bitbucket.org/osrf/sdformat/issues/199/urdf-to-sdf-conversion-ignores-links#comment-47642199 , but for some reason is not visible if I am not logged in Bitbucket. Reporting hereafter for GitHub users:

But I'd expect a URDF link without an inertia element to be converted to an SDF link without an inertia element, which is valid SDF.

The semantics of SDF <link> without an inertia element is a link with mass of 1 Kg and diagonal inertia matrix of 1 Kg m^2 .

The semantics of URDF <link> without an inertial element instead is not defined in http://wiki.ros.org/urdf/XML/link , but I would say that the major of software in ROS interpret it as a massless link, that is tipically used as a proxy to represent kinematic frames as URDF does not support any way to explicitly express frames (https://discourse.ros.org/t/urdf-ng-link-and-frame-concepts/56).

Example of where a link without inertial element is considered massless include:

For these reasons I think that converting any inertial-less URDF link to an SDF inertial-less link may be quite complicated, as it will add 1 kg for each inertial-less link contained in those models. To be honest, PyBullet is instead an example of a library that converts URDF inertial-less links to links with a mass of 1 kg, and we had several problems exactly for this reason, as our robots started to weight 100 Kg more due to all the "kinematic frames" contained in the model, see #12 (comment) .

@diegoferigo
Copy link
Member

I found this tutorial about the differences between SDF and URDF frames specifications quite interesting:

https://bitbucket.org/osrf/sdf_tutorials/src/default/pose_frame_semantics/tutorial.md

@traversaro
Copy link
Member

Issue in bullet related to loading SDF files converted from URDF files: bulletphysics/bullet3#1707 .
Issue in sdformat related to produce SDF models without <use_parent_model_frame>1</use_parent_model_frame> :
https://bitbucket.org/osrf/sdformat/issues/189/convert-urdf-files-to-sdf-with .

This is fixed now when using sdformat >= 8.4 .

@traversaro traversaro changed the title Problems when using these models in PyBullet PyBullet assumes that links with no inertia element has a mass of 1 while other tools assume that they have 0 mass Apr 6, 2020
@traversaro
Copy link
Member

I updated the issue to track the only remaining problem with PyBullet.

@erwincoumans
Copy link

erwincoumans commented Apr 6, 2020

We are probably not going to break the existing PyBullet API for this. We can add a flag to loadURDF to change behavior though.
You can trivially fix this by fixing the URDF file to always have a field with some meaningful mass.

Note that a single free floating link with zero mass (and no children/parent) will not simulate properly and will be regarded as static.

@traversaro traversaro changed the title PyBullet assumes that links with no inertia element has a mass of 1 while other tools assume that they have 0 mass Add support for using icub-models out of the box with PyBullet Apr 14, 2021
@traversaro
Copy link
Member

Modified the name of the issue to clarify a bit the context. Probably as part of this we can also add a note in the README.

@traversaro
Copy link
Member

See also https://github.com/rustlluk/pyCub .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants