ur modern driver raw data

edit

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.

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.

The values you see in TF will be calculated from the joint angles and known model of the robot, not just converted from RPY values provided directly from the driver. Roll Pitch and Yaw is not the recommended way to transfer orientation information.

The reason my Euler angles are not preferred is because there are 12 different permutations of rotation orderings meaning conversions between different systems can be problematic, it's possible this is exactly what's occurring in this case. It's also possible that the fixed base frame being used by the robot monitor may be different to that being used in ROS.

In short this is not a simple problem, and unless you can find out the rotation ordering used the Euler angle representation used by the UR robot console it's going to be hard to replicate.