Competing in a Regional Soon ? - Watch out

Make sure you have read and understood team update 14.

Today our robot was dead during part or all of 6 out of 8 matches even though it was completely mechanically functional. Twice it was caused by opponent teams robot smashing into the our wall in autonomous causing our laptop to blue screen and reboot and the second time crash on the floor and even after a reboot of the laptop, the robot autostart failed. Another team I am told had one or both of a laptop and tablet destroyed in a similar situation today. No penalty or consequences what so ever to the robots that caused it.

I think FIRST needs to immediately implement one or more of the following:

  1. If a robot in autonomous crashes so out of control hard into the wall causing a driver station of the teams behind wall are immediately effected (ie their robot goes dead. a) the offending team should get no score for the match and or b) better still the match is immediately restarted.

  2. Teams should be allowed to hold their laptop during autonomous so as to protect them.

All laptops are expensive fragile electronics. Velcroing them so they can be smashed about without consequence is ridiculous.

Dave Edwards
Mentor - Runnymede Robotics
Team 1310

Were you using the hook/loop on the station?
I recall some serious impacts in the past that didn’t knock laptops over. Perhaps a foul for manhandling the field?

Teams should know that the driver’s station will be slammed, hard. Sorry to be blunter than a dull chisel, but since it was in a team update, this was more or less to be expected.

Get some velcro. Enuff said.

We knocked a laptop off today. We apologized and made sure the teams laptop was ok. However, no penalty should be leveled against the team that knocks the laptop off, because the laptop won’t fall off if you use the velcro. Simple solution: use the velcro. I think teams are also allowed to catch their laptop if it falls off (or if they’re not, they should be).

Yea. We have velcro on our driver station now thankfully… saw a couple driverstations fall down after robots just slammed into the wall… pretty scary stuff for the driverstation laptop. :ahh:

The velcro is exceptionally good.

You really want to punish the entire team for the thing one robot did? You really want to restart the entire match, despite how long and frustrating that would be?

Also, a rule would never be allowed that would let drivers hold their laptop. Way too much potential cheating involved in this.

I believe you’re completely over-exaggerating the punishment and this scenario in general. StongHold is a very rough game, so it is your duty as a team to be prepared for it in all manners, not just preparing the robot.

They are:

What’s wrong with G14? You can grab your laptop if someone is about to slam into the wall.

During AUTO, DRIVE TEAMS may not directly or indirectly interact with ROBOTS or OPERATOR CONSOLES unless for personal safety, OPERATOR CONSOLE safety, or pressing an E-Stop for ROBOT safety.

David

How fair is it to have your robot not compete because someone’s autonomous is intentionally(or not) written to run into the wall. It isn’t fair to the team who can’t play. Despite that team’s best effort someone else’s actions are what prevent them from playing.

I mean, it’s unfortunate, but you’re also allowed to catch it if it’s imminently falling.

I think this is a different situation if robots are running into walls so hard that the driver stations are BSoDing immediately without falling off. Velcro isn’t going to prevent damage from blunt trauma to a hard drive.

It’s really not fair to have your robot not compete because of this. I agree it is a huge issue for a lot of teams, but I don’t believe punishing the team that did it in this scenario is the right response. I believe that it should be expected that this can occur, and teams should be prepared for this. Teams have to prepare for the game in all aspects. Having your driver station crash by being hit by the force caused by a robot prevents you from playing; having your robot break by bring hit by the force caused by another robot prevents you from playing. With the chance of a driver station crashing, causing the same effect as a robot breaking, shouldn’t teams prepare for a robot hitting their castle wall as well as hitting their own robot?

Basically, I agree with this:

If you are going to take this stance I have a question,

How do you plan to prevent your laptop from blue screening assuming your driver station is attached with velcro?

Currently the sentiment from FIRST would indicate to me that if I wrote an autonomous that ran our robot in the alliance wall on purpose there isn’t much they would do to stop this.

FIRST has so far seems to have ignored the intent of someone hitting the wall. I’m sure if we blatantly hit the wall in an attempt to disable our opponents people wouldn’t be very happy with us.

I’d like to see a change so that all teams shouldn’t have to worry about this situation. As said in another thread

Most instances seem to be people not writing a proper autonomous code and ignoring the consequences by hiding behind the team update.

I want to see a better option than the current one.

I’ll ditto the call for some intervention here. Velcro will keep a laptop from getting thrown to the ground, but it’s entirely possible for a robot to hit the DS wall hard enough that it’s equivalent to dropping the laptop on the ground. It seems like G24 (no strategies aimed at damage/disablement) should apply to repeat offenders. If your robot is slamming into the DS wall every match, it should be assumed your strategy is to disable your opponents’ robots by damaging or dislodging their operator consoles.

If your laptop is properly secured there is a higher probability that the opposing robot will break itself then your laptop although it’s definitely possible.

Id recommend everyone changing out hard drives in their laptops to ssds. You can get a 60gb model for under $50 and will most likely prevent your laptop from bsoding after impact.

“Our robot catches on fire a lot, and will probably catch other robots on fire as well. We suggest other teams at the event invest in ABC fire extinguishers for their drive teams, just in case you face us…”

Right conclusion. Wrong reasoning. :smiley:

That sounds like what happened to us two years ago. We had just won a final that would have allowed us to go on to the state-level competition, but it was decided that the match had to be replayed because one of our opponents had gotten a no robot code flag in the DS after teleop started (though their auton functioned normally.) After this, they were allowed to re-upload code, which isn’t right imo. When we re-did the match, their robot backed up then drove into our driver station at full power, knocking our Velcroed DS off. Though it was caught by our driver, we disconnected from our robot and lost about 20 seconds getting everything back together, followed by unexplainable periodic disconnecting from our robot for the rest of the match. We lost by a small margin. Needless to say, everyone on our team was furious for various reasons, especially since we checked the logs in our DS and found issues communicating with the FMS server to have caused the disconnecting issue. While I agree that you should expect the DS to come under a certain amount of battering, I feel like something like the events described in auton should at least merit a restart of the match if the DS had been velcored. Since you’re only 20 seconds in, there wouldn’t be a huge loss of time either.

I disagree. In past years match cycle times were around 7 minutes on average. (longer this year from what I’ve heard). Most matches have less than 45 seconds of MC introductions. Therefore, most of the time is spent on moving robots into starting positions, letting them boot up, and resetting the field. When a match gets replayed, even immediatly after a field fault, all of that needs to happen all over again (robots need rebooted, at least it used to be that way, I’m not an FTA) The point is that replays cost events a decent chunk of time, and how far the match had progressed is more or less irrelevant.

The general rule has been that if the issue was on the field’s end (or due to a volunteer’s error), you are offered a replay due to field fault. If the issue was on your end, no replay. The latter includes issues due to an opposing robot, in which case they get penalized (and carded if warranted), no replay.

So, unless the driver’s station shelf collapsed or the velcro ripped free from the shelf, you probably won’t get a replay from getting your station slammed in autonomous.