Take an exit with dignity

[Zach Purser]

Originally Posted by nukemknight

In the match where the whole red end of the field failed (we think the center team kicked the controller!) and the match was restarted, 1610 did not have a working code on the robot and therefore sat dead the entire match. The DS software even said "No Robot Code."

When you say you did not have working code, do you mean that the robot wasn't working before you put it on the field, or are you saying that the reboot somehow affected your code?

[rspurlin]

Given that you expected the robot to perform when you placed it on the field, yet it has failed during the match, how can you or FIRST be certain that if you take your controls to the field, you can drive it off? Is this honor reserved for those who exhibit the symptoms listed above, or is it available to those robots that threw a chain, roasted a CIM, had a battery become disconnected or otherwise stopped working during the match?

I mentor a team. I know how much time, effort and emotion goes into the design, construction and operation of the robot. Is it possible that there is some team that has worked just as hard as you have and didn't get picked to play in eliminations?

If I might, let me suggest that we remind ourselves of our mission and celebrate the accomplishments of all teams, not just the competition winners or elimination participants.

[kjohnson]

Originally Posted by FRC4ME

You guys seem to have a lot of issues getting stuck in autonomous mode. Moreso than other teams. Perhaps you're doing something unusual in autonomous that is causing problems with FMS. I would be interested in seeing your auto code if possible (from either 2010 or 2009). Not because I'm saying that your code is the problem; if the problem is FMS, though, your code seems to contain the trigger that reproduces the problem.

We had very few teams have this happen at VCU, and it just so happened that 134 experienced this problem in back-to-back matches. 134 communicated with the FMS before beginning the match, but would not move in the tele-operated period, and seemed to still be stuck in their autonomous program although FMS had successfully placed 134 into tele-operated. As FRC4ME said, this could be a programming issue, although I can't say for sure. Can anyone on 134's programming team shed some light on how they got working again?

Originally Posted by Zach Purser

When you say you did not have working code, do you mean that the robot wasn't working before you put it on the field, or are you saying that the reboot somehow affected your code?

The robot did not have working code loaded onto the cRIO before beginning the initial match. I referenced the re-started match simply because that is the match this happened to occur in. All other robots in that match rebooted their robots before the restart, and worked properly for the duration of the re-play.

[FRC4ME]

Originally Posted by synth3tk

I'd rather keep my pride and show FIRST that my robot was not at fault, too.

But that's just me. Who knows what the students would want, much less the safety/logistical implications would be.

This idea seems to me like it promotes an antagonistic relationship between FIRST and teams. I think FIRST wants the field to work and competitions to be fair as much as we do.

[mrmummert]

Hi...

