A few years ago I helped open source a URDF Loader library for both Unity and three.js along with an accompanying webpage to view URDF files with drag-and-drop functionality. It was recently found on Twitter and I was told I should share it here!
The repo includes example models of JPL’s ATHLETE robot in a variety of configurations, so a big thanks to the ATHLETE team for supporting this, too.
Web Based URDF Viewer
You can view and use the web viewer here! The page should work on any platform, though folder-drag-and-drop is only available in chrome, and can be used to preview a URDF file. Of course you can use the loader as dependency, as well, to load models into your own applications.
A less advertised feature of the web tool is that you can also drag to manipulate any single degree of freedom joints in the system:
At JPL we’ve adopted the URDF format for some non-ROS-based robots to tap into a de facto standard and easily swap between robot models. Internally we are building a variety of web-based operations and validation tools for upcoming missions including the Mars 2020 Perseverance rover and will be using this library to help view and drive our rover. We hope to open source more of our work for these tools to share with the community in the future!
I should use this moment to say that there are a few shortcomings of the URDF spec that we would love to see addressed in the future that other formats do not address or are otherwise unsuitable for. Specifically support for parallel joints and support for more geometry formats. We’ve been able to work around these limitations for the moment but it would be great to see URDF evolve into a more universal description (heh) for use inside and outside of ROS to more fully describe the types of kinematic systems that are often used in hardware. As much as possible we want to avoid writing our own new file formats and variants. We’d love to discuss more if there’s a proper platform for it!
I’ve seen quite a few web-based robotics tools and projects take advantage of the loader and I know our team is excited to see what people do with it and how people benefit from our work. I’d be elated to see how people use this so feel free to share your use cases, submit issues and feature requests, and share if you’re able to use it! Please enjoy!
Thank you so much for all publicly available work everyone has put into the community! I hope everyone is staying safe.
This is not too well known, but there isn’t really anything in URDF which prevents you from using mesh formats other than .stl, .dae and .mesh.
As long as the mesh loader which eventually gets to load the mesh can deal with it, you could load anything you’d need/want.
Typical loader would be Assimp, and essentially anything Assimp can load can be used (I’ve got models which use .fbx fi). It won’t always be pretty, and there are some rough edges, but you’re not limited to plain .stls.
Note: this really only means mesh data. It won’t extract bones or joints from files which support such metadata.
This is not too well known, but there isn’t really anything in URDF which prevents you from using mesh formats other than .stl , .dae and .mesh .
Yes structure of the format itself doesn’t prevent it – my tool here allows for overriding the the load mesh callback to enable loading any geometry format. It does look like RViz uses ASSIMP to load geometry so this may just be a matter of updating the docs. The URDF spec document makes the geometry format support sound very limited (STL and DAE only):
The recommended format for best texture and color support is Collada .dae files, though .stl files are also supported.
If there are no objections it would be great to update the docs to say that the mesh file extension is flexible but of course compatibility is dependent on the application – most or all reasonable file formats would be supported in ROS via ASSIMP, though. This would enable and encourage users to use more efficient and more generally compatible file formats for their models.
We’re using GLTF and GLB and in some cases PLY for our models for a variety of reasons and at least on the surface it looks like we’re creating out-of-spec and ros-incompatible models which seems to not be the case and something I want to avoid.
What would the right way to get the URDF wiki updated be?
You mean the javascript library loading the meshes? Not in any of the ROS packages, correct?
Yes, I’d say updating the documentation would be fine.
Especially in the way you suggest (“compatibility will depend on the application loading the urdf file”).
Well technically the “only” thing needed to edit the wiki would be to register for an account (and then request write access in ros-infrastructure/roswiki#258).
I write “technically”, as there is another aspect here, which is how compatible this is with “older versions of URDF”.
I don’t believe that’s a problem here though: Assimp has been used “since time immemorial” in ROS to load meshes, so I believe using formats other than the three listed now is supported on all supported ROS releases.
Edit: also related (and very nice): it seems Ubuntu Focal comes with version 5.0.1 which supports .zae, which is compressed Collada (assimp/assimp#2545). That potentially saves up to 90% on mesh (and typically also ROS package) size.
You mean the javascript library loading the meshes? Not in any of the ROS packages, correct?
Correct I mean in this javascript package.
Yes, I’d say updating the documentation would be fine.
Especially in the way you suggest (“compatibility will depend on the application loading the urdf file”).
Well technically the “only” thing needed to edit the wiki would be to register for an account (and then request write access in ros-infrastructure/roswiki#258).
Great! I’ll make an account and propose the change in the wiki. It seems like a safe change to make.
If I’m understanding right people are proposing replacing URDF with a GLTF variant that includes joint and other kinematic features? To be honest it sounds like a huge mistake. We should let GLTF (or any mesh format) be good at what it’s intended for – storing geometry data – a let our kinematics format be good at storing kinematic information. Otherwise we’ll be stuck chasing every new geometry format that comes out trying to inject robotics use cases into something that wasn’t originally intended for that. As it is URDF is immune to the changing world of graphics formats and can be evolved to represent structures that GLTF’s tree hierarchy isn’t designed to support. It’s also human readable, easier to write / modify, and is supported via Xacro generation.
URDF has some shortcomings I would like to see fixed, too, but I’d rather see those problems addressed in a format many people are already using, that the robotics community has control over, and has a well contained scope. I’m relatively new to this community still and maybe have some unconventional use cases but I’d be interested in being involved in these discussions if possible. I suppose that just means keeping an eye out for URDF related discussions because there doesn’t seem to be an centralized place where this problem is being discussed. I’ve been waiting for years for movement on URDF2 to support closed chain kinematics but there never seems to be any progress there.
Edit: also related (and very nice): it seems Ubuntu Focal comes with version 5.0.1 which supports .zae , which is compressed Collada (assimp/assimp#2545). That potentially saves up to 90% on mesh (and typically also ROS package) size.
Heh, yeah my thinking has evolved since then and I’ve gotten some pushback that we’re not creating to-spec URDF files because of the mesh format so I figured I’d mention it again. I appreciate you sharing your expertise in this area a second time.
I have taken a look at ZAE but it’s a bit obscure. We’ve chosen GLTF because the memory footprint is pretty compact and parse time is very fast especially in browsers. It’s pretty well supported now, too, so it’s easy to generate and look at.
Well technically the “only” thing needed to edit the wiki would be to register for an account (and then request write access in ros-infrastructure/roswiki#258).
Thanks for your help – I’ve just made the change to the URDF Link page to update the wording for the mesh field. Here’s the change (diff):
A trimesh element specified by a filename, and an optional scale that scales the mesh’s axis-aligned-bounding-box. The recommended format for best texture and color support is Collada .dae files, though .stl files are also supported. The mesh file is not transferred between machines referencing the same model. It must be a local file.
to
A trimesh element specified by a filename, and an optional scale that scales the mesh’s axis-aligned-bounding-box. Any geometry format is acceptable but specific application compatibility is dependent on implementation. The recommended format for best texture and color support is Collada .dae files. The mesh file is not transferred between machines referencing the same model. It must be a local file.
Any feedback on wording and clarity is appreciated. It might be worth mentioning GLTF alongside COLLADA as a recommended format for textured models if there’s an interest within the community in using it.
