Technical Article

Robot Collision Recovery and Prevention

October 20, 2022 by Shawn Dietrich

When a robot crashes, it needs to be put back into position. The steps in this process depends on the end user and the equipment manufacturer. Understanding why the robot crashed also helps prevent future failures.

Robot Collisions and Crashes

Just about every robot in production will experience some kind of crash or bump, and most of the time these crashes will occur at low speed with the technician holding the pendant. Sometimes crashes happen at full speed and can occur for many reasons: maybe the fixture holding the part moved, maybe the gripper didn’t open because of a damaged electrical connection, or maybe the PLC sent the wrong command number to the robot.

 

Robot collision recovery

Figure 1. Robot collisions incur serious downtime costs and headaches. But is it appropriate to allow the robot to recover itself automatically? Image used courtesy of Canva

 

Regardless of the reason, if a crash occurred, the robot must be recovered. There are two main schools of thought as to how that robot should recover.

Some people believe any crash that occurs should only be dealt with by a trained technician via the robot teach pendant and manually jogging the robot back to a known position. Other people might argue that if the robot can recover on its own, why not program that feature into the robot code?

The most popular (and perhaps the most important) question that is asked after a crash is, “How did this happen?” This is most effectively answered by collecting a small amount of data reflecting not only the time of the incident, but also a brief period of time leading up to the incident.

 

 

Multi Arm Robot

Figure 2. Any robot working alongside other equipment is subject to collisions. The recovery process is very important. Image used courtesy of Unsplash

 

Manual Recovery by Jogging to Safe Position

To ‘recover’ a robot means to get the robot back on a path or to a known position and clear any program handshakes or internal tracking code. Once the robot is recovered, the robot program loop can be started again, and the PLC can issue another command.

There are many different ways to achieve recovery. The easiest way is for a technician or trained personnel to use the teach pendant and manually jog the robot back to an exact safe position.

Subroutine recovery functions can be written to facilitate this process and clear any program tracking. This process is the fastest to integrate and requires very little programming. While slightly more automated than purely manual jogging, this method still relies on the robot operator to successfully recover the robot. If the operator chooses not to use the helper functions, the robot program could be started at a dangerous position within the code. The PLC code would require extra code to ensure the operator has completed the helper recovery program successfully.

 

Technician jogging a robot

Figure 3. Manual recovery involves using the teach pendant to jog the robot to a safe position. Although this is the most reliable, supervised method, it can be slow and inefficient. Image used courtesy of Canva

 

Another downside to manual recovery is the length of time it would take to notify a trained technician and for the technician to make their way to the problem robot. Some factories are very large and it can take some time to get a technician to where they need to be. In numerous cases, a trained technician isn’t always on-site and requires many hours of downtime until the robot can be safely recovered.

These problems argue in favor of designing an automated recovery option to save time, money, and frustration.

Automatic Robot Recovery

Not all crash scenarios are capable of automatic recovery. For example, safety zone violations must be cleared with the teach pendant, as automatic motion would be highly dangerous. A safety zone violation can occur if the robot is using calculated positions and is commanded outside the safety zone. Once the zone has been violated, a technician must use the teach pendant to clear the fault and move the robot back into the safe zone.

Scenarios involving collision detection are those best suited for automated recovery. All robots will have some kind of collision detection where the controller monitors torque or current required to move a joint according to an expected payload and inertia. If that torque or current rises above a threshold, a collision detection fault will occur.

With most robot models, such as with ABB robots, this collision detection fault raises an interrupt handler, essentially a flag bit that will be triggered regardless of the current location in the program. This interrupt can be used to call other functions or move the robot back on a path or to a known position. This recovery style requires more programming and debugging, but once complete, it can be used on other robot applications since the framework of the recovery process will be similar.

How Do You Automatically Recover a Robot?

When developing a recovery program, it is important to ensure the PLC or central controller will still recognize the fault and prevent further motion until the fault is cleared. Unexpected motion of robots is not a favorable sight for maintenance staff and safety representatives.

Again using an ABB robot as an example, you will need to configure the collision detect interrupt in order to capture it in your code. Most controllers have such interrupts built in, but they do not trigger any action unless configured, otherwise, the robot may execute an unknown recovery process and cause further damage and hazard.

 

Fault light on FANUC teach pendant

Figure 4. A FANUC robot controller indicates the presence of a fault visually. This is helpful, although faults can originate from other sources than just collisions alone. Image used courtesy of Canva

 

Once the collision event is configured, you can write your interrupt within the motion program. I prefer to put the interrupt at the bottom of the program, and using the ERROR keyword we can then look for the correct error condition. In the code below, when a collision is detected, the following process occurs:

A fault is set

A stop move is issued

The robot path is cleared

The robot restart is asserted

Finally, a recovery program (similar to the manual program where the current position is compared to known positions) will move the robot back to the known position.

The output CmdDone is set at the bottom of the interrupt so that the PLC can issue another command.

ERROR
  IF ERRNO=ERR_COLL_STOP THEN
    ! Report Collision Fault
    BitSet dnFltPend1,3;
    SetGO go03FaultBits1,dnFltPend1;
    WaitTime nFltSend;
    !
    ! Abort Move
    StopMove;
    ClearPath;
    StartMove;
  
  !
    ! Move Home
    mRecover;
    SetCmdDone;
    RETURN ;
  ENDIF

Next Question: How Did The Crash Occur?

This question is always asked after a crash happens, maintenance staff always want to know the root cause of issues, and for good reason. Knowing the root cause will sometimes help you prevent the incident from happening again in the future.

With ABB’s collision detection interrupt, you are able to write code that will execute whenever a collision happens, and remember, this does not include safety zone violations. To help with the debugging process or troubleshooting, it can be helpful to log certain variables either within the interrupt program, or relay an instruction to the central control system to immediately log important process data.

The PLC command number and any related tag values are the first variables that should be logged after a collision, especially if the position changes based on a variable sent from the PLC.

Joint torque is another variable that should be logged at the time of a collision. As robot joints wear out over time, they require more torque to move. This can result in a collision detection error being triggered with the robot actually not hitting anything. With most systems, these parameters can be stored in retentive global variables or written to a text file that is saved on the hard drive of the robot. Maintenance staff can then review these files to assist with troubleshooting the collision.

To Auto Recover or Not Auto Recover?

This question ultimately should only be answered by the controls engineers developing the robot programs and the end user of the robot after a careful safety analysis is completed.

Integrating an automatic recovery program after the robot is already installed can be difficult and require a lot of programming. Adding an auto recovery feature to a system integrated into a facility that does not employ strong robot programmers could result in many late-night phone calls if the program is not debugged and documented thoroughly.

Whichever method you choose, the goals remain the same: ensure the robot can easily recover to a safe, known position so that it can be restarted quickly to reduce downtime, provide valuable diagnostic logging, and minimize dangerous situations for workers and other equipment.

Want to learn more about programming ABB or FANUC Robots?