Safety Issue: Robots Moving in Pits

[philso]

Originally Posted by robochick1319

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.

Is this the only way to make the testing safe? Perhaps consider what FrankJ suggested. In Risk Management, we are taught to minimize the probability of a negative outcome AND minimize the impact of that negative outcome.

It must be recognized that the negative outcome is not the desired outcome when testing a mechanism and that it is only one of many possible outcomes, most of them positive. It must also be recognized that the negative outcome of testing a mechanism is often unforeseen. Totally denying the opportunity for that negative outcome to occur means that the team developing the mechanism does not have the chance to know about the negative outcome and so they will not find a way to mitigate it. Thus the hazard still exists. It has just been shifted to a different time and place.

Originally Posted by robochick1319

I think you may have misunderstood my point. I don't care how you run your team so long as the decisions you make for your team do not negatively impact my team (i.e. cause a serious safety risk).

You be you, let me be me, but let's all do it...safely? (rhyming not intended, I swear)

While it is very undesirable for the negative outcomes of one team's actions to have an impact on other participants, it is also very undesirable when one or more teams perceives a threat and imposes extra restrictions on other participants who have a way of dealing with those threats. While a proposed rule may make sense when examined in isolation, it's value is diluted when added to an already long list of rules (how long is the Game Manual and the Game Q&Q now?) that participants are less and less likely to read the longer it gets. The risk of something bad happening then increases as you add more rules. There are questions asked on CD where the answers are in the Game Manual and require little or no interpretation or cross-referencing to other rules.

[artdutra04]

Originally Posted by xXhunter47Xx

FWIW having a modular electronics system can easily solve this issue.
If you use powerpoles for connecting motors (which if you are using SRX/Victor SP motor controllers you should be) it's all a matter of unplugging them.
Tada, robot can be on floor and you shouldn't need four-five people around the driver station in case it decides to emancipate itself from the pit.

You can also just pull the breakers for the motors (such as drive train) that you don't want to test.

[robochick1319]

Originally Posted by philso

While a proposed rule may make sense when examined in isolation, it's value is diluted when added to an already long list of rules (how long is the Game Manual and the Game Q&Q now?) that participants are less and less likely to read the longer it gets. The risk of something bad happening then increases as you add more rules. There are questions asked on CD where the answers are in the Game Manual and require little or no interpretation or cross-referencing to other rules.

I would imagine that it would be added to the Safety Manual and the Administration Manual since it would be a general FIRST rule and not game specific.

And if we are really talking about preparing kids for the "real world" industries, how many companies ignore significant safety hazards cause new rules would make "the manuals too long."

I am sure there are lots of teams who don't read the manuals as they are written now and that would be unlikely to change even if we did shorten them. TL;DR is a real thing after all. That is why (like other game and safety rules) it has be regularly discussed and enforced until it becomes as natural as wearing safety glasses.

[jman4747]

I don't get this discussion.

Just don't let the wheels touch anything. Don't unplug your electrical components, don't stare at/rely on your e-stop, just get some 2x4s and put them under it.

If you don't want it to drive away don't let it!

[Chris is me]

Originally Posted by jman4747

Just don't let the wheels touch anything. Don't unplug your electrical components, don't stare at/rely on your e-stop, just get some 2x4s and put them under it.

I just want to reiterate that it's impossible to properly test any floor pickup mechanism without the robot on the floor. There are times when wheels have to be on the ground. A number of good solutions have been proposed, including simply pulling breakers which is really even easier than propping a robot up.

[jman4747]

Originally Posted by Chris is me

I just want to reiterate that it's impossible to properly test any floor pickup mechanism without the robot on the floor. There are times when wheels have to be on the ground. A number of good solutions have been proposed, including simply pulling breakers which is really even easier than propping a robot up.

1. Fair point, but just build a wood platform for the tote/can to sit on.

2. Depending on your design geeting to a breaker may not be ideal for repeted tests. It also adds another chance for error. If someome put it back in the wrong spot or worse forgot to turn of the robot first, for example.

[Chris is me]

Originally Posted by jman4747

1. Fair point, but just build a wood platform for the tote/can to sit on.

I think expecting teams to build structures to do basic tests with in their pit is a bit much, really. Making this "no wheels on ground" rule isn't worth putting that burden on teams when any number of much easier solutions will definitely prevent this problem (code, breakers, etc).

