Banging the driver station

[rsisk]

At a competition we were at recently, one of the teams would repeatedly hit the driver station wall very hard during teleop. Hard enough to dislodge computers and even knocking the e-stop off and disabling a team's robot.

It seems they would drive into the wall, turn and then shoot a low goal.

I tried to research the legality of this going through the game manual and could not find a good ruling against it. The driver station falls into a gray area where its not part of the arena, and not part of the robot. So "damaging" tactics don't apply. No real arena damage unless the e-stop incident is considered.

The closest rule I could find that would apply is 5.5.4, but even that is up to the subjective opinion of the referee...

5.5.4 YELLOW and RED CARDS
In addition to rule violations explicitly listed in Section 3 (3.4 Rules), YELLOW CARDS and RED CARDS are used in FIRST Robotics Competition to manage Team and ROBOT behavior that does not align with the mission of FIRST.

The Head REFEREE may assign a YELLOW CARD as a warning, or a RED CARD for DISQUALIFICATION in MATCH, as a result of egregious or repeated ROBOT or Team member behavior at the event.

Question: Is this just part of the game play we should plan for? Or should this type of game play be made illegal?

[mman1506]

Refs at GTRC were issuing red cards for this behaviour if repeated.

[tomy]

There was a robot at the Duluth Regional that would do this every time in Auto Mode. They went through the defense then went full power at the wall. There should be a rule against this.

[GreyingJay]

I like the red card.

We were at GTRC and had it happen to us - luckily we caught our stuff and were relatively unscathed - and saw many other teams suffer because of it. 1310 was down for several matches due to damage to their driver station laptop.

The rules do not seem to forbid it and Team Update 15 seems to say "it will happen, deal with it". But I do not think it is good to reward lazy programming. I get that you want to be able to breach the rock wall. But come on, how hard is it to put a timer on your code or add sensors?

I had several chats with our autonomous programming team and we agreed that even though it would be easy to do, and legal, it would not be either gracious or professional to use that tactic in our auto code.

[rsisk]

I am only referring to robots under operator control in teleop.


Autonomous robots, I can "understand" accidentally banging the DS, and this was addressed in an update.

[Richard Wallace]

Originally Posted by rsisk

I am only referring to robots under operator control in teleop.
Autonomous robots, I can "understand" accidentally banging the DS, and this was addressed in an update.

I cannot "understand" either situation. I think Head Refs should be giving stern warnings and yellow cards the first time they see a team do this, either in auton or teleop. And red cards if it happens again. This kind of play is not in the spirit of the FIRST Robotics Competition. People who want to play that way should quit FIRST and play Battlebots instead.

[nstephenh]

A note about hitting the wall in auto: If you are using a time or distance-based autonomous to travel a certain distance, you run into issues with sticking on defences. We had issues not getting traction with the rock wall immediately, and so we had to increase our autonomous driving distance such that if we didn't get traction, it would get over eventually, and if it did... well... "BANG."

[Abrakadabra]

Originally Posted by nstephenh

A note about hitting the wall in auto: If you are using a time or distance-based autonomous to travel a certain distance, you run into issues with sticking on defences. We had issues not getting traction with the rock wall immediately, and so we had to increase our autonomous driving distance such that if we didn't get traction, it would get over eventually, and if it did... well... "BANG."

NO - this is not an excuse, especially from a team that just this weekend won an Innovation in Control Award!! (I certainly hope it wasn't for your "navigation" system.) Everybody else seems to be able to avoid it - why can't you?

I totally agree - it should be a Yellow card for the first offense, and a Red for the second. If a team can't control their autonomous, then they shouldn't run it until they can. If a team persists in doing this during teleop, then there is absolutely no excuse.

I know we try to be all GP and everything here on CD, but in this instance, I think some public shaming of those who persist in this lazy practice is totally appropriate.

(And no - my team is not one of those who have had their DS unceremoniously dumped - at least not yet! I just think it's a real shame that some teams have no consideration for the teams behind the opposite driver station and for the hard work that others have put into controlling their robots properly.)

[bdaroz]

Originally Posted by Abrakadabra

Everybody else seems to be able to avoid it - why can't you?

Let me ask a rookie team question....

Our autonomous is strictly time/heading based as we only have the FC Round 2 Gyro to use. We've timed our bot over distances to get an approximate ft/s speed and use that to run our auto.

Given that we have to add a "fudge-factor" to get over some obstacles, how do you suggest we accomplish breeching and guaranteeing we don't hit the tower wall? (And no, we don't have the money for an IMU - I tried.)

(FYI - we won't be able to test any of our autos until Thursday this week, robot got bagged before we could.)

[kmodos]

Originally Posted by bdaroz

Let me ask a rookie team question....

Our autonomous is strictly time/heading based as we only have the FC Round 2 Gyro to use. We've timed our bot over distances to get an approximate ft/s speed and use that to run our auto.

Given that we have to add a "fudge-factor" to get over some obstacles, how do you suggest we accomplish breeching and guaranteeing we don't hit the tower wall? (And no, we don't have the money for an IMU - I tried.)

(FYI - we won't be able to test any of our autos until Thursday this week, robot got bagged before we could.)

Use a second gyro if possible and tilt it on its side to measure if you are flat. Or use the accelerometer. Or ultrasonic sensors to measure the barriers between defenses. There are many ways to do this with many different sensors.

[alicen]

Originally Posted by Abrakadabra

I totally agree - it should be a Yellow card for the first offense, and a Red for the second. If a team can't control their autonomous, then they shouldn't run it until they can. If a team persists in doing this during teleop, then there is absolutely no excuse.

I just wanna touch on this one tiny thing - sometimes you think your auto is right, then it's not. If a student makes a small error, should they be yellow carded immediately for it? (I'm ONLY talking about this situation, not things like stepping over defenses, and other YC things)

Story time! In 2009, at the Bayou Regional, we set our auto to go for 2 sec, just enough to cross a line halfway down the field. Nope, that robot FLEW across the field and smashed into the driver station wall, moved the whole thing back an inch or so as well. Nobody's controls were thrown, nobody had issues that match. If it were your call, should we have been yellow carded? We mangled our robot arms and fixed the auto for the next match.

[42!]

Harsh as it is, Most of the high ranked teams will tell you that you should never put an autonomous on the field that you haven't tested on the practice field yet.

[GreyingJay]

Accidents happen and in certain cases I think it's certainly fair to be lenient.

This year especially, it's pretty easy to determine whether it was an accident or whether it was just lazy coding to get the breach. "Drive full speed till you hit the wall" is a legitimate, but lazy, auto strategy.

if it were up to me, the first one would be a stern warning (this would cover accidents), second time would be yellow card, third time would be a red card.

In addition to the sensor integration ideas mentioned already, even just ramping the throttle would help. if you're down to a gentle tap by the time you hit the castle wall, you're fine.

[bdaroz]

Originally Posted by kmodos

Use a second gyro if possible and tilt it on its side to measure if you are flat. Or use the accelerometer. Or ultrasonic sensors to measure the barriers between defenses. There are many ways to do this with many different sensors.

Unfortunately extra sensors we don't have.

I didn't realize there was a built-in accelerometer on the RoboRIO though. I'll bring this up and see if the team can find a way to make use of it.

Thank you.

[kuraikou]

I think that is just something that happens that you have to deal with. This has been a problem that many teams have had, and been a problem for many years, you just kind of have to design your driver station around it. FIRST even provides loop side Velcro so that you can securely mount your computer to the driver station, yes it's a problem, but it's one you will have to get around yourself.