Take an exit with dignity
 

2009 Chesapeake regional finals, team 134 ‘s robot runs autonomous, then shuts down with no operator control, match 1, but the alliance wins. A system check is completed between matches and everything is working on the robot. Match 2 is a repeat of match 1, but ends in a loss. Match 3 we change drivers stations and our robot works fine without a hitch and we have a legitimate loss to our strong alliance opponents. Fast forward to the 2010 VCU Virginia Regional semi-finals, match 1, team 134’s robot runs autonomous, then shuts down with no operator control, our alliance has its first loss. A system check is completed between matches and everything is working on the robot. Match 2 is a repeat of match 1 with the exception that in the last 35 seconds of the match the other 2 robots in our alliance lose their operator control and we all set stationary on the field for the remainder of the match. This is a tough way to be eliminated for the season. I suggest to FIRST that if they continue to replay matches at their whim, then in elimination rounds, if a robot fails to move at any point during the match and a system check is completed after the match and everything is working, then the team has the right to request a different driver’s position for the next match. If FIRST does not allow this and the robot fails to move a second time and is eliminated by the field system, then out of the respect for the team’s gracious professionalism that the FTA can not identify any issue, the zone should be cleared and the team allowed to tether their robot and drive it to the gate in dignity. That way at least the audience and fellow alliance partners will know it was not the team’s robot that was the failure. This might take a bit extra time, but it would be little in exchange for the hours teams sat waiting to start matches while the field was reset to accommodate this year’s game adapters. In addition, if enough robots drove off the field fully functional under tether control, perhaps FIRST will have to admit that they have a random, but re-occurring issue with their field control system.

Our congratulations to our opponents in the red alliance of teams 1676, 1418, and 1086, you were a truly an awesome powerhouse and fully deserve to be the VCU Regional Champions. Nonetheless, if the blue alliance of 339, 435, and 134 had been given full operator control for our matches, there is no doubt in my mind the stands would have seen a set of matches they would not have forgotten.

David Kelly, 2009 Chesapeake WFF

Re: Take an exit with dignity
 

I would support this type of exit.

I would also support the idea of more extensive testing procedures on the competition setup, or at least publicizing the methods of testing. Without transparency, it's difficult to justify spending $5000+ on a system that may result in catastrophe due to errors other than your own.

Re: Take an exit with dignity
 

I had similar thoughts when we had trouble with our robot communication this year. It always worked flawlessly except when on the field. We sat dead for 3 out of 10 matches during qualifying. In our case, we knew we were dead before the match started and we stayed dead through both autonomous and teleoperated mode. We were able to find a procedure to connect to the field and that took us through the finals at KC.

Re: Take an exit with dignity
 

very well said Mr. Kelly. Very well said.

Re: Take an exit with dignity
 

We had a similar case this year at the Salt Lake City, Utah Regional. We had not a single problem like it until the finals of eliminations. During our first match, we ran until a certain point in the match, where we lost connection. We won that match. We did a system check, everything worked perfectly. Next match, same issue, while our alliance partners would jump in and out of com. We lost that match. Another system check, everything fine again. It occurred once more, and even though we had only lost that 1 match during the eliminations, we lost the next one, coming in second place. It's frustrating, and I understand where you're coming from. We've been around for 6 years now, and we have yet to win a regional...which is by no means impossible, but we've come oh-so-close on a number of occasions. This one is kind of hard to swallow, and I can relate to you. Every single time...at the exact SAME TIME in each match...frustrating.

This problem seems to be occurring in more than just our cases, though. I respect your statement, and humbly agree. I would furthermore like to thank the FTA and every other field crew member at the Utah Regional, I still had a blast even though the ending didn't quite turn out in our favor :)

Re: Take an exit with dignity
 

SciDKelly134, greetings from 339!

