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.

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

[AWoL]

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.

Encoders?

[Abrakadabra]

Originally Posted by bdaroz

Let me ask a rookie team question....

If you are low-bar capable, one thing you could do is always ask your alliance partners if you can have the low bar spot - it never hurts to ask. And if one of them has a low-bar autonomous that does more than cross (i.e. also scores) then you should consider not running auto that match or else just run a short distance for the 2 point REACH.
Another thing you can try without adding any additional sensors is reading the current from your speed controllers directly from the PDP. Presumably you will see a spike in current as your bot climbs over the defense, then it will level out once it reaches the other side. Just do a moving average of the current over time and stop when you see it going down.
If you can add encoders to one or both sides, then you can better measure distance traveled, and again, averaging over time will give you velocity. When you see the bot speed up after the defense, then shut it down. (of course, this presumes that your wheels don't slip excessively while crossing).
In the future, you might want to consider an ultrasonic sensor (relatively cheap, but prone to signal scatter from the diamond plate walls) or for a little more money, one of the new compact LIDAR units.

Originally Posted by alicen

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?

A Yellow card is meant to be a warning - there is no immediate penalty, but it is a strong incentive to not do it again. Giving an "extra strike" as Greying Jay suggests would be difficult to track unless FIRST goes to a 3 card system.
I am of the school that believes no code should be run on the field unless it has been duly checked out on the practice field, and if that can't be done before a match, then you just have to forego the potential auto points until you can. Of course, there are always things that can go wrong due to unforeseen special circumstances (see 3467's whirling dervish can grabbers from last year), but the Yellow card warning would be a strong incentive to figure out why it happened (as we did) and make sure it never happens again.

[TDav540]

Originally Posted by Abrakadabra

A Yellow card is meant to be a warning - there is no immediate penalty, but it is a strong incentive to not do it again. Giving an "extra strike" as Greying Jay suggests would be difficult to track unless FIRST goes to a 3 card system.
I am of the school that believes no code should be run on the field unless it has been duly checked out on the practice field, and if that can't be done before a match, then you just have to forego the potential auto points until you can. Of course, there are always things that can go wrong due to unforeseen special circumstances (see 3467's whirling dervish can grabbers from last year), but the Yellow card warning would be a strong incentive to figure out why it happened (as we did) and make sure it never happens again.

This is where I have to interject. To start, my opinion on this issue: If it's a repeated autonomous, the head referee/lead FTA should ask the team to investigate other ways to deal with the situation, possibly even going as far as to make recommendations himself/herself. Additionally, they should also expect, but not require, the team to investigate help with it's autonomous. While I don't believe that teams should run into the wall in autonomous, I don't find it a serious enough issue (especially with velcro on the driver station) to warrant a card.

Now to my point: not every event has a practice field, and not every team has/can afford sensors. For example, there was no practice field at Columbus this past weekend. In this case, teams did not even have a chance to test autonomous modes. Additionally, there were a couple of teams that had autonomous modes that ran into the driver station. These teams were generally rookies. While I'm not saying that all rookies cannot afford sensors, many cannot. As a result, I do not feel like there can be any expectation for teams to not run into the driver station wall in autonomous. The rules cannot change just because a team is a rookie; what is applied to one must be applied to all. Would I like them to test it? Of course, the less violent, the better for everyone. But I don't think it should be required.

Tele-op, however, is rather straightforward; if a team continues to hit the driver station, a red card is completely warranted.

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