Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
hidalgoem opened this issue Jul 18, 2023 · 4 comments
Open
Labels
requires testing Requires some (hardware) testing

Comments

@hidalgoem
Copy link

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
Copy link

MCR100 commented Jul 20, 2023

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
Copy link
Collaborator

fmauch commented Jul 20, 2023

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
Copy link

MCR100 commented Jul 21, 2023

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
Copy link
Author

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

@fmauch fmauch added the requires testing Requires some (hardware) testing label Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
requires testing Requires some (hardware) testing
Projects
None yet
Development

No branches or pull requests

3 participants