Join Hackaday Editor-in-Chief Elliot Williams and Staff Writer Dan Maloney for their take on the hottest hacks in a hot, hot week. We found a bunch of unusual mechanisms this week, like an omnidirectional robot that’s not quite wheeled but not quite a walker either. Or, if you’d rather fly, there’s a UAV that’s basically a flying propeller. There’s danger afoot too, with news of a chess-playing robot with a nasty streak, a laser engraver that’ll probably blind you, and a high-voltage corona motor that actually does useful work. We’ll use our X-ray vision to take a deep dive into a 60-GHz phased array antenna, let a baby teach a machine what it means to be hungry, and build a couple of toy cameras just for funsies. Balloons as a UI? Maybe someday, thanks to ultrasonic levitation. And we’ll wrap things up by snooping in on the Webb telescope’s communications, as we find out how many people it takes to make wire harnesses. Spoiler alert: it’s a lot.
Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
Episode 179 Show Notes:
News:
What’s that Sound?
- Listen to the podcast, recognize the sound, fill out the form to be elligible to win a Hackaday Podcast t-shirt.
Interesting Hacks of the Week:
- Turn Drone Into A Large Propeller To Increase Hover Efficiency
- Reverse Engineering A Phased Array System Reveals Surprising Details
- Atmospheric High-Voltage Motor Makes Useful Power
- Digital “Toy” Camera, Made For Tilt-Shift And Other Analog-Like Experimenting
- Omnidirectional Walker With Wheeled Feet
- Digital Measuring Wheel Is Exactly What It Sounds Like
Quick Hacks:
- Elliot’s Picks:
- Dan’s Picks:
Frankly, I’m disappointed that nobody has watched the robot chess video closely. So much reporting about this is wrong. Please watch the video again and notice that the robot does not grab the child’s finger. It is halfway through a move to take the child’s piece. First it removes the child’s piece and then replaces it with its own piece. Therefore the child’s finger is crushed between the piece the the robot is placing and the piece that the child has pre-emptively moved because he was about take the robot’s piece.
That might seem like a trivial distinction but it means at least 2 things:
1) It had nothing to do with the gripper, cameras, image recognition or *groan* AI ethics
2) It had everything to do with the fact that this is an industrial robot that is not designed to be around people.
The robot appears to be a Kuka Agilus (I have worked on some robots from this family) and let me tell you that this is bad, even for an industrial robot. Kuka robot controllers do not have adequate collision detection. You can set a per-axis torque limit, but that limit pays no heed to the speed/orientation/payload of the robot, so it is difficult to set it to a meaningful threshold without risking false triggers. In contrast, ABB robot controllers check the current torque against expected torque, taking into account the robots speed/orientation/payload. Therefore, the Kuka robot will not stop until it has literally given its all, and then it will stay there. In contrast, ABB robot controllers will attempt to reverse the last 75ms its trajectory to remove the pressure (you can see how much pressure was being applied to the finger by how far down the robot moved after he got his finger out). Finally once the robot has stopped, Kuka robots have no manual brake release button. In contrast, ABB robots have a brake release button and the larger robots have a per-axis button. So you’re left with an awful decision: Remove obstruction first (they probably broke his finger by pulling him out) or grab the joystick and tell everyone around you “Stand back, I’m 85% sure I’ll drive this thing in the correct direction first time”. The joystick on a Kuka pendant is a 6-axis joystick mounted on the side of the pendant and can be configured in different directions. It’s daunting enough without children involved. Also if there are emergency stop buttons to push (which there should’ve been) and if someone has helpfully pushed one or more, you can no longer move the robot without releasing the emergency stop(s).
This safety trifecta (collision detection / retraction / manual release) is why we stopped using Kuka robots at work.
There’s no excuse for having that robot around people. Both Kuka and ABB make collaborative robots that would be perfectly suited to this task. They are lightweight, slower moving, have adequate torque sensing, collision detection but…
…they are $10k-20k extra. This ends up being purely a money vs safety story.
I’m with you.
The robot appears to be programmed to execute its moves essentially open-loop once the human presses the clock. Nobody on Hackaday said anything about AI or CV, except that it does seem to read the board after the human has moved. It certainly wasn’t _going for_ the kid’s finger — the kid got in the way of a pre-programmed motion.
And we all seem to agree that it’s not an appropriate setup vis-a-vis safety.
Since you seem to know a bunch about these — I was wondering what the “right” press-the-red-button mode could possibly be with a big robot arm. You can’t just say de-energize the motors, b/c then the thing falls over. You can’t lock motors full on, b/c then it won’t let go of the kid’s finger.
Back in the day, we didn’t have the sophisticated sensors to say “reduce all torques to the point where the arm doesn’t move, but only that far” but it strikes me that you could do so these days. That might actually be a useful big-red-button action — going to some kind of neutral / minimum torque.
Of course if any of the position sensors fail, it fails. But it might be better than just holding position at full torque? I can’t see a perfect solution here.
The mainstream news reporting on this was woeful and the first link in the show notes is a particularly groan-worthy mis-interpretation of the incident, shoe-horned into a giant rant about ethics in AI (which itself may have some merit but I wasn’t going to read 6500 words to find out).
The “right” way to deal with robots vs. people as I see it can be broken into 2 main options:
1) Use a “standard” industrial robot with interlocks to ensure that the robot is never live with a person in proximity. Robots are usually in cages where all doors have safety switches. If a person needs to frequent the same area, you use a light curtain (a series of parallel beams to detect entry) or a floor scanner. There are standards that govern the complicated relationship between the distance from the light curtain to the robot, the stopping time and speed of the robot, the resolution of the light curtain (can you fit a finger, hand or arm between the beams), the sum reaction time of all the safety switches/controllers/relays and the theoretical max entry speed of a person. More upmarket robot safety systems can use floor scanners with multiple zones to scale the robots max speed based on human proximity to satisfy the above relationship while getting maximum productivity from the robot. With industrial robots, when the safety is tripped, all brakes go on (the brakes require power to release so even a power failure renders the robot “safe”). If people aren’t in there while the robot is moving, locking motors in position is the safest when people are around. One caveat to that is the automatic attempted retraction-after-collision in my previous reply which can add extra safety by minimising the risk of built up pressure that could be invisible to a person entering a robot area.
2) Use a “collaborative” robot. The collaborative robots that I have worked with have a number of means of minimising risk. Speed, torque and grip-strength are all limited by mechanical design and by software. Per axis speed is limited as well as the cartesian speed of the elbow and tool. The torque is compared against the expected torque, calculated using known mass of arm/tool/workpiece/etc. Deviations above a certain threshold are considered collisions and lead to a stop. On the up-side, any real collision (or even encoder or motor failure) will cause a stop immediately. On the down-side, it’s difficult to do meaningful work like this. If you google “Yumi vs Rubiks” you’ll find one of my videos with a collaborative robot, and in that example, turning one face of a rubiks brand cube (not a speed cube) was near the limit of the friction that the robot can cast a blind eye towards before suspecting the worst. There’s some direct tradeoffs between safety and usefulness, which leads me to suspect that the number of these at tradeshows and educational institutions outnumber those doing “work”.
The stop regime for that robot was to lock the brakes for the first 4 axes and leave axes 5,6,7 free (robot makers seem to prefer making collaborative robots 7 or 14 axis rather than 6, presumably to mimic human movement better). The arms were very light and the brakes were fairly weak, so you could overpower them if needed, or you could press the brake release button. This feels like the closest you can practically get to the “perfect” safety stop scenario.