²
Blog post by David McMillan, Senior Application Engineer at AMT. David has been in the robotics industry for more than 20 years, and is one of AMT’s go-to people for new or unusual technologies. For more information on AMT’s expertise in robotic applications, visit this link. To read David's humorous eBook, Improving Robot Accuracy, click here.
(Ahem!)
Hi! I’m Dave, and, uh… I’m a crash-test dummy (also an automation engineer, but that’s not the fun part of this story).
Oh, and there’s a bit about mounting sharp tools onto cobots (collaborative robots), why that might be a bad idea, and how to handle it if you have no choice. But you’re not here for boring stuff like that, right?
The Tale Begins
This tale begins, as so many do in our line of work, with a deceptively simple customer RFP: a lightweight robot to pick up small bolts and drive them into specific holes in a part, to a specified torque, without all that expensive safety stuff that we normally surround our robots with to keep them safe from those pesky, squishy human operators.
It seemed straightforward enough: the required payloads and speeds were well within the capacity of a light-weight cobot, and cobots don’t need safety fences, gates, scanners, etc., right? Okay, let’s do this!
(Those of you who have done this dance before? Feel free to insert your favorite comedic “traffic pileup” sound FX here)
Unexpected Hurdles
The first unexpected hurdle was the actual torque that needed to be applied. Buying a “smart” torque driver that could handle the task, as well as light enough to be carried by the cobot, was easy enough. Until someone thought to ask: “Can the cobot resist that torque?”
That ended up being a tricky question to answer. On the surface, it seemed easy – the cobot only needed to hold still while the torque driver was torquing down the bolt. How hard could that be?
Fairly hard, as it turns out. Cobots are, by design, much weaker than their “big iron” cousins. This doesn’t just limit their ability to lift and carry payloads, but also their capacity to resist external forces. In this case, the “recoil” of the torque driver would be enough that the cobot, even on its most “insensitive” settings, would interpret it as a collision and throw a safety fault. Which is also by design: in order to be safe to work around humans, cobots are built to be hypersensitive to anything that might possibly be human contact – even poking one with a single finger can be enough to make a delicate, sensitive cobot stop and yell for help.
(They’re also very thin-skinned to criticism – don’t yell at them too much, their feelings are easily bruised. Don’t ask me how I know this.)
Fortunately, our selected cobot had a non-collaborative mode (NCM) available, which could be switched on and off from inside our program. And in NCM, the robot was strong enough to hold out against the forces being applied by the torque driver. But! I hear the audience already saying: If you set your cobot into NCM, it’s not Safe anymore!
Very true! And thus, the First Lesson of Collaborative Robotics: when your cobot is not 
configured for collaborative operation, it’s not a cobot anymore. This may only be temporary, but whenever your cobot is in NCM, you must treat it as if it were a “big iron” robot, or else you are not Safe. And being Safe (not just “safe”) is important in robotics – humans have a bad tendency to get their squishy bits into your nice clean automation if it’s not Safe, and the resulting mess takes forever to clean up. So, keeping everything Safe is good. It’s also The Law, in many jurisdictions, and we all like staying out of jail, right?
Enter our next relevant cobot feature: this particular cobot had a safety module that worked the same as those for its “big iron” cousins. And one of its options was a safety-rated “standstill mode” – basically, it would hold the robot in one place, and if it detected the robot moving more than a couple of millimeters, for any reason, it would kill the robot with a safety fault.
The Process
So! We now had all the bits and pieces we needed, all that remained was to assemble them into a working whole.
Our process for handling the torque issue became:
1. Robot in collaborative (Safe) mode
2. Robot picks up the bolt, and moves to the hole the bolt needs to be driven into
3. Robot activates standstill mode
4. Robot activates NCM (it’s important to do this after activating standstill mode!)
5. Robot triggers the torque driver to, well, torque down the bolt (in this case, no one could get their fingers under the bolt head, so this presented no safety issues)
6. Robot activates collaborative mode
7. Robot deactivates standstill mode (again, this needs to be after reactivating collaborative mode)
8. Go to step 2
Force Versus Area
But what about the crash-test dummy story? I hear the audience asking. That’s what we came to read!
Okay, okay, I’m getting there. This actually starts with the next unanticipated issue we ran into: force vs area.
Here’s the thing: cobots are “inherently safe” because they are “force and energy limited” (at least in collaborative mode). A cobot cannot exert enough force to do serious harm, cannot build up enough speed to do serious harm, and immediately stops with a safety fault if it detects any conditions that violate those rules – for example, if it detects that it’s collided with something, or someone, with anything greater than a certain safety-rated level of force.
But injuries aren’t simply caused by force – they’re caused by force over area. A boxing glove hitting you with five pounds of force won’t even raise a bruise. A screwdriver (the pointy end) hitting you with five pounds of force can hurt, and even cause injury, because the screwdriver concentrates that force onto a sharp point.
This is why most cobots look like they were designed by Apple, all soft curves and no sharp corners – avoiding sharp corners that can concentrate force helps make them Safe. On the flip side of that, attaching a sharp pair of scissors to your cobot is only marginally safer than letting a toddler run around with those same scissors (Look! A call-back to the title!).
In our case, the bolts we were picking up and inserting into holes were flat-tipped, but they were quite small, M5s (about 3/16”, for you non-metric types). And while a detailed discussion of RIA 15.06 lies outside the scope of this article, that specification actually lays out specific limits for force/area for specific body parts. It turns out there are different limits for fingers than for palms, than for forearms, and so on. And since the operator’s hands were the body parts most likely to accidentally get caught between our cobot and the part, the “hands” table of the RIA spec was where we had to look for our limits. And discovered that for the small contact area of the tip of an M5 bolt (about 20 mm², or about 0.03 in²), the allowable force was quite low.
Now, one of the limitations of all cobots that’s not always obvious is that there is a lower limit for the amount of contact force they can reliably detect. And the higher the cobot’s rated payload, the higher that limit is likely to be. In our case, our cobot could not reliably detect contact forces lower than about 35 N (about 7.8 lbs) at the end of our torque driver. Or, rather, if the cobot’s sensitivity was set any lower than that, it would start getting “false positives,” detecting collisions even when it was moving in open air. So, that gave us a lower limit for the sensitivity we could use.
And this is where I used myself as a crash test dummy.
Now, in my case, the emphasis is probably on “dummy,” but I wasn’t quite foolish enough to simply place my hand on the table and let the cobot stab me to see what happened (entertaining as that might have been for my audience). Instead, I used another feature most cobots have: position-holding mode. On most cobots, you can program the robot to hold a position in space against external forces, up to a certain limit – above that limit, the cobot will let itself be pushed around.
So, I programmed our cobot to hold position up to 35 N of force, stuck an M5 bolt into the torque driver, and proceeded to (carefully!) press relevant bits of my squishy self against the tip of the bolt until the cobot moved. Then, I measured the amount of damage to my anatomy (remember, if you take good records, it’s not playing around, it’s SCIENCE!).
The results were… anticlimactic. No severe bleeding, not even any major bruising. Just some small (but sore!) dimples in my epidermis that took maybe half an hour to fade. The RIA safety spec turns out to be on the conservative side – color me surprised!
Now, I should hasten to point out that this experiment did not qualify as a safety-rated test, and as such was not a free pass to ignore the issue. But it did give us a good practical benchmark for what we were dealing with, as well as a visceral (see what I did there?) appreciation for what the abstract numbers in the RIA chart translated to in real-world “ouch” units.
Summary
In the end, by the numbers, we were able to make our system sufficiently Safe as to pass the applicable safety standards and still qualify as a cobot. Success! Bonuses for every– what do you mean, “another harder job”?
Well, as fun as this has been, I have to get back to work. But I would like to leave you with these closing thoughts:
1. Buying a cobot is the beginning of your detailed safety evaluation and analysis, not the end.
2. Cobots may be inherently Safe, but keeping them Safe once you start strapping on sharp pointy bits, powered tools, high-energy lasers, spray guns, flamethrowers, tasers, or other hardware is just as complex as making a “Big Iron” robot Safe – probably even more so, given that using a cobot implies an expectation of “no fencing.”
3. Cobots tempt one into complacency – not just integrators, but end users. People just won’t be as careful around a cobot as they will around a (much scarier) “Big Iron” robot. Keep this in mind during your safety evaluation.
4. Using a cobot means you have to read more sections of the safety standards documents, not fewer. And your checklists get longer.
5. Making “Big Iron” robots Safe is often as “simple” (ahem) as “more fence!” Making a cobot Safe (and certifying it so) can easily be more complicated, in large part because a cobot is liable to have more direct interactions with Squishy Humans, and thus more opportunities for something to go wrong.
And now that I’ve made sure none of my dear readers will be able to sleep for at least a week, my work here is done! Happy cobotting!
For more of David McMillan’s humor and robotics expertise, download his eBook, Improving Robot Accuracy.