Banging the driver station

FIRST General Forum
1

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?

2

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

3

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.

4

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.

5

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.

6

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.

7

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

8

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

9

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

10

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.

11

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.

12

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.

13

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.

14

Unfortunately extra sensors we don’t have. :frowning:

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.

15

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.

16

The Control Award was for our vision system. In addition to goal tracking, we have also been working on using neural networks to track balls. We don’t currently implement ball tracking, but we are working on it.

This is a good question, and there are various different reasons. How the robot handles when it hits the defense comes down to a lot of different variables, including what type of drivetrain was used, wheel size, and exact angle that we hit it. Our drivetrain is certainly not perfect at going over defenses, and we have to hit the rock wall just right to get enough traction to go over.

If you look at some of our matches on Saturday, you will notice that we stop before the alliance wall in our first few matches. The question then is what changed between then and the end of today. This requires a bit of explenation. Our autonomous reads values from the Dashboard via Network Tables for an autonomous (do nothing, drive, drive and aim, etc) and a distance to travel. At some point the robot stopped reading these values at the start of auto while on the feild (expect another post about this tomorrow). We don’t know why; It worked just fine on the practice feild, and we tested multiple times. Since we no longer had the option of reconfiguring the distance our robot drives based on what defense we were in front of, we were faced with the option of having no autonomous or having an auto that goes x inches, and to change that we would have to recompile and redeploy.

We played a match; auto went fine (crossed the defense, didn’t hit the wall). We played another match, and we got stuck on the rock wall. We now had the choice between not always being able to get over the rock wall or definitly getting over the rock wall by running for all of autonomous (just in case we get stuck). We chose the more strategically viable option, in order to get the most points.

Lazy? Perhaps. I would certainly describe some programmers on my team using this word at times, myself included. But in this case, particulary our case where we had to make this change at competiton due to an undiagnosable issue, we feel it was the right decision. Furhtermore, we’re not entirely sure how we would detect our total distance traveled. We’ve talked about adding an ultrasonic sensor, and I believe we’ve experimented with using our NavX MXP to detect distance traveled, but we’ve had trouble with both of these methods in the past. Encoder values have been the most relable way of detecting distance traveled. This doesn’t work when we loose traction with the ground.

I expect that most teams that build custom driver stations have velcro on the bottom, or put velcro on the bottom of their laptops (We did after we noticed wall-banging in Palmetto). Furthermore, most refs have been allowing teams to catch falling driver stations/controllers, crossing the line with no penalty.

I appologize for typos or anything else messed up or confusing about this post, I’ve been at a robotics competition for a while and am very tired.

17

To me I don’t think its worth a yellow card.

There are so many reasons why a robot could smash into the DS wall in this game without it being “attempting to damage the opponent’s DS” which is the only thing worthy of a yellow card.

What if the code is off? What if I sensor fails or gives a wrong reading? What if it’s a rookie team that has no sensors and was just guessing?

In teleop it seems to me that most of the time teams are running into the wall because they can’t see whats going on and its much easier to hear that you hit something and turn to low goal then it is to hope your close enough that you don’t run into the invisible barrier on the batter and beach yourself.

I don’t think anyone is trying to attack other driver stations. It just comes with the “violence” (not in a negative way) of this game

18

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.

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.

19

Encoders?

20

Encoders aren’t going to work with rough terrain/rock wall/ramparts/moat unless you have a robot with treads that goes over them slowly like a tank because you lose contact with the ground and have a free-spinning wheel that’s still counting up inches.