Discrepancy at Chesapeake, Israel, Waterloo?

[Killraine]

I looked over the data from all of the regionals of the first 4 weeks after getting back from Chesapeake this weekend. At Chesapeake, there seemed to be an occasional problem where the middle blue alliance station would not establish communication with the robot. I was not surprised to see the data reflected this, with the Red alliance winning 61.5% of the qualification matches. I was surprised to see similar results at both the Israel and Waterloo regionals. Did you guys have a similar problem at your regionals?

Here is the data:

Regional Blue Win % Red Win % Difference
Israel Regional 37.97% 62.03% 12.03%
Chesapeake Regional 38.46% 61.54% 11.54%
Waterloo Regional 61.36% 38.64% 11.36%
Pittsburgh Regional 58.06% 41.94% 8.06%
Washington DC Regional 42.11% 57.89% 7.89%
Finger Lakes Regional 57.58% 42.42% 7.58%
NASA VCU Regional 57.14% 42.86% 7.14%
Greater Kansas City Regional 56.94% 43.06% 6.94%
MI - Traverse City 56.58% 43.42% 6.58%
Peachtree Regional 56.34% 43.66% 6.34%
MI - Cass Tech 56.25% 43.75% 6.25%
Philadelphia Regional 56.25% 43.75% 6.25%
Wisconsin Regional 54.93% 45.07% 4.93%
Midwest Regional 45.07% 54.93% 4.93%
Bayou Regional 45.61% 54.39% 4.39%
Los Angeles Regional 54.29% 45.71% 4.29%
Oregon Regional 53.97% 46.03% 3.97%
Boilermaker Regional 53.85% 46.15% 3.85%
Arizona Regional 46.97% 53.03% 3.03%
St. Louis Regional 46.97% 53.03% 3.03%
Silicon Valley Regional 47.62% 52.38% 2.38%
BAE Systems Regional 52.38% 47.62% 2.38%
Oklahoma City Regional 47.76% 52.24% 2.24%
New York City Regional 48.05% 51.95% 1.95%
New Jersey Regional 48.61% 51.39% 1.39%
MI - Detroit 48.75% 51.25% 1.25%
MI - Kettering University 51.25% 48.75% 1.25%
MI - Lansing 51.25% 48.75% 1.25%
Dallas Regional 49.25% 50.75% 0.75%
Buckeye Regional 50.63% 49.37% 0.63%
Boston Regional 50.00% 50.00% 0.00%
San Diego Regional 50.00% 50.00% 0.00%
Florida Regional 50.00% 50.00% 0.00%


The difference column is merely how far off the results are from a 50/50 split (Obtained by abs(50 - Blue Win %)). You can see it jumps from 8% at Pittsburgh to 11% at Waterloo. Everything up to Pittsburgh seems to go up fairly linearly.

[Alex Cormier]

Very interesting information. But I am not really liking the "error" name for the difference. How about use the word "difference"? sounds better.

[Killraine]

Agreed. Error makes it sound like Percent Error, which would be a whole different thing entirely. I edited the post.

[Tom Line]

Putting your %'s into minitab and doing a simple capability sixpack, the distribution has a P value of .59, which strongly suggests you have a normal distribution.

Looking at the tails of the normal curve, only a couple values fall just outside that range, and you have both a long term and short term capability of well above 2. There is a bimodal distribution, but this sample size of regionals is somewhat limited.

With this limited sample size, my answer currently would be "It's well within expected limits".

Yeah, I know, it doesn't answer your question really. But everything points to normal statistical variation in Team winning percentage.

[Jonathan Norris]

Waterloo only had 34 qualification matches... So I am not surprised it is a bit off.

[Alex Cormier]

Waterloo only had 34 qualification matches... So I am not surprised it is a bit off.

44 Qualification matches.

[Killraine]

Waterloo only had 34 qualification matches... So I am not surprised it is a bit off.

Well, that addresses one of them. Does anyone have any details on Israel?


Also, @ the data from minitab: Are you sure its not looking at it on too large of a scale? The data is clearly pretty linear up until the 3% jump.

[Tom Line]

Any statistician will tell you that statistics never conclude anything - they are merely interpreted to mean something. You can, generally, argue any point you like if you know how to twist them well enough.

However, in this case, I think it's pretty fair to say you've simply found the tails of the curve. Someone's got to have the highest and lowest scores, after all.

[vivek16]

I think it's just coincidence, it's not like one alliance color has more at every single regional. The discrepancies happen.

http://imgs.xkcd.com/comics/correlation.png

-Vivek

[Nuttyman54]

I think it's just coincidence, it's not like one alliance color has more at every single regional. The discrepancies happen.

http://imgs.xkcd.com/comics/correlation.png

-Vivek

It's not always coincidence. In the case of Chesapeake, the middle blue station appeared to have chronic problems with dead robots. As we all know, a dead robot is pretty tough to overcome, and is possibly responsible for the discrepancy we've seen at Chesapeake. I don't think it's possible at this point, but I'd like to see the stats on how many matches had a disabled robot at the Blue 2 station, and how many of those matches blue lost.

[Seat Ninja]

My team was at Chesapeake. We were mostly on the blue alliance. As you can see below.

[rcflyer620]

I was an FTAA at Chesapeake and can tell you the most of the problems with "dead" robots were operator error. The most common was robots going on the field with the cRio un-plugged from the radio. The FTA had made it clear that once the gates were up you could not correct things like that on the field. We even announced it in the pits to no avail.
Unfortunately I also mentor team 2199 who lost a very good chance at being regional champion due to the robot in Blue-2 de-linking after autonomous. The weird thing is that it exhibited the same behavior in the previous match but in Blue 3 lending credence to the argument that it was a robot problem.
One thing I found that was fairly consistent was the flat black ethernet cable provided in the kit was problematic. teams that had swapped it out for real twisted pair ahd almost no problems with communication.

[JohnBoucher]

The most common was robots going on the field with the cRio un-plugged from the radio. The FTA had made it clear that once the gates were up you could not correct things like that on the field. We even announced it in the pits to no avail.

Really? How many robots were not able to compete because of this?

[Kingofl337]

I was an FTAA at Chesapeake and can tell you the most of the problems with "dead" robots were operator error. The most common was robots going on the field with the cRio un-plugged from the radio. The FTA had made it clear that once the gates were up you could not correct things like that on the field. We even announced it in the pits to no avail.
Unfortunately I also mentor team 2199 who lost a very good chance at being regional champion due to the robot in Blue-2 de-linking after autonomous. The weird thing is that it exhibited the same behavior in the previous match but in Blue 3 lending credence to the argument that it was a robot problem.
One thing I found that was fairly consistent was the flat black ethernet cable provided in the kit was problematic. teams that had swapped it out for real twisted pair ahd almost no problems with communication.

Yes, it was funny how blue had consistent problems at Chesapeake. So, bad in fact that before the finals two members from team 190 at different times said "I hope you don't end up on the blue alliance". Team 134 ran consistently though qualifications and eliminations never changing their code or robot configuration. We were forced to change to the blue side of the field. On our first finals match, two robot crashed and disabled each other. They disconnected from the field so the FTA claimed it was a power issue. Then on the next match 134 disabled in the middle of the match for no apparent reason and was still connected to the field. All attempts to convince the FTA that field my have been the issue were ignored. In the third match with no changes other than rebooting the robot and swapping driver station loactions with us team 134 ran fine.

Really? How many robots were not able to compete because of this? I know of at least 6 times where the FTA took the time to point out the mistake to the team(s) and told the scoring table to disable the robot.

[dk5sm5luigi]

Really? How many robots were not able to compete because of this?

I would have to say that I saw that happen at least 7 times. The FTA would bring the student out onto the field point out the issue and then disable them before the match started.

On another note do these stats include eliminations? If so then the data won't be accurate because in eliminations the higher seed is in red and in theory more likely to win.

[Kingofl337]

On another note do these stats include eliminations? If so then the data won't be accurate because in eliminations the higher seed is in red and in theory more likely to win.

That is not accurate, because the new scoring software cannot swap alliances. We were denied our request to stay on red alliance despite being the higher seed.

[dk5sm5luigi]

