How to use the calibration tag?

[krebsalad]

I have somehow implemented this calibration package. My goal is to calibrate an abb robot with the use of a realsense d415 camera and just one checkerboard. I do get some results, a calibrated URDF and some camera calibration yaml files. My results are probably not that good yet. I am planning to use more features in the future. Atleast, if i can get the calibration results working.

My problem here is that I do not know how to make use of the calibration rising tag that is inserted in to the updated URDF. Initially, i thought this was a standard URDF element and that it would be taken in account when planning. But, there is no difference at all in the movement when I try using the updated URDF. I've looked around but could not find much information regarding this. Can someone point me where I can find more information about this calibration tag and how it should affect positioning?

In case I have to implement this part myself. Do I simply add these offsets to the joint states? I saw something similar in the UR_driver here: https://github.com/ros-industrial/universal_robot/blob/hydro-devel/ur_driver/src/ur_driver/driver.py#L341

[mikeferguson]

Yes, the robot drivers (or whoever publishes joint_states, and processes the commands) needs to handle the rising tag. The tag is "somewhat standard", but in reality, was originally specifically for the PR2. Many robots have used the tag since the parser supports it.

We recently discussed this in #49, which you might find helpful to read. We then updated the Readme in the Exported Results section to describe how the offsets are added:

Changes to free_params (joint offsets) are applied as "calibration" tags in the URDF. In particular, they are applied as "rising" tags. These should be read by the robot drivers so that the offsets can be applied before joint values are used for controllers. The offsets need to be added to the joint position read from the device. The offset then typically needs to be subtracted from the commanded position sent to the device

Feedback on how to make this more clear, or more visible to first time users, is certainly appreciated.

EDIT: just looked at your UR link -- I'm not familar with "calibration_offset" tag -- it looks like their code is not using urdf_parser/urdfdom (or urdf_parser_py), so I'm not sure if that is actually a supported tag by the URDF parser. It looks like the newer "ur_modern_driver" package does not support that particular tag (or any joint calibration, which honestly probably isn't needed on an arm as factory-precise as the UR5)

[krebsalad]

Thanks for your answer. I am not using the UR driver, I was finding some examples to work with. At the moment I am using the abb_driver which in itself makes use of ROS-industrial industrial_core. This is the connection to the actual robot. So i was thinking of adding the functionality somewhere here: https://github.com/ros-industrial/industrial_core/blob/kinetic-devel/industrial_robot_client/src/joint_relay_handler.cpp#L98

But I would rather not make changes in the industrial_robot_client. From what I understand, I need to edit the joint states before sending them to the controller, or even before planning the trajectories. In that case, the one publishing joint states is the robot_state_publisher. I will try making some changes here: https://github.com/ros/robot_state_publisher/blob/kinetic-devel/src/robot_state_publisher.cpp#L83

Feedback on how to make this more clear, or more visible to first-time users, is certainly appreciated.

For now, I will be trying out the package myself. I will make sure send some feedback. When the time comes, should I make new issues? or do you want it a different form?

probably isn't needed on an arm as factory-precise as the UR5

This is probably also the case for the current ABB robot I am using. Rather than precision, i am more interested in other benefits of ROS, such as, what I believe being the stronger point in this case, image visionary/perception. As this could help achieve a more absolute accuracy, rather than a repeatable accuracy. Excuse me for my English.

[gavanderhoorn]

@krebsalad wrote:

But I would rather not make changes in the industrial_robot_client. From what I understand, I need to edit the joint states before sending them to the controller, or even before planning the trajectories. In that case, the one publishing joint states is the robot_state_publisher. I will try making some changes here: https://github.com/ros/robot_state_publisher/blob/kinetic-devel/src/robot_state_publisher.cpp#L83

robot_state_publisher does not publish robot state, but TF frames. It takes in JointState msgs and outputs TF transforms.

Updating JointRelayHandler to be able to handle calibration could be interesting. But before you do, please open an issue on the tracker so we can discuss possible implementations.

probably isn't needed on an arm as factory-precise as the UR5

This is probably also the case for the current ABB robot I am using. Rather than precision, i am more interested in other benefits of ROS, such as, what I believe being the stronger point in this case, image visionary/perception. As this could help achieve a more absolute accuracy, rather than a repeatable accuracy

Industrial robots typically have a high repeatability, not accuracy.

[krebsalad]

This issue was moved to issue 218 in industrial_core