Should a calibrated frame be in a URDF

edit

This is an approach that would require some custom code, but I think satisfies your requirements. It doesn't address the actual issue with URDF updating though.

The cell urdf could leave out some of the transforms, in particular between the frames that are to be calibrated wrt each other. An additional node could then be used that completes the TF tree by broadcasting the calibrated (fixed) transforms, loaded from some suitable datastore. The node could be made to accept updates to the transforms (based on a calibration result) and be asked to persist the updates, or to reload them from disk (to allow an external process other than the ROS node to update the data).

This should avoid the issue described by @jbinney, as long as nodes do not internally cache the transforms in some way.

A similar situation where a static description of a robot is located in a 'free space' by the use of a transform broadcasting node is in localisation, where the free space is the map, and a localisation package calculates and then broadcasts the transform between the map and the robot's frame.

If I understand correctly, once you calibrate your cell, those settings remain valid during operation, and hopefully for a 'long' time, whatever long means. Furthermore, I assume that you don't need to dynamically reload the URDF with the system up and running.

If the above assumptions hold, a pattern that could work rather well is the following:

• Have all parameters that are subject to calibration (xacro, yaml, etc.) in a separate package (or packages). Let's call it my_cell_calibration.
• The default version of my_cell_calibration contains nominal values, and is what you use in simulation.
• Once you perform a calibration for a specific setup (sensor, robot, cell), you create a new version of my_cell_calibration and overlay it for your setup, so it gets picked up instead of the default with nominal values.

In this way, you don't need to touch the original URDF or other config files upon a calibration run. Just overlay and restart the relevant components.

Update after comments. On dynamically changing frames

If you want to dynamically change the frame associated to a joint or link, I would suggest extending the robot_state_publisher node. This node currently takes as inputs a URDF and a joint_states topic. You could add an additional, optional configuration that specifies which frames are subject to change dynamically. These frames would default to the value specified in the respective <origin>, but the node would create subscribers for updating those values.

The configuration could look something like:

dynamic_frames:
  - foo_joint
  - foo_link
  - bar_joint

which would create these subscribers of type geometry_msgs/PoseStamped:

robot_state_publisher/dynamic_frames/foo_joint
robot_state_publisher/dynamic_frames/foo_link
robot_state_publisher/dynamic_frames/bar_joint

Naming and namespacing can vary, but you get the idea.

The output of robot_state_publisher would still be a set of tf frames, but ones that take into account the dynamic variations of otherwise static URDF frames.

Update 2. Further comments

The upside of this approach is that the tf frames will be up to date with calibration updates. The downside is that exiting code that parses the URDF, like the kdl_parser, for instance, would not be aware of the updated frames.

Also, if your calibration routine also calibrates joint zeros, you would need to feed updated offsets to the entity that publishes the joint_states topic.