That is not accurate, because the new scoring software cannot swap alliances. We were denied our request to stay on red alliance despite being the higher seed.

It is close enough. The only time it isn't true is if an alliance beats a higher seed alliance. Either way most of the time in the eliminations the red alliance has a higher chance of winning which then would make these stats inaccurate if eliminations are included.

[AdamHeard]

Despite dead blue robots, This trend seems to pop up every once in a while. "The Red alliance wins more, bla bla bla, not fair, bla".

I saw an article a while back saying in a lot of 1v1 Olympic sports, red was more likely to win, but by the same small amount shown here.

I chalk it up to random chance, as at every regional I've seen the amount of No-shows is far more than the amount of dead robots, so I can't imagine the dead robots making a huge difference overall.

[Kingofl337]

It is close enough. The only time it isn't true is if an alliance beats a higher seed alliance. Either way most of the time in the eliminations the red alliance has a higher chance of winning which then would make these stats inaccurate if eliminations are included.


Not at Waterloo the blue team beat the red team in the quarters #4 and in the semi's #2.

[Kingofl337]

Despite dead blue robots, This trend seems to pop up every once in a while. "The Red alliance wins more, bla bla bla, not fair, bla".

I saw an article a while back saying in a lot of 1v1 Olympic sports, red was more likely to win, but by the same small amount shown here.

I chalk it up to random chance, as at every regional I've seen the amount of No-shows is far more than the amount of dead robots, so I can't imagine the dead robots making a huge difference overall.

Not when the FTA is not letting teams play 6-7 times a regional.

[Lil' Lavery]

My team was at Chesapeake. We were mostly on the blue alliance. As you can see below.

You were on the blue alliance 4 times, and the red alliance 3 times. Yes, you were "mostly on the blue alliance," but you're not going to get any more even than 4 and 3 in a 7 match regional...

[Dave Flowerday]

This is purely anecdotal, of course, but we also suffered issues on the blue side of the field on practice day at BMR. In one match our robot remained unconnected (No Comm) for the whole match. The FTA advised us that the WPA station may have fat-fingered the WPA key, but we verified this afterwards and the WPA key was correct. In the next match we ran fine, without changing anything on the robot. Even though we ran fine in that match, however, I stood behind the FMS computer and watched the statistics. Before the match started, our robot was connected, then dropped out for 20 seconds or so, then connected (and this repeated 3 times). Evidence that it dropped out included a rapid-flashing signal light on the robot and a rapidly-increasing Lost Packet Count on the FMS computer (in addition to Raul throwing his arms up in the air as the DS said No Comm). This issue did not occur while we were enabled in the match and as far as I know we had no further issues. In both of these cases I believe we were on the blue side of the field.

Another team at BMR (135 I believe) spent several practice matches dead as well, and they triple-checked everything on their end too. Not sure if they were red or blue though.

There's definitely some gremlins lurking in the control system at this time.

[Nuttyman54]

Does anyone who has set up or torn down the field know if the drive station control boxes for each side are marked as "red" or "blue"? I believe the Chesapeake field came from Boston, which had experienced the same problem with the red middle station. One match at Boston was restarted at 4 time because of this. Is it possible that this station became middle blue at Chesapeake?

[petek]

Not when the FTA is not letting teams play 6-7 times a regional.
I suggest that a better way to have phrased this would be "Not when non-functional robots are placed on the field 6-7 times."

At each of the four regionals I've worked at this year, the number one problem on the field has been teams forgetting to plug the Ethernet cable back into port 1 of their cRIO.

Throughout practice and early qualification matches we've given teams the chance to correct their error, and given them warnings that we would not continue to let them hold up everyone else if they continue to make this mistake. By Friday afternoon the Head Refs have usually taken the position that if everything else on the field is ready to go and a robot fails to link up because of this error, we would disable the robot and go.

I just cannot fathom how a team, who has put in countless hours and effort to get this far, does not take a checklist with them to queuing and spend the 30 seconds it would take to make sure the Ethernet cable is plugged in correctly, the battery is charged, etc. One of the things FIRST does a pretty good job of teaching is responsibility. Once they sit idle for a match we rarely see a team forget to plug their cRIO in twice. I call that a success.

[Kingofl337]

I suggest that a better way to have phrased this would be "Not when non-functional robots are placed on the field 6-7 times."

At each of the four regionals I've worked at this year, the number one problem on the field has been teams forgetting to plug the Ethernet cable back into port 1 of their cRIO.

Throughout practice and early qualification matches we've given teams the chance to correct their error, and given them warnings that we would not continue to let them hold up everyone else if they continue to make this mistake. By Friday afternoon the Head Refs have usually taken the position that if everything else on the field is ready to go and a robot fails to link up because of this error, we would disable the robot and go.

I just cannot fathom how a team, who has put in countless hours and effort to get this far, does not take a checklist with them to queuing and spend the 30 seconds it would take to make sure the Ethernet cable is plugged in correctly, the battery is charged, etc. One of the things FIRST does a pretty good job of teaching is responsibility. Once they sit idle for a match we rarely see a team forget to plug their cRIO in twice. I call that a success.


I do not believe such a warning was given at Chesapeake, and a pit announcement doesn't count as you could barely hear the PA. If a team received a verbal warning and failed plug it in the next match that is one thing. You have to remember this is a new control system and teams are still learning. On the IFI system we had a dedicated tether port but on the cRio we must use the same port as the wifi bridge, as such if the cable is not pushed in all the way it can pop out of the lan port. Plus you are not only punishing a team this year but an alliance who had no fault in this teams error. Finally the new system links up very slowly compared to the IFI system, teams used to know almost instantly if all is well, not this case here.

[Liz Smith]

I do not believe such a warning was given at Chesapeake, and a pit announcement doesn't count as you could barely hear the PA. If a team received a verbal warning and failed plug it in the next match that is one thing. You have to remember this is a new control system and teams are still learning. On the IFI system we had a dedicated tether port but on the cRio we must use the same port as the wifi bridge, as such if the cable is not pushed in all the way it can pop out of the lan port. Plus you are not only punishing a team this year but an alliance who had no fault in this teams error. Finally the new system links up very slowly compared to the IFI system, teams used to know almost instantly if all is well, not this case here.

I'm biased too and this is only an opinion, but I believe it is the responsibility of the teams to make sure their robot is ready for each match.

I don't think that anyone is getting "punished" for anything. If anything, I think it makes it more fair to the teams who are more prepared, and that do make pre-match checklists. If a team forgets to plug their radio in it's unfortunate for everyone on the alliance but no one's fault but the team themselves. If you as a team member want your robot to successfully run every match then why not take the initiative to do double checks on your radio cables, batteries, and all other connections. Similarly as an alliance member, why not remind your partners in the queuing line to check their connections as you check your own. You wouldn't expect the field crew to make sure all your drive motors are connected and check to make sure your battery is fully charged before each match so why should they be the ones responsible for making sure your radios are connected properly?

[Josh Goodman]

I do not believe such a warning was given at Chesapeake, and a pit announcement doesn't count as you could barely hear the PA. If a team received a verbal warning and failed plug it in the next match that is one thing. You have to remember this is a new control system and teams are still learning. On the IFI system we had a dedicated tether port but on the cRio we must use the same port as the wifi bridge, as such if the cable is not pushed in all the way it can pop out of the lan port. Plus you are not only punishing a team this year but an alliance who had no fault in this teams error. Finally the new system links up very slowly compared to the IFI system, teams used to know almost instantly if all is well, not this case here.

Liz and Pete are both very good FTA's that I've seen in action. I agree with you guys completely on this. The team is responsible for their own robots and connections. This being said, I know many people had trouble connecting to the field in Chesapeake and I think it should be the responsibility of the field crew to let the teams know/give a warning if something was connected wrong or something was not done right. I personally don't know exactly how the field works and when someone doesn't tell me that I'm doing something wrong (and I usually do check after a match if something doesn't work right), I wouldn't know what to change. I think this is a big problem for newer teams who haven't been to as many competitions.

In short, I agree with the FTA's, the teams shouldn't blame everything on the field....it's really not their fault. But I also think that the FTA's should provide feedback to the teams on what went wrong so they do not make that mistake again (thank you Liz :)).

[Jared Russell]

One other theory:

