Ask Your Question

Should a calibrated frame be in a URDF

asked 2014-08-27 17:01:42 -0600

I'm working on a robot cell that has many different pieces of equipment. The equipment geometry/location is captured in a single URDF for the robot cell. In operation, I would like to calibrate the transforms between pieces of equipment. In some sense, these transforms are semi-fixed (i.e. they are fixed once calibrated). Is there a best practice for achieving this?

One approach is to update the URDF during the calibration step. However, there don't appear to be any urdf writers, so I would have to write my own (a clue that this is the wrong approach). Once the URDF is updated, it would have to be "reloaded" in order for the updates to be reflected in the running system. "Reloading" the URDF would also be custom functionality.

Does anybody know of an alternative approach?

edit retag flag offensive close merge delete



There was some work on a python library for reading, calibrating and writing URDFs. It should still be part of the calibration stack.

ahendrix gravatar imageahendrix ( 2014-08-27 17:16:04 -0600 )edit

In the past I've usually manually done the "reloading" of the urdf by restarting the entire robot. Automatically reloading the URDF while running would be neat, but also could be tricky. You would need to make sure that every ROS node is designed to watch for and use a modified robot description.

jbinney gravatar imagejbinney ( 2014-08-27 18:13:11 -0600 )edit

3 Answers

Sort by ยป oldest newest most voted

answered 2015-02-23 08:11:11 -0600

marbosjo gravatar image

Any news on this issue?

We are working in a continuous calibration approach of a movable robot cell, so the calibration could change at any moment, but reloading the urdf model is not possible for us.

The best solution would be if the joint_state_publisher/robot_state_publisher fully support floating joints. Is somebody working on that? The main problem is that the sensor_msgs/JointState does not have a type field to specify which type of joint it is, so only supports joints with one degree of freedom. Maybe it could be possible to have joints more values in the array, and letting the joint_state_publisher/robot_state_publisher to match each joint according to the type associate to the name the joint. But this would break the current standard message.

Any ideas?

edit flag offensive delete link more


If you want to publish a floating transform directly, you should probably use a standard TF publisher instead of trying to use joint states.

ahendrix gravatar imageahendrix ( 2015-02-23 14:36:14 -0600 )edit

So... What is the point of having a floating type joint? You cannot have a full model of your robot in a URDF, because the robot_state_publisher is going to publish all the transformations, and if you publish your own, there will be conflicts due to some being published twice with different values

marbosjo gravatar imagemarbosjo ( 2015-02-24 04:35:30 -0600 )edit

I started a PR to address this, but haven't gotten back to it. See Issue. It's mostly done, but I've been swamped lately.

sedwards gravatar imagesedwards ( 2015-03-13 10:55:31 -0600 )edit

answered 2014-08-28 01:54:13 -0600

gvdhoorn gravatar image

updated 2014-08-28 03:02:37 -0600

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.

edit flag offensive delete link more

answered 2014-09-01 08:57:54 -0600

Adolfo Rodriguez T gravatar image

updated 2015-02-24 05:13:47 -0600

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:

  - foo_joint
  - foo_link
  - bar_joint

which would create these subscribers of type geometry_msgs/PoseStamped:


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.

edit flag offensive delete link more


Unfortunately, we need to dynamically reload the parameters in order to "show" the calibration has worked. Restarting the application isn't desired from a user experience level.

sedwards gravatar imagesedwards ( 2014-09-04 08:57:49 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2014-08-27 17:01:42 -0600

Seen: 502 times

Last updated: Feb 24 '15