We use a “reverse launch”…
The robot is never over the scale when our auto works properly. It’s hard to plan for losing connection with the field…
I feel they should have replayed the match since they disabled their bot in auto… They didn’t even let the drivers try to fix the situation. Bad call by the refs/fta.
The rules seem to be written correctly. G19 provides the head ref some leeway to make a judgement call. Adding more complexity to the rule set would not make a judgement call any easier or make people feel better about it.
“If offense is via a ROBOT and the Head REFEREE determines that further damage is likely to occur, offending ROBOT will be DISABLED.”
Many elevators this year had enough power to lift robots off the ground. Given this occurred in autonomous, it seems reasonable to assume that further damage is likely to occur.
David
Why? There is no provision for replays for software failures. The Refs and FTA made the best calls they could considering the circumstances.
My issue with this is the reaction of the crowd, and it embarrasses me that I’m part of the same group (FIRST) as they are, since I believe we should support teams that have difficulties … rather than jeer at them.
To HBR members responding to my post, the intent was to express sympathy for how difficult it was to handle the scale from that side as we were assessed fouls as well, just not as badly. We both had the same general strategy to avoid fouls.
I don’t think the crowd was jeering. It’s highly unusual, ridiculous even, for scores to get that high. The crowd got excited by the scene. There is no question that Indiana teams support each other through difficulties, but that doesn’t mean the crowd will go dead silent, including the alliance that is winning the match.
They should have at least let it go ~5 seconds into teleop. If the drive team had no control, then they can disable it. It’s not right to have a faulty auto that isn’t in your control and with no damage to the field even after it pulled the scale down and be disabled for it during auto period.
Oh come on you guy with the risk/reward calculation B.S. It’s bad game design* to make the best way to win the game also the best way to end up with a stupid, accidental, uninspiring, un-fun bunch of penalties. Double scale auton is much more important this year than any other auton ever due to the fact that getting an early leads makes it likely you’ll keep it, a unique aspect of this year’s game that is the cause of a lot of issues. Combine that with the scale being a penalty magnet and we get situations like this that are fun for no one.
*for FRC games
Yeah, but this is a ridiculous way to think about the rules versus the teams. Let’s actually talk about blame.
Why is there such a brutal and humiliating consequence for an autonomous routine that suffers a seemingly unpredictable (and otherwise very minor) non-software failure? We’ve see teams crushed and alliances sunk from one inadvertent move around the scale time and time again at a rate completely unprecedented in other games. That is not an individual team’s fault. It is a clear indication that either the field or the rules are not rules are not living up to the requirements of FRC. I believe we have a right to better.
The field could really easily have been designed with 4’ fences around the scale plates similar to those on the switches that prevent teams from driving underneath. This would greatly cut down on the number of these stories and, while slightly changing the design calculus for a good scale scoring robot, not undermine the fundamental challenge of POWER UP. The fact that the GDC didn’t seem to foresee this, or did and concluded it was an acceptable aspect of the game, is concerning to me.
On the other hand, the rules could have specified a procedure for dealing with robots stuck on the scale in a way that accurately assessed the problem they create without the obnoxious punitiveness of 30 technical fouls. I wasn’t at the event, but I think that if it were my team, a red card would have felt like a much more graceful and fair punishment than racking up 750 foul points individually.
Your “It’S pArT oF tHe ChAlLeNgE” attitude is not only uncritical of the underlying problem; it’s also a disservice to the teams who do try to push boundaries. When was the last time a glitch in autonomous could turn into more points in fouls than any clean match has ever seen? I’m not necessarily blaming the referees here, because the letter of the rule is that the situation is a tech foul per five seconds, but the system is flawed for putting the crew into this position.
Most of all, you assume this “risk/reward” setup is simply a benign feature of the rules and this game. It is not. Why would FIRST ever want to design a game that so viciously disincentivizes autonomous routines that fail? I want to see teams wow me with what they can achieve, not hide from the deluge of penalties if they try. It goes back to the culture change message at FIRST’s heart. If we ever want FRC to be a spectator sport or widely recognized, we must encourage teams to push the envelope every step of the way. I love this game for the most part, but if POWER UP isn’t compatible with these objectives, maybe we need to think hard about whether another game with similar features should be released.
TL;DR: I thought FIRST was about chasing perfection and catching excellence, not cutting our teams down for their efforts.
This, IMO, would be the best way to handle situations like these. Every year teams like 1747 achieve incredibly sophisticated technical feats with their robots (see 1747’s motion profiling two-cube auton!!). It seems reasonable to expect a similar level of sophistication from the field, especially given the cost of participation for each team.
I see this as no different than winning on a red card. In 2016 we won an event on a red card and nobody cheered. I don’t think it’s unreasonable for teams to be able to think about how their opponents feel
Exactly! Team 1747’s autonomous routine is incredible! They use motion profiling algorithms that they created themselves to achieve a two-cube scale autonomous routine. That is exactly the kind of innovation that this program is meant to encourage and reward, rather than punish with game designs that make it too risky to try.
Not only is 1747’s autonomous code incredible, they were kind enough to give us a presentation on how it works a few weeks ago, and give us access to their code! They absolutely deserved the GP award at this event. I look at them as an amazing inspiration for how every FRC team should behave.
Just wanted to say 1747 has one of the best autonomous modes in Indiana right now. Starting down 2 cubes on the scale is so hard to overcome.
Things always seem to break at the worst moments in FRC unfortunately and this was one of those times. The nature of this year’s game is very unforgiving when things like this happen. Don’t let it get your team or drivers down; you’ll bounce back and play even better next weekend.
I was at this event and was sitting in front of 135 and 1018. I actively saw key students trying to quite down the cheering and about 30 seconds into the match everyone was sitting down form their teams. I will say the last 5-10 seconds of the match everyone in the event started cheering for the score to break 1000. I also did not hear chanting “kill.”
Teams are neglecting to add some very simple things to their code that could easily prevent this.
if(!gyro.initialize()){
gyro.plugBackIn();
}
This is kinda beating around the bush though where something like this would be much more effective.
if(goingToHitScaleAndGetTonsOfFouls){
dont();
}
Maybe FRC could add some better documentation for WPIlib to make these fixes more obvious but you can only ask for so much.
Reading this a a member of Team 135, I would first like to offer my condolences to 1747 on what happened at Plainfield. It was hard to watch their robot, which had previously had one of the coolest autos I have seen, get disabled on the scale (seriously, that 2-cube over-the-back fling was sick). Up in the stands, I’m pretty sure more of us were screaming about the fact that the score broke 4 digits, and less about the actual match results; and on top of this a lot of us (135 and 1018 were sitting together) actually cheered when 1741 attempted to dislodge the robot from the scale. Also, i’m personally skeptical about how necessary it was to disable the bot in the first place, but I believe the refs did what they thought was right to protect the field. On a side note, the closest thing I can figure to the “kill” chant that was my team’s “You” chant, since I didn’t hear anything like it from either us or 1018 (I couldn’t hear much else though).
I could see that it’s very possible, because of the amount of noise, that certain areas didn’t hear it. 1747 was sitting on a different side than most teams. It’s possible it happened via a small subsection (or even just one) student.
However, if it did happen, the team has failed their students. Part of what FIRST embodies has not taught to them.
I think this is definitely a moment for students of any and all teams to reflect on, so they know how to act in these situations, and become stronger together.
Many teams do the scale auto just fine. Its this seasons version of the HIGH GOAL and this time unlike other times a team can TAKE OUT the HIGH GOAL in auto. Thats the issue. Not the rules and not the refs. It’s simply the PowerUP game as designed using primary scoring methods called platforms at a height robots can crash into.
That will not likely change in week 5 so until next year thats the way it is. Some teams can do it, others can’t. Alliances have a responsibility to scout and know what their partners can do or risk fouls.
To be fair to those that do , teams that can’t and take out the scale will be fouled according to this years rules. As I have witnessed.
I would tell any team (my own included) that auto mode needs to monitor itself for fault conditions and that the robot needs to fail into a safe state.
A few things to consider monitoring:
-Loss of communication
-Sensors initialized correctly
-Encoders counts reasonable
-Gyro giving expected readings
-Motors drawing acceptable currents
-Camera seeing target on time
-Robot is transitioning from one state to another in a reasonable time.
-LIDAR giving expected readings
This type of monitoring is useful during teleop too, suppose your elevator got stuck retracting down. If you see a stall by looking at motor currents, you can disable retracting for a few seconds. Better to stop the current action than break your robot or the field.
Ouch. Experiential learning hurts sometimes. Good luck at Tippecanoe and District Champs!
1 Like
I’d be interested in how you do all of that - that’s a nontrivial problem because robots are so entrenched in I/O. It’s not quite the same problem as a typical unit test or something.
At what point does your team just log everything related to robot state (sensor readings, variables, current output of motor controllers, etc.) instead of programming defensively?