Hello there!
Hope everyone is ok with the current situation all over the world.
I am trying to detect weigh differences when picking a box. As in this topic (Payload measurement on robot) is said I followed these steps:
- Move to position 1
- zero_ftsensor()
- Move to position 2 (and pick the box)
- Move to position 1
- wrench=get_tcp_force()
F_x=wrench[0]
F_y=wrench[1]
F_z=wrench[2]
F_m=sqrt(pow(F_x,2)+pow(F_y,2)+pow(F_z,2))
mass=F_m/9.81
Anyone has suggestions? I am getting very strange values. Should I use only the F_z for the mass?
Thanks in advance!
Hi,
did you try only using the Z force ? as the script doc says, get_tcp_force() returns the values in your base coordinate system. If you mounted your robot e.g. on a wall you have to use wrench_trans to transform your forces, otherwise it should be fine 
Hello @m.birkholz,
thanks for your reply.
Yes, I did try with only the F_z component and I got also strange values. I will try again tomorrow and update you.
PS: I am also updating the payload and CoG when picking the box in order to avoid protective stops.
Summary
Hi,
my answer above only works for a gripper that grips from “upside down” pointing orthogonal to the gripping plane. You do have to use wrench_trans to get the right weight, no matter how the gripper is holding your box. I think this will work using the rotations of the pose_inv of your actual tcp position and transform them with wrench_trans.
Edit: please ignore this and sorry for the confusion. you do not need a wrench transformation in this case
Hi,
I am not sure about what you mean.
Let´s say:
- Move to position 1
- zero_ftsensor()
- Move to position 2 (pick the box, update payload and CoG)
- Move to position 1
- pose_act = get_actual_tcp_pose()
- pose_act_inv = pose_inv(pose_act)
- wrench = wrench_trans(pose_act_inv, ?)
- F_x=wrench[0]
F_y=wrench[1]
F_z=wrench[2]
F_m=sqrt(pow(F_x,2)+pow(F_y,2)+pow(F_z,2)) or F_m = norm(F_z)
mass=F_m/9.81
“?” means that I do not know what to place there.
I think they main issue you are facing, is that setting the payload is also zeroing the sensor. As long as the z-axis of your base is aligned with the gravity, you should be able to use the wrench[2] without any wrench_trans.
Hi @Ebbe,
Thanks for replying.
I see your point.
But then, I am risking the robot to protective stops.
I am more interested weigh differences than a precise weigh of the box.
To fully clarify things,
The function “get_tcp_force()” returns the measured force values at the TCP but in the coordinates of the base. Therefore, if your gripper is horizontally, and you push in the direction of the gripper, the measured force will not increase in the z direction but in a combination of x and y.
If you want the values in the tool coordinate system, a transformation is required. For this, I advise the article Force in tool coordinate system
One other thing, the force measurement, is this performed in a separate thread? If not, it will not work since you only asked the force once which is at the line “get_tcp_force()”. If you put this code in a thread, it will continuously check the force values (so the values are continuously updated) and thus you would be able to detect a drop in the force by adding a comparison.
Hi @d.verhofstadt,
Thanks for your clarification. I understand what you mean. And the force measurement was not in a thread.
Let´s put this example to see if we can finally achieve a conclusion:
- Robot moves to P1
- Pick the box and update payload and CoG
- Robot moves to P2 (+Z tool axis, in this point is where I am interested in checking the payload to discard the box or continue with the process)
- Check the force and get the mass (as I said previously I am more interested in detecting weigh differences between consecutive boxes)
What do you suggest then?
PS: the setup in the image is the same than the one I got on my real installation
2 things:
First how to check this. What I thought was that you wanted to check continuously whether the box was for instance still gripped. Because, assume the box would fall or come loose, a difference in force can be detected. In this situation you need a continous force update (thread).
But in your situation (as I understand it), you just want to measure the payload and check with, for instance, a predefined value if it is good or not. For this you can check the measured force only once. So no thread would be needed. Of course, you could check a number of times and calculate the mean in order to reduce the measurement noise.
In order to do this, just do:
at P1, before Grab:
zero_ftsensor()
at P2:
measured_force := get_tcp_force()
weight = measured_force[2]
if weight differs
do this (discard)
else
do this (continue)
If you want to check the weight (not mass) between 2 consecutive picks, just work with an additional variable in which you store the previous mass.
Secondly, what is the required accuracy of the force measurement? And which robot series are you using? From the image, I would assume a CB-series which doesn’t have a force torque sensor. The values returned from the function get_tcp_force() for a CB series are estimated values. NOT MEASURED ones. So if you have a CB series, either use a force torque sensor, or buy a e-series and implement the CB series in another project.
If you have an e-series, take into account the accuracy of the built-in force torque sensor. It could be that it is not accurate enough to detect this difference. In which case you could use a force torque sensor of OnRobot, Robotiq, …
Hi @d.verhofstadt,
I do have an e-series. The image was an example of the setup.
You understood my situation correctly.
My problem relies in how to establish a relationship between the values of the “get_tcp_force()”(in N) and a mass (in grams). Because I can appreciate differences in forces, but I (or the final client) want to understand those differences in grams.
Last but not least, in your pseudo-coding you are not updating payload and CoG. This could lead to protective stops. Or it is necessary to get the correct force/mass values?
I’m not sure what you mean. In order to determine the mass out of the values, just divide by the gravitational constant g = 9.81 (± 10) (F = m * g).
Or does this return incorrect results?
Yes indeed, I didn’t set the payload because I thought that the object to be picked has a low mass. You do not have to set it, it will not affect your force measurements. The payload setting of the TCP is just for collision detection (protective stop). If you pick an object of 500 gram, the chance for a protective stop is low whereas with an object of 2 kg the chances are higher.
Of course, setting a correct TCP payload is always best, but in some cases (low mass) it can be neglected.
@GumerCascales, In your movement from P1 to P2, you should keep the acceleration low to avoid the protective stop.