URDF, SDF, MJCF Model Loading

[cmuell89]

Hey all,

I am curious if support exists, or will in the future, for the loading of URDF, SDF and/or MJCF model files into nphysics. This functionality would make nphysics highly desirable for simulating robotics and help Rust expand into the robotics world in general. This is something I could potentially help with if there agreement to support such model files.

Perhaps the library is still too young in that it is missing a large variety of joint types, motor types, and sensor types etc,. to make URDF loading of models feasible.

[sebcrozet]

Hi!

There is no support for any file format in nphysics yet. And adding these would be a great contribution!

Regarding missing features, what types of joint types are missing exactly? I believe nphysics supports most types of joints with most combinations of degrees of freedoms. Perhaps there are some robotics-specific joints I am not aware about?

What are you referring to with "sensor types"? nphysics has a concept of sensors for collision detection without any effect on the simulation state, but I guess that's not what you call sensors?

Would it be possible for you to give a more detailed list of the missing feature to cover what URDF needs?

[cmuell89]

I was referring to the fact that the README mentions some limitations due to the age of the library: "more joints, joint limits, joint motors and breakable joints". My comment was really the opening for a discussion about whether asset files like URDF etc,. are supported. W.r.t. robotics, this would make the use of this physics library much more desirable, but might also be suitable for other applications utilizing other asset files.

What is your opinion of adding additional dependencies?
https://github.com/OTL/urdf-rs

[Ralith]

Is there any reason these need to be baked in, rather than maintained as an independent crate? It'd be nice not to increase the build/maintenance load for all the users who aren't doing robotics research.

[cmuell89]

There is no particular reason. Certain physics libraries will offer support for the loading of model files and URDF is a common format for certain applications. Maintaining a separate crate seems like an appropriate choice. I am not very familiar with Rust and so I'll have to evaluate my ability to contribute. We can close this for now if you'd like, and perhaps I or someone can reopen if a good approach is implemented as an available add-on package/crate.

[sebcrozet]

@cmuell89 Looks like the README is slightly out of date. I don't think we need any more joints. Though it is true that not all our joints support motors and limits yet.

I agree with @Ralith that it would make sense to put this on a separate crate. Though this separate crate could be located on the same github repository as nphysics itself if we want to make its maintenance easier (to always keep it in sync with the latest nphysics version).

We can close this for now if you'd like, and perhaps I or someone can reopen if a good approach is implemented as an available add-on package/crate.

Let's keep this open so it is clearly visible in case someone else wants to try implementing this, unless you manage to do it yourself. Feel free to ask here on on the rustsim discord if you have difficulties working on this!

[neachdainn]

I am working on a (mostly functional at this point) URDF loader for nphysics. I am currently trying to get permission from my advisor to release it as open source, so it may not be available for a few months.

[neachdainn]

As an update, the loader I have works and I'm pretty happy with it and I should hopefully have it released as OSS by the end of October. A few notes, though:

• I do not have Xacro or ROS package support and I have zero desire to add any ROS to the loader. However, it does handle the file:// scheme and it does have a way for the user to add their own collision mesh loading.
• I have found that most URDFs are totally unusable inside of nphysics without some kind of collision filter. Many of the robot models are designed with assumptions about self-collisions (or lack thereof). Assuming Give access to body set in broad phase filter #278 is merged, I have a few filters included in the loader that will probably solve collision issues for the majority of robots with user-defined filters filling in the gaps.
• Some simulators (i.e., Gazebo) merge groups of fixed links. I'm sure there is some performance benefits for this, so I may include it as a loading option, but my loader currently doesn't do this. Mostly because it can be annoying when you're trying to find the position of a link that has been merged away.