Re: Safety Issue: Robots Moving in Pits
 

[quote=robochick1319;1457350]
If anything the only way that we wouldn't test and run our robot in the pit is if we get 10 practice field. We are never going to solve the pits not being "safe". There so many things that could go wrong. Why would we take away from everyone else the ability test their bot because of 1 team? Your always going to get that 1 team/person who isn't being "Safe"

I'm going to propose our team making a platform with 2x4's in the front and a plywood platform in the back for the totes to sit. That way you can test your stacking mechanism on the floor. If my team agrees I'll build it today slap a vinyl number on it and bring it to the sbpli regional.

Re: Safety Issue: Robots Moving in Pits
 

I commend your good intentions but good luck getting more than a few teams who would want to use it. I forsee that even if provided with said platform most teams wouldn't use it because of the simple fact that the platform you build for your robot won't suit theirs.

Re: Safety Issue: Robots Moving in Pits
 

What happens when a robot drives off of the platform? Or am I missing something?

The robots frame will be resting on the 2x4's not the wheels. It's OK dude.

Re: Safety Issue: Robots Moving in Pits
 

Its a valid point and a safety concern as to why just throwing it on wood blocks isn't always as safe as it sounds. I've seen many robots tip off of wooden blocks when the robot appendages move and the CoG shifts.

Re: Safety Issue: Robots Moving in Pits
 

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.

If the wood blocks are wide enough it shouldn't tip over.

Re: Safety Issue: Robots Moving in Pits
 

Okay, dude. That was not at all obvious from what you described.

It sounds as if you'll be making it available for any team to use, so how will it be general enough to work with any team's frame/wheel combination?

Re: Safety Issue: Robots Moving in Pits
 

This too. Heck, if something went wrong our robot would tip over, blocks or otherwise...

I've also seen wheels climb on top of blocks and drive off them. Blocks are not fool-proof.

It will be made for the kit chassis. Even a version that has the front cut out. We can't adapt It that well for everyone but most people who don't have a safe system in place are probably teams using the most chassis.

Re: Safety Issue: Robots Moving in Pits
 

Consider making a robot 'playpen' instead. A plywood sheet covered in carpet with a rigid barrier around the edge. Robot drives on carpet, works with any chassis, robot can't drive away, no blocks to tip over...

Re: Safety Issue: Robots Moving in Pits
 

I am not at all objecting to this idea, and more power to you for taking this initiative that you see as useful.

That said, most of this thread is about how smart and well-meaning safety devices and procedures (pulling breakers, disabling code) can be improperly/ineffectively implemented without something at we're calling "common sense" and/or "safety culture". Depending on your team and robot, it may be more likely that you'll disable code incorrectly, or that you'll disconnect electronics incorrectly. Or that you'll use the mechanical wheels-up method incorrectly. Have you ever seen a robot change CG quickly or contact something with its manipulator such that its wheel contact the blocks? I have. What about someone or something knocking into it that could cause the wheels to contact a surface?

Is the mechanical solution better than the programming or electrical solution? In general? Maybe. For a specific team? Who knows; I don't. Feel free to argue that it's better, but I don't see how you can argue that it's foolproof. Maybe you can personally make a rig that is foolproof (I raise you a better fool) by sizing it correctly/etc, but it'll be just as specific if not more so than pulling a breaker. Every solution has its problems; ignoring them seems to me personally to be hypocritical.

Re: Safety Issue: Robots Moving in Pits
 

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.

Re: Safety Issue: Robots Moving in Pits
 

On the initial point, the thread is about robots driving in the pit. If we try to have any broader of a discussion this won't yield any result. All of FRC safety is to big for one thread.

"Lack of basic integration between hardware and software to ensure basic functionality works as-designed" and "Unchecked electrical modifications by a rookie student - really, teams do this?" Yes I'm pretty sure it has/will happen. You do realize this is FRC right?

In fact very early in our 2014 build this (variation on elc scenario) happened with a couple of our rookies. Just as the drive base was done I instructed them to use their own knowledge and reading skills to figure out how to wire it. The point was to not have me/mentors hover over them when we don't need to and let them learn from any mistakes. So after they were done we placed the drive base on blocks, place the battery in, check main breaker, plug in battery, and flip main breaker. And the robot goes nowhere as the left side drive spins in mid air. I knew it would happen but I was sill able to let them see it and understand how that kind of mistake would affect them in less controlled environments. If we were at a competition at that knowledge level they wouldn't have looked at a victor 888 so long as I was around or even alive.

My elc scenario example assumes 1. lack of a more experienced person to check 2. competition stress and fatigue 3. added stress of a critical failure 4. an immediate time crunch. 5. no blocks. So yes I can see how something similar can happen.

Edit: Just as I post this and go to the top of the page I see this in the spotlight section: I always say find what works best for your team, for your given situation. Why should we rely on someone else to tell me what will work best for our situation? - JVN

So I'll take that as a sign to quit arguing.