I had the opportunity to talk to your drivers a bit while they were still on the field and I must say the situation was just plain awful. I felt truly horrible for your team as clearly nobody had any idea what was going on. Sitting from my seat and watching the extensive conversation with the head referee our three captains did was just painful and I really do wish it could have turned out some other way. I'm behind the exit idea and very much behind doing something to the field control system. Standing up there next to Matt (head field op) and Glen (FTA) as they frantically tried to bring the field to order, going as far as to call the field management system's creator between matches (holding us up a good 40 minutes) only added the icing to the cake. In the end, a proper readout of all information could have at least led to more answers and an ability to get our solutions from the creator better.

All of that aside, it was horrible how you guys died on the field, nothing could have properly explained it and every odd was against us. What really bothered a few of the volunteer higher-ups was that all of the backup teams packed up too, so we didn't even have that opportunity to test another robot or something. I've wanted to mention this in a different thread but here will do: Regulate! Do not allow the teams in the "roundup" or whatever to pack up unless they MUST be home, if they just sit in the stands, there is no reason for them to box up. They very well have had an important impact on our situation (either in testing the field, or whatever).

A few thoughts anyway, glad to see you posting in here 134, I still hold strong that you guys were a fantastic alliance selection and I'm proud to have worked with you. Watching your team hang again and again really got me excited, I loved shouting at the top of my lungs about it each time. Good on you folks!

Re: Take an exit with dignity
 

I was watching those matches. I really have no clue what happened. I can't imagine that you getting stuck in autonomous and 339 and 435 losing comms was a coincidence, but I can't imagine what type of FMS failure could have caused such a chain of events, either.

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.

Re: Take an exit with dignity
 

What was the procedure?

Re: Take an exit with dignity
 

I have to say that THAT would be a classy move. The team is bloodied, but they are marching off the field of battle with their heads held high and their proud steed ready for more.

Re: Take an exit with dignity
 

It sounds like a good idea in theory. But I'm afraid in practice it would devolve into an exercise of someone deciding how crappy you have to be before you get to do the consolation walk. I wouldn't want to be the one announcing that. "OK, Team 6789, you had a bad day of it. But please power up your controls so you can exit the field with honor."

Re: Take an exit with dignity
 

Hi...

I'm with team 1610, We were with you guys at the hotel. Its a shame how things turned out given You all were doing so well on Friday. We think We had the same problem on Saturday. We had trouble on the red end of the field. We would work fine on tether in the pit and it would not even move on the field.We did everything that Matt and Kyle told them to do.

