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

This is an approach that would require some custom code, but I think satisfies your requirements.

The cell urdf could leave out some of the transforms. In particular between the entities 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).

I think this would avoid the issue mentioned by @jbinney, as long as nodes using transforms do not cache them in some way. As long as all involved nodes use the updated -- calibrated -- transforms, things should be ok.

This is an approach that would require some custom code, but I think satisfies your requirements.

The cell urdf could leave out some of the transforms. In particular between the entities 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).

I think this would avoid the issue mentioned by @jbinney, as long as nodes using transforms do not cache them in some way. As long as all involved nodes use the updated -- calibrated -- transforms, things should be ok.

PS: I think such a setup (with the non-changing parts of your robot / cell in the urdf, and the entities actually placing those static descriptions in a 'free space' not part of the urdf) is similar to how you would normally use a urdf of a robot and a localisation package to provide the information as to where that robot should be located, relative to a map or similar reference.

This is an approach that would require some custom code, but I think satisfies your requirements.

The cell urdf could leave out some of the transforms. In transforms, in particular between the entities 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).

I think this would This should avoid the issue mentioned described by @jbinney, as long as nodes using transforms do not internally cache them the transforms in some way. As long as all involved nodes use the updated -- calibrated -- transforms, things should be ok.way.

PS: I think such A similar situation where a setup (with the non-changing parts static description of your a robot / cell in the urdf, and the entities actually placing those static descriptions is located in a 'free space' not part of by the urdf) is similar to how you would normally use a urdf of a robot transform broadcasting node is in localisation, where the free space is the map, and a localisation package to provide calculates and then broadcasts the information as to where that robot should be located, relative to a transform between the map or similar reference.and the robot's frame.

This is an approach that would require some custom code, but I think satisfies your requirements.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.