UR5e - dynamically off-setting tool weight from the force/torque sensor

[hidalgoem]

Hi, We are working with a UR5e robot and ROS noetic. We have a tool attached to the robot flange. we want to read the contact force applied on the tool, so we were looking to dynamically offset the weight of the tool from the sensor readings. This is to get only the contact force applied on the tool. Are there any ways to do that with ROS by using python?. Does setting center of gravity and tool weight in the teach pendant automatically offset the weight from the force sensor readings?. @fmauch

[MCR100]

Yes, I am having the same issue. Eventhough I included the mass and COG in teach pendant. It looks like the /wrench topic is not offsetting the weight of the gripper. Is it possible to get something like RTDE robot controller output "actual_TCP_force" through ROS, which as per this reference would offset the weight @fmauch @gavanderhoorn

[fmauch]

Please do not @-mention people directly in issues, especially not people not directly involved in a repository. Many people consider this rather impolite.

There are a couple of aspects involved in the question:

1. The wrench reported by the driver is the actual_TCP_force from RTDE transformed into the tool0_controller frame. It should include zeroing the FTS and compensating for the configured payload.
2. The FTS on the robot needs to be zeroed at some point. This can be done by calling rosservice call /ur_hardware_interface/zero_ftsensor
3. You can dynamically set the payload using

   rosservice call /ur_hardware_interface/set_payload "mass: 0.5
   center_of_gravity:
     x: 0.0
     y: 0.0
     z: 0.5"
   

[MCR100]

Thank you for the reply. Since both of them contributed to similar issues in the repository I tagged them just to grab their attention. But I will avoid tagging hereafter. Intention was never to be impolite, as everyone contribution in this platform help us immensely in our work and thankful to them.

A follow up question, although the /wrench reported by the driver is close to zero, still have some offset at particular poses (as discussed in #617). Is it possible to get the raw ft_sensor data like in RTDE using "ft_raw_wrench" so that we can implement our own gravity compensation.

[hidalgoem]

Please do not @-mention people directly in issues, especially not people not directly involved in a repository. Many people consider this rather impolite.

There are a couple of aspects involved in the question:

1. The wrench reported by the driver is the actual_TCP_force from RTDE transformed into the tool0_controller frame. It should include zeroing the FTS and compensating for the configured payload.
2. The FTS on the robot needs to be zeroed at some point. This can be done by calling rosservice call /ur_hardware_interface/zero_ftsensor
3. You can dynamically set the payload using

   rosservice call /ur_hardware_interface/set_payload "mass: 0.5
   center_of_gravity:
     x: 0.0
     y: 0.0
     z: 0.5"
   

Thanks for your soon reply and sorry for the wrong use of "@". I did't know it was impolite, that was not my intention.

Regarding the issue, we have tried zeroing the FTS, however as MCR100 mentioned, It is still showing an offset when the the tool orientation change, and setting the payload seems not to be working for us. Is there any other solution?.

Thanks

[159chenJie159]

Please do not @-mention people directly in issues, especially not people not directly involved in a repository. Many people consider this rather impolite.请不要在议题中直接 @提及人员，尤其是不要直接参与仓库的人员。许多人认为这相当不礼貌。 There are a couple of aspects involved in the question:这个问题涉及几个方面：

1. The wrench reported by the driver is the actual_TCP_force from RTDE transformed into the tool0_controller frame. It should include zeroing the FTS and compensating for the configured payload.驱动程序报告的扳手是从 RTDE 转换为 tool0_controller 帧的actual_TCP_force。它应该包括将 FTS 归零和补偿配置的有效载荷。
2. The FTS on the robot needs to be zeroed at some point. This can be done by calling rosservice call /ur_hardware_interface/zero_ftsensor机器人上的 FTS 需要在某个时候归零。这可以通过调用 rosservice call /ur_hardware_interface/zero_ftsensor
3. You can dynamically set the payload using 您可以使用``` rosservice call /ur_hardware_interface/set_payload "mass: 0.5 center_of_gravity: x: 0.0 y: 0.0 z: 0.5"

Thanks for your soon reply and sorry for the wrong use of "@". I did't know it was impolite, that was not my intention.感谢您的回复，并为错误地使用“@”而感到抱歉。我不知道这是不礼貌的，那不是我的本意。

Regarding the issue, we have tried zeroing the FTS, however as MCR100 mentioned, It is still showing an offset when the the tool orientation change, and setting the payload seems not to be working for us. Is there any other solution?.关于这个问题，我们已经尝试将 FTS 归零，但是正如 MCR100 提到的，当工具方向发生变化时，它仍然显示偏移量，并且设置有效载荷似乎对我们不起作用。还有其他解决方案吗？

Thanks  谢谢

Hello, I'm not sure if you managed to resolve this issue in the end. My current situation is the same as yours — even after setting the payload and zeroing it, the offset still appears when I change the tool orientation. I'm unsure whether this offset value is correct. Do you have any suggested solutions?

Please do not @-mention people directly in issues, especially not people not directly involved in a repository. Many people consider this rather impolite. There are a couple of aspects involved in the question:

1. The wrench reported by the driver is the actual_TCP_force from RTDE transformed into the tool0_controller frame. It should include zeroing the FTS and compensating for the configured payload.
2. The FTS on the robot needs to be zeroed at some point. This can be done by calling rosservice call /ur_hardware_interface/zero_ftsensor
3. You can dynamically set the payload using

   rosservice call /ur_hardware_interface/set_payload "mass: 0.5
   center_of_gravity:
     x: 0.0
     y: 0.0
     z: 0.5"
   

Thanks for your soon reply and sorry for the wrong use of "@". I did't know it was impolite, that was not my intention.

Regarding the issue, we have tried zeroing the FTS, however as MCR100 mentioned, It is still showing an offset when the the tool orientation change, and setting the payload seems not to be working for us. Is there any other solution?.

Thanks

Hello, I'm not sure if you managed to resolve this issue in the end. My current situation is the same as yours — even after setting the payload and zeroing it, the offset still appears when I change the tool orientation. I'm unsure whether this offset value is correct. Do you have any suggested solutions?

[abuibaid]

Hi everyone, have you all solved this issue or were you able to solve it? Actually at the moment I have same problem!

Regards,

[abuibaid]

(Follow-Up questions):

1- If I wish to reset these services that I called regarding the setting payload and zeroing FTS, is there any way to do it?

2- In the HMI, which is directly to the robot controller, there is a way to define TCP, Payload and etc., is it more recommended than using these rosservices?

[urfeex]

(Follow-Up questions):

1- If I wish to reset these services that I called regarding the setting payload and zeroing FTS, is there any way to do it?

What do you mean by "reset these services"?

2- In the HMI, which is directly to the robot controller, there is a way to define TCP, Payload and etc., is it more recommended than using these rosservices?

Defining the TCP is not possible through ROS services. setting the payload should be the same, no matter which way is used to trigger it.

[abuibaid]

What do you mean by "reset these services"?

for example, if you set the payload through rosservice, it will be sat and if you wanna change it, just change the parameters to 0s. But in zero_fts's case, it is always triggered, such that, whenever you hit "externalcontrol" play, it will be reseted! am I correct?

if yes, how to release this trigger?

[urfeex]

But in zero_fts's case, it is always triggered, such that, whenever you hit "externalcontrol" play, it will be reseted! am I correct?

I am not aware of such a trigger. If there is one, that's outside of external_control's scope.