Re: Einstein Field issues Handled correctly?
 

This.

Re: Einstein Field issues Handled correctly?
 

Well the only problem with this theory is that DFS is an Access Point feature. The Access Point picks a channel to transmit on based off its detection of possible interference. I don't know exactly how the FMS manages the wireless access points, but I think the wireless channels are manually selected. Even if they're not, the DFS wouldn't kick in that often, and the WiFi clients shouldn't have trouble following the AP from one channel to the next. But mostly, I think FIRST is setting channels manually so this wouldn't be a problem.

Re: Einstein Field issues Handled correctly?
 

I think only the field and game elements are pristine, and the electronics have been used at other events.

Re: Einstein Field issues Handled correctly?
 

I don't know for certain, but Einstein is a complete field and as far as I know they use that field in its entirety for those matches.

Re: Einstein Field issues Handled correctly?
 

Don't have anything to add except to say that this is not true. The problems in CT were never diagnosed. We swapped out a cRio in Houston because we saw the same thing in a practice match, and couldn't bear the thought of doing nothing, even though the cRio swap didn't make much sense. We had no problems after that swap until what you saw on Einstein.

Re: Einstein Field issues Handled correctly?
 

Bill has always implied that the emergency field in Kentucky (?) or Tennessee (?) was a total emergency field in case something ever happened to another one; otherwise it was just for Einstein. However, I would consider an electronics system that was in use for a few events to be more solid than an untested one... at least we know where and when it has and hasn't worked before.

I imagine/blindly put faith into the idea of it will be an awkward topic of discussion in a blog post from the director.

Also, while I will congratulate the teams that have one (and they do deserve it) I believe it's just as important, if not more, we solve the issues relative to the complex and mentally/emotionally taxing 4-year-old communication system.

Re: Einstein Field issues Handled correctly?
 

I agree. These communications problems are not new. They've persisted through out all levels of competition to this point.

As I've stated elsewhere when Team 11 had issues 3 times in Philly. I didn't feel that it dramatically effected our placement based on what we saw when we competed entirely free of issues at other events. By a turn of events we went to Championships anyway.

Sure there's room to argue the point. However, as long as the people are effected fairly randomly let's not forget that these folks built some really phenominal robots and we all played the same game.

Chance is always an element. Be it a bizarre unexpected balance, a sudden broken part or even a software failure. Sometimes the chance is a spectacular show and sometimes not.

As far as how FIRST handled this? Troubleshooting of this type has been limited to the events. Everything else, like this survey, is generally a collection of anecdotal evidence. I expressed my concerns about field communications before this year's first event (based on our off-season experience at Monty Madness last year...see the topic about alternate control systems) and I expressed my concerns about how the troubleshooting was pushed back generally at all events in the 2 recent years with this radio system in the other topic. I myself was spare parts at the MAR Mount Olive events and we had a few issues with this problem and despite much effort to track the only thing that helped them was driving with the camera off and hence mostly at a disadvantage. The situation was put on this path by FIRST and people close to FIRST. This was the risk at every event and every event had the same problem not just the Championship. I presume that FIRST had figured they had this problem well under control when they started Championship given the pattern of the behavior. Perhaps FIRST just felt it fair not to eliminate the problem now that it had already messed with all the events up to that point...but they did allow some replays which is inconsistent (perhaps the story changed under the hot lights). Things apparently did not work out. I saw the look on everyone's face. They don't need this topic to tell them this can not be allowed to happen again....we need quantifiable evidence not anecotes and we need it when the problems happen not after the fact when things are all apart or it's just speculative no matter who's speculating really. We as teams can't test on their competition fields; both because we don't have access to them all the time and because often the rules prohibit the effort during competition matches.

I'm sure it'll get fixed it's hard to ignore it's a priority under the circumstances.

Re: Einstein Field issues Handled correctly?
 

What I would do with the Einstein field is to run it in a Week 0 event before putting it into storage. It won't be as pristine, but you get a chance to clean it up before the big show, and you know that it worked (or didn't) when you put it in the trailer. I'd rather have it working and slightly ugly than pretty and not working.

Re: Einstein Field issues Handled correctly?
 

Another idea relating to this. Take the electronics from the most reliable field. AKA has the least comm failures throughout all the regionals. But take the carpet game pieces and field elements from the backup field. Then you have the best comms with the best looking field. The backup electronics could be used at MAR or another state district to get them ready for CMPs. Maybe not the best solution for the backup electronics but it better than them being tested at CMPs on Einstein.

Re: Einstein Field issues Handled correctly?
 

We would all also love Einstein with maybe a few short speeches.

