Take an exit with dignity

[DonRotolo]

Originally Posted by SciDKelly134

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.

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.

[Tom Line]

Originally Posted by Don Rotolo

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.

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.

[Dustin Shadbolt]

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

[Radical Pi]

Originally Posted by Don Rotolo

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

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

[PAR_WIG1350]

The FMS is not flawed; it just has surprise features


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

[DonRotolo]

Originally Posted by Tom Line

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

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

[Tom Ore]

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.

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.

[Pat Roche]

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

[FRC4ME]

Originally Posted by Tom Ore

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.

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.

[FRC4ME]

Originally Posted by Pat Roche

snip

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

[Radical Pi]

Originally Posted by Pat Roche

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.

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.

Originally Posted by Pat Roche

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

coincidence

[mahumnut]

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.

[Pat Roche]

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.

[ideasrule]

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.

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.

[FRC4ME]

Originally Posted by Pat Roche

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.

Are you using SimpleRobot or IterativeRobot?

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