Ask Your Question
0

ur modern driver raw data

asked 2019-02-19 07:15:20 -0500

raghad.husari gravatar image

updated 2019-03-04 01:29:03 -0500

Hi, I am using the ur_modern_driver to control my ur10 robot arm in ROS kinetic. I can see the end effector position and angles (in quaternion) by echoing /tf, however, 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). 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)

Thanks in advance. Ragahd

edit retag flag offensive close merge delete

Comments

Which frame pair are you looking at? If it's base_link->ee_link, then it is to be expected that you don't get the values that are shown on the teach pendant.

gvdhoorn gravatar image gvdhoorn  ( 2019-02-20 02:17:58 -0500 )edit

no, I am looking at tool0_controller frame

raghad.husari gravatar image raghad.husari  ( 2019-02-23 23:38:00 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted
1

answered 2019-03-04 02:23:27 -0500

gvdhoorn gravatar image

updated 2019-03-04 02:44:43 -0500

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.

edit flag offensive delete link more

Comments

"the calibration is not actually hidden" I found the DH-parameters, but we didn't manage to reproduce the tool0_controller. Did you have more success?

NEngelhard gravatar image NEngelhard  ( 2019-03-04 07:22:11 -0500 )edit

Yes, but it's not trivial, as using those values in a URDF requires some data transformations.

Note: you will not get tool0_controller exactly though, as the robot does a bit more than compensate for kinematic offsets.

Using the calibration will be supported by the new driver, as I wrote above.

gvdhoorn gravatar image gvdhoorn  ( 2019-03-04 07:24:06 -0500 )edit
0

answered 2019-02-19 12:12:01 -0500

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.

edit flag offensive delete link more

Comments

Thanks for your reply. I just want to know if there is a way to access and print the raw data from the driver (where exactly the parsing is happening). I want to see the data that is coming from the robot arm itself.

raghad.husari gravatar image raghad.husari  ( 2019-02-20 02:08:49 -0500 )edit

"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." The UR provides a more accurate pose for the TCP (using a hidden factory calibration), so this is only correct for all other joints.

NEngelhard gravatar image NEngelhard  ( 2019-02-20 03:10:01 -0500 )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

1 follower

Stats

Asked: 2019-02-19 07:15:20 -0500

Seen: 230 times

Last updated: Mar 04 '19