So I have just consumed most, if not all, of the discussion so far (hurray for lazy Fridays) including the recording of the meeting. Here are a few observations:
All the formats seem to have arisen from fire-fighting small problems in small problem domains rather than intentional design. Everyone participating in the last year of discussions is representing their stakeholders and their requirements; but the conversations seems to be “How can we make the current robot description techniques less broken?” rather than “What set of stakeholders and requirements will give us the best foundation for the future?”
Given the number of people volunteering to do anything, moving to and incrementing on SDF seems like the best bet.
At the heart of a robot description, the most important thing is that the mental model, and any given element of that model, is documented in enough detail so that you, and I, and everyone else understand the context and agree on what the element is. After that we need a defined data representation, with a common, easy to implement format being nice to have.
I’m seeing a general confusion between configuration (robot A has a gripper and robot B does not) and the dynamic state of things (robot A picks up an object and we add a rigid constraint between the pose of the EE and object to represent that). There is nothing wrong with bootstrapping any dynamic models with the robot description, but they are a different thing.
There was some discussion about moving the robot_description parameter to a latching topic. Fine idea. Outside the scope of a robot description format.
The robot description is a storage/wire format. There is a point in time when all data retrieval and parsing is finished at which point there is a robot model in memory. What happens after that point is application specific. Declaring which end effectors are available is part of the robot description. Signaling the switching of tools or the mounting of a tool at t=0 is not part of a robot description.
There has been some discussion on compose-ability, extensibility, and whether a core description (or well defined sub-descriptions) should be used. Dependency hell issues were raised with regards to plugins, URI’s and the like.
I don’t have anything new to add to that discussion. The core description thing seems to be an artificial issue created by assumptions about the responsibility of the tools using the description to their downstream users. The robot description should not care about those third party consumers. Any parseable and coherent subset of the robot description should be fine.
Dependency hell is not a reason to disallow dependencies. If managing external connectivity or packaging of multiple elements is beyond your project, then you should keep everything in one file.
There was discussion about xacro, template engines, and GUI editors. I think these are outside the scope of the robot description, beyond indicating a format that has good libraries available.
One final observation is that while it appears that SDF is the easiest path, the SDF creators have a mental frame that constrains their thinking. Nothing wrong with that, but it’s worth taking a careful survey of others using rigid body robot models. People deploying robots in experiments or the field. People transferring CAD or optimizer designs. I think most types of users have been participating in the discussions so that’s good.