Wrench topic publishes significant force values when no force is being applied

[ibyou1997]

Affected ROS Driver version(s)

UR10e

Used ROS distribution.

Noetic

Which combination of platform is the ROS driver running on.

Linux without realtime patch

How is the UR ROS Driver installed.

From binary packets

Which robot platform is the driver connected to.

UR E-series robot

Robot SW / URSim version(s)

2.1.2

How is the ROS driver used.

Headless without using the teach pendant

Issue details

Summary

I am using the topic /Wrench to get the force and torque reading from the FT sensor. I was expecting to get values near 0 when the robot is stopped and there is no interaction force on the robot's end-effector. However, Calling zero_ftsensor service seems to help at the start but after applying a force and releasing the FT value seems not to be non-zero(or close to zero).

Expected Behavior

the expected response is that the FT value should settle down after applying force, or at least end up with the same level of noise.

Actual Behavior

When applying the force at the end effector the robot doesn't settle to the actual noise level. A you can see in the figure, the applying force was around 80 to 83.6, and then no force was applied.

Workaround Suggestion

If a workaround has been found, you are welcome to share it.

Thanks in advance!!!

Relevant log output

No response

Accept Public visibility

• [X] I agree to make this context public

[fmauch]

@urrsk would you have a comment on this? Since we're merely publishing the data read from the robot I'm not sure what to say about this.

[ibyou1997]

@fmauch, We attempted to compare the UR FT sensor value against an external sensor, but it appears that the UR sensor amplified the FT values in some way. It is worth mentioning that we didn't set up for FIFO scheduling - could this be the issue? The robot is functioning properly with the external sensor without the need for any FIFO scheduling.

[ WARN] [1699366921.122824786]: Your system/user seems not to be setup for FIFO scheduling. We recommend using a lowlatency kernel with FIFO scheduling. See https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/blob/master/ur_robot_driver/doc/real_time.md for details.

[urrsk]

@ibyou1997 Thanks for asking. Beside of being a very fast an stiff force torque sensor. The FT sensor unfortunately do drift due to e.g. temperature. Therefore it is strongly suggested that you zero the sensor just before you need to use it or apply another approachs to avoid be affected by this drift.

In case you need an accurate sensor. It is possible to add a third-party sensor to the robot. See Force torque sensors on the UR+ Products overview

In addition the robot also do a gravity compensated of the sensed force and torque, to compensate for gravity when the tool angle towards gravity changes. This compensation is based on the payload and center of mass setting active on the robot.

[ibyou1997]

@urrsk Thank you for you answer.

Firstly, we added a ur::msg::SetPayload to set the payload as we need. and afterwards we zero the sensor before starting the admittance control loop using std::srvs::trigger to /ur_hardware_interfance/zero_ft_sensor while in headless mode.

The UR10e Force/Torque sensor works fine using UR-RTDE running in Python for our admittance control with the same robot and installation, but when running the same code in C++ with ROS, the acceleration of the robot spikes (becuase of high sensor value) and causes it to go into violation stop?

We have tried using a third-party Schunk Gamma sensor as force feedback for the same setup, and with this, the same admittance control in ROS works fine.

With some debugging we believe the problem is with the force/torque sensor values from the UR10e FT sensor. Perhaps somewhere in the ROS Driver for the sensor. Do you have any suggestions on how we can solve this without using a third-party sensor, as it would be ideal to use the UR10e built-in sensor?

[urrsk]

@ibyou1997 is it possible that you can share the ROS admittance control script?

Regarding to set the payload, you can also use the 'set_payload' service see code

[ibyou1997]

Thank you for your response. We have identified the problem: the wrench was published with respect to the TCP frame instead of the base frame. However, URTDE uses the ft value with respect to the base frame. To solve the issue, we have transformed the Ft measurement to the base frame.

[urrsk]

@ibyou1997 Thansk for the feedback. Happy you got it to work