We were one of the back-up teams.(7th then 4th after others left) Although we were late getting inspected for the finals (and yes we were thinking of packing early too, but did'nt) We did'nt start to pack until we were sure we were not needed. This by then was the next to last final round. We were like the fourth alternate and I've never seen anyone go thru three robots in finals (although we came close to that in the finals in Atlanta one year where we also were alternates) So we waited until then to pack.

Re: Take an exit with dignity
 

Last year, in Seattle, we inexplicably lost mobility in our second quarter-final match.

Our alliance partners did a great job of going on without us, and with our help might have been able to force a third match. Might... we were up against a pretty good alliance.

In any case, we tethered up after the match and everything worked fine. Just as it had in our previous matches, practice field work, etc. We have no proof, however, that we hadn't done something weirdly wrong that didn't bother our robot in all the other matches, but did in this one. There was no evidence that it was the field, but there was also no evidence that it was our robot. The only evidence was that something didn't work right.

The problem doesn't seem to be one of leaving the field "with dignity" or not, but rather that the robots and FMS have reached a level of complexity that makes it very difficult to know what went wrong. If we can't diagnose a problem, then we can't solve it.

Jason

Re: Take an exit with dignity
 

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.

Re: Take an exit with dignity
 

Hank,

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

Re: Take an exit with dignity
 

What if it isn't a field fault? Maybe your ethernet cord is loose at the radio or cRio and the tether cord works better. Can the FTA tell if this is the case? There are other situations where the field would not be at fault.

How long does it take you to unlock the driver station from FMS? How well can the robot handle the gate? How far out of the gate can you go before it becomes a safety hazard?

This would slow down the field and anger people. Someone will come along saying "Why do they get to drive their robot out instead of carrying it." Maybe you could look elsewhere for problems instead of trying to look good.

If you drive your robot out, I will know it doesn't work on the field and instead of being reassured that it isn't your fault, I'll be afraid to pick your robot at another event.

Re: Take an exit with dignity
 

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?

Re: Take an exit with dignity
 

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.

Re: Take an exit with dignity
 

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?

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.

Re: Take an exit with dignity
 

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.

Re: Take an exit with dignity
 

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.

Re: Take an exit with dignity
 

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.

Re: Take an exit with dignity
 

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.

Re: Take an exit with dignity
 

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.

Re: Take an exit with dignity
 

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.

Re: Take an exit with dignity
 

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.

Re: Take an exit with dignity
 

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

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.

Re: Take an exit with dignity
 

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.

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.

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

Re: Take an exit with dignity
 

Thanks. :D 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.

Re: Take an exit with dignity
 

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

Re: Take an exit with dignity
 

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.

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

Re: Take an exit with dignity
 

Quoted for truth. I have no doubts that the 134 alliance would give us a run for our money.

I went over to offer any help at all after the first failure, watched as they tethered, and saw the motors run with my own eyes. Something similar happened to us in NJ (no joystick response coming out of Auton) that was "fixed"* by plugging both USB Hub connectors into the robot (I started a thread about this just after NJ), but 134 was using only 2 joysticks, so USB power consumption was ruled out. I also advised them to consult with the FTA, which they did.

My heart sank to the ground when it happened a second time.

Sure, we like to win, but only in a fair fight. What happened just stinks.

Somehow, the actual cause needs to be identified, we can't just chalk it up to some random event.

Re: Take an exit with dignity
 

Don, we had the /exact/ same issues during a match at Western Michigan. We have never had communications problems. Nor have we had on-the-field code problems.

When the match started, our robot went through autonomous. When it shifted to teleop, our drivers had NO control. Pushing F1 to refresh the USB devices did not work. Our quick thinking driver unplugged all the USB and plugged it back in, and voila, we had joysticks.

Our classmate is at 100% battery all the time. We charge it with an inverter on the cart when it isn't plugged into an outlet. Our human player (who is also a programmer) is methodical and incredibly competent. We KNOW we did nothing wrong that match.

Re: Take an exit with dignity
 

We had a similar issue. I think I would completely support this type of exit.

Re: Take an exit with dignity
 

Unfortunately, I doubt any major debugging will be done until the offseason. At the moment, probably all of the official fields are flying around the country to be used at the various regionals. The people who wrote the FMS and know exactly how it works are probably working as hard as they can to find the problems, but until some correlation is found between the various field issues they probably can't do much to fix it. It's not like they can run down to a regional and install a "debug FMS" to monitor every little thing that is happening. It would totally disrupt the matches.

I highly doubt that there is more than one major issue with the field. From what I've seen and heard, the non team-caused failures seem to have some sort of domino effect, causing other robots to fail somehow. Perhaps there is one little bug with something a team does on their robot, and it cascades across the field to other robots.

I think it might actually be a good idea if the beta teams could get together and play on an early build of the new FMS for the season. The entire point of a beta is to figure out how to break a system so it can be fixed, and the beta would provide a perfect opportunity for this. You get to try out new features, have the resources of teams who are pretty much writing the documentation on the system and know what works and what doesn't, all trying to "break the field". It's a perfect chance

Re: Take an exit with dignity
 

The FMS is not flawed; it just has surprise features;)


I hope luck is on our side in Boston and Atlanta.

Re: Take an exit with dignity
 

That quote deserves its own thread; maybe some other team will benefit.

Re: Take an exit with dignity
 

