I know this is a topic that has been discussed before, but it seems like my case is a bit different from previous topics.
My case is:
In some cases the boxes are stuck to each other and therefore I would like to verify that one, and only one box has been lifted by the UR10e. As the boxes each is around 2,5 kg there is a significant difference.
For this I am using the inbuilt F/T sensor( our salesrep promised the costumer that the robot could do it).
My code goes a bit like this, mixed commands and scripts.
movel(posex) ;;My position before lifting
Direction: Base Z+ (until distance 150 mm) ;;Lifting the box.
wait 1. 0 second
force_boxes := get_tcp_force()
force_z := force_boxes/9.82
I think you get the gist of what I am doing.
1: Going the position before lifting.
2: Waiting to ensure stable joints.
3:zeroing the F/T sensor.
4: Lifting the boxes up(direct move z).
2: waiting for my joints to be stable.
5: reading the force applied to the arm and then isolating forces applied on the z-axis and converting them to kg.
But… as my positions differ, both XYZ and orientation I get signifacnt different readings( from 3 kg to 13 kg ).
I tried to see if i could find some correlations between the misreadings and the actual position, and I can only see aslight correlation for the different z positions. (I have 16 in each stack).
1: Is what I am doing somewhat right?
2: If so, has some else experimented in making a formular which can compensate math-wise for the forces applied of different positions?
3: If not, would I be wasting my time trying to make such a function myself?
Thx in advance
Hi @anr1 ,
One thing you may need to pay attention is that the get_tcp_force is retuned in base coordinate, not the tool coordinate.
You can refer this article to do the transformation.
Moreover, the force() could return the extra force exerted on the TCP in the form of saclar, not in the form of vector.
Hope these two could help you a bit.
I tried using the script in the link you sent, but the results seems more random.
I have logged position compared to Get_tcp_force() and get_tcp_force_tool() and will see if I can find some correlation tomorrow.
I’ll get back to this thread if I find a fix for my problem .
As far as I can tell from your description, you are zeroing the ftsensor after the tool has moved over the tray? Are you sure the tool is not affected/touched at all by the tray when zeroing, since this will cause inconsistent readings? You should do the zeroing before moving over the tray in my opinion.
That is what is happening.
As my tool has “sliders” I should not be in contact with the boxes. But I can not guarantee that the boxes are affected a bit by these at some spot as they are calculated from a serach.
Thx for the input, will try it first thing monday