How to avoid the robot to stop when an impact occurs?

Catherine_Bernier

I just got a question from a customer.

In the process, the robot can't really stop if an impact occurs because it then needs someone to reset and restart it. Hence, the robot safety basics cause the robot to stop on an impact.

Is it possible to simply make the robot compliant upon impact? Meaning that if an impact occurs, the robot will compensate but never stop running?
Can the robot be reactivated without a specific human intervention?

The goal is to stay safe of course.

Etienne_Samson

@Catherine_Bernier the FT Sensor can indeed be used to improve the collision detection provided with the UR.

A few things to remember:

• The sensor is not safety rated
• Whatever program you build around the sensor signal, it will never overcome the UR safety settings.
• Sensor recommended threshold is 5N in X and Y et 2N in Z

Now on how to do this:

• Build a thread where you continuously look over the force signals in Fx, Fy, Fz
• Have a collision force threshold
• Build an "if" loop where you would stop, slow down or change direction if you detect a force higher then your threshold.
• To have a good accuracy on the force, you need to slow down, if you move at full speed your prorgram will not have time to react on the force reading and you will probably end-up 

Catherine_Bernier

@Nicolas_Lauzier Can the FT300 be useful in that case?

matthewd92

Even if the robot is made compliant, what would take it out of compliant mode and back to resume normal operation?  If it's hitting something in the process you have to ask why that is. If they mean sometimes it's faulting out because they are getting into a position where the robot is "thinking" it's hitting something we use force compliant mode a lot to overcome that so that the robot can be free in certain axes to "find" it's own way. An example is sliding a part down a track. We were having issues where the part would occasionally bind and cause the robot to fault. We put the robot into force mode at the beginning of the slide and allow the robot to rotate slightly around the z axis as well as have linear compliance in the z and y axis, we are sliding in the x direction. The key to making this work was reducing the compliant speed down to maybe 10mm/s on the linear and 5-10 degrees per second on the rotation. We were using forces of 0 in both linear and rotation. Now the robot is able to slide the part freely and can move around as required to overcome any binding issues. 

carlosjoserg

Thanks @matthewd92

Is it possible for you to share how do you setup that behavior a bit more technically?
What force mode type do you use (Simple, Frame, Point, Motion)?
What kind of features you define to achieve the desired motion if any, or if you use Tool or Base as features?
I guess for your usecase, you add a MoveL (as opposite to MoveP or MoveJ) within the Force Mode command, is that right?

Again, thanks in advance.

matthewd92

@carlosjoserg I will usually have the force node within a MoveL with a waypoint before that starts that move and then a waypoint for the end of the move within the force node.  I generally use tool as the feature, or a taught feature,  as its rare that I am moving directly in line with the base frame.  Something set-up like this



The secret that I found to using the force mode effectively is to limit the speed in which the axis is able to move in compliance.  If you don't do this the robot tends to "flop" over on itself.  This was the Aha moment for me in using the force wizard.

carlosjoserg

That is very illustrative @matthewd92

Just to be sure, in the description, you said you are sliding in X, so you don't want to tic the compliant along X as shown in the screenshot, is that right? I guess you meant to tic Y, otherwise the robot won't follow the X-component of the waypoint if I understand well the tic/not-tic behaviors in the compliant field, plus you would want to set a force threshold higher than zero along the sliding direction as well, right?... This different behavior obtained by ticking or not that field is what I find a bit misleading in the user manual.

matthewd92

@carlosjoserg  Sorry, in the example I set up I was actually moving in the y axis, pushing the part away from the robot. But you are correct, you don't tick the axis you are trying to move in. 

carlosjoserg

Don't think this necessarily solves the question in first place, where perhaps the compliance might not be allowed either, but I certainly found your reply useful.

Thanks!

Sebastien

@matthewd92  @Catherine_Bernier
Would this be accepted according to safety regulations? In my head, upon collision with an operator, you need to stop the robot to avoid further damage to the operator. The stop signal in the UR caused by a peak in force is probably dual channel safety and hence Safe to use to detect collision. However, is the force data that we can use in force mode a dual channel signal as well that we can use?

matthewd92

My understanding is that the FT sensors are NOT safety rated devices and probably should not be used as a replacement for the right safety parameters on the robot.  In other words don't crank up the force and speed in the safety settings when you might hurt someone and plan to use feedback from an FT sensor to provide a "safe" environment.