At Philadelphia, there were four referees, each with varying levels of experience. With six payload specialists, plus alliance stations and robots to watch, it takes a lot of skill not to miss anything. Where particular referees are positioned on the field can definitely make a difference when it comes to the amount of penalties spotted.

[dk5sm5luigi]

I can't believe some of this conversation. Are we here to make the competitions run more efficiently or are we here for the high school students and make sure they have as enjoyable time as possible?

Everyone should be answering we are here for the students. How every goes about that is different but I feel we should be out there doing our best to let every one compete. Not to punish three teams for a couple of peoples mistakes. Yes we are trying to teach real world lessons but we are also trying to teach everyone that engineering is fun. Which is more important learning real world experiences or being drawn into engineering?

[DaveF]

...and looking at it another way.... the field is run by volunteers doing their very best with what they are provided. Is it fair to speculate about what they did and didn't do, what they should and should not have done, what did and didn't happen, what was and was not said, when you were not there on the field looking at the robots, discussing the issues and monitoring the FMS? There is a lot of misinformation in this entire thread. It is much different watching the occasional match from the driver's station or watching all the matches from the stands, than it is when you are on the field for every match.

[dk5sm5luigi]

...and looking at it another way.... the field is run by volunteers doing their very best with what they are provided. Is it fair to speculate about what they did and didn't do, what they should and should not have done, what did and didn't happen, what was and was not said, when you were not there on the field looking at the robots, discussing the issues and monitoring the FMS? There is a lot of misinformation in this entire thread. It is much different watching the occasional match from the driver's station or watching all the matches from the stands, than it is when you are on the field for every match.

I was on the field the entire time as a volunteer and heard many of the conversations going on. I could not believe what I saw and heard some of the time.

As far as there being field issues I wasn't paying attention to which spots had these problems and don't necessarily agree with what some people are saying here. My only issue is with how teams were being disabled before the match even started.

[samir13k]

I dont know if this is just a thing thats in our head, or an actual problem.

We won every match on blue and lost every match on red, and our partners Wildstang said that they had a similair scenario. Also, 2 matches in a row during the quals our partner robot in the center position were having issues with their coms during the match and were sitting ducks. (both were on red alliance)

edit: It was the Boilermaker regional

[waialua359]

The point that should be made is that if there was a problem on the field, volunteers or not, it should be addressed. One example is allowing a rematch.
In Portland, if there was a problem, it was addressed, even though it delayed the scheduled matches. The quarterfinals ended at 5:20pm. In San Jose, there was no rematches. In fact, the regional including awards ceremony ended at 5pm. I'd take the former, so that every team has a chance to compete fairly.
This is an expensive event. If the regional only has 7 matches, you can do the math and figure that it amounts to almost $860 per match. The point is to inspire kids both professionally and gracefully. I hate the fact that the thread is turning into a "volunteer" issue again, like in previous years and that we should just suck it up if a problem occurs.
Let's have the attitude to explore issues/problems and fix them collaboratively. :)

[pitzoid]

Interesting thread:

Let me dispell some of the myth.

FMS sets up connections exactly like you do in your testing except for the fact you're using a WPA key to make sure no one can interferre with your radio transmissions intentionally/unintentionally.

Each team has a VLAN tunnel specifically for their bot that doesn't cross with ANYTHING else on the field. Certain things are blocked in the tunnel having to do with video ports, but nothing else.

So for the most part, communicating with your bot on the fields is the same as whatever testing you did at your school.

That being said, some things I've noticed that you all should look out for hooking up on the field.

1) Make sure your ethernet connection is all the way inserted into your DS
2) Make sure the DB9 is plugged in securely also. If the DB9 seems "loose" make sure you mention this to the FTA so they can correct. The DB9 supplies power and the enable circuit for the DS, if it jiggles loose during a match, you will see the DS screen go dark or reboot causing connection loss.
3) No Comms issues could be for a number of reasons. Initially mainly having to do with the static discharges that were happening on the field, but that seems better with the addition of the trailer drag chains. I'd suspect now many of the issues being seen have to do with radio placement in the robot, i.e. where the WGA is.

I was at the PHX regional this past weekend helping out the FTA when I could (been a PHX regional judge last 6 years) and I saw a few times where teams would have issue with their radios dropping during a match and the number one thing I'd get from hostile teams when this happened was "it worked in our lab". Well guess what, being on the field with 5 other robots and a bunch of production gear is worlds apart from "being in your lab" not optimal for potential noise being introduced to your radio. So regardless of whether you think you've got it ll figured out or not, move the radio as far away from other noisey things like motor controllers and relays as possible. I suggest a MINIMUM of 6", more if you can. In Phoenix there was not a single field fault the whole tournament. There was one replay due to a vision target falling off a trailer during a match. The Qualification and Elimination tournaments both finished early. Certain FTAs and Field Crews are still gaining familiarity with the new robot and field systems. Until we work through this natural cycle of introducing new gear, there will be some issues. We're already seeing incredible improvements from the first couple weeks of regionals, the last two weeks overall have run very smooth (after introduction of the trailer chains).

There's no FMS conspiracy to make Red win more than Blue, thats just silly. The scorekeeper has indicators on their screen for if FMS is having issue with any of its periferies on the field. FMS communicates with each SCCE on the field every 20ms to check the gigabit network. This is twice as fast as you communicate with your robot. If there's a problem, it lets the scorekeeper know.

[MrForbes]

One thing I found that was fairly consistent was the flat black ethernet cable provided in the kit was problematic. teams that had swapped it out for real twisted pair ahd almost no problems with communication.


So regardless of whether you think you've got it ll figured out or not, move the radio as far away from other noisey things like motor controllers and relays as possible. I suggest a MINIMUM of 6", more if you can. In Phoenix there was not a single field fault the whole tournament.


Hmmmm....interesting....the flat, black ethernet cable is rather short, the twisted pair cable is kind of long. Could it be that those robots with the radio mounted further away from the other electronics worked better? or that the shorter cable just doesn't work as well?

(I love the correlation-causation comic)

[JohnBoucher]

I would have to say that I saw that happen at least 7 times. The FTA would bring the student out onto the field point out the issue and then disable them before the match started.

Is this by direction of the GDC or a local decision?

[Jack Jones]

… You wouldn't expect the field crew to make sure all your drive motors are connected and check to make sure your battery is fully charged before each match so why should they be the ones responsible for making sure your radios are connected properly?

Interesting thread:
…
Until we work through this natural cycle of introducing new gear, there will be some issues.
.

There’s your answer. The field crew deserves our understanding while making the new system work. The reverse should also be so. The big difference is that the teams are the customer and the crew, paid or not, works for them.

[rsisk]

Does anyone who has set up or torn down the field know if the drive station control boxes for each side are marked as "red" or "blue"? I believe the Chesapeake field came from Boston, which had experienced the same problem with the red middle station. One match at Boston was restarted at 4 time because of this. Is it possible that this station became middle blue at Chesapeake?

The SCC have red/blue tape at the top of the handle but that doesn't guarantee that they are setup that way. It's possible for the spare SCC to be in use as was the case for part of LA and PHX.

[Bongle]

I think that if a team puts a robot on the field that doesn't have its radio plugged in, it is their own fault, and it isn't the FTA's job to make sure they have it right.

As for the "but what about the alliance they bring down with them?" argument, that's an invalid argument. If that argument guided decisions, then teams with poor robots would never get to play, because they'd bring down their alliance. A team with an unplugged radio made a mistake, and their alliance partners made a mistake by not checking for the unplugged radio.

The ease of checking for and fixing an unplugged radio and the dire consequences of failing to do so should make it absolutely inexcusable for a team or alliance to be so boneheaded as to put a robot on a field with their radio unplugged.

Then there are the logistics issues if the FTA allowed them to plug it in once they detected an unplugged radio:
-What if a team's radio is located in a relatively inaccessible location on the robot?
-Would they delay the match by 2 minutes while the team digs out the radio and plugs it in?
-Will they only allow teams with accessible radios to plug them in?
-Who would decide what is an accessible radio versus an inaccessible radio?
-What if they accidentily discover (or cause) another wiring bug like unplugged cables? Will they be allowed to put those back in?
-If not, how would you enforce the "only plug in your radio and nothing else" rule?

