Displacement in the published tool frame using forward_cartesian_traj_controller

[3473f]

Summary

I am using URSim 5.12.0.1101482 to simulate a UR10e robot during development. In my urdf I have a rivet gun attached to the robot's end effector and I use ROS Noetic to program a trajectory using the forward_cartesian_traj_controller controller (it is a requirement that we use the robot's actual controller for kinematics and not MoveIt or similar). I set the TCP in URSim according to the CAD model data and I can see that it is correct before the robot starts moving. However, when I connect URSim to the driver, the published frame "tool0_controller" exhibits a displacement in the Y-axis which should not exist. The robot will then use the displaced coordinates and not the "real" ones set in URSim.

Versions

• ROS Driver version: latest on ROS Noetic
• Affected Robot Software Version(s): URSim 5.12.0.1101482
• Affected Robot Hardware Version(s): -
• Robot Serial Number: -
• UR+ product(s) installed: -
• URCaps Software version(s): External Control 1.0.5

Impact

The robot moves to the wrong points.

Issue details

I am using URSim 5.12.0.1101482 to simulate a UR10e robot during development. In my urdf I have a rivet gun attached to the robot's end effector and I use ROS Noetic to program a trajectory using the forward_cartesian_traj_controller controller (it is a requirement that we use the robot's actual controller for kinematics and not MoveIt or similar). I set the TCP in URSim according to the CAD model data and I can see that it is correct before the robot starts moving. However, when I connect URSim to the driver, the published frame "tool0_controller" exhibits a displacement in the Y-axis which should not exist. The robot will then used the displaced coordinates and not the "real" ones set in URSim.

Use Case and Setup

ROS Noetic in WSL under Ubuntu 20.04 and URSim 5.12.0.1101482

Project status at point of discovered

during development

Steps to Reproduce

• Set a TCP in URSim
• Use the forward_cartesian_traj_controller controller to control the robot

Expected Behavior

the TCP is to be displayed as in URSim

Actual Behavior

The tool frame exhibits a displacement in the Y-axis

Workaround Suggestion

Noting yet.

[fmauch]

I cannot really reproduce this:

Could you please check the output of rosrun tf tf_echo tool0 tool0_controller? Since you are using a simulated robot with (assumably) no configured calibration parameters, this should return exactly the transformation you setup on the TP.

[3473f]

Hi, I am running a simulated robot and not loading any calibration data when launching the driver. Here is the output of the tool0 -> tool0_controller transformation after a goal is sent to the robot

- Translation: [0.093, -0.058, 0.187]
- Rotation: in Quaternion [-0.000, 0.000, -0.000, 1.000]
            in RPY (radian) [-0.000, 0.000, -0.000]
            in RPY (degree) [-0.000, 0.000, -0.000]

[fmauch]

To narrow it down: You could check the reported transformation between base and tool0_controller on ROS. This should be exactly the same as you see on the TP when selecting "base" as feature, as this is basically only forwarding the transformation reported by the controller. With tf2_tools you can specify the precision, which should help achieving the same values (make sure to use base, not base_link, as base is per REP the same as the base frame of the robot controller):

rosrun tf2_tools echo.py -p 5 base tool0_controller

When this shows the same values as the controller (which it really should!), there's got to be something wrong with the URDF model. This could either source from a false calibration (which you confirmed to not have touched) or by loading the wrong model, e.g. loading a ur10 instead a ur10e. In your screenshot in the OP it seems like you have a more complex description created already. You could try reproducing your issue with the plain ur10e description, e.g. by only launching the driver as explained in the README. If the problem does not exist there, as it does for me, there's probably something wrong with your workcell URDF.

[3473f]

I am closing this issue since I no longer have access to the simulation.