Getting the relative height of the 2x4s vs the platform correct is also tricky (2x4s must be taller than wheel ground clearance, platform has to be difference between two)

2. Depending on your design geeting to a breaker may not be ideal for repeted tests. It also adds another chance for error. If someome put it back in the wrong spot or worse forgot to turn of the robot first, for example.

The PDB is supposed to be at least clearly visible anyway (R29) and should be somewhat accessible. If it isn't, then you can disable the drive in code, use the e-stop etc. In our case, we run through a pre-match systems check before queueing, which provides an opportunity to show this problem.

[jman4747]

Originally Posted by Chris is me

I think expecting teams to build structures to do basic tests with in their pit is a bit much, really. Making this "no wheels on ground" rule isn't worth putting that burden on teams when any number of much easier solutions will definitely prevent this problem (code, breakers, etc).

Getting the relative height of the 2x4s vs the platform correct is also tricky (2x4s must be taller than wheel ground clearance, platform has to be difference between two)



The PDB is supposed to be at least clearly visible anyway (R29) and should be somewhat accessible. If it isn't, then you can disable the drive in code, use the e-stop etc. In our case, we run through a pre-match systems check before queueing, which provides an opportunity to show this problem.

"no wheels on ground" is an easy solution to the previously stated problem and is how we handle it, not a rule suggestion. I think driving on the floor in the pit is wrong. There is not enough space.

The idea of relying on code is fine but it doesn't remove the human error from the problem. The issue of a runaway robot would probably a software problem anyway. It also doesn't account for an electrical failure causing the problem.

The breaker is the next best in my opinion but it's to easy to pull out or replace the wrong one and is sill subject to a more catastrophic problem, albeit less likely.

Also if a team can't think up a simple plywood and 2x4 platform how did you build a robot with a pickup system?

[SJaladi]

Originally Posted by jman4747

Also if a team can't think up a simple plywood and 2x4 platform how did you build a robot with a pickup system?

I think it's not so much a matter of not being able to make a simple platform, but rather it being much more time efficient to simply pull out the breakers. I agree that it would be highly unfortunate if one were to plug the breakers back into the wrong spot, but this can be easily managed by a bit of attentiveness and clear labeling of the ports on the PD board.

[mrnoble]

Pull your Andersons for each drive motor.

[jman4747]

Originally Posted by mrnoble

Pull your Andersons for each drive motor.

That only works if you use a reusable connector between motors and the PDB. We (4080) do have Andersons between motors and Tallons so we can follow that advice. Some teams like to solder however.

[jman4747]

Originally Posted by SJaladi

I think it's not so much a matter of not being able to make a simple platform, but rather it being much more time efficient to simply pull out the breakers. I agree that it would be highly unfortunate if one were to plug the breakers back into the wrong spot, but this can be easily manafged by a bit of attentiveness and clear labeling of the ports on the PD board.

My only problem with that is that the safety system is susceptible to fail due to the same kind of mistake that would cause the problem it is there to prevent.

Programming & e-stop scenario: Team 9999 has just arrived to their regional on Saturday morning and is eager to test their auto which closes a gripper around a can and drives backwards with it. They orient the front of the robot facing the inside of the pit with can in place. The operator places the laptop on a chair behind the robot which is facing the isles. In the software there is a front panel button (Boolean labeled "Disable Drive?") that disables the output from the state machine to the robot drive vi. Unfortunately the programmer got the wires mixed such that when "Disable Drive?" is true the output from said state machine is sent to the drive vi instead of zero. Thus when the robot is enabled and successfully grabs a can the operator raising both hands in triumphant celebration just misses his laptop as the robot proceeds to back away with it and the can.

Breaker scenario: Simultaneously one pit over, team 9998 had a rough day yesterday. An old victor 888 gave out and they hastily replaced it with a gifted Tallon SR. They quickly prepare to power up the robot and upload code that initializes a Tallon instead of a Victor. A rookie student is ordered to pull out the breakers for the drive motors only and returns with 4 40 amp snap actions in his hand. With a glance at the PDB his Sr student is satisfied and orders the robot on. The robot then proceeds to take a nice long arc out of the pit directly into team 9999's runaway bot. What they hadn't realized is that yesterday they managed to hook up the Tallon's Motor +/- side into the PDB. Furthermore the rookie had removed two breakers for drive motors and two for the lift and not the one on the revered Tallon.