[pitzoid]

Until we work through this natural cycle of introducing new gear, there will be some issues.

Well, these are just my personal opinions, but being everyone seems to think their own opinion best, I thought I'd just share mine.

My back ground is running nuclear reactors on submarines, and building automation equipment responsible for billions of dollars of manufacturing. Needless to say, these are two real world environments where “attention to detail” is critical. One could cost many lives, both could cost a lot of money. Both things are near and dear to people everywhere.

With that said, how did I get an aptitude to field deploy complex gear the way I can and overcome a million variables having to do with dealing with imperfect technology and inexperienced techies? Well, I screwed things up. Mostly in situations that didn’t kill people or cost millions of dollars, but that’s how I learned my “attention to detail”. My programmers still marvel at how myself (not really much of a programmer) can test their code, and find things they would have never thought of. It’s because I have a logical sense of thought and I notice the small details. All this came from training, a lot of training. Student competitions are great places to learn this as no one is going to die, and at the end of the day, all you did was learn.

The people who equate the money spent on this program to the number of matches a team runs are missing the big picture. Yea, it stinks when your bot just sits on the field while the other bots run around, but you learn a lot from that. People learn best when they self question their abilities about something they care about, if you aren’t going to try your best to make yourself better, no one else will. Pride and Ego are very powerful forces.

Is it right that teams were bypassed to get a match going on time? Don’t know, wasn’t there. But for the most part, if a Match was scheduled to start and all the teams weren’t, kinda sounds like the real world….. I mean, planes usually don’t wait for you when you’re late to the gate, why should FMS? You can argue this up and down, there are probably a thousand “right” answers. Fact is, if you weren’t there, you’re burning a bunch of wasted calories. Every event has its own personality.

:yikes: :D

[Dave Flowerday]

Is it right that teams were bypassed to get a match going on time? Don’t know, wasn’t there. But for the most part, if a Match was scheduled to start and all the teams weren’t, kinda sounds like the real world….. I mean, planes usually don’t wait for you when you’re late to the gate, why should FMS?
So how does that work in the other direction? We lost almost an hour at BMR due to the failure of FMS and the field. Why should 5,000 people have to wait for that to get fixed?

We've got people in this thread calling teams who forget to plug in their radios "boneheaded" and generally deriding them for forgetting something that's easy to forget after rushing to get the Labview change that just took 10 minutes to compile loaded on their robot with seconds to spare and something that they didn't have to worry about with the IFI system because the IFI engineers anticipated this problem and designed a solution in (separate tether port). Yet any time similar criticism is spoken towards the FIRST side of things, there's pleas for patience as the event staff "learn the ropes" of the new system, or accusations that it's un-GP to complain about FIRST's stuff not working, etc. It all seems a little lopsided to me.

Basically, FIRST took a working system, made it more error-prone, and then blames the teams for making errors. Nice.
The people who equate the money spent on this program to the number of matches a team runs are missing the big picture. Yea, it stinks when your bot just sits on the field while the other bots run around, but you learn a lot from that.
I don't really think teaching teams hard lessons is FIRST's big picture. Their "big picture" is inspiring students and getting them interested in science and technology. Sitting on the side of the field with a non-functioning robot is not inspiring and makes the technology look error-prone and frustrating. I believe IFI understood this well and that's why they had someone at every event making sure that every robot was linked up and ready to go for each match. The fact that they switched to a new system takes forever to link up is a decision FIRST made that they should have to live with, but they seem to be shifting the burden of this decision to the teams who had no input when the decision was made.

As you can all tell, I'm getting very tired of everyone ripping on the teams. Maybe I should take the same attitude as others here are taking next time a team asks me for help in the pits. If they were too "boneheaded" to show up with a working robot then too bad for them. Wonder how FIRST would feel about that attitude.

[kjohnson]

First, let me address the discrepancy issue between red/blue alliances: what a joke! Whether you are on the red/blue alliance makes no difference, everything comes down to who your alliance partners are and how well you play the game. I was on the field for nearly every match (practice, qualification, and elimination) at the NASA/VCU Regional. We had the same amount of problems with communication not syncing on both the red and blue alliances, but the difference was that we did our best to fix them. Read on...

I think that if a team puts a robot on the field that doesn't have its radio plugged in, it is their own fault, and it isn't the FTA's job to make sure they have it right.

Then there are the logistics issues if the FTA allowed them to plug it in once they detected an unplugged radio:
-What if a team's radio is located in a relatively inaccessible location on the robot?
-Would they delay the match by 2 minutes while the team digs out the radio and plugs it in?
-Will they only allow teams with accessible radios to plug them in?
-Who would decide what is an accessible radio versus an inaccessible radio?
-What if they accidentily discover (or cause) another wiring bug like unplugged cables? Will they be allowed to put those back in?
-If not, how would you enforce the "only plug in your radio and nothing else" rule?

At VCU, we did everything possible on field to get every team's communication linked. If their radio was unplugged, the field crew plugged it in. If the robot's power needed to by cycled, we did. We made every effort to have every team play in every match (Just ask the 3rd seeded alliance of 612, 2068, and 1908). If there was an issue other than the radio, we bypassed the robot for that match and directed the team first to inspection to have their game adapter checked for proper configuration, and then to the NI representative. After reprogramming, teams that dropped communication randomly during the match had further problems (ask 2108, 1222).

Even after all the problems with unplugged radios and taking the time to fix them, we still finished Friday ahead of schedule!

The majority of teams that were bypassed had either reset their game adapter, or had a programming issue.

Is this by direction of the GDC or a local decision?
It was a local decision by that regional to bypass the teams with unplugged radios. As I said above, at VCU we made every effort to ensure communication.
We even allowed teams that never practiced on Thursday to come onto the field and check communication before the pits closed at 8 P.M.

[Vikesrock]

So how does that work in the other direction? We lost almost an hour at BMR due to the failure of FMS and the field. Why should 5,000 people have to wait for that to get fixed?


Unfortunately this fits the analogy pretty well. If you miss the plane, it's your problem, but if the plane is late everyone gets to wait around for it. Here's the thing though, do we really want to be comparing ourselves to an industry with such low customer satisfaction?


I don't really think teaching teams hard lessons is FIRST's big picture. Their "big picture" is inspiring students and getting them interested in science and technology. Sitting on the side of the field with a non-functioning robot is not inspiring and makes the technology look error-prone and frustrating. I believe IFI understood this well and that's why they had someone at every event making sure that every robot was linked up and ready to go for each match. The fact that they switched to a new system takes forever to link up is a decision FIRST made that they should have to live with, but they seem to be shifting the burden of this decision to the teams who had no input when the decision was made.


I completely agree. In the 3 events I have been at in my previous two years I do not recall a single match starting with robots not linked with the field. In fact I remember the exact opposite, every effort was made to get a team linked with the field before the match started. If teams were allowed to go on to the field and turn their robots on in previous years I definitely think they should be able to go plug in their radio this year.

FIRST made the decision to change to a control system that takes longer to sync and FIRST made the decision to have a game with a long field reset time. The burdens that these two things place on the schedule should not be passed on to teams unless absolutely necessary.

Does starting a match without a team tech them a lesson about attention to detail? Probably. Does it inspire them? Probably not. As much as this competition "isn't about the robots", the robots are what inspire the students. Matches where your robot doesn't move aren't fun or inspiring for the drivers, the coach, or the parents and students in the stands. We should be doing everything we can to get every robot moving in every match.

[Bongle]

As you can all tell, I'm getting very tired of everyone ripping on the teams. Maybe I should take the same attitude as others here are taking next time a team asks me for help in the pits. If they were too "boneheaded" to show up with a working robot then too bad for them. Wonder how FIRST would feel about that attitude.

Just so it doesn't look like I'm only tossing stones at other people:

-It was boneheaded in 2004 AND 2006 when I and the other programmers mistakenly let the robot run in a match with code that couldn't drive in a controlled manner, leaving us ineffective for a match.
-It was boneheaded in 2006 when I didn't check the charge level of the backup battery before a match, leaving the RC dead.
-It was boneheaded in 2006 (again) when I uploaded an old version of the code, thinking it was the new version, leaving the robot undriveable.
-It was boneheaded in 2006 (was not a good year for me) when I failed to remove the programming cable and it got caught in our drive chains, ending a match.
-It was boneheaded this year when we failed to double-check our main battery wire, which then came loose and left us dead for the entire match.

