Another useful feature that is relatively easy to standardize and implement is relative path for specifying resources such as meshes. As per URDF specification, the only way of accessing file is via the package:// URI, so to make sure that a URDF in an arbitrary folder can correctly load its meshes, you need to append some folders to ROS_PACKAGE_PATH or AMENT_PREFIX_PATH. Allowing relative paths, it would be possible to load URDFs without the need to have any environment variable defined. This feature is already implemented in URDF â SDF conversion (see Allowing relative paths in URDF by FracturedShader ¡ Pull Request #1213 ¡ gazebosim/sdformat ¡ GitHub), but it is not covered in the specification, so we could use that an an example of how relative path resource specification could work.
Whatâs the rationale for spending time improving URDF, if SDF has these features?
Wasnât the (implied) motivation behind ros/sdformat_urdf to allow SDF to take the place of URDF?
Edit: Iâm not saying I necessarily believe SDF is a panacea. The lack of support in industry standard tooling is a problem fi. But if the choice is between facilitating migration to SDF or updating URDF to achieve a limited form of feature-parity with SDF, perhaps the former is a more efficient use of everyoneâs time.
Thatâs a very important thing to figure out on the coordination level.
For me, the main difference was so far that it was somewhat easier to create URDFs than SDFs (friendlier syntax, fewer required elements etc.). But I agree the differences are so minor it might be best to merge both.
Another point to discuss could be the urdfdom library and why is it distributed via Debian packages instead of ROS buildfarm. I remember it took about 3 years to fix the bug with wrong parsing of floats on non-English locale systems. Thatâs unacceptable.
I am not sure if this is the right place, but what do you think about USD with the Physics schema?
It is open source, has great industrial traction (when Apple, NVIDIA, Autodesk + many others are on board with something, usually it makes sense to listen) and there is already a ROS-compatible implementation (NVIDIA Omniverse / Isaac Sim). I think it would make sense to add native support for this into the open-source simulators like Gazebo and Webots.
Should I open a new topic to discuss this?
Kind regards,
Gergely
Yes, I think this is a great idea. If youâd be willing to translate it from the wiki into Markdown and then open a PR in GitHub - ros/urdfdom: URDF parser , weâd be happy to review it.
From my point of view (that is both somebody that is mantaining a URDF model of a robot, and of a library that consumes URDF), the problem is that for various reason (including its simplicity w.r.t. to more complex formats like SDF or USD) a lot of community/users are using URDF. I may be a pessimist, but I doubt there is any effort that in the short term can make them switch to SDF or any other format.
On the other hand, I think that the effort necessary to solve existing issues related to URDF is worth the benefit in the short term, but clearly this is just my personal evaluation. Note that on the other hand I fully agree that it does not make sense to try to add new complex features (such as closed loop support, for example) to URDF, as those are already present in SDF.
Just FYI, there is already some support for USD in sdformat, see sdformat/README.md at sdformat13_13.4.1 ¡ gazebosim/sdformat ¡ GitHub and GitHub - gazebosim/gz-usd: Command line tools to convert SDFormat to USD and viceversa .
Great, thanks! Do you think it make sense to have it in urdfdom or a separate repo? I do not want to overcomplexify things, but I am a bit afraid of how to handle specification releases if we use the same repo of urdfdom repo. At the moment the current URDF specification is informally known as 1.0 (see urdfdom/model.cpp at 41838e1f3623e0538a402024b76f296dbbcbed9f ¡ ros/urdfdom ¡ GitHub), so I think we would like to tag releases like 1.0.x, 1.0.y and 1.0.z , while urdfdom is at release 3.0.0 (Release 3.0.0 ¡ ros/urdfdom ¡ GitHub), so that it would be a bit complex to handle.
Anyhow, the .xsd is already stored in urdfdom (see urdfdom/urdf.xsd at 41838e1f3623e0538a402024b76f296dbbcbed9f ¡ ros/urdfdom ¡ GitHub), so probably the easiest thing is indeed to also keep the specification there as well, and then to think about how to handle tagging later. We could do like for sdformat, in which there is the SDF version and the library version that are different, but they are mantained in the same repo.
Yes, this is exactly my thinking. The git tag on the repository is essentially tagging the code, while the version of URDF that is supported is in the specification and XSD.
My issue with splitting it up is that the set of URDF repositories is already highly fractured and hard to follow. Adding yet another repository wonât help with that situation. We can consider doing splitting it out in the future if we think that is worthwhile.
One way to address this would be to make either SDF a superset of URDF, or provide a âseamlessâ conversion at runtime. The first will likely not happen, the second seems already possible.
Itâs not a short term thing at all, I agree. But I donât believe we should be looking for a short term solution in this case. It would be a mistake to allow legacy or installed base to prevent actual solutions from being developed.
If a (belated) ROS 1 â ROS 2 (for robot modelling infrastructure) does not provide an opportunity for breaking changes, what would?
Sorry, I probably was not clear in expressing my point of view. I am totally for going for switching SDF in ROS/ROS2. I just think that we should also (meaning: I am happy to work on this, not âsomeone else should work on thatâ : ) ) fix some annoyances (not adding features) related to the URDF specification.
The goal of for the fixing the URDF specification issue that I mentioned is twofold:
- Fix problems in the short term, that I guess it may not be relevant in the long term, but is probably the main motivaiton on my side : )
- Help on the goal of âseamless runtime conversionâ of SDF, as some of the problems that I mentioned (clear specification, extensions, relative paths) could also impact any user that would like to migrate SDF.
Welcome to the jungle of robot modeling formats and converters! Here is a frightening schema:
XACRO â URDF â Gazebo SDF
XACRO â URDF â Webots PROTO
USD â SDF
I believe these different file formats deserve different purposes:
- visualization (URDF)
- control (URDF)
- simulation (USD, SDF, Webots PROTO)
XACRO adds some scripting capability on the top of URDF, which is also a feature of some simulation formats, such as Webots PROTO.
At each of the 3 levels described here, we need different type of information:
- visualization: meshes, materials.
- control: joint types, positions, orientations, lengths, hierarchical structure, etc.
- simulation: physics properties, bounding objects, device properties, etc.
This information is increasingly depending on the software or libraries using these file formats:
- visualization is pretty standard, in particular with respect to meshes and standard 3D model files (STL, OBJ/MTL, DAE). However materials can cause problems to some rendering software which do not support advanced features such as Physical-Based-Rendering (PBR).
- control also contain pretty standard information that most capable software library can interpret and use.
- simulation is obviously the more specific to the simulator used as it must contain additional information which is very specific to the simulator and/or underlying physics engine, such as device properties, physics engine parameters, etc.
The main question for a robotics developer is: âIn which format should I store my model to make it as universal as possible?â
Today, there is unfortunately no good answer to this questionâŚ
However, the current consensus is to store the model in XACRO format which can in turn be translated to URDF and then to Gazebo SDF or Webots PROTO using scripts and tools. But this doesnât work great and you will have to put some Gazebo and/or Webots specific information in the XACRO model using the <gazebo> and/or <webots> tags and probably fix the conversion scripts to adapt to the latest features of the simulators.
This looks fundamentally wrong to me. Mainly because these specific tags are useless at the modeling and visualization levels.
I would advocate the reverse approach:
- store the model in a simulator-specific file format (either USD, Gazebo SDF or Webots PROTO)
- from this format, you can easily export the URDF for visualization (RViz) or control purposes.
To make this approach more universal, we should probably put the effort on developing converters for converting between different simulators: USD â Webots â Gazebo â other simulators, and drop the <gazebo> and <webots> tags from the URDF models. As a bonus, we could also drop XACRO, as its functionality should be implemented in USD / Gazebo SDF / Webots PROTO. Finally, we could also use a simpler standard format for exporting 3D visualizations/animations, such as Collada, X3D, etc.
IMO, that approach would greatly simplify the developer workflow and help the community to focus its development effort on tools that will become more and more efficient and easier to maintain.
This is actually not the best approach. Our robots have the following structure:
- robot_description/urdf/model.xacro
- robot_gazebo/urdf/model.gazebo.xacro
This way, you easily split the sim-specific things to a separate package. We could even have a separate xacro for new Gazebo and one for classic Gazebo if the differences are too big. You can easily extrapolate to PROTO/USD. Each simulator can have its own extras file, but all of them would be based on the same kinematic structure defined in robot_description.
Of course, it would be even better if you could just convert the base URDF to SDF and then write the gazebo-specific tags directly in SDF. AFAIK, this is not possible now. But Xacro with <gazebo> tags is âalmost SDFâ 
I would not. Letâs make ROS as accessible to newbies as possible. Usually, creating a valid (not even speaking about functional!) simulation model is usually much more difficult than creating just the URDF with kinematics and maybe meshes. I still like the idea of building the robot from the bottom up.
With the sim-first approach, you would hit a different scale of problems - how would you encode Webots-specific tags in a Gazebo SDF file?
I think that USD is much more than just a format for robotics simulation data (and I would argue that it is not simulator specific, even though currently only NVIDIA Isaac Sim implements it):
- it provides great ways with its payload and overlay support for large teams to work together on complex worlds/simulations
- it already allows importing data from commercial CAD software to make the creation of true âdigital twinsâ easier
- And not just for the robots themselves, but most commercial Architectural CAD packages already have USD export functionality.
So it becomes very easy to take the CAD model of a Warehouse/Factory and the CAD model of the robots that are supposed to work in there and run simulations while both the robotics engineers and the architects are working on their side of the project.
My ideal workflow would be:
Robot design in CAD â Digital Twin in USD format â URDF for ROS2 integration.
Thatâs a proffesionalâs workflow. My view is that ROS has always tried to be as open to newcomers as possible. Being on the proffessionalsâ side, however, was always a problem in ROS 1 as many things were just âas someone wrote themâ. I agree that one of the main goals of ROS 2 was to get closer to the proffesionals. But still, hobbyists and students are a key part of ROS community and their use-cases should be considered with a similar weight as the proffesionalsâ ones. There is maybe no single âcatch-them-allâ solution. Maybe both ways (bottom-up and top-down) have to be supported.
Iâm joining late on the wagon but I stumbled upon this discussion and I have been using urdf/sdf for years now so here are some issues Iâve identified that would need improvement in my opinion.
There are probably some things that I might have misunderstood and that could be solved with better documentation / tutorials.
Some context:
Iâm working on the robot Miroki from https://enchanted.tools/, it has spherical joints for the hands and is mounted on a rolling globe.
- Allow to load meshes from a relative path to the urdf file location.
If I understand correctly, the general flow is to load urdf via robot_state_publisher, listen for some JointState messages and publish transforms that are then used by rviz.
Since Rviz can either listen to a topic containing the urdf or load it from file, it means that when read from a topic it has no idea where the file on disk was loaded from. In this situation it makes sense to use a package:// url for the meshes or absolute paths.
But for all other cases, the loader knows the path to the urdf file so it should be able to load the meshes relative to this file.
One solution would be to give an option to the loader to replace at load time relative path to absolute path, this way when the URDF is published on a topic by robot_state_publisher it has absolute paths.
Also there are some third party tools like foxglove studio or the vscode extension outside of ROS that were forced to support the use of the âROS_PACKAGE_PATHâ or similar stuff to allow loading urdfs. Allowing relative meshes here would solve this workaround.
- Versioning and distributing urdfs / xacro
The portable and common way to share urdfs is to use create a ros package ârobot_descriptionâ containg some xacro/urdf code.
Here the workflow isnât clear for me:
- should you provide only xacro code versioned in git, and let the cmake commands of the package call xacro to generate the final urdf/sdf files ?
Personnally I think itâs wrong to have to regenerate the files on each build, or even worse on each launch, iâve seen some launch files calling xacro at runtime.
We should be able to share the final generated urdf file without the need for the user to recall xacro to generate it.
Maybe here it would be great to have some kind of âtemplateâ robot_description package, that is linked to at the end of the urdf/xacro tutorials. It could even be a special verb when creating a package:
ie ros2 pkg create_description [robot_name]
- Support for spherical joints
Since urdf is often used for visualisation, I donât see where is the limitation for visualizing spherical joints, as loong as there is a TF published, rviz and other tools shall be able to display them without issues. So the issue isnât for display but for computing the TF from a joint position.
This issue shall not be a limitation in the URDF format itself since itâs a limitation in the KDL library if I understand correctly.
The user shall have the possibility to not use robot_state_publisher and compute/publish their own transforms if needed.
-
Support parallel linkage
Same argument than for the spherical joint, if the limitation is in KDL it shoudlnât impose a limitation on the file format itself. -
Support âweightlessâ kinematic links like in SDF
Here the similarity between URDf and SDF is kind of an issue, and I tend to prefer the way SDF does it.
Iâve seen some urdf files with dummy masses and inertia matrices in some links that were definitely only purely kinematic. If I understand they were put there because the urdf to sdf converter doesnât like empty inertia matrices, Iâve found the minimum weight to be like 1e-5 kg.
So iâm not sure if the URDF standard allows to have no mass/inertia attached to a link and this is a problem of the CAD export tool / urdf â sdf converter. Maybe I misunderstood.
Thank you for your time reading this. I hope Iâm not totally of topic here.
Just highlighting here another post related to this topic: Short-term WG about URDF / description formats . Anyone who has the will to give URDF some time and discussion is welcome.
URDF is not only for visualisation. Aside from <visual> there are also <inertial>, <collider>, we have <joint> tags and so on.
The formatting probably ate some XML tags in your post. Can you please update it to fix the formatting?
I have quite extensive experience in using URDF (w/ and w/o xacro) and SDF for simulation, control, and planning purposes. Many discussions I was part about description formats always reached a consensus that can be summarized as: SDF is a great description format what can do everything URDF can with added features on top, but that XX tiny library that cannot be replaced with anything else does not support SDF so eventually URDF has be used for the entire software architecture.
I agree that SDF has a lot of features related to simulation, but today it seems to be the better maintained solution among all with better tooling. On new projects, when it is possible, I typically tend to support SDF since any URDF can be easily converted to SDF.
I think that here, similarly to the formats of meshes, there is no silver bullet. Iâd really love to see someone taking the responsibility to start the development and guide the community towards a shared effort to obtain the corresponding counterpart of assimp. I have never seen any concrete proposal nor any shared desire to converge towards a single solution, and a rosetta stone / intermediate representation probably is what would make everyone happy without asking to alter significantly the software infrastructure.
The golden solution would be supporting exchangeable descriptions among:
- URDF
- SDF
- Mujoco XML
- USD
- glTF (future physics extensions)
Of course, there are solutions that will not be 100% compatible.
A byproduct of such tool, is being able to perform model verification (too often Iâve seen custom parsers that handle elements using custom approaches), and to some extent model processing (e.g. lumping links together, inverting the kinematic tree by changing the root link, etc.).