Also, I will state one more thing before I turn off for tonight.
I came into FRC as a freshman. You know what my first memory of a regional was? Not starting play until the afternoon in 09 because the field was bugging out. You know the thing a remember most vividly in 2010 outside of our ludicrous finalist bid and the case of the missing in-game piece? Standing in queue for 45 minutes in VA while we dealt with field issues. 2011? Watching a robot get pulled off because of communication issues the field was experiencing (the station where the team was located had problems all afternoon with a variety of robots). 2012? Almost losing in the semifinals because the robots would lose communication midmatch and we would reboot midgame to stand a chance.

I know chance is a factor in everything, but when I pick up a remote, I don't plan on blowing up my TV. The chance of that happening is severely mitigated by evolved technology.

Last two matches of Logomotion on Einstein
 

Was the same system used on Einstein last year (Logomotion)? If I remember correctly, during the last two matches of Logomotion a RED Alliance robot worked in autonomous and then did not work at all during driver control. Was this a robot problem?

Re: Einstein Field issues Handled correctly?
 

The radios use a spread spectrum technique for transmitting the data at the most fundamental level. Various techniques are used to enhance the data throughput from what is achieved in the 802.11a,b,g to get the 802.11n data rates.

One of the benefits of using spread-spectrum techniques is the very high noise immunity giving a highly reliable connection. More reliable than narrow band transmission techniques. Instead of transmitting a signal over a narrow bandwidth, the information is spread over a very wide bandwidth, at a relatively low amplitude. The receiver de-spreads the received signal, restoring the original narrow bandwidth and high amplitude. Narrow-band interference sources (radar, noisy electrical equipment) would be squashed in amplitude and spread over a wide bandwidth by the de-spreading process in the receiver and the majority of the noise energy can be filtered out very simply. That is one of the reasons why this technique was used by military radios for many years before the ISM band was made available for civilian use.

Due to how the spread-spectrum transmission technique works, it is difficult to believe that only one or two channels can be corrupted for a whole match by a narrow bandwith, short duration transmission like the weather radars or wideband weather phenomena such as lightning. They ought to affect all channels in a similar way, simultaneously or not at all. The only way I can think of to adversely affect a single channel would be to jam it using a spread-spectrum transmitter set to the appropriate channel. Either FIRST missed some signal source when setting up the fields or someone was intentionally jamming. If find the latter hard to believe.

The radios are a consumer grade item but their design would have been tested very thoroughly by the manufacturer and their other customers. I would imagine that the teams experiencing trouble would have been able to check for connection before each match or they would have raised a concern and not allowed the match to start.

This leads me to ask if the FMS software that manages the robots through the 802.11n link may have some bugs in it. I am sure that the developers of this software would have tested it to the best of their abilities. However, there can be issues and conditions that only show up with certain combinations of hardware and other software. The FMS software would have far fewer users and instances of use, overall, than even low-volume commercial software so obscure bugs can be very difficult to trouble shoot and would probably require tools not available to the FTA at a competition. Perhaps the developers should visit one of the upcoming off-season events and bring all their tools and toys. That is what our engineers at work do when a customer experiences unusual behaviour that the Field Service people cannot fix.

At Alamo, one of the robots in the alliance opposing ours was immobile for the whole match leading to the match being replayed. If my memory serves me correctly, it was announced that 148 had become indicated as a no-show so their channel was shut down, rendering them immobile for the duration of the match. I have no way of knowing if our (148's) experience is at all related to what was seen at the CMP but the symptoms look similar. By the way, one of the other teams did all the scoring and handily beat our alliance single-handed :(

Re: Einstein Field issues Handled correctly?
 

Did the thunderstorms supposedly start around the same time as the beginning of Einstein?

Re: Einstein Field issues Handled correctly?
 

One other thing that I'd like to say.

Einstein this year was a minor speedbump compared to another event a couple years back. Admittedly, said event had a number of factors besides the field issues complicating things.

I would not say that we've had nothing but problems since switching the control systems/wireless. However, I will say that field connection problems seem to have become more prevalent, and if this continues to be an issue, I expect that FRC HQ will be under significant participant pressure to change something with the system. Whether it's the FMS (which was mostly reliable the last couple of years), or a "Not my system" attitude held by both teams and field crew on occasion, or the routers on the robots, something needs to be made more reliable.

With the IFI system, they could tell right away whether it was the field or your robot, and if it was your robot they'd help you find and fix the problem. I haven't seen that type of full-system support the last few years--maybe because it's a multiple-manufacturer system. The system as it is is pretty good... but with this public of an issue, it could use some improvement.

Re: Einstein Field issues Handled correctly?
 

I think this is a very plausible theory. TCP is a "reliable" protocol, which means it retransmits afet some time period if the packet is not acknowledged. However, it only does this for unicast (point A to point B comms) packets. But multicast (point A to many points) or broadcast (point A to everyone) do not have acknowledgements and don't retransmit.

Does FIRST use multicast or broadcast in this application? I don't know, but it makes some sense that they would. By using one of these, you can be sure that nobody gets started before the others, assuming everyone gets the packet in the first place.