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
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
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.
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.
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, …
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.