Our programming mentor thinks he may have found the issue. Sorry I can't be too specific, but he changed the location in code when the camera is launched. We'll find out in Minneapolis.

Re: Take an exit with dignity
 

One thing that really bugs me about this not exiting out of autonomous issue is that it is an issue that has occurred to more than one team in more than one year (meaning multiple programmers/program variations). I witnessed the incident in Annapolis last year. Two matches in a row the robot never exited autonomous mode and driver control was never established. 134's robot last year was programmed in Labview.

During Virginia this year the robot ran autonomous as expected. No driver control was established. The FTA said the robot had near perfect connectivity and everything looked normal per their computer interface. This year's robot was programmed in Java by a different programmer. The issue occurred two matches in a row.

I also witnessed the same issue with identical symptoms while a member of 229 last year in Rochester where the robot ran autonomous and never entered driver mode. Keep in mind the driver station changed hardware and again programmed by a different program and programmer with a different team number.

Also to be noted: all three of these instances occurred in the blue center driver station.

Three different variations and one same result.

Normally I might call that a coincidence but after seeing this years robot run through 50+ matches (including the Suffield Shakedown, 2 practice days, 2 sets of qualification matches, 15 or so elimination matches) not to mention numerous hours outside of the competition venues and doing so flawlessly then suddenly having the issue two times in a row with not having changed anything in the code or wiring (which I myself checked after the first failure with no changes per the usual) seems to be a bit suspicious. Being a mechanical engineer with a background in electronics and spending much of my current professional life doing debugging, all the symptoms seem to point towards an intermittent issue with the field system. I suspect the issue is somewhere in the code to the FMS system but this is outside of my knowledge area so I cannot offer a cause/corrective action.

I also could not speculate as to whether the exit is a good idea or not, but accountability and sensitivity to these issues would be very much appreciated. As a mentor (just like many other mentors) I put in a lot of time, effort and money into this program. I am right there with the kids lobbying outside of businesses for support. I am right there with the kids as we as a team strive to build a competitive robot and then if we are lucky we are able to afford to attend two regional competitions. There really is nothing worse than watching your robot sit still for two minutes and your season coming to an end with nothing more than a 'we don't know what it is so too bad'. As an adult I am disappointed to see that hard work come to such a poor end. I can only imagine how discouraging that is to a middle school/high school age kid. It also begs the question what message are we sending as professionals and engineers. To me this shows a gross lack of accountability. I am not saying stop all matches to debug every problem and do not misunderstand me I am not pointing fingers at an individual but as a culture changing organization we need be more aware of the underlying tone we are setting for the students under our charge. A simple 'we are not sure what this issue is but we will investigate it and let you know what the results are' would go a very long way.

That said, with the collective brain power that exists in these forums, I truly hope someone can figure out this bug, especially before it bites another team in the butt.

1676, 1086, & 1418 it would have been a very close and awesome semi-final if we ran. You certainly had a really great alliance and I congratulate you on your success. Best of luck the rest of the season to you. Maybe someday we can all get together for a rematch ;).


-Pat

Re: Take an exit with dignity
 

May I ask why you have to keep this secret? I can completely understand a team not wanting to release the code they have worked so hard writing to the community until after competition season. But if you've discovered a simple fix that may prevent other teams from having connectivity issues, it seems to me like the GP thing to do would be to share it.

The location in the code where the camera is launched doesn't sound very proprietary, anyway. Perhaps you could ask your programming mentor if it's alright to share the fix.

Re: Take an exit with dignity
 

As I'm sure you know, programming bugs are never really "random," and as intermittent as this one may seem, there is probably a common thread (perhaps literally :p) among the code of teams experiencing this issue. Not that your code is the problem, but your code contains the trigger that reproduces the problem.

