Demo_Force_Twist_Release program tripping with C204A3:Sudden Stop Detected Fault

Hennie

We have sold some torque force sensors recently and the client experimented with the RobotIQ – Demo_Force_twist_release program. He found that the force feedback works great and the program performs well.

 He did have a problem with the speed though: Whenever he increased the (Speed_inc) variable for axis 6 only (or wrist 3 in the UR world) to greater than 0.33 the robot would trip with error

C204A3: Sudden stop detected

 Now we are guessing that we are breaking one of the speed or acceleration rules, we would just like some clarity on the meaning of the value 0.33 and if there was anything else ( within the demo program) that we could do to increase the speed of that motion.

Thanks Hennie

Grady_Turner

@Hennie  I have run into this problem in a more general way.  If you have a loop with some robot movement (speed, force, or waypoints) and that loop has a constantly monitored exit condition (or just a short loop time) you will see this error after surpassing a certain speed.

Basically what happens is that the robot will  still physically be in motion after the loop exits, and depending on the next command the joints will have no movement parameters from the controller and will try to immediately stop.  This causes either the error you are seeing (sudden stop) or another error that says "invalid set point."

There are two ways around this:  Slow the movement down if acceptable, or add a "stopl(a)" command right after the loop.  stopl(a) [or stopj(a)]  is a command that sends a command to decelerate the robot at value "a."  stopl() is for linear stop, and stopj() is for decelerating in joint space, and units will be m/s/s or rad/s/s respectively.  The stop command will still only work up to a certain limit though, and requires some trial and error.

Grady_Turner

@JeanPhilippe_Jobin @Alexandre_Pare   Can you offer any other advice?

Alexandre_Pare

@Grady_Turner @Hennie
Grady I think you are right. @JeanPhilippe_Jobin will be able to elaborate more on the speed_inc variable. 
I saw some error with loops once that I think was also related to this. When I hit play, if the loop has no delays in it or position speeds are too fast I get an infinite loop error and the program won't run. I think it is the same things as what you are saying. Have you seen that before?

Grady_Turner

@Alexandre_Pare I meant that the error occurs when the loop's exit condition is met, and then the robot has no physical movement command and so tries to stop with immediately.

Nicolas_Lauzier

@Grady_Turner @Hennie

I think Grady is right. Another possibility is that if the increment is too high, the robot will check for the force level between each motion only and therefore a high force can be induced if the the contact is with a rigid object. This high force may cause a "sudden stop".

Another way of implementing this would be the following:
- Insert a "if" with the option "expression checked continuously" select. The condition could be, for example, "if Fz >= -10".
- Inside the "if", place a relative move, for example a 10cm downward motion
- Make sure you have a "set zero" before the motion (or before the "if"), when there is no contact with the tool.

This will make sure that the robot moves until the force meets a certain threshold (in this case 10N upwards). You will need to increase the speed gradually as a high speed will make the real force exceed the threshold (the robot needs time to stop).

This alternative method works well when you need to move until a certain force is reached, but is not meant to control a force continuously.

bsawlor

I've run into this issue, using the if with check expression continuously, monitoring Mz to check clockwise and counterclockwise force.  But the error shows up not on that move, but on the gripper open afterwards, even with adding a wait between the move and the gripper open.  Is the situation the same in this instance, or could there be a weird scenario with this setup?

matthewd92

@bsawlor  You may be having too much force twisted up in the arm and so when you release the gripper the arm suddenly moves (you probably can't see this) causing an unexpected motion.  Try placing the gripper opening inside of a force wizard node.  Use the frame type with tool as the frame of reference.  Then allow the Z rotation to be compliant.  I would start with a low rotational velocity like 10 degrees/second and work up as needed to eliminate the fault.  This will allow the arm to float when you open the gripper and should stop the fault.

If you need any help around implementing this let me know and I can do a sample program

bsawlor

Tried inserting the force with the gripper as indicated, now instead of stopping on the gripper action, it stops on the wait that is still present above the force command.  As the part this test is on is plastic, I have the range for the force on the if statements set with minimum change triggering the next command, so I highly doubt the forces it's detecting are too high.  The other thing is, I test by applying pressure on the gripper as it rotates to simulate it hitting the physical limit of the part, so I can iron out the specifics before introducing the part to the gripper.  It's representative but should still work.  Both with the part, and using my fingers, the same error pops up, even though it's reacting for the force detection as it should.

matthewd92

@bsawlor  Have you tried taking the wait out?  Can you send a screenshot of your program?

bsawlor

matthewd92

@bsawlor the only thing that I see in your code that is different from what we do on a daily basis is the else statement attached to each of the continuos if statements, we just use the if with the check box checked for motion.  The other thing that we usually do differently and I cannot see it mattering is we have the if statement inside the movej so that only a waypoint is inside there and maybe a flag so that we know whether we made the point or exited early such as 

global didWeMakeThePoint = False<br>movej<br>&nbsp; waypointBeforeMyForceControlledOne<br>&nbsp; while Mz <.2 # The if statement with the checkbox checked effectively becomes a while statement<br>&nbsp; &nbsp; waypoint<br>&nbsp; &nbsp; didWeMakeThePoint = True<br>&nbsp; end<br>&nbsp;open gripper
<br><span style="font-family: Hind, sans-serif;">&nbsp; <br>At this point I will usually evaluate whether we made it or not, depending on the task, to determine what my next step is. &nbsp;If all I am doing is using this as a search method then I don't care but if its trying to insert something without faulting on overload then I will use this to know whether the part was inserted for example</span>

The one thing that I will say is that we have not deployed too many robots with the robotiq URCap, we mainly use the script functions since they seem to run faster for us for whatever reason.  Maybe try using the script function rq_open_and_wait() instead of the program node from the URCap.  I will be doing some testing in the next couple of days to actually quantify that position and will post the results here.

If you want to send over the program I can try to take a look at it as well more closely where I can click around and see if anything pops out at me or I am sure there are others on here as well that can also look at it if you don't mind it being on here in a public forum.  If not you can email it to me at [email protected] 

bsawlor

I did manage to get past the error, by using the stopj command to stop the movement after it detected the moment.

matthewd92

Im going to have to remember to use the stopj more often, occasionally we have issues with some of our weird moves that we are making.

Glad you were able to get it running @bsawlor