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.
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:
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.
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.
It is clear that the URDF needs an update. Here’s a minimal set of new features that have to get into the URDF.
In the following, the individual points will be discussed and solutions will be suggested respectively.
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.
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.