Launcher Safety Ideas

[Al Skierkiewicz]

Jim,
It is usually a simple matter of knowing how the solenoid reacts at power on and making that default position be the "parked" position for actuators. Many times, teams do not take the time to distiguish that. If the action does not cause a robot part to extend out of the sizing box no change is made in the design process. Parts should not move until enabled.

[MrForbes]

That will work if we make sure to always "park" the mechanism before powering on the robot.

One concern we have with this concept is that this would cause the mechanism to park itself at power off, which could cause unexpected actions for those not familiar with the robot. It would be nice if the robot would just sit there when we kill the power.

[t-raum]

Our team plans on launching the ball. To help with safety in the pits and on the field we plan to make a safety latch that goes over our mechanism to prevent injury. We also plan release the energy in the system after the plate has been on without dry firing it.

The main thing that will help stop accidents in the pits and on the field is the fact that everyone working on the robot or in close proxcimity to it should know that it could potentially go off and take every action to ensure that this does not happen. This involves knowing where your team members are and making sure that innocent bystanders are told they need to get away from your launching device so they do not get hurt. You can tell them to admire at a distance until you are sure the system is safe.

[MrForbes]

We are taking a different approach. As Gdeaver says, a mechanism that can store energy and quickly release is a dangerous thing, and we felt that relying on interlocks and safety procedures is not adequate. So, we designed our mechanism to behave like any other pneumatic actuated device when the ball is not loaded into it (ie. it moves slowly), and to act like a ball launcher only when the ball is in place.

I think it would be difficult to do this with any mechanism that uses springs.

And any mechanism that has a latch (or two or three or...) that suddenly releases a spring loaded bar is intrinsically dangerous.

[SSMike]

I'd like to add that any team that is considering a launching mechanism should make sure that they have proper practice as to working the launcher. Like it was said above, the last thing that you want is for your launcher to go off when an inspector, team member, or bystander is too close.

That being said, I would like to remind everyone to try your best to control not only when you launch the ball, but where. Obviously, no one should (and I hope no one would) ever try to aim at another robot. First off it is a penalty, and second it just unsportsmanlike. While accidents happen, please try your best to minimize them by launching so that another robot will not be damaged.

--Mike

[The Lucas]

Originally Posted by Al Skierkiewicz

Jim,
It is usually a simple matter of knowing how the solenoid reacts at power on and making that default position be the "parked" position for actuators. Many times, teams do not take the time to distiguish that. If the action does not cause a robot part to extend out of the sizing box no change is made in the design process. Parts should not move until enabled.

To add to this: Please only use only single solenoid values on your firing mechanism, which default to "not fire". Double solenoid values stay in their last position, which may not be visually apparent when there is no pressure.

Also, use a momentary push button to launch instead of a several state switch. To reiterate what Jason said some sort of ball sensor should be part of the firing sequence.

Those are my suggestions, here are my concerns:

Please design your robot so that its firing mechanism is not loaded in the Starting Configuration, since the robot must be sized in this configuration without additional restraints. Sliding the robot into the sizing box and using the magic sizing wand on a loaded robot could set it off and that is not safe. There will be plenty of time between match start and first hurdle to load you mechanism (the whole 15 sec hybrid mode for instance).

Finally, this is a high speed collision game, so consider 20fps collisions as "normal operating conditions"

[rcflyer620]

Ah, all well and good. But here's what really concerns me (and if there is already an active thread on this please point me to it)...
This whole IR board thing and what we are allowed to do with it. I personally will be very afraid in the pits if anyone near me is using the same IR channel and accidentally sets off something on my robot or a robot near me.
The IR board is outside the limits of the tether and in my mind that poses a huge safety issue in the pits.

Any other thoughts? or am I just paranoid?

--Mark

[thefro526]

One of my main concerns with launchers is the possiblilty of launching a ball onto another bot. My teams bot should be robust enough to withstand an impact but some bots won't.

[EricH]

Originally Posted by rcflyer620

Ah, all well and good. But here's what really concerns me (and if there is already an active thread on this please point me to it)...
This whole IR board thing and what we are allowed to do with it. I personally will be very afraid in the pits if anyone near me is using the same IR channel and accidentally sets off something on my robot or a robot near me.
The IR board is outside the limits of the tether and in my mind that poses a huge safety issue in the pits.

Any other thoughts? or am I just paranoid?

--Mark

I too am concerned about this. There are some ways to avoid it, including:

• Robot OFF when in the pits, unless you are testing.
• Robot DISABLED when on, unless you are actually on the field or doing something with it.
• Make something that can cover your IR board and shield it while in the pits, unless you need to test it. FLL teams have been encouraged to do this for a while now; a common trick is to line a box with aluminum foil.
• Warn surrounding teams that you are testing. This gives them time to avoid issues or warn you that there may be an issue.