The URDF (Universal Robot Description Format) has not been updated in quite a while. Although it has served the ROS community admirably, it has several notable shortcomings. In this effort, we will try to modify the URDF specification to catch up with the needs of the ROS community. There are two parts to the URDF: (a) The XML format itself, (b) The URDF parser.

This document currently addresses only the URDF format itself.



SDF Format

The SDF or Scene Definition Format was defined for the Gazebo simulator and has become fairly well standardized for Gazebo. It is a viable alternative to the URDF although it comes with several pros and cons:

  1. It exists and has been used and developed for a while.
  2. It supports multiple robots (in a world).
  3. It includes support for several types of sensors.
  4. It includes support for storing state of the robots and the world.
  5. It supports closed loop chains.
  6. It includes a C++ API.
  7. It is now fairly independent of Gazebo.
  8. It uses XML.
  1. The SDF has several simulation specific parameters.
  2. It does not support groups.
  3. The SDF is designed to support simulation worlds. The URDF was designed to support a single robot.
  4. The SDF has no support for specifying hardware parameters.
  5. The SDF cannot be exported from any CAD software today (AFAIK).


Collada is a new format that has started to become more accepted. It is widely used in ROS for certain robots as well and is well-supported in OpenRAVE too. It has its own pros and cons.

  1. It exists and has been used and developed for a while.
  2. Several CAD software packages can export COLLADA files.
  1. It is not very human readable.
  2. There is no support for actuators/transmission specifications?

SMURF & SMURF scenes

The Supplementable, Mostly Universal Robot Format (SMURF) was designed as an extension of URDF and alternative to SDF and is described on the github page of its parser. The basic idea behind its design was to keep URDF to stay compatible with current software tools and extend it in a human-readable and modular fashion, thus the use of YAML and distributed files.

SMURF scenes or SMURFS were designed to allow arranging multiple SMURF entities in a world, similar to SDF (see the file format page of the MARS simulation software, a simulator similar to Gazebo). The same modular principles apply as with SMURF itself: A robot is defined once in its SMURF definition, SMURF scenes merely describe how SMURF entities are placed, avoiding redundant definitions.

URDF 2.0

It is clear that the URDF needs an update. Here’s a minimal set of new features that have to get into the URDF.

  1. Multiple robots - The URDF currently supports a single robot tag. We compose multiple robots into a single robot description by using Xacro and manually adding joints between robots, i.e. we treat a collection of robots as a single robot. MoveIt! uses groups to then allow users to address each part of the robot as a single entity. It is not clear that the URDF needs to allow multiple robot tags. However, there is a need for being able to parse some world description and know all the robots that exist in the world.
  2. Closed loop chains - The URDF must be able to support the specification of closed loops, e.g. four-bar linkages or delta robots.
  3. Groups - URDF should natively support the specification of groups (user-defined sets of joints). This will significantly reduce configuration effort for upstream elements, e.g. MoveIt! or ROS-Control and also ensure consistency, e.g. there are too many places where lists of joints are currently specified in config files.
  4. Sensors - URDF must include support for the most commonly used sensors.
  5. Zero State/Default State/Saved state - The URDF should include support for specifying the initial or default state of a robot.
  6. Versioning - Support for versions.

In the following, the individual points will be discussed and solutions will be suggested respectively.

Modular structure

The SMURF format uses a modular structure, allowing to hierarchically combine definitions of sensors, motors etc. for a model. This facilitates re-use of definitions. For instance, a specific laser scanner would only have to be specified once and could then be used in all robot models using that hardware; the model could even be provided by the manufacturer. Definitions of robot components can be stored in repositories (possibly also provided by manufacturers) and simply checked out when needed for a model, making handling and updating of models a lot more efficient. Having such centralized model repositories would also simplify resource sharing between ROS, Gazebo and other tools.

In case a specific model would have to change a component’s properties from its default values found in the git, a project-specific fork or branch could be created, or properties could be overwritten locally without having to change the linked file, as it is currently already possible in SMURF.

World Specification

URDF only describes one robot, but no environment or other robots and objects. There is a fundamental functional difference here: URDF is supposed to describe the “blueprint” of a robot and thus contains no states of joints, motors etc., whereas a world format will need to describe specific states of all entities in it, including those of robots.

To avoid both redundancy and behemoths of files, it makes sense to link to individual robot definitions from within the world definition. This is the case in the SMURF scene format developed for the MARS simulation. Similar to SMURF itself, a list of ‘entities’ is defined, each linking to a file specifying where the actual definition of the respective entity is found. This allows for instance to have separate robots or other environment objects in separate folders under (git) version control and combine them into a scene without having to update the scene when the robot definitions get updated.

However, the file tag in SMURFS is simply resolved by the parser, so that all contents of the specified file are added to the entity definition at parsing time, thus making it perfectly valid to not link to a file and simply directly define an entity in the scene when needed.

Every entity has a type, in the case of a robot defined for MARS, this type would be SMURF. In MARS, this makes it possible to create plugins for the simulation providing a factory for specified types and thus making the SMURF scene format easily extensible.

Additionally, assigning a name to each entity would allow to simply link the same file and thus the same robot definition multiple times in the same (world) context, providing namespacing of all components defined for each robot, such as joints, motors or groups.

Moreover, it would easily be possible to attach one entity to another entity via a specified joint, enabling assembling a complex robot from simpler parts such as legs and arms or switching tools such as grippers on a robot. Currently, SMURFS includes only a simpler variety of this, allowing to anchor a robot to the world with a fixed joint or let it move freely. Since URDF joints already include a fixed and floating type, this could easily be replaced and extended.

For all the nice structure and flexibility SMURF scenes provides, they currently do not specify anything beyond entity lists. Yet worlds should contain other specifications, ranging from physical properties such as gravity vectors and friction parameters, over purely graphical elements such as background sky boxes or HUD elements. Such properties are already well-defined in the SDF World format and should not need to be reinvented. The same goes for the planning-relevant data defined in MoveIt! Planning Scene.

One issue that has to be decided is the use of XML vs. YAML: SMURF uses YAML, while SDF uses XML. While XML has been around for much longer and there are extensive sets of tools available for it, YAML is much more human-readable and slimmer. Due to similarities in syntax, YAML is also very easy to work with using Python dictionaries. Since Python is used extensively in ROS, this would simplify a lot of use cases.

Proposed Solution

Closed loop chains



Robot State