340lb Open Source BattleBot Malfunctions In Near Attack At BarCampAustin3 During SxSW.
Document Actions
As they say, it's all fun and games until someone loses control of a 340lb battlebot
So this weekend BarCampAustin3 (held during SxSW) featured a ton of amazing things including some fantastic sessions, a mini iPhoneDevCamp, and a singing Unicorn at Karaoke Apocalypse.
All went well save one small incident involving a 340lb BattleBot malfunctioning and then taking off as fast as it could for the closest Microsoft employees (including Josh Holmes who you see leap out of the way). Thankfully no one was hurt or injured and they were amazingly good sports afterwards:
Many thanks to the folks at Viewzi.tv for the amazing editing job. And, yes we still love Brady and TeamDX! Good luck in the new season on ESPN guys!
_____
tags:
Deadman switches
Posted by
Paul Reiber
at
2008-05-22 13:24
Even on my "toy" LEGO Mindstorms robot projects, I design in "deadman switches".
It's a simple idea - a touch sensor for my thumb that has to be held down for my robots to move. Here's an example of how you might add this safety measure to your own robots:
I use two LEGO Mindstorms controllers, talking Bluetooth to each other. One is the "robot", the other is the "controller". The controller sends arrays of information (mostly sensor readings) to the 'bot, 4 times per second. That could be higher, but I've found 4x/sec to be a reasonable balance, resource-utilization-wise.
Most of the information that's sent in those arrays is cool stuff like motor-encoder-values, accelerometer and gyro readings, but most important value sent over to the robot is an integer "mode".
The robot's main loop uses the mode value that it gets from the controller (4x per second) to decide what to do next. Inside the "case" statement for the mode, it takes one discreet "step" in that mode, using whatever other information it needs (remote sensor readings, local variables, local sensor readings, etc.) to accomplish that step. If the mode involves a PID loop, it would take only one step of that PID loop, rather than looping inside the case statement. I.e. it's NOT ok to implement inner loops that ignore the changes to mode that might be happening.
OK here's hoping you're still with me. I said this was simple, and it really isn't very complicated. On the "controller" side, there's a user interface for selecting the desired mode, but that end-user-decision gets overridden in an instant (or a quarter second anyway) by the logic that checks if the deadman switch is pressed. Any time that switch isn't being held down, the controller is sending 0 for the mode instead of the value the user desired.
The final part of this is to have "mode 0" on the robot implement a full stop. As in, "stop the motors, hit the brakes."
End result: As soon as I let my thumb up off of that touch sensor, my robots stop dead in their tracks.
Here's hoping this little gem of advice will help others avoid mishaps like this one.
-Paul Reiber
http://reiber.org
It's a simple idea - a touch sensor for my thumb that has to be held down for my robots to move. Here's an example of how you might add this safety measure to your own robots:
I use two LEGO Mindstorms controllers, talking Bluetooth to each other. One is the "robot", the other is the "controller". The controller sends arrays of information (mostly sensor readings) to the 'bot, 4 times per second. That could be higher, but I've found 4x/sec to be a reasonable balance, resource-utilization-wise.
Most of the information that's sent in those arrays is cool stuff like motor-encoder-values, accelerometer and gyro readings, but most important value sent over to the robot is an integer "mode".
The robot's main loop uses the mode value that it gets from the controller (4x per second) to decide what to do next. Inside the "case" statement for the mode, it takes one discreet "step" in that mode, using whatever other information it needs (remote sensor readings, local variables, local sensor readings, etc.) to accomplish that step. If the mode involves a PID loop, it would take only one step of that PID loop, rather than looping inside the case statement. I.e. it's NOT ok to implement inner loops that ignore the changes to mode that might be happening.
OK here's hoping you're still with me. I said this was simple, and it really isn't very complicated. On the "controller" side, there's a user interface for selecting the desired mode, but that end-user-decision gets overridden in an instant (or a quarter second anyway) by the logic that checks if the deadman switch is pressed. Any time that switch isn't being held down, the controller is sending 0 for the mode instead of the value the user desired.
The final part of this is to have "mode 0" on the robot implement a full stop. As in, "stop the motors, hit the brakes."
End result: As soon as I let my thumb up off of that touch sensor, my robots stop dead in their tracks.
Here's hoping this little gem of advice will help others avoid mishaps like this one.
-Paul Reiber
http://reiber.org
Forgot your password?
New user?
BarcampAustin 3 was fun.