Safety Issue: Robots Moving in Pits

[hunterteam3476]

[quote=robochick1319;1457350]

Originally Posted by Andrew Lawrence

This entire argument is based on one's arbitrary definition of safety. If I see something as safe, then none of this applies to me. Likewise if I see something as unsafe, it all applies. The people arguing for stricter safety rules see every potential danger as unsafe, and that's their definition of the word, that's perfectly alright. The people who say such a change isn't needed see the same small potential dangers as acceptable, yet unlikely risks, and therefore view the whole thing as safe - that's their definition of the word, and likewise, that is perfectly alright.

There are clear safety hazards (such as launching frisbees into the air in the pits) that everyone can agree on as being unsafe. Anything we all agree on also happens to already be a rule (funny how that happens). The gray areas of ambiguity vary from team to team, and as such, I would suggest actions taken on these issues should be based on each individual team. As the age old saying goes, "You run your team, and I'll run mine, and we'll all be okay as long as nobody is hurting the other".[/QUOTE]

Yes, but when you run your robot in the pit, lose control and hit a team member from ANOTHER team then all teams become concerned about how you run your team.

I guess I would just ask everyone to really, really think if there is another way you could test your robot without engaging the wheels (lift them off the ground or disconnect them).

This thread has shown that I am in the minority on the opinion that this is serious risk to teams. I hope there are no future incidents that prove me right.

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"

[Sperkowsky]

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.

[SJaladi]

Originally Posted by Sperkowsky

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.

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.

[JamesCH95]

Originally Posted by Sperkowsky

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.

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

[Sperkowsky]

Originally Posted by JamesCH95

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.

[BrendanB]

Originally Posted by Sperkowsky

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

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.

[omalleyj]

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.

[Sperkowsky]

Originally Posted by BrendanB

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.

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

[JamesCH95]

Originally Posted by Sperkowsky

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

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?

[JamesCH95]

Originally Posted by BrendanB

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.

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.

[Sperkowsky]

Originally Posted by JamesCH95

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?

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.

[JamesCH95]

Originally Posted by Sperkowsky

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.

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...

[Siri]

Originally Posted by Sperkowsky

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.

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.

[philso]

Originally Posted by omalleyj

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.

[jman4747]

Originally Posted by JesseK

but wheels off the ground wouldn't solve anything for these two teams. These two hypothetical teams appear to have very little safety culture to begin with, and it starts with the adults being involved in the things that could hurt the kids or other teams.

For example ...

Lack of basic integration between hardware and software to ensure basic functionality works as-designed - Why is the team eager to test auto if they haven't performed even the basic tests for 'disable drive'?

Unchecked electrical modifications by a rookie student - really, teams do this? That's more likely to cause a robot to go up in smoke than it is to cause a runaway robot. That's also a massive liability for the adults on that rookie student's team. It doesn't mean the adult does the work or even directly oversees it - rather, the adult checks the system before power is put to it. This two-party check (not 'glance') system is SOP for any maintained industrial electrical system before power is turned on. The two teams have to consciously agree that the system is safe.

Testing a moving auto on the floor in the pits is a HUGE no-no. You're absolutely right - this should be off the floor - yet most teams with a safety culture already do this. Most teams with a safety culture also understand the futility of in-pit on-floor auto testing since the floor isn't the same as the carpeted field.

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.