Are you doing anything...unusual in autonomous? Something most teams might not be doing? Examples I can think of include: spawning new tasks/threads, using an SPI, I2C, or serial driver, calling native vxWorks API functions, using interrupts on the digital inputs, calling FPGA functions directly, reading/writing files on the FTP server, doing anything network-related. All of these things should work, but perhaps one of them is broken and no one has realized it yet because the feature is so rarely used. I would especially look for anything timing-related, since the problem appear intermittent.

The question that perplexes me is: if the issue is intermittent, why does it always occur two matches in a row?

I'm not FTA or anything...just a guy who has spent a lot of his free time in the past few years studying the cRIO and control system. I would love to see this issue fixed, and am curious to hear if you discover anything.

Re: Take an exit with dignity
 

It's a known issue and 100% error of the team's programmer. Java and C++ code waits for the autonomous code to finish execution even when the FMS switches to teleop. The LabVIEW error is a little tougher to explain but it is user error.

coincidence

Re: Take an exit with dignity
 

The entire system this year is ridiculous. From the 70 point penalties because of missing the ball return ONCE, to the buggy classmates, to their having to accommodate for two different types of bridges and booting up the new bridges before the old bridges, to the glitchy scoring sensors (as seen at the VCU regional, we lost 17 seeding points because of this, I mean how hard is it to have humans keep track of 4 goals as opposed to last year with a whole bunch of crazy stuff flying all over the place which was all tracked by humans.). This year was full of glitches and bugs and rule misjudgments, however, the volunteers and field management staff all handled these problems very well and provided for a reasonably smooth experience.
I heavily agree with your suggestion of tethering the robots and driving them off the field. In D.C we had a few matches where we weren't able to establish comms and were only able to sit throughout the match. we were then blamed for having a faulty CRIO which we all knew was code for "There is something wrong with our system and we don't have the time to diagnosis it so live with it" which given the pressure throughout the day was a reasonable response, but being able to tether the robot and drive it off the field would have just been that much sweeter.

Re: Take an exit with dignity
 

The code was a simple drive forward for x seconds then do nothing for x number seconds (sorry I cannot recall the exact number of seconds but it was approximately 19). There was nothing executing beyond that. We tested this during our system check field side. It worked 50 matches in a row successfully. It was the only autonomous code we had in our robot. It makes no sense that after match 50+X all of a sudden a timing issue like that would begin occurring without changing something in the software.

Re: Take an exit with dignity
 

What's wrong with valuing competition? It's the most powerful driver of progress in existence. Let's face it: it wasn't community service or gracious professionalism that made the light bulb, the telephone, the computer, radar, or any other technology possible. It was intense competition, often with war in progress or looming on the horizon.

As for communication problems, 610 didn't have any problems except during one match when the bridge power cord came loose, but I'm still very anxious about our next regional.

Re: Take an exit with dignity
 

Are you using SimpleRobot or IterativeRobot?

Also, how are you implementing the "do nothing for 19 seconds" part? Timer.delay()? Thread.sleep()? wait()?

Re: Take an exit with dignity
 

I'm not saying to get rid of it completely, which you seem to assume. I just think that in a program like FIRST, I feel (my opinion, not fact) that all I see is regarding the competition itself.

But whatever. Maybe I'm just crabby.

Re: Take an exit with dignity
 

I agree, but don't see it as a problem. After all, it is the FIRST Robotics Competition.

Re: Take an exit with dignity
 

Sorry I can't speak to that with much knowledge. I only know the 10000 ft. logic of the program. I can ask around and see what I get for an answer.

Re: Take an exit with dignity
 

Not entirely sure I agree here.

Yes, C++ (what 1075 uses) DOES wait to start Teleop() until after Autonomous() is completed.

However, Autonomous() at least, as defined in the SimpleRobot template, has a While(IsAutonomous()){} loop in it. If your code is designed to pay attention to this fact, you should have no problems forcing your Autonomous code to stop operation the instant FMS changes your robots status from Autonomous to Teleop.

Re: Take an exit with dignity
 

