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

I wonder if there is a way to get the original roll, pitch and yaw angles that are published by the robot before converting them into quaternion in the ros driver (i.e. I want to display the raw data that is coming from the robot).

No, there is no way to do that with the default ur_modern_driver.

But note though: FK is performed by robot_state_publisher, not ur_modern_driver. So ur_modern_driver does not actually publish any Cartesian info, unless you are referring to the tool0_controller frame.

The reason I am doing so is that I noticed that the roll, pitch and yaw of the robot (that can be seen from the robot monitor) are not the same as the ones published in the driver at some poses (try converting the roll, pitch and yaw angles manually you will get different ones that are produced by the driver)

If that is the case then I would say that is a bug, as the conversion should always be correct.

But do note @NEngelhard's comment: robot_state_publisher uses straightforward FK based on joint angles (published by ur_modern_driver) and the URDF. As that does not take any calibration into account (@NEngelhard: the calibration is not actually hidden, it's just not used) the tool0 frame will not be completely coincident with the robot's TCP.

tool0_controller however should be identical though, as it's a straight conversion from the data broadcast by the robot controller.

I wonder if there is a way to get the original roll, pitch and yaw angles that are published by the robot before converting them into quaternion in the ros driver (i.e. I want to display the raw data that is coming from the robot).

No, there is no way to do that with the default ur_modern_driver.

But note though: FK is performed by robot_state_publisher, not ur_modern_driver. So ur_modern_driver does not actually publish any Cartesian info, unless you are referring to the tool0_controller frame.

The reason I am doing so is that I noticed that the roll, pitch and yaw of the robot (that can be seen from the robot monitor) are not the same as the ones published in the driver at some poses (try converting the roll, pitch and yaw angles manually you will get different ones that are produced by the driver)

If that is the case then I would say that is a bug, as the conversion should always be correct.

But do note @NEngelhard's comment: robot_state_publisher uses straightforward FK based on joint angles (published by ur_modern_driver) and the URDF. As that does not take any calibration into account (@NEngelhard: the calibration is not actually hidden, it's just not used) the tool0 frame will not be completely coincident with the robot's TCP.

tool0_controller however should be identical though, as it's a straight conversion from the data broadcast by the robot controller.

I wonder if there is a way to get the original roll, pitch and yaw angles that are published by the robot before converting them into quaternion in the ros driver (i.e. I want to display the raw data that is coming from the robot).

No, there is no way to do that with the default ur_modern_driver.

But note though: FK is performed by robot_state_publisher, not ur_modern_driver. So ur_modern_driver does not actually publish any Cartesian info, unless you are referring to the tool0_controller frame.

The reason I am doing so is that I noticed that the roll, pitch and yaw of the robot (that can be seen from the robot monitor) are not the same as the ones published in the driver at some poses (try converting the roll, pitch and yaw angles manually you will get different ones that are produced by the driver)

If that is the case then I would say that is a bug, as the conversion should always be correct.

But do note @NEngelhard's comment: robot_state_publisher uses straightforward FK based on joint angles (published by ur_modern_driver) and the URDF. As that does not take any calibration into account (@NEngelhard: ( @NEngelhard: the calibration is not actually hidden, it's just not used) the tool0 frame will not be completely coincident with the robot's TCP.

tool0_controller however should be identical though, as it's a straight conversion from the data broadcast by the robot controller.


Note that the new driver (for CB3 and up) that was announced by Universal Robots at the last ROS-Industrial EU conference (2018, Stuttgart) will take the calibration data into account.