Robotic safety standards are designed for commercial bots, but amateur robot builders should also consider ideas like the keepout zone where a mobile robot isn’t permitted to go or how to draw out the safety perimeter space for your experimental robot arm. After all, that robot arm won’t stop crushing your fingers because you built it yourself. So, it is worth looking at the standards for industrial robots, even if your aim is fun rather than profit.
The basics of this for fixed robots like robot arms are defined in the standard R15-06. You don’t need to read the full text (because it costs $325 and is *incredibly* tedious to read), but the Association for Advancing Automation has a good background on the details. The bottom line is to ensure that a user can’t reach into an area that the robot arm might move to and provide a quick and easy way to disable the motors if someone does reach in.
Robots that move, called Industrial Mobile Robots (IMRs) or Autonomous Mobile Robots (AMRs) bring in a whole new set of problems, though, because they are designed to move around under their own control and often share space with humans. For them, the standard is called R15.08. The AGV network has a good guide to the details, but again, it boils down to two things: make sure the robot is keeping an eye on its surroundings and that it can stop quickly enough to avoid injury.
There just was recently a news story about a South Korean employee who got maimed by an industrial robot and died of his injuries. They were apparently inspecting the robot, but had not disabled it or its sensors, so it recognized a box in the employee’s hands and went to pick it up, grabbing the poor guy, instead.
I did a course on programming ABB industrial robots and we went through quite a bit of safety procedures and mechanisms and basically this exact scenario was one of the examples the instructor told us about.
Keepout zones as a safety solution are, in my experience, a solution of very last resort. With very rare exceptions, it’s much harder to prove that a robot won’t ever move somewhere it’s physically capable of than to simply position it such that it never moves anywhere dangerous. That said, I work in industrial automation, in factories with enough floorspace to not necessitate too much space sharing. I think one of the biggest obstacles is the sheer number of hours, and thus dollars, everybody has to spend in safety review and qualification meetings, it could easily add a couple dozen grand to a project’s bottom line. I have seen it a couple of times, with the ones that spring to mind being:
– A very expensive robot-mounted tool for a process that requires a lot of human involvement. Robot’s mounted in the middle of two work cells so as humans work in one of them, the robot is locked out of that side and works on the other.
– Similar robot, but instead of one of the cells you have a calibration/maintenance area.
– A robot (6ax or gantry) on a long linear rail, people can work on tooling in one section and the robot is locked out of that area.
I’m sure that there are fields where this might be more commonplace, and I also know that there are fields where COBOTs are being integrated, specifically to try and facilitate space sharing with humans. I haven’t had direct experience with COBOTs (a lot of it is that they are, by necessity, very slow when in human-interaction mode), but it seems closer to happening in my field with every project I’m on.
Something not obvious: I worked in a factory for a while that used huge palletizer robots to stack 50 pound bundles of product. It had a fence about 8 feet high around it to keep people out of the work cell but I always wondered how far it could throw a bundle over the top of the fence if it lost grip during one of the high speed motions. My guess is about 25 feet based on the speed it moved.
Back in the late 80s, I was attending a DECUs ssymposium (a conference for DEC gear users, supported and vendor). One presentation was by a leading light in the use of DEC gear for controlling industrial robots. Somehow the subject of dealing with cocky overconfident young system programmers who wrote bad code for these dangerous devices came up. The expert said he had developed a way to deal with them. He’d ask them if thye were really sure there were no bugs in their code. If they replied yes too quickly, he’d tell them they had to stand in the test cell with the robot while it did its task, controlled by their code He reported that they always said that maybe they’d like to take another look at their code, to make sure it was good…