There is some nice discussion on how to improve the current URDF format and parsers to fill some immediate needs.
This topic is for questioning everything and discussing what the perfect way to share and reuse information about a robot might be.
What needs are there? What assumptions can we make?
A short list of the needs fullfilled by a robot description:
Save time by not having to think about and create a project specific description. (Accompanied by the risk that the description designers made provisions to handle all aspects of a description that your project needs.)
Share a description for reuse by others. You and the peers you are sharing with must agree on the meaning of some subset of the information in the description.
Share a description between different softwares. By using a single description, errors introduced by data entry mistakes are eliminated. DRY.
what else?
A short list of things we need from the description:
Easy to create and edit across all platforms.
Minimize difficulty in integrating the description into new codes/languages/platforms.
A starting set of description information that is useful and whos meaning is agreed upon.
The ability to be extended as needed with project specific info.
The ability to be formally extended by the community as progress maches forward.
Considerations:
The descriptions are primarily created by people and the one tool in common across all platforms is the text editor.
The descriptions are primarily consumed by software.
What is this robot we are describing? What information do we need to share?
What counts as a robot really? For the purposes of this discussion a robot is any physical device whose interaction with the world is sensed, processed, and acted upon in an intentional manner.
For instance, some robots can be described as a set of rigid bodies and constraints on those bodies. Others include soft bodies or flexures. Nonlinear constraints (such as joint limits) and losses (transmission inefficiency) are often known or estimated well enough that we want to include them in the description. Sometimes the constraints are simplified to the joints between bodies and described in the manner of a graph.
Thoughts
Myself, I use URDF only when forced to by the tools needed for a particular project. I prefer an embeddable scripting language (lua, python) for the description. Cleaner than XML for editing and one has callback functions for non-linear or heuristic information. If you are unfamiliar with this approach, RBDL has a nice basic example.
Sounds great right? However I donāt get any of the benefits of a well designed and dessiminated format.
Any given description is usually project specific (No standard object model)
Only my internal software reads the description, so not a lot of reuse between software.
No reuse between peers either. As a consultant an annoying amount of my work is confidential.
The big question:
I see enough frustration in the world with the limitations of URDF that itās clear that there is a need for something more. What does the next generation of robot description look like?
XML was intended as a language primarily for computers to work with, with human readability as a bonus. The lack of tools for creating and editing URDF files in a more suitable interface is the problem, rather than XML, in my opinion.
A YAML format for URDF would probably be as readableandcwritable as the RBDL format you mentioned.
Does the use of a scripting language provide any other benefits, such as programmable features? That would be an interesting concept.
I agree that there are nicer, more suitable interfaces for creating and editing the robot information. However, ASCII text is a format that almost everyone on almost every platform can edit. No one has to wait for the editing tool and all itās dependencies to be brought to their platform.
I prefer YAML to XML for static data files as well. The RBDL uses the Lua programming language. (The RBDL format is Lua).
Yes. If the definition file is used statically and only loaded from disk, then the language can be used to encapsulate concepts, deal with repitition nicely, and increase readability. For instance, if one wanted to specify their link parameters in terms of of Denavit-Hartenberg parameters instead of xyz-rpy, one would just insert a small function at the top of the file to do the conversion.
If the definition file is used dynamically, then one can write functions in the programming language that are called by the code using the file. For instance, one could have a joint_friction(joint_number, joint_angle, joint_velocity) hook function defined in the config file that would get called during simulation steps.
It would be nice to have URDFās in python, like how dynamic_configure files work.
That way it is not yet another language to learn.
The robot description would be much cleaner, you could support generating the description from parameters. This is useful for highly configurable robots such as the turtlebot, which currently hack this functionality into the existing xacro/urdf system.
We should have the gazebo people and the ROS-I people as part of the discussion. @Paul_Hvass and I been discussing this topic for a while. It would be good to have one format for all of the ROS / Gazebo projects. SDF was something that we thought could be the format. There is a long thread on this on the old google groups.
@rohbotics You can see how creating URDFās in python can work in practice with https://github.com/hauptmech/odio_urdf. I wrote when I needed to deal with non-trivial URDFās. I find working with XML directly (editing the files) unpleasant. The idea that one would write a python script to parse and execute a language embedded into xml (ie xacro), rather than just using python directly, confuses me to no end. But Iāve seen colleagues invest a lot of time and frustration using xacro to try to solve the problems they have with the URDF format so I guess it makes sense to some.
Though perhaps Iām misunderstanding you. Do you mean instead that youād like to see a dynamic_configure API? A robot_model node that you can dynamically update using dynamic_configure instead of a static xml text robot_model parameter?
EDIT: It seems the general consensus is to standardize on the SDF format. That seems like a sane iteration of the current situation with ROS and Gazebo.
I started this thread hoping for some discussion on, well, next generation robot descriptions. Harmonizing current formats (URDF/SDF/etc) is a really important discussion for the community; but thatās really about cleaning up the current generation.
Thatās why I brought up the Python description format.
ROS2 replaces XML launch files with Python ones, I think that it makes sense to do something similar with URDF the other source of XML pain in the ROS ecosystem.
Looks like your stuff generates XML and sends it out to stdout and eventually into the robot_description parameter to be used by robot_state_publisher.
I think for the next generation of URDF, I would like to get rid of the XML entirely (if possible) and have the Python code actually act as robot state publisher and send out the description data on a latching /robot_description topic, as well as tf data.
As for the actual format, I like odio_urdf but I havenāt looked at it very closely.
Yes, that code is specifically for the URDF way of describing robots. The internal hierarchy of objects mirrors the URDF elements, and each object has a string representation that matches the URDF XML.
Iām having a hard time picturing why one would want to do this.
There are many uses for a robot description that have no need for ROS IPC.
Also one could argue that the state of the robot should not be part of itās description. The simbody user and theory documentation has some nice discussion of this, though with a focus on simulation and the simbody implementation.
Iām not sure python would be an ideal choice for describing a robot. Python was not designed to be a data exchange language. In addition, web applications, which can parse XML, would have a hard time with python.
Hi all, it seems that there is interest in figuring out what to do ASAP for ROS2, which was not the point of this thread. Iāve started a topic for URDF2/SDF2 and Iāll link in the external discussions mentioned above so there is a good start for that.
Describing flexible link robots? Reconfigurable robots? Soft robots? Able to wrap your head around configuration languages, or why a shared object file with an API might make a good reuseable, shareable robot description? Continue below.
Iāve always found a lot of value in a non-interpreted interchange format, like URDF or SDF or even HTML or JSON. So, for me I donāt like the idea of a description format that exists only in an interpreted form (like as Python or Lua).
Itās convenient to have these tools when writing the descriptions, but very inconvenient when trying to consume the description in many different places. I think a good middle ground is like what we have with xacro + URDF. You might have issues with either xacro or URDF, but I think a good idea that came out of that is to pair a well established interchange format with ātemplating-likeā tools to make it easier to create the description by hand or programmatically. This is reflected in things like web development, where the interchange format is HTML, but commonly the server will use a scripting language to generate the otherwise tedious to specify XML content.
I think a key part of an interchange format is that itās content is very clear and easy to grasp and process by all. A simple declarative text file certainly achieves that.
The strength of that approach is that when in inevitable need for dealing with repetitive and formulaic declarations arises, you can use xacro and I can use assembly and everyone is happy.
So I agree there is a strong case for a non-interpreted format.
Can you elaborate on what about an interpreted/script interchange format worries you? The second you touch ROS (or xacro) you are loading the python library, so the memory/processing overhead canāt be the issue. Configuration scripts usually have a minimum of ācodeā in them (cmake being an ugly exception) and thus a minimum of patterns or idioms that are tricky for the new user, but perhaps that is the concern?
Is this what you would choose if you had a blank slate going forward? Is there anything you would want to see change or improve?
If the data exchange (previously I used interchange, which I think is not the correct terminology now) format is a script or interpreted then everyone who uses it needs to have an appropriate interpreter loaded and any context that might be used in the script. For example, RBDL requires everyone that needs the description to have a Lua interpreter. Lua is by no means a heavy requirement, but there are plenty of platforms where that would be inconvenient at best, for example loading the description in a webpage (couldnāt find a Lua vm in javascript) or iterating through the links in Matlab (couldnāt find one here either), neither of which have a native way to hook into a lua interpreter. You can always parse the description lua file in C++ and then serialize the in-memory āobjectā to send it to a browser or to Matlab, but then you just have an unofficial data exchange format.
Even if you manage to get an interpreter at each place where you want to use the description then youāre likely to need some additional context to be available at each of those places too. Because the description script can have logic in it, itās a natural extension to want to use command line arguments or environment variables or something else to modify the resulting description. You could limit this functionality, perhaps RBDL does, but this is a core utility that people use in xacro and really need to make it easier to describe robots with lots of optional configurations. If you have no static intermediate format, then this context needs to go along with the description script so it can be given to the interpreter at each end point where the description is consumed.
Why do you need python to touch ROS? I can write a URDF without using xacro and load it with a pure C++ library. In fact Iād argue that having an intermediate format that is data only would considerably reduce cpu and memory overhead compared to an data exchange format that is interpreted, especially when being consumed in several places.
I would prefer an explicitly defined data exchange format for the description that is data-only (probably XML or JSON) and then pair that with a prefered templating interface (xacro, erb, empy). That way consumers of the description can remain as simple as possible and the developers who are creating the descriptions have tools to help them with authoring. It would be great to have a āpreferedā or āprescriptedā template engine to use, that way tools could be built to understand them, but by leaving that unspecified developers get the freedom to use whatever template engine they prefer.