[pavie]

Also tried VERY hard not to jump into this, but some worrisome ideas are being tossed around...

Our team has observed and experienced multiple FMS failures throughout this season, very similar to what occurred in St. Louis (not just during the finals). It's highly likely that some component(s) of FMS other than robot hardware or software are causing it to fail.

The general technical requirements of FMS (explained in multiple post before, so I won't repeat them) are WELL WITHIN what WiFi + basic TCP/IP networking can handle, with all necessary access controls and bandwidth allocation limits. There is certainly no need to even consider switching to alternative radio technologies (we'll all be wishing to be back on WiFi in no time...:-).

There are two key issues:

1. As far as networking setups go FMS is fairly simple (not trivial, but for a truly competent network architect it is pretty pedestrian). The amount of traffic is also relatively trivial (compared to a commercial environment, not a home router with an XBOX or two). All FMS traffic should be 100% logged for post-mortem analysis. Again, it is well within technical capabilities to do so. The real challenge lies in the availability of people/tools capable of analyzing that data on the spot and diagnosing the problem.

2. Consumer-grade wireless networking devices have NOTORIOUSLY bad firmware. They are built for "easy setup" and "check box features" for marketing purposes, but as anybody who's ever tried any of the more sophisticated features in consumer routers (e.g. web filtering or QoS, not to mention throwing larger numbers of devices at them) knows, these features are often buggy or simply don't work at all. The usage pattern of FMS pushes the D-Link devices into areas they are not really built for and do not experience in normal consumer usage (and are therefore very unlikely to be tested/debugged/fixed - not because they're "bad" products, but because this is not their normal operating regime and their target consumers simply don't care).

It appears that FIRST will have to allocate more resources to both #1 (understanding what's going on through careful trace analysis) and #2 (creating an environment for effectively simulating worst-case game conditions and figuring out what brand of equipment satisfies those requirements or how to configure it to avoid pitfalls). The solution is unlikely to be "build custom hardware or firmware", because statistically it's much more likely to be even buggier than any widely-used commercial solution, not to mention economic (non)viability of that approach.

I suspect that there may be vendors willing to hep out with both #1 and #2, but the biggest challenge may not be technical but human (relinquishing a bit of control and allowing another party to step in).
Broken code is usually easier to fix than bruised egos :-).