ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

While it's certainly possible to update link lengths in parsed URDFs (it's just an in-memory representation of the xml based file format after all) there are two problems with doing that:

  1. even though robot_description is (typically) a "global" parameter, changes to the in-memory representation local to one consumer will not be forwarded (or persisted) to the parameter automatically. But even if they did, then ..
  2. none of the (officially supported) consumers of URDF expect robot_description to change at runtime, so they don't typically check the parameter for changes nor parse it again to update their internal model, not even if those consumers are found inside the same process (ie: node)

This connects to a much wider discussion about the (perceived) immutability of URDF that has taken place at venues such as ROSCon and the robot description formats category on ROS Discourse.

Note that comments typically focus on URDF and how this is a serious problem with it, but I don't necessarily agree with that: keeping state consistent across multiple, asynchronously participating entities in a distributed system is just not a solved problem. The same issues would arise when using SDF for instance (although that format would solve a few others).

There are certainly avenues to explore (I'd still like to take a closer look at usd fi), that will take time and someone (or someones) will need to spend that time to investigate a replacement

While it's certainly possible to update link lengths in parsed URDFs (it's just an in-memory representation of the xml based file format after all) there are two problems with doing that:

  1. even though robot_description is (typically) a "global" parameter, changes to the in-memory representation local to one consumer will not be forwarded (or persisted) to the parameter automatically. But even if they did, then ..
  2. none of the (officially supported) consumers of URDF expect robot_description to change at runtime, so they don't typically check the parameter for changes nor parse it again to update their internal model, not even if those consumers are found inside the same process (ie: node)

So I believe the answer to your question would be "yes, it is supported, but probably not in a way that would fit your use-case".

What is typically done is to write a custom, purpose-built calibration node that as its input takes a URDF / xacro, performs a calibration and then outputs an updated URDF. An example would be the robot_calibration package fi -- although that focuses on robots (ie: kinematic chains) specifically).

What could be an alternative to updating URDFs themselves -- which is very limiting as you would not be able to (easily) output xacro fi -- could be to use xacro's yaml support: place offsets and distances / link lengths in the .yaml file and have the calibration tool update/output that.

That would still need a restart / reload of any URDF consumers, but .yamls are much easier to read/write by both humans and machines than a potentially unlimited nested xacro hierarchy.


This connects to a much wider discussion about the (perceived) immutability of URDF that has taken place at venues such as ROSCon and the robot description formats category on ROS Discourse.

Note that comments typically focus on URDF and how this is a serious problem with it, but I don't necessarily agree with that: keeping state consistent across multiple, asynchronously participating entities in a distributed system is just not a solved problem. The same issues would arise when using SDF for instance (although that format would solve a few others).

There are certainly avenues to explore (I'd still like to take a closer look at usd fi), that will take time and someone (or someones) will need to spend that time to investigate a replacement

While it's certainly possible to update link lengths in parsed URDFs (it's just an in-memory representation of the xml based file format after all) there are two problems with doing that:

  1. even though robot_description is (typically) a "global" parameter, changes to the in-memory representation local to one consumer will not be forwarded (or persisted) to the parameter automatically. But even if they did, then ..
  2. none of the (officially supported) consumers of URDF expect robot_description to change at runtime, so they don't typically check the parameter for changes nor parse it again to update their internal model, not even if those consumers are found inside the same process (ie: node)

So I believe the answer to your question would be "yes, it is supported, but probably not in a way that would fit your use-case".

What is typically done is to write a custom, purpose-built calibration node that as its input takes a URDF / xacro, performs a calibration and then outputs an updated URDF. An example would be the robot_calibration package fi -- although that focuses on robots specifically (ie: kinematic chains) specifically).chains).

What could be an alternative to updating URDFs themselves -- which is very limiting as you would not be able to (easily) output xacro fi -- could be to use xacro's yaml support: place offsets and distances / link lengths in the .yaml file and have the calibration tool update/output that.

That would still need a restart / reload of any URDF consumers, but .yamls are much easier to read/write by both humans and machines than a potentially unlimited nested xacro hierarchy.


This connects to a much wider discussion about the (perceived) immutability of URDF that has taken place at venues such as ROSCon and the robot description formats category on ROS Discourse.

Note that comments typically focus on URDF and how this is a serious problem with it, but I don't necessarily agree with that: keeping state consistent across multiple, asynchronously participating entities in a distributed system is just not a solved problem. The same issues would arise when using SDF for instance (although that format would solve a few others).

There are certainly avenues to explore (I'd still like to take a closer look at usd fi), that will take time and someone (or someones) will need to spend that time to investigate a replacement