matthewd92
@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
pocket_empty = False
if force()<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
If empty_pockets≟10
PatternPoint_1
Gripper Open
power_down()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
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:
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.