Collaborative robots and breaking down evolving risk assessment

Source: Robotiq

During the last 50 years, industrial robots have been increasingly used in manufacturing industries around the world. The technology has been evolving and adapting to the needs of its users. Over the years people have been doing their best to analyze the safety aspects related to a robotic cell. Of course, accidents happened and risk assessments became more crucial. At the same time, safety standards and safety components have also been evolving to better address safety issues related to robotics. So where do we we stand today?

From the moment when the first robots were introduced into factories, the industry has been studying how certain robots and their surrounding equipment could potentially harm the human workers who interact with them. We have been looking at automation as a whole. Asking ourselves questions like:

• How fast can this robot move?
• How far can it move?
• How dangerous is the process that the robot is performing?
• How can I prevent these strong and fast robots to hit a worker?

These types of questions allow users to perform risk assessments; to identify safety features that could be added to the robotic cell to keep human employees safe while the robot is running. The common solution to keeping humans safe usually involves locking the robot inside safety fences that prevented any contact between the robot and the human workers. Thus this solution became common to people involved in the risk assessment process. These ideas are very prevalent and almost automatic. This way of thinking is still what we use today when it comes to doing a risk assessment for a robotic cell. It looks like our mindset is programmed this way and this may seem like the best way to do it.

However, robots have evolved and we should take advantage and adapt to these changes. Believe it or not, with collaborative robots becoming ever more frequent in the market today we have to change our mindset. We have been creative in the past in finding new applications for robots, now it’s the time to be creative about how we do risk assessments. I recently attended a conference on collaborative robots given by our partner, Advanced Motion and Controls, in Montreal in February and this conference completely changed my thinking on the risk assessment process. As Universal Robots users discussed applications and risk assessments that they had done at different factories, two important quotes stuck in my mind.

1. Risk assessment for collaborative robots are not ‘Volume’ based, but rather ‘Sequence or Process’ based.
2. A risk assessment for a collaborative process is not something you set in stone, but rather an evolving process that will change over time.

Let me describe these two ideas and explain how they changed my thoughts about risk assessment.

Saying that the risk assessment of a collaborative application is sequentially based rather than volume based means you have to approach your risk assessment differently. Instead of looking at the big picture for the robotic cell and working the risk analysis on the entire process with all its components, you should split up the various aspects and analyze them one by one.

For the purpose of this article we will consider the following example. You have a robot that is used to load parts onto a workstation for assembly by a human. Once the assembly is done, the robot picks up the assembled part and places it on a conveyor. In this example, the robot and human worker can work in two distinct assembly regions. Therefore, while the human is assembling one part, the robot is already loading parts and preparing for the next assembly (see the schematic below). Also note that the human cannot physically reach the conveyor.

So the old way of thinking when we looked at traditional industrial robots would be something like this:

I have a robot that can go really fast and potentially hit a human. If this happens, the human worker can be seriously injured. I need to prevent contact with the human at all times, anywhere in the cell. So right away, I am thinking cages, fences or light curtains.

There are 2 assembly zones inside the robotic cell that need to be accessed by both the human worker and the robot, but not necessarily at the same time. This is a complex part to deal with using an industrial robot. I can use an area scanner to monitor the human position and deny access to the robot when the human enters a specific zone. It may get hard to handle all situations in this case because the human and robot will interact a lot during the day so there are many different cases you need to handle in the programming sequence.

Also you still need some sort of physical or safety rated separation between the zone where the robot will interact with the human and the zone where it will be allowed to operate at high speed. Something like safety curtains, or actuated doors. You also need a fence in between the two assembly zones if you want the robot to be able to move in one zone while the worker works in the other nearby assembly zone. Because you don’t want to operator to walk 5-10 steps to reach the other assembly zone, you want them very close to one another.