TLDR? yes. Unlikely to happen next to each other? Yes. Completely improbable on their own? Not even.

[SJaladi]

Originally Posted by jman4747

TLDR? yes. Unlikely to happen next to each other? Yes. Completely improbable on their own? Not even.

Again I agree that it is possible to happen, however the intent of my post, which in all fairness I didn't specify clearly, was that in the specific case of our team we found that this year removing breakers was a far more efficient alternative to making the aforementioned plywood/2x4 platform. This is both because we have a very visible and accessible PD board to verify that the correct breakers have been removed, as well as what I would like to think is a reasonably experienced pit crew who would not make such a mistake. I totally agree that the safest way for a team to test their mechanisms would be the construct a platform like you described, but when we compared the relative ease of removing breakers with proper attention and care with the time required to build such a platform, which would have to be built to accommodate and appropriately simulate the height difference between our wheels and our intake, we decided that the breaker method was far optimal. Again I agree that if there is any risk of the robot driving away due to code or electrical uncertainty it should be tested with the wheels off the ground, something our cart allows us to do, however we will put the robot on the ground with the appropriate breakers pulled out to test our intake system.

TLDR; We personally found the removing breaker method to work for us, but I agree that the wheels being propped up is a failsafe way of testing mechanisms.

[philso]

Originally Posted by jman4747

Also if a team can't think up a simple plywood and 2x4 platform how did you build a robot with a pickup system?

Originally Posted by jman4747

My only problem with that is that the safety system is susceptible to fail due to the same kind of mistake that would cause the problem it is there to prevent.

Yet more large pieces of equipment in a crowded pit. Have you ever seen a robot launch it self off wooden blocks placed under it that contacted the wheels?

Originally Posted by Chris is me

I just want to reiterate that it's impossible to properly test any floor pickup mechanism without the robot on the floor. There are times when wheels have to be on the ground. A number of good solutions have been proposed, including simply pulling breakers which is really even easier than propping a robot up.

Disconnecting power sources (i.e. pulling breakers or fuses) is an accepted practice in the electrical/electronics industry.

Originally Posted by robochick1319

I would imagine that it would be added to the Safety Manual and the Administration Manual since it would be a general FIRST rule and not game specific.

And if we are really talking about preparing kids for the "real world" industries, how many companies ignore significant safety hazards cause new rules would make "the manuals too long."

I am sure there are lots of teams who don't read the manuals as they are written now and that would be unlikely to change even if we did shorten them. TL;DR is a real thing after all. That is why (like other game and safety rules) it has be regularly discussed and enforced until it becomes as natural as wearing safety glasses.

My issue with the suggested rule (no wheels on the ground) is that it is specific to a particular risk and that there are more general precautions (keeping a clear "Kill Zone") that can be applied to this and other hazards without making the test condition so different that the results are invalid. In previous games, being struck by a game piece at a distance would have been a more likely hazard than being struck by the robot itself. The "canburglar" mechanisms used this year have a long reach and they could be a hazard whether the wheels were on the ground or not (or if the robot had no wheels, like Stretchy from Israel).

Keeping the safety rules simple and easy to understand and apply is real world industrial practice. The safest systems/environments are not the ones with "the best rules". They are the ones with effective rules that one can apply without referring to a manual when needing to apply the rule.

Keeping a clear kill zone is also a standard industrial practice, especially in a dynamic environment where all kinds of new things are tried in a shared space making it difficult to foresee all possible hazards. We keep at least 6 feet away from equipment we are not familiar with in our production test areas and our R&D labs. This type of environment also makes it difficult to make detailed safety rules since the next project (or next year's game) can present hazards that we have not encountered before.

In terms of preparing kids for the "real world", I would rather hire one who could think and devise a way to get the task done in a safe manner over one who just followed the rules since following the rules does not necessarily mean that one understands the logic and intent of the rules.

[JesseK]

Originally Posted by jman4747

My only problem with that is that the safety system is susceptible to fail due to the same kind of mistake that would cause the problem it is there to prevent

....

TLDR? yes. Unlikely to happen next to each other? Yes. Completely improbable on their own? Not even.

There are a lot more safety issues in this scenario. It seems to me like you're fishing for a better way to promote a culture of safety for all teams, 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.