[URDF-NG] Next-generation robot descriptions

[hauptmech]

@de-vri-es

There is a big difference between using a python tool and having to embed a python interpreter in your own program. For starters the tool is completely optional, and there are actually cases where I didn’t use them.

Embedding interpreters is not that bad, comparable to adding a parser for XML, depending on the interpreter. I spent a little while above convincing myself above that declarative text is better but when I look at the total ecosystem, the total workflow, I’m not sure. Meanwhile many would never have to embed; as they are just writing descriptions and letting robot_state_publisher and friends do the work.

@de-vri-es

Additionally, having an interpreted description format introduces the risk of malicious robot descriptions abusing exploits in the interpreter or surrounding process.

The security aspect is very interesting. Probably especially important as something like ROS Industrial gains traction. Depending on context, sandboxing the interpreter would make sense. Same as with xacro. Signed config files (regardless of format) will become more common I would expect.

@de-vri-es

It would also force the use of a specific scripting language while with current URDF you can use whichever scripting language or template engine you want.

Yes, it would force a language, just like XML, and to be honest, I don’t really love any of the candidates. But python is the scripting language of choice for ROS, and very lightweight python engines exist, so that would be a strong contender.

@de-vri-es

I’m confused by this train of thought. To me, shared object form or any other binary format is “favouring the machine”. Binary formats are generally more compact, easier to parse and arguably easier to generate from code. They are also very difficult to read by humans, let alone edit.

I was observing that since the complexity of a URDF is often enough that people will use a language (xacro is the common one now I guess) or an GUI editor, maybe there is no real benefit to the text file. No text file might simplify all the readers. Just thinking outside the box here. (ELF is not an idea that will survive, but it does intrigue me.)

The ultimate goal is to have a definition that everyone knows how to read and agrees what the meaning of the sub-bits is. That’s what the URDF is. So when trying to design a format, we take a step back and look at all the producers and all the consumers and try to see where the overlap is the densest. Maybe it’s a text file, maybe it’s a text program, maybe it’s a binary file, maybe it’s a memory image.

Almost everyone consuming the description will parse it and map it into a data structure. For many of the consumers, the same data structure will work fine. A GUI editor would probably work directly with that same data structure. A very simple console editor could work with that same structure. And anyone wanting to create the structure without the GUI editor could certainly throw together a shell script using the console editor.

There are pros and cons. Equivalents in common use are the windows registry, gnome configuration, and there are certainly frustrations when one can’t just use a text editor.

@de-vri-es

However, I also agree with @jon that the most important question first is “What should be in the robot description(s)?” and not what format(s) will be used to store it. The latter is a technical detail (an important one, but nevertheless).

Yes, I hope the other thread picks that up.