-
Notifications
You must be signed in to change notification settings - Fork 35
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
Comments
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
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
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?
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 |
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. |
Can you try loading the sdf model without hands? @anqingd |
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? |
Sorry, I thought we were committing directly the SDF files in that repo. |
Thanks @traversaro |
Issue in bullet related to loading SDF files converted from URDF files: bulletphysics/bullet3#1707 . |
Relatively to the problem on how to have kinematic frames in URDF/SDF models, see also RobotLocomotion/drake#9350 . |
@anqingd can we close this issue? In case, feel free to close. |
You could explicitly add inertia in each link with mass zero, instead of leaving out the inertia completely for those links?
You can simply reset the joint state, after loading the URDF:
|
Thanks @erwincoumans for chiming in!
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.
Great, thanks. cc @anqingd @diegoferigo |
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:
|
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 |
This is fixed now when using sdformat >= 8.4 . |
I updated the issue to track the only remaining problem with PyBullet. |
We are probably not going to break the existing PyBullet API for this. We can add a flag to loadURDF to change behavior though. Note that a single free floating link with zero mass (and no children/parent) will not simulate properly and will be regarded as static. |
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. |
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:
The text was updated successfully, but these errors were encountered: