Force Touch-Off Giving False positives

wileydavis · February 2017

I'm probing a pallet of stock to find the top piece using the force() function. It works really well but occasionally gives false positives where it thinks it's hit something when it hasn't. If I use the force() < 60 then it only happens once every 100 parts or so. But I've found that it becomes more unreliable as the force limit goes down, where at 30N it always triggers right away. I have the payload set using the weight and cg given by robotiq (900g). Here's the code I'm using:

Tray Probe
             Probe Variables
               Wait is_steady()≟ True 
               pocket_bottom≔pose_trans(Tool,p[0,0,.127,0,0,0])
               pocket_top≔get_actual_tcp_pose()
             If force()&lt;60
               MoveL
                 pocket_bottom
                 pocket_empty≔ True 
                 empty_pockets≔empty_pockets+1
                 pocket_top
                 If empty_pockets≟10
                   PatternPoint_1
                   Gripper Open
                   power_down()

At 30N it happens at the beginning of the move. But at 60N, on the occasions it messes up, it happens at the bottom of the pocket. Is it possible that the stop at the pocket_bottom waypoint causes the loop to exit before setting pocket_empty to true? Maybe slow it down? I'm probing at .025m/sec.

wileydavis · February 2017

@matthewd92 the units are in/sec and in/sec/sec. over four runs the averages are all within 2% of one another for a given speed/acceleration combo.

matthewd92 · February 2017

@wileydavis are you using the check continuously feature on the if statement for the force?

The reason I ask this is generally I will have something like this

If empty_pockets≟10
  PatternPoint_1
  Gripper Open
  power_down()pocket_empty = False
if force()&lt;60. # with the check box checked
  moveL
   pocketBottom
  pocket_empty = True
# This is the end of the "while" loop if statement
if pocket_empty = True
  empty_pockets = empty_pockets+1
moveL
 pocketTop
&nbsp;

The reason I break out the rest of the moves beyond the actual probe move is I only want to exit that portion of the if statement once I find something is so that I know for certain if that flag is raised or lowered so that I can take action on it and guarantee that the action will take place. If you have the check box checked on the if statement, as soon as that condition is no longer met the if statement exits, which is the behavior that we want. If you do not have the checkbox checked then you are basically entering the statement if the condition is met but then the only thing that causes it to exit is the completion of the block, not the changing of the condition.

Also, I have seen this same issue, the built in force sensing is not the most robust feature probably due to how its implemented. We wind up using forces around 100 to 120 for a lot of probing tasks, I will generally start high and then work my way down to where I find a good balance between probing effectiveness and not pushing too hard on what we are looking for.

wileydavis · February 2017

@matthewd92 - I do have the continuous button checked for that loop. At 60 it works most of the time. But separating out the rest of the statements after the pocket_empty==true statement makes a lot of sense. I really wonder if the stop at the pocket_bottom waypoint causes the loop to exit before pocket_empty can be set to true. That might also explain a weird behavior I was seeing when the probe move was faster... on some empty pockets it would skip the move to pocket_top and would move to the next patternpoint of the pallet. The probe always works perfectly when something is there for it to find.

wileydavis · February 2017

@matthewd92 - I cleaned up the while loop per your advice and out of curiosity added a little logging to see what the force() function was returning at the pocket_bottom waypoint (stopping in air, no contact). I set it to probe the 10 empty pockets 9 times (90 samples) and had some interesting results. Seems the force is quite dependent on the acceleration value of the moveL to pocket_bottom, with lower values returning higher force. Values for tool speed and acceleration are in inches.

24.36 average force with a high of 46 @ .5 / .5

16.45 average force with high of 36 @ 9.8 / 47.2

12.43 average force with high of 26.02 @ .5 / 47.2

So the force values vary a good bit but slowing the tool down but keeping acceleration up seems to stabilize them somewhat.

matthewd92 · February 2017

@wileydavis that's pretty interesting! What's your unit of measure for speed and accel? I'll have to try something similar when I have a chance and report the results to see how consistent it is.

Discussion

Force Touch-Off Giving False positives

Best Answer

Comments