I know Kyle....We think the gaming adapter cord was loose for two matches. but on saturday we double checked (don did ,remember he had to keep loading the default drive code back in when other code did'nt work) and it would work fine in the pit and it would'nt move at all on the feild two times we were on red. Is it also possible it could have been a combination of both the feild and something on the robot that when each are checked nothing shows but combined together they cause trouble? I'm not saying it was the feild or the robot, but something weird was going on.

[Justin Montois]

I don't want to make it seem like it's is definitely a field issue or a team issue but there are an awful lot of teams voicing similar concerns, mine included.

We sat dead on the field after ~5 seconds of operator control for both of our quarter-final matches. In the first quarter final match, two robots on our alliance were dead. It is a terrible way to lose. I give all 3 teams on our alliance credit, we handled it with GP but it still is a tough way to go out after working so hard all build season.

No one on the field team could tell me what went wrong, they insisted it wasn't a field issue, and perhaps it wasn't. But the sheer number of teams reporting random dropouts of their connection during elimination matches especially is disappointing.

I remember using the old IFI system it was almost plug and play. It had generic code that could have you at least DRIVING in almost no time at all. I think the system we are using is way beyond what we need.

I think a good solution would be to have a 'lite' control system for teams that don't need all of the bells and whistles that our current system has. Maybe some teams can use it but the vast majority of teams, especially rookies don't need that expensive of a system to run their robots.

I appreciate what FIRST and NI have done to give us a control system with some amazing capabilities. I really do hope that these growing pains pay off in the end, but right now they certainly do hurt.

[kjohnson]

Originally Posted by mrmummert

We think the gaming adapter cord was loose for two matches. but on saturday we double checked (don did ,remember he had to keep loading the default drive code back in when other code did'nt work) and it would work fine in the pit and it would'nt move at all on the feild two times we were on red. Is it also possible it could have been a combination of both the feild and something on the robot that when each are checked nothing shows but combined together they cause trouble? I'm not saying it was the feild or the robot, but something weird was going on.

The game adapter power cord being loose was very likely the source of your sluggish communications. The match where communication dropped during the match was either the game adapter cord or a voltage drop caused by the drive-train. If the battery voltage drops low enough, it will cause the cRIO to reboot, and will not reconnect to FMS for the remainder of the match. We saw this happen in quite a few teams throughout the three days of competition.

The match where 1610 never moved at all was absolutely because of bad robot code, and just happened to also be on the red alliance.

[Tom Ore]

Originally Posted by keericks

What was the procedure?

I don't have the exact procedure, but I believe the drive team waited until the other two alliance memebers were connected to FMS before pluging in our drivers station and turning on the robot. This worked every time. If we plugged into the field too soon we would get a watchdog time out. The field could connect to the driver station but the driver station could not connect to the robot - so we knew we were dead but the field had a green light and the match was started.

[Tom Ore]

Also, it's still an open issue. It takes us an extra couple of minutes to get connected to the field. We are a bit concerned that if we still have the problem in Atlanta we may not get the extra time we need. We're hoping to find the root cause when we go to the 10,000 Lakes regional. There seemed to be several teams at KC that had the same or similar issue.

[The Lucas]

Originally Posted by Tom Ore

I don't have the exact procedure, but I believe the drive team waited until the other two alliance memebers were connected to FMS before pluging in our drivers station and turning on the robot. This worked every time. If we plugged into the field too soon we would get a watchdog time out. The field could connect to the driver station but the driver station could not connect to the robot - so we knew we were dead but the field had a green light and the match was started.

Perchance do you have an old adaptor (WGA600N) and your alliance partners have the new adaptor (WET610N)? They are now making it a point to turn on all the new adaptors on first then the old ones.

[synth3tk]

Originally Posted by rspurlin

If I might, let me suggest that we remind ourselves of our mission and celebrate the accomplishments of all teams, not just the competition winners or elimination participants.

Hard to do that when human nature tells us to only celebrate the "winning" teams.

In my honest opinion, it seems that there's very few people, at least from what I see at CD, that celebrate the non-competition merits of FRC teams. Again, that's only my opinion. Maybe I'm missing all the "good" threads.

[FRC4ME]

Originally Posted by nukemknight

We had very few teams have this happen at VCU, and it just so happened that 134 experienced this problem in back-to-back matches. 134 communicated with the FMS before beginning the match, but would not move in the tele-operated period, and seemed to still be stuck in their autonomous program although FMS had successfully placed 134 into tele-operated. As FRC4ME said, this could be a programming issue, although I can't say for sure. Can anyone on 134's programming team shed some light on how they got working again?

Wait...I have a question for 134: when you were unable to move, what did the driver station display read? "Autonomous enabled," or "teleop enabled?" (or something else?)

If it read autonomous enabled, I can't imagine how you could cause such a problem in programming.

If it read teleop enabled, but the robot seemed to still be running autonomous code, I can show you a million ways to cause such a problem in programming.

Originally Posted by The Lucas

Perchance do you have an old adaptor (WGA600N) and your alliance partners have the new adaptor (WET610N)? They are now making it a point to turn on all the new adaptors on first then the old ones.

This right here is an indication that FIRST does not fully understand the FMS they are dealing with. Correct me if I'm wrong, but the order in which you connect devices to a WiFi network should have no affect on how the system works. We have found a solution that seems to make things work, but I doubt anyone understands why it "works," and whether it leaves behind any residual problems. One of the first steps toward solving the FMS bugs, IMO, would be to determine why the boot order matters. This could possibly shed light into the root cause of other problems.

Originally Posted by synth3tk

Hard to do that when human nature tells us to only celebrate the "winning" teams.

In my honest opinion, it seems that there's very few people, at least from what I see at CD, that celebrate the non-competition merits of FRC teams. Again, that's only my opinion. Maybe I'm missing all the "good" threads.

Try this forum:

http://www.chiefdelphi.com/forums/forumdisplay.php?f=58

I don't think most of the teams in there won their regionals (yet, at least).

[synth3tk]

Originally Posted by FRC4ME

Try this forum:

http://www.chiefdelphi.com/forums/forumdisplay.php?f=58

I don't think most of the teams in there won their regionals (yet, at least).

Thanks. But I meant celebrating the other accomplishments. Such as raising money in x-amount of time, some form of community service, etc. But I guess as long as we're humans, the competitiveness will always be a top aspect.

[FRC4ME]

Originally Posted by synth3tk

Thanks. But I meant celebrating the other accomplishments. Such as raising money in x-amount of time, some form of community service, etc. But I guess as long as we're humans, the competitiveness will always be a top aspect.

Hey...Robots are cool. Fundraising is boring. Every team knows that.

[McVey]

Originally Posted by The Lucas

Perchance do you have an old adaptor (WGA600N) and your alliance partners have the new adaptor (WET610N)? They are now making it a point to turn on all the new adaptors on first then the old ones.

I'm pretty sure that at the regionals coming up (and especially at Atlanta) the field operators are going to become very strict about this. At the Virginia regional the field supervisor told each team in specific when to turn their robots on which helped when things were really crashing over and over.

Originally Posted by FRC4ME

Hey...Robots are cool. Fundraising is boring. Every team knows that.

Part of the issue with the awards that focus on fundraising / community and whatnot, is that large teams have a higher chance of winning them. If you have 60 team members, I imagine a good number of those kids have an opportunity during the build season to intentionally participate in non-directly-robot things to get such awards. On the other hand, small teams of something like 10 members generally have no free members to contribute time to that sort of thing. Of course, this just further pushes the value of growing teams, but just saying the important stress size puts on things. Of course, once a small team wins one of these awards, isn't it so much cooler too? Everything seems to be a double edged sword...