View Single Post
  #104   Spotlight this post!  
Unread 16-03-2015, 13:19
philso philso is offline
Mentor
FRC #2587
 
Join Date: Jan 2011
Rookie Year: 2011
Location: Houston, Tx
Posts: 938
philso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond repute
Re: Safety Issue: Robots Moving in Pits

Quote:
Originally Posted by omalleyj View Post
I am glad to see there are so many suggestions for safe bahavior, not just "its impossible" posts, or "it has to be this <insert your favorite> way" posts.

Let me share some of mine (team programming mentor):

Every time the code changes retest.

Because getting practice field time is difficult we try to make sure the change seems to work by running it first in Test Mode, On Blocks, in the Pit. Then test on the Practice field in teleop and autonomous.

Test mode is a wonderful thing, you can test just subsystems without messing with your full auto or teleop code. This makes initial testing easier and more safe by omitting drive or mechanism code that isn't being tested.

Never enable the robot if you aren't looking at it (this is sometimes tricky, but do it). While the robot is enabled everyone in the pit should be eyes on the robot.

Announce loud and clear that the robot is about to be enabled, in which mode, the expected behavior, and likely bad behavior to watch for.

Always have your hand on the E-Stop.

Always disable as soon as you can and before anyone approaches the robot who isn't involved directly in the testing.

Rings of team members shielding the area is needed to prevent passers by from wandering in, it doesn't stop the robot getting out.

While I love people coming to the pits to visit, they should not be there if the focus isn't on greeting visitors. If everyone is wrapped up in fixing and testing its better to have them return later.
A software glitch is another reason to keep a clear kill zone around the robot when testing, regardless of where the testing is being done. Jim's recommendations that people be warned to be vigilant are another "must do". How many of you have seen a change made to one part of the code and an unrelated part of the code gets screwed up? Just because you "only changed the code controlling the LED underglow" does not mean other actuators or motors might not start moving. While pulling the breakers can prevent an accident, you will still have to test with the complete system with the breakers installed because you will be unable to detect the fault if the breakers are pulled.
Reply With Quote