The gaming adaptor problem is a tough one and not entirely FMS's fault. I thought the WGA600N worked well last year. Unfortunately, it was discontinued for the WET610N. Now you have lots of teams with the old adaptors, and many teams with the new ones since they cant get the old ones (and we have an unavoidable mix).

Before I say this next part, let me preface it by saying that Cisco/Linksys makes great products and I thank them for their sponsorship of FIRST. Linksys products are my preferred brand and what I usually tell family and friends to buy when they ask for advise. I use the old adaptor on the comp bot and the new one on the practice bot. The 2 adaptors are noticeably different. WET610N takes much longer to even connect to the Linksys router, independent of any other FIRST equipment. What is it doing during this time? Looking at the Cisco site it seems to be focused on Streaming video to HDTV and has 3 antennas as opposed to 2 . Of course more features for increased boot time is a great trade-off to make in a product that doesn't need to boot often in its intended use (once a month maybe?) Keep in mind we are not using these products for their intended use (see the power adaptor which is even harder to keep in on the new one). For our use, boot time is critical.

Now the big problem (as I have heard from web casts I'm not an FTA) is that the new ones tend to interfere with established connections of the old ones. This would seem to point to an FMS bug but it could be a problem with the 2 adaptors. Has anyone tried to use both at once in their lab? If I was using both adaptors at home and setting up the new one temporarily knocked the old one off the network, I probably wouldn't even notice because it would reconnect in a few secs. Unfortunately in our use this is a big deal. It would be nice if Cicso could provide some sort of WGA600N compatibility firmware for WET610N. Maybe there is a set of settings that can achieve this? (I dont know)

We get the first instance of the camera in the constructor (for the robot class in C++) after a 10 sec wait. I have tried other places that have not work (however updates may have fixed this). Keep in mind that you are not just connecting to the camera, you are connecting the PCVideoServer to the Classmate. I wish that they would decouple the Camera and the PCVideoServer feed like last year. Yes I know it is easier to use, but you don't have the ability to control the feed anymore and start it at a different time.

In Baltimore, one team was having issues transitioning in teleop from auto using LV. they had timer waits at the end of auto. I advised them to get rid of the end of auto timer and disable the user watchdog. They seemed to run fine after that when I saw them and they didn't ask for any more help.

Any waiting (over a tenth of a sec) in auto is just a bad idea to me. I know it is easier to program but it is important that you get out of autonomous and into teleop ASAP after the teleop bit is set no matter when that happens or what your robot was doing. Instead of waiting on timers, check them periodically and if auto period ends before your timer reaches its value, go to teleop.

Re: Take an exit with dignity
 

Perhaps Cisco/Linksys could develop custom firmware for their WGA600N or WET610N for FRC, so that all the fancy features we don't need are turned off, and the system is optimized for lightning fast boot and connection.

Seems plausible to me...

Re: Take an exit with dignity
 

When we use our WGA600N, we are communicating in about 7-10 seconds. The WET610N takes 30-45 seconds. Bootup time aside, we haven't had any problems with the WET610N. Though waiting is *very* annoying when you're in a hurry. We'll be replacing the "new" bridge with an "old" bridge next season, assuming the WGA600Ns are still legal.

Re: Take an exit with dignity
 

...I wouldn't bank on anything for next season, given all the trouble this season. FIRST may well come up with an entirely new solution to the Wifi->Robot link.

Re: Take an exit with dignity
 

The Toltechs had serious communication issues at the Arizona Regional this year, and we were by no means the only ones. Like most of the anecdotes here, we worked fine tethered and in practice. But, on the game field, we had slow and/or dropped connections.

At the FTA's suggestion, I even went out on Friday to a local BestBuy to purchase a new gaming adapter. Apparently the one we had was "twitchy." (His words) Even then, we would either not connect or lose control after a few seconds of Tele-op.

One thing we felt (my fellow mentors on 499) was that the gaming adapter was designed to remain stationary on a desk or shelf, always powered on. Perhaps the bumps and shocks of competition, along with numerous powerups/powerdowns, are simply more than it was designed to handle.

The worst part for me was to see the disappointment on my students faces. They spent (like everyone) many hours working on the bot, and many hours traveling, just to see the result of their work sit on the field. Very Frustrating!

Pete

Re: Take an exit with dignity
 

I can see where you might be coming from but what doesn't make the slightest bit of sense to me is that it started occurring after 50+ matches. It seems to me something like this should have surfaced much earlier and doesn't explain why during the system check auto worked fine and didn't get hung up. Sorry I'm not trying to be argumentative but nothing seems to fit all the symptoms that were displayed by what was a previously flawless working robot.

Re: Take an exit with dignity
 

The thing is Autonomous coding is MUCH different from teleop coding. In teleop, the entire code is usually a loop that reads in data at the beginning and writes at the end. IsTeleop() is a fine solution to ending the teleop properly.

Autonomous on the other hand, it usually seen more as a pre-programmed set of instructions, executed sequentially. Very few teams do something as complex as a state machine that uses the IsAutonomous check in a continuous loop. The average C++/Java team will probably do waits between pre-defined commands, which does fail the termination part. The most common problems are when teams don't enforce the end of autonomous period in their code and just let it sit, waiting for an input (such as a ball hitting a sensor). Even in your IsAutonomous loop, if the code doesn't make it through the loop then end of autonomous is never checked, and the loop cannot end.

Re: Take an exit with dignity
 

Let me go ahead and show my ignorance here. I haven't been part of programming the robot since FIRST switched to the current controller, but aren't there any watchdog timers to prevent you from getting stuck in automode?

Re: Take an exit with dignity
 

Nope, none at all. The SimpleRobot template for code simply is call Autonomous(), wait for field to signal end of autonomous, run Teleop(), wait for field to signal end of teleop.

Re: Take an exit with dignity
 

I was assisting at the Dallas regional, and would follow nonmoving robots back to the pits to help resolve the problem. We saw a small number of issues that explained the failures.

The most common issue was loose power connectors. Robots that disable for ~15 secs, then continue had the cRIO reboot -- wiggle the connectors at cRIO and at PD to find which is loose. If the robot is disabled for 30 to 40 secs, check power to the bridge. Also, bridge only power issues don't affect RSL. If it was 40 secs and RSL goes out, check battery connectors.

Clearly, a cRIO reboot that isn't explained by a loose connector can also be a code issue especially if running C/C++.

If the reboots are due to a weak battery, the RSL tends to be dim. Clearly the DS should help identify this as well.

Another issue, harder to diagnose from the stands is the Security button on the bridge. If the bridge can move and an impact can cause the lock button on the front to be pushed, the robot will not move for the remainder of the match, and the Security LED will be blinking green or amber at about 3Hz on the bridge after the match. It blinks green for about two min, then amber for several more minutes.

One well built robot had the bridge security button pushed several times. Testing the bridge outside of the robot, it seemed that the board moved within the case, possibly due to their good job of hard hit testing before ship. Replacing the bridge resolved their issue.

-------

DS setup:
Do not plug Cypress board into an external hub, plug it directly into the laptop port. This may cause the Cypress to stop working, but it may cause the entire hub to drop out. This is often corrected, for awhile, by unplugging and replugging. Hit F1 if the match has already begun.

To test the Cypress board, press the button. If one red LED lights up in response, the board has not been recognized. If zero LEDs light up, everything is fine. This should match the state of the LED on the DS I/O tab.

To test joysticks, click a button and see if the LED on the Diagnostics tab turns blue, or if the listbox line turns blue on the setup page. When disabled, the DS scans for joysticks once per second. This is too expensive during a match, but F1 will force a rescan if connections are changed during a match.

-------

I'm not posting this here to declare that the field or FMS never has issues, but in my investigations, the issue was explained by one of the above. Hopefully this will help with troubleshooting.

Greg McKaskle