Any mistake that can be fixed in less than 30 seconds (ok, the code ones may not be 30-second fixes anymore :( ) and only takes a visual inspection to fix, I would call boneheaded. I don't really mean it in a mean way, I just mean it in a forehead-slapping "oops" way.

[Kingofl337]

Pitzoid I have a request, for love of all that is good please update the monitoring software for Atlanta that monitors the following things...

Log the following times per team
1. Field E-Stop Status Per Robot
2. Driver Station Connection -> Ping is fine
3. Wifi Bridge Connection -> Again Ping
4. System Watchdog
5. User Watchdog
6. Log The console data being sent from the cRio for each team

This data can be used as a black box of sorts to determine why a robot stalls on the field.

Also, I agree with Dave, this was not the teams decision to switch this new system. Why are we being punished when it breaks down? I can't believe that it hasn't come down from FIRST to always err on the side of the teams if no obvious problem is found.

[Alan Anderson]

We lost almost an hour at BMR due to the failure of FMS and the field.

It's more than a little unfair to call a complete loss of externally provided power to the entire pit and field a "failure of FMS". :mad:

For those of you complaining about the time it takes for the 2009 FRC control system to "link up with the field", my observation is that it's really a very quick process, on the order of five or ten seconds. What takes time is the cRIO booting up and starting to run the user code. The WGA is fully active and in the loop long before the cRIO even starts looking for the DS. I doubt that the FMS can tell that a team has managed to leave the network cable disconnected between the cRIO and the WGA until 30-45 seconds after the robot has been powered on. It isn't the FMS you need to be focusing your attention on; it's the cRIO. (Maybe the boot time can be reduced in the future by implementing something like a "hibernate" mode, or even a precomputed RAM image deployed as part of the program load process.)

[Dmentor]

This thread seems to have veered onto a tangent. I can't comment on what occurred at Chesapeake but I wanted to confirm Kyle's statement regarding NASA/VCU.

At VCU, we did everything possible on field to get every team's communication linked. If their radio was unplugged, the field crew plugged it in. If the robot's power needed to by cycled, we did. We made every effort to have every team play in every match (Just ask the 3rd seeded alliance of 612, 2068, and 1908). If there was an issue other than the radio, we bypassed the robot for that match and directed the team first to inspection to have their game adapter checked for proper configuration, and then to the NI representative. After reprogramming, teams that dropped communication randomly during the match had further problems (ask 2108, 1222).

Even after all the problems with unplugged radios and taking the time to fix them, we still finished Friday ahead of schedule!

The field crew and referees were fantastic at NASA/VCU (well actually pretty much everything was awesome at NASA/VCU except getting beat in the semifinals again). They were helping to fix problems all regional long. When 1908's gaming adapter had to be replaced before the quarterfinals, Kyle patiently confirmed the configuration and assured us that he would do everything possible on the field to ensure that they were working properly. And he did, thanks Kyle! While 1908's robot was immobile for nearly all of QF 4-1, I'm convinced it had nothing to do with the gaming adapter.

In practice at DC, we had discovered that we always had to start the DS first, wait until it finished booting, and only then power on the robot. If we didn't follow the procedure, we would often experience odd robot behavior (sometimes we would be immobile, sometimes only our autonomous would work, sometimes our DS digital IO wouldn't work even though everything else worked fine, etc.) At DC, we could recreate this condition while tethered in the pits so we developed a startup procedure. At NASA/VCU, we continued to follow this procedure and it worked great until Q38 where we were once again immobile during the whole match. Of course everything checked out just find in the pit, but in the debrief with the drive team, the only deviation from the startup procedure that we used in the pits and what was used on the field was that when the DS was powered on for Q38 it was not in a disabled state (??). We tried but couldn't reproduce this failure in the pits, but we subsequently modified our startup procedure to include ensuring that the DS was in a disabled state before powering on the robot. This seemed to eliminate any further odd robot behavior. After QF 4-1, we also made sure 1908 followed our startup procedure and they didn't experience any further odd behavior but the issue could just have been a lose wire.

Thanks so much to the NASA/VCU crew for ensuring that all the teams had the best possible opportunity to shine!

[Dave Flowerday]

It's more than a little unfair to call a complete loss of externally provided power to the entire pit and field a "failure of FMS". :mad:
I'm not talking about the 20 minutes of power outage - I can't believe anyone would think I'd blame that on anything other than the burned up breaker that caused it. I'm talking about the 45+ minutes afterwards that the field could not be restarted and wouldn't work, despite the obvious multiple restarts of the whole system by the field crew (who did an excellent job dealing with the situation).

[Lil' Lavery]

This thread was somewhat painful to read. Teams are pointing at FMS/Volunteers, Volunteers are pointing at Teams/FMS, FMS is pointing at teams, etc.

I know some posters have been more forthright and accepted responsibility, but in general people are making much more sweeping generalizations than they should (including my intro).

Like most difficult problems, this one is multi-headed and problems exist in each area.

Teams:
Ultimately the ball is in your court to make sure your robot is ready. I know about and I feel the pain of having a knew control system, long labview downloads, and having another series of items to have to worry about each match. And I wish every event had the time and crew that would allow for the event to be streamlined and fair. But the simplest way to make that happen is to take care of stuff on your end.
Write a pre-flight checklist. Run through it before each and every match. Find ways that work to make sure your robot can sync with the field quickly and flawlessly. Help out your alliance partners (and preferably each and every team in FIRST) to do so as well.

Field Reset/FTA/Volunteers:
Your job is not only to help the event run in a timely manor, but to also help the teams get the most out of the event (though that applies both ways, nobody like events that run 4 hours over). I know this is hyperbole, but you could run 80 matches in 3 hours if you allowed 0 minutes for teams to get on the field in between matches. Yet nobody would be happy with that. Running on time is great, but so is having teams running.
Try to help teams ensure they're ready to go by the time they're setting their robot on the field. Queuers and reset volunteers can ask the teams who are in queue if their radios, DS, and batteries are plugged in. You can post signs by the entrance to the field to help remind teams of the same thing.

FMS/FIRST/Other affiliated Parties:
Yes this is a new system. Yes we all expect it to have its kinks. Yes, it can run well when everything goes right and the teams do everything right.
But this is the real world. Not everything will go right, and the system needs to be designed to incorporate that.
We need ways to help fix and diagnose connection issues and controls issues (both from the field and robot perspective) quickly and efficiently. Whatever of these can be implemented DURING the season (once properly tested), should be. We shouldn't wait until next year.
We need to find ways for the robots and field to connect faster/cRio boot faster.
We need to find ways for the field to be reset faster so the teams can start booting and connecting their robots sooner.
We need to make this whole process more team friendly, and find better ways for teams to fix whatever issues they can BEFORE they get on the field.


Pointing fingers isn't going to solve anything, and neither is getting your feelings hurt. Determining solutions and being pro-active is required, but so is determining what isn't working currently. No party should be happy with the current situation, or any situation like it. Every party involved should be working to make the process better, pick up their end of the bargain, and work WITH the other parties instead of against them.

[petek]

(snip)...the only deviation from the startup procedure that we used in the pits and what was used on the field was that when the DS was powered on for Q38 it was not in a disabled state (??). At the risk of driving this thread even further off track, I saw this condition once in Pittsburgh and it turned out to be a flaky DS Ethernet connector.

[ColleenShaver]

I do think the efforts of the NASA/VCU field crew should be applauded! It's great that they were able to support so many teams and still run a timely event.

I understand it is difficult, and where to draw the line between team responsibility and teaching a lesson is blurry at best. But all being said, a little leniency for the teams who I think have been incredibly patient adapting to this entire process is in order.

I wasn't on the field the entire time in Chesapeake, but I was there on the sidelines the 3 different qualification matches where one of our partners was disabled by the FTA.

In two matches, everything was hooked up correctly as far as everyone could tell. The robots could not communicate so they were disabled. After some follow-through by our programming mentor & them not working the next match, it was determined one team had a radio problem. Another was never solved.

But red or blue, to allow plug in or not, there are a couple things that did disturb me:
- In our other match, the team had not plugged in their radio after being tethered in the pit. It was discovered once the field was set and all other teams linked and ready. The team was called back out on the field, shown the problem, allowed to plug it in, and then the scoring table was told to disable them. It certainly wasn't a time saving measure! Why not let the kids play? Why embarrass them like that? I'm sure they felt bad enough. This was done repeatedly when these problems happened.

- Teams have no way to troubleshoot problems, particularly with wireless. They are only allowed to tether in the pits and then they step on the field and are told "it's your robot".... Well their only defense is "it worked in our lab" because it's their sole point of reference. I totally agree with Adam's point of getting some more diagnostic tools in so field staff can say "it's an issue with your XXX" and teams have a chance of fixing it! How can you make a checklist when no one knows what you're looking for, and much of it can't be tested?

In general, teams were told to turn on the robot and leave the field immediately (some at the threat of disablement).... no 'gates down'. While I can certainly appreciate the consistency with which the field was run, I don't think it served the interest of teams or time-saving.

I personally am willing to give FIRST the chance to work out the bugs of all this new stuff, but I do think those representing FIRST (paid, volunteer, etc) need to show teams the same bits of compassion. I congratulate the events that have found the way to balance all perspectives on the issues!

[pitzoid]

Log the following times per team
1. Field E-Stop Status Per Robot
2. Driver Station Connection -> Ping is fine
3. Wifi Bridge Connection -> Again Ping
4. System Watchdog
5. User Watchdog
6. Log The console data being sent from the cRio for each team.

Well I think everyone needs a reality check on this one.....

I think the Lil Lavery comments are typical of what happens in these threads, everyone starts making assumptions about something that is contributed and before you know it it turns into the "finger pointing" fest. And for the most part thats why people who are in the "know" on things won't comment because nothing positive will come of it.

I didn't say it was the teams fault, I didn't say it was the volunteers' fault. I said "I wasn't there" so I don't know what happened, most of this stuff is at the discretion of the volunteers at the event and we can only hope they did the right things based on whatever circumstance they were dealing with.

As for what FMS has for trouble shooting, well, its about 2X what the IFI systems had (I know, I paid alot of attention to it the 2008 season). We can do this based off of how versatile ethernet is compared to other communication systems. Everything listed above and more is monitored, logged, and warnings issued. If its not being used, it because the operators are missing something. Fact is, FMS won't even let you start a match unless all 6 teams are linked with bots (or bypassed). QOS is monitored to make sure that the link between operator and robot is less than a 25ms loop (there and back), averages about 23ms. Thats what the Green Blinking light is you see on the score keepers table is, indication to the MCs and Announcers that the teams are technically ready to play the match. If someone was bypassed, it was a call made by the field personnel based on whatever circumstance they were dealing with. Fact is, I've had alot of scorekeepers comment to me that they are amazed by the way FMS is helping to run events this year....

I think sometimes people forget that we are dealing with very complicated devices that are essentially all prototypes, many built by people who are just getting their feet wet with technology. These aren't consumer toasters you buy at the local Target and even those don't work all the time. So sometimes they work, sometimes they don't, if the volunteer field personnel spent time fixing every bot that was not working on the field when it comes out, the tournaments would not finish in the alotted time. So its all sorta a wrong if you do, wrong if you don't situation, i.e. a no win. Its just the reality of the situation.

And just so you know, I'm very much a proponent of all bots must run on the field during the tournament if we can make it happen, soo much so that when the PHX event got down to the last bot that hadn't run during a match yet (the team had alot of issues they were trying to overcome), we figured that the teams radio wasn't working correctly, we didn't have a replacement they could use, couldn't find any close to the venue (guess teams had already bought out Best Buy), so I drove 45 minutes Friday night (each way) to find a store that had a couple WGAs, paid for it myself came back and gave it to the team Sat morning so they could run their last couple matches, let them have it.

So I guess what I'm ptting across here is please don't make assumption about what I put out or FMS capabilities, if you have questions, I'll answer you. PM me if you want, I've tried to answer all the messages that I've got this year. I want nothing more than every FIRST team to have an awesome time. And for the most part we've acheived that this year. People forget how long it took to get acclimated to the new IFI system after the introduction in 2004 (it took years) we are doing our best to make sure we work out the kinks as soon as possible.

THX :)

[pitzoid]

- Teams have no way to troubleshoot problems, particularly with wireless. They are only allowed to tether in the pits and then they step on the field and are told "it's your robot".... Well their only defense is "it worked in our lab" because it's their sole point of reference. I totally agree with Adam's point of getting some more diagnostic tools in so field staff can say "it's an issue with your XXX" and teams have a chance of fixing it! How can you make a checklist when no one knows what you're looking for, and much of it can't be tested?

Hey Collen, I'm glad you bring this up. I know this is an issue and we've hit it around alot. 4FX has a solution for it also. We have a new team sign we designed that has a screen on the back of it that can do custom messages for each team, now only to find the budget to get them deployed for next year ;)

[bandducky511]

This thread seems to have veered onto a tangent. I can't comment on what occurred at Chesapeake but I wanted to confirm Kyle's statement regarding NASA/VCU.


At NASA/VCU, we continued to follow this procedure and it worked great until Q38 where we were once again immobile during the whole match. Of course everything checked out just find in the pit, but in the debrief with the drive team, the only deviation from the startup procedure that we used in the pits and what was used on the field was that when the DS was powered on for Q38 it was not in a disabled state (??).

Thanks so much to the NASA/VCU crew for ensuring that all the teams had the best possible opportunity to shine!

Good job on making it to semi-finals! I remember going against your bot in Q38. It started during autonomous at the outpost and did move; however, it stopped moving after our alliance partner collided with your bot. There was a huge collision with 3-4 robots around that outpost that match (if I remember correctly). The immobile part may have been caused by the collisions :S
Also, the DS does not need to be enabled or disabled. However, before you turn the robot on make sure it is disabled or enabled and on tele-op. The field judges are supposed to automatically turn each driver station on disable and autonomous at the beginning of each match (from what I have seen)

[MrForbes]

How can you make a checklist when no one knows what you're looking for, and much of it can't be tested?

I made up this checklist during Thursday of our first regional, I couldn't get anyone to use it, but here it is anyways :)

Place Robot
Hitch Trailer Securely
Battery Strap buckled
Plug in Battery
Check battery cables—bumper perimeter
Align Turret
Load Balls
Field says 1726 over our Driver Station
Power ON
Check Router for power/comm.
Electronics Cover secure

Comments?

[pitzoid]

For those of you complaining about the time it takes for the 2009 FRC control system to "link up with the field", my observation is that it's really a very quick process, on the order of five or ten seconds. What takes time is the cRIO booting up and starting to run the user code.

WGA is ~15 seconds to boot
DS is 10 to 20 seconds depending on how fast it identifies its USB devices
cRio can boot in as fast as 10 seconds (what I've seen in the shop, mine don't have a bunch of user code in them though)

I've seen WGAs link with the field AP in <2 seconds, and then I've seen them take as long as 20 seconds in the field, and I've seen some that don't link at all :D It all comes back to how much RF interferrence the WGA is getting from the robot. I.e. where the radio is placed in relation to metal bulkheads, motor controllers, relays and a multitude of other RF noisey things on the bots. this has been a common theme in many of my posts. I saw someone used my "it worked in our lab" comment, and the fact is, maybe it did work in your lab, but was marginal "in your lab", get out to the competition field with other RF competing devices and maybe it won't work..... That was the point. If you have one point of referrence and you know someone else that literally had hundreds, I'd go with that advice.

RF is voodoo, many things can affect it, treat with as much respect as you can.....

[Kingofl337]

Pitzoid, if a log of each match with of all of this information is available the field staff doesn't know how to get at it, because every time a robot stops running they usually have no clue idea why. If you have put in place the tools to monitor the DS, Bridge and the cRio individually that capability is not being utilized.

I have never herd someone on the field say "The log indicates the bridge stopped responding 1min 35sec into the match, but the driver station was still responding." or "The robot stopped communicating with the field at 1min 36 seconds the bridge and the DS were still responsive, at that time the console log shows the cRio sent out a message that FrcUserProgram.out had a stack dump."

All I've herd is the "Your robot disconnected, but the lights on the bridge are still blinking" or "The light for your robots disable light was flashing every now and then I don't know why"
Later investigation led to the user watchdog being to aggressively set and a image processing task was taking a little long to complete and the robot ran despite the disable light flashing.

[pitzoid]

Pitzoid, if a log of each match with of all of this information is available the field staff doesn't know how to get at it, because every time a robot stops running they usually have no clue idea why.

Well, the issue you run into with training some volunteers is that they'll shake their heads "yes" that they understand everything you've just told them but didn't listen to a word. And some volunteers are just above awesome in how well they handle things :D

We try to make things like the robot match logs (which by the way was never easily available from IFI) as intuitive as possible, its in the training, why they don't get it I don't know the isolated reason.

BUT, in Match Review, in FMS, when a match is completed (i.e. commit score has been pressed for that match) the robots listed for that Match will turn into either a blue or a red button (depending on alliance, if the match is "not completed", the bots are just listed on a white background), press it (in Match Review) and it pops up the robot telemetry log for the match. The log only records while the match timer is running.

Bots can drop for a number of reasons during a match, hard to say any 5 things are the possible reason. Could have to do with bad code (seen lots of stops in code), low batteries, loose connections, radio placement, the Static discharge issues, etc.... The log does record the FMS connections status alongside the robot telemetry, I've yet to find data that shows FMS connections dropping when robots did (i.e. how we isolated some of the DS issues so quickly), all field equipment runs QOS logs. Telemetry now is still somewhat limited to just communication stuff. I had a talk with some NI folk the other day about bringing out data on every resource a team is using on the cRios and then figuring out a way to distribute this to teams post events. We have big plans for FMS, time and resources will tell what comes to realization.

I think this thread is flying off the track now, if you guys want to start an FMS technical thread we can, we talked about one in the official FIRST forum, but I don't know if anyone would pay attention to it there :D

[Kingofl337]

Well, how about the ability to dump that data to a thumb drive via a simple click. If a robot stops working a team can request field data review the data back at the pits?

edit:

I think all teams want is to be able trouble shoot issues they encounter on the field. If a team spends the money to goto Atlanta and their robot stops and the answer is "I don't really know" that will be unfortunate.

Also, with the IFI system all that was needed was packet loss and battery voltage. Plus, they sent a rep to every event that knew the system inside and out.

[pitzoid]

Well, how about the ability to dump that data to a thumb drive via a simple click. If a robot stops working a team can request field data review the data back at the pits?

Thats a good idea... I can think of even better ways :D

Maybe next year we can have a way to do this, the hurdle with FIRST is always resources. And to be honest, with the economy going the way it is, who knows what will happen next year? We're all facing economic challenges.

But, remember why its important to keep the matches running on schedule, regional committees bring in officials to do speeches and such (which many pay for the event), and certain venues will have monetary penalties if the event runs late, so there are many many tradeoffs....

I'm all for providing teams more resources, just have to figure a way to get them paid for.

Everyone write Obama and tell him FIRST needs stimulus ;)

[smtoney]

Speaking for Chesapeake:

As one poster on line mentioned "However, in this case, I think it's pretty fair to say you've simply found the tails of the curve. Someone's got to have the highest and lowest scores, after all." I'm even more surprised that Boston, San Diego and Florida had exactly 50/50 splits. (And Boston is where our field was before us!)

Look at the data this way as well. For the 31 regional's where there was a difference 13 of them the difference went to red. Exactly what one would expect from a normal distribution.

Note: that the eventual winning alliance in eliminations played quarters
and semis on blue and was 4-0 on blue.

One of the FTA's present and the Field Supervisor have both e-mailed me to indicated that they felt there was NOT a universal problem on Blue 2. One of our official scorekeepers was keeping independent notes and link failures were pretty evenly distributed over the 6 positions.

To really point to a single station you would need to have the points scored by robots by match to see if there is an anomaly. Take it from me (and my major was Mathematics), what we have here is too little data being stretched to far. Plus using the data published does not account for results changed due to penalty's, and we had at least two that I recall.

Not to belabor the point, but I don't see a statistical discrepancy. And certainly not one that points to a single driver station. Not with this data.

[Nuttyman54]

Speaking for Chesapeake:

I'm even more surprised that Boston, San Diego and Florida had exactly 50/50 splits. (And Boston is where our field was before us!)


Which came from Manchester before that. Both regionals had numerous replays for field errors. I recall that Boston was going to replay matches 44 through 50 at one point, but some of them were declined by the affected alliance.

This is not to say that the replays are the reason for the 50/50 split or anything of the sort, simply that the field at Chesapeake came from two regionals which had major problems with the system.

[Galum]

Not sure if someone mentioned it already (yes I'm too lazy to read through the thread), but Israel had the same communication problem with the central blue outpost. Not with every robot, but throughout the competition we experienced several incidents with this particular outpost.

I'd like this to be confirmed by a judge/FIRST personal as I was mostly in the Pit area.

[kjohnson]

The field crew and referees were fantastic at NASA/VCU (well actually pretty much everything was awesome at NASA/VCU except getting beat in the semifinals again). They were helping to fix problems all regional long. When 1908's gaming adapter had to be replaced before the quarterfinals, Kyle patiently confirmed the configuration and assured us that he would do everything possible on the field to ensure that they were working properly. And he did, thanks Kyle! While 1908's robot was immobile for nearly all of QF 4-1, I'm convinced it had nothing to do with the gaming adapter.
...
Thanks so much to the NASA/VCU crew for ensuring that all the teams had the best possible opportunity to shine!
Thanks! I'm glad your alliance was able to advance through 1908's problems. They linked with the field during QF4.1 but did not move. They reprogrammed before QF4.2 and never had another issue.

I do think the efforts of the NASA/VCU field crew should be applauded! It's great that they were able to support so many teams and still run a timely event.
Thanks! We were just as surprised as anyone else that we were able to finish on time. At some points, we were even ahead of schedule. For most matches, the field was reset and robots in place before Jeff began announcing teams.

Good job on making it to semi-finals! I remember going against your bot in Q38. It started during autonomous at the outpost and did move; however, it stopped moving after our alliance partner collided with your bot. There was a huge collision with 3-4 robots around that outpost that match (if I remember correctly). The immobile part may have been caused by the collisions :S
Also, the DS does not need to be enabled or disabled. However, before you turn the robot on make sure it is disabled or enabled and on tele-op. The field judges are supposed to automatically turn each driver station on disable and autonomous at the beginning of each match (from what I have seen)
Yes, that collision caused the communication issue. It showed immediately on the Field Monitor after the collision.

As for enable/disable, until the scores from the previous match are committed, the next matches driver stations are enabled. When the team numbers change to the current match, the DS is disabled. There were a few instances where some robots on the field had already booted and their motors jumped for a split second when the field switched matches.

WGA is ~15 seconds to boot
DS is 10 to 20 seconds depending on how fast it identifies its USB devices
cRio can boot in as fast as 10 seconds (what I've seen in the shop, mine don't have a bunch of user code in them though)

I've seen WGAs link with the field AP in <2 seconds, and then I've seen them take as long as 20 seconds in the field, and I've seen some that don't link at all :D
At VCU the DS took typically less than 20 seconds to boot. As long as the DS has booted, it took about 30-40 seconds for each robot to sync with the field (from power on, to confirmed communication).

[Killraine]

A couple notes on the data I posted:

1) It is data from the qualification matches only.
2) It was not intended to prove that there were problems at any regional. I noticed this discrepancy and merely posted the data to stimulate some discussion.

I have a question though, after reading through this thread. What can a team do when they have a pre-match checklist, go through and make sure everything is plugged in and it all checks out, and then get on the field and can't establish communication? I know this was the case for our team in our last qualification match at station Blue 2. The "solution" was that our robot was disabled before the match and the match was played. In fact, the field team at Chesapeake seemed to be assuming that communication problems were robot-side. Our team couldn't do anything to prevent and/or fix the problem and the people running the field can't be expected to troubleshoot every robot that can't establish communication. What can we do in this kind of "no-fault" situation that left all of the students on our team feeling dejected and helpless?