Another potential solution could be to have the assembly table mounted on a rotary actuator that would rotate both assembly zones such that one is on the robot side and the other on the human worker side. If this is the way we go, we need a design with no pinch points during the turning motion and we need to consider fault sequences if something gets stuck. So you can see we can have a lot of alternatives and lose time trying to find the best cost-effective and safe solution!

Now, with collaborative robots designed to work alongside humans and doing the analysis on a sequential level, rather than the entire robotic cell, we will do something like this:

The robot is picking parts and placing them in assembly zone #1. In this process, the robot can make contact with a human worker at any time. So the robot speed should be reduced during this part of the trajectory and the power and force limiting functions of the collaborative robot should be used to prevent injuries in the case where the robot accidentally hits the worker. In order to figure out a safe speed at which the robot can move I can use the formulas set out in the new ISO 15066 technical specification recently promulgated on this subject. So establishing these values is much simpler.

At this point you might be tempted to say that when humans are outside the collaborative zone the robot should go as fast as it can to reduce cycle time. Instead, take a look at the average cycle time for the worker to do the assembly before the robot comes and picks it up. This will set your required cycle time for the robot motion. You will most likely be left with two options.

• Option 1 is simply that you can run the robot at the safe speed during the entire process therefore no need to add any extra safety features.
• Option 2 is that you need to increase the speed of the robot at some places in the process to reduce the overall cycle time. In this case, the best solution might be to simply add an area scanner or a light curtain that would detect the worker’s presence in the ‘fast operating zone’. Again with cobots compared to industrial robots, when a human enters the robot’s zone, there is no need to stop the robot. You can simply have the cobot set to the maximum speed that you calculated from the ISO 15066 technical specification.

Another example of a sequentially based safety analysis is where a robot has to carry a sharp object from one point to another as part of its task. The old way of thinking would probably be to say that since the object is sharp, the robot can severely injure a human worker. But let’s look at this more closely:

The robot will pick up a sharp object from point A and move it to point B. Assume that in all other steps of the process the robot is not carrying this object. The question should then be — how can I make that move from A to B safe while carrying the sharp object? The answers can be as simple as carrying the object in a certain path or orientation, such that the sharp edge is facing backward during the motion, therefore, eliminating the risk of someone getting stabbed or cut by the object as the robot is moving.

Also, reducing the speed for this move is another potential solution. Instead of finding ways to prevent stabbing in all aspects of the cell, you could consider only the potentially dangerous sections and do the analysis on these. Of course, it would be a good idea to make sure that you lock these programs with a password to prevent modification without a revised risk assessment. Every time the robot’s program is altered you should review your risk assessment and verify that the modification does not affect the cell’s safety. This is why it is an evolving risk assessment process.

You can easily see how collaborative robots might have initially been perceived as a nightmare by people responsible for workplace safety, especially if they thought that risk analysis was complex for robots. But breaking the risk analysis down into sequential steps, knowing the process is not set in stone, makes the whole process manageable. This will also make it easier to convince management or workers about the safety of these robotic cells. Changing your way of thinking about safety analyses and remembering that the evaluation process can be changed as circumstances dictate will definitively convince more people to try collaborative robots.

Also, don’t forget that when performing a risk assessment with a force limited collaborative robot, like Universal Robots, the severity level of possible injury can be lowered when the cobot is properly adjusted for force and speed. Using a cobot like this should help you reach the proper performance level rating (PLR) for your automation task.

If you enjoyed this article, you may also like:

• Safety concerns for collaborative robots
• Should we fence the arms of Universal Robots?
• Key takeaways from #ICRW2015 International Collaborative Robots Workshop

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

Alexandre Paré is an Application Engineer at Robotiq.

Alexandre Paré is an Application Engineer at Robotiq.

Robotiq Inc. Robotiq's mission is to free human hands from tedious tasks so companies and workers can focus where they truly create value.

Robotiq Inc. Robotiq's mission is to free human hands from tedious tasks so companies and workers can focus where they truly create value.