Also, if anyone has comprehensive scouting data for the Chesapeake event, I would like to take a look at it. I would need the points scored by individual robots (not teams, would like to eliminate HP points) correlated to a match number. From there, I could look for correlation between non-functioning robots and the station they were at.

[Rick TYler]

One thing I found that was fairly consistent was the flat black ethernet cable provided in the kit was problematic. teams that had swapped it out for real twisted pair ahd almost no problems with communication.

I know I'm late to this thread, but the FTAs at Seattle must have replaced a zillion Ethernet cables. That and telling teams to plug batteries into cRIOs seemingly took half their time.

[Rick TYler]

the field team at Chesapeake seemed to be assuming that communication problems were robot-side. Our team couldn't do anything to prevent and/or fix the problem and the people running the field can't be expected to troubleshoot every robot that can't establish communication. What can we do in this kind of "no-fault" situation that left all of the students on our team feeling dejected and helpless?

I am NOT an FTA, but I did sit next to them for three days. They can do a lot more than assume that it's a robot problem, since their control console sees lots of information on the field and the robots. I heard FTAs telling teams that their main batteries were low, that their driver's stations were flaky (replaced on the spot), that their radios weren't working right (replaced on the spot), and that they had bad Ethernet cables (replaced on the spot). I was really impressed with how much they knew. Only when the radio link was working, all the monitored on-board components were reporting OK, and the field was reporting OK did I start a match with a motionless robot. For what it's worth, the problems weren't spread out -- it was the same handful of robots over and over again.

I am very sympathetic to your plight (kids on my teams have failed to start in a finals match three times in the last two years), but I don't know what else the field crew can do when all the diagnostics are reporting "Good" but the robot doesn't move. I DO know that the FTAs in Seattle sometimes spent five minutes trying to get a single robot working before some matches, and were always disappointed when a 'bot DNS'ed.

[Rick TYler]

Is this by direction of the GDC or a local decision?

At Seattle the FTA assts would either fix it or allow the team to fix it -- all the way through the tournament. The only time we bypassed a robot is when no one could figure out how to get it running in a reasonable amount of time (a couple or three minutes). We still finished on schedule, so you don't have to be harsh to run a tight event.

[Mark McLeod]

We used the Chesapeake field on Long Island after you were done with it. Now it's on it's way to Atlanta.
Blue 2 was indeed very, very slow to link up, and we spent a lot of effort making sure whatever team was in that spot got cabled up as quickly as the field was ready.
With that said, however, Blue 2 was not the cause of any failures during a match, and I paid particular attention to that station. That doesn't mean teams didn't blame it, because it was out of the ordinary and that always makes people suspicious and quick to blame.
The delay in linking up did finally go away when I swapped out the Blue controls for another reason.

The FMS worked every time. That doesn't mean we didn't find cause to swap out cables, have robots slow to connect initially, or pour over the field stats. With every robot failure during a match I was able to identify a root cause and have the team correct it in time for their next match. Team's were still accusing the field of course, but every one of them found what I told them to look for when they got back to their pits. It pays to follow up with each team and then stand with them the next time they have a match. Troubleshooting the field is a psychological as well as a technical exercise. It means talking with each and every team, finding out what they were doing when the robot stops moving, what they last worked on in the pits before the match. Wires pulled out when a cover was shut, batteries with bad cells signified by precipitous drops in voltage by multiples of 2, a cRIO reset itself only once, robots that ran off on their own and stopped responding to the driver, loss of power, DB9's knocked out of drive stations unnoticed, Watchdog's going unfed or worse on the hairy edge of flickering between enabled and disabled, radios going dead or intermittent during a match.

Troubleshooting is an engineering exercise and it pays off big to keep a clear head and not blame unknowns, such as the field, or assuming it couldn't be your robot. That only blinds you to discovering the cause and correcting it. It's also very important that the field crew not randomly throw out blame, but investigate everything about the field that they have control over. I stopped some of our crew from automatically blaming the radio when robots can't link with the field. If you can't positively identify a cause, even if it's by progressively and systematically replacing cables and black box components, then don't tell teams it's the fault of xxx! I worked the WPA at another regional and the field would sent robots back to us blaming the WPA. Not once was it the WPA, and that misdiagnosis undermined the team's confidence in the field personnel. We organized differently at SBPLI. Whenever a robot had communication issues that couldn't be resolved on the field during Practice Day it was just sent to software inspection. In the heat and passion of the competition analytical thought sometimes gets left behind, but that's where it serves you the most. I do still have one team insisting that that it couldn't be their wiring, because they hadn't touched it, so it had to be the field. Even though other mechanisms on their robot were operating fine and only their two drive Jaguars were giving the "no pwm" blink. They're still speaking to me only because they won :).

We didn't start a single match at SBPLI without every robot in place and communicating with the field (except for one robot who missed a few matches after they burst into flames...:eek:). We did a lot of team training throughout Friday, beginning with the queuers checking for plugged in bridges and making sure the drive teams plugged in when they were told, the field crew making sure the robots were promptly powered up, the tech crew running around troubleshooting non-communicating robots. Driver Stations were dead when they arrived on the field, but we quickly swapped them out with spares we held ready. None died during a match. That doesn't mean teams still didn't forget to turn their robots on, or plug their bridges in, or even completely forget their battery at least once. Yes, we sometimes picked up after them, but we didn't disappoint all those other team members who worked hard for this single event they're able to attend this year.
We were running 5 minute turnarounds and had to slow down to 6 minutes to give the scores time to post. We were able to deliver 11 matches and the solid performance of the field (along with terrific scorers, refs, field reset, queuers, and of course the teams themselves) is what made that happen.

[mtaman02]

Just to elaborate on what Mark has said thus far which he mostly covered everything in great detail...

As the FTAA of the SBPLI Regional we had approached a different kind of sequence then what FIRST had suggested (won't go into details on that). After we seen that we could easily shave a few seconds to a couple of minutes off on this somewhat new sequence the next thing "I" looked for was immediate connection between Robot <-> DS Robot <-> FMS DS<-> FMS. Once I got a green light on my screen that everything is linked the "tree" would also simultaneously green up. After that I started looking for Battery Voltages and Connection Stats and noted anything that would / had caused a team to stop dead in the match throughout the entire match... (some of you noticed me coming to talk to you b/c of low voltages / no voltage reading or some other form of tech advice besides what Mark would have also said)... To my understanding unlike the previous system, this system here can drain a battery well and still keep communicating but too avoid getting to that point as soon as the voltage dropped below 10 1/5 vdc and consistently dropped or steadied out I cautioned the teams to change out the battery for a charged one. With loads of help from Mark and Bharat I was able to give them an exact error that I seen whether by looking at the screen OR looking at the team and their robot themselves. They promptly went over, investigated and solved in a timely manner.

Yea we did have a robot sit dead in the water by disable and if I'm not mistaken it was a DS E-Stop error or Automatic Disable when the match started [Don't remember which one], we had hard reset the DS and Robot to try and fix this... After running a back to back match after the error had occured the team ran fine. Whether it was FMS or the Field Monitor lockup I cannot say only b/c to much stuff went on during the match reset. Aside from that the only other robot to miss matches was indeed 263 for their unfortunate burnout which was later corrected.

That's why I cannot stress it enough that when your regional is well run and is being widely talked about you really need to thank those involved =), Teams for their continued understanding and cooperation, Volunteers and Coordinators who keep the regional going on time and flawless =). I don't think I've seen any other regional work harder to ensure and achieve the multiple goals set forth other then the Championship itself.

[mtaman02]

We used the Chesapeake field on Long Island after you were done with it. Now it's on it's way to Atlanta.

Actually its on its / should be in Michigan AND THEN it goes to Atlanta =P

Some place out in Yipslanti =)

I should know I put it on the truck =P (boy did Bill have it easy that regional =P)

[AlexD744]

Isreal and Waterloo are both small events and might not have as many matchs (I'm not sure about this). If they were less matches wouldn't that mean that a few matches could sway the percentage a lot. Isn't a rule of statistics that the more you flip a coin the evener it will get. Well maybe those fields weren't "flipped" as much and it show in the win percentage. i will check on how many matches were played.