[mathking]

I have a plea to make to FIRST and the teams hosting off season events. Let's try to scrupulously document and analyze the problems and see if we can find out what is actually going on to cause all of the dead robots.

I was not at the Championships, but I was watching online when I could and getting constant updates from my team. And I saw some of the same issues happen at Buckeye and Queen City. It happened to us twice at Queen City, both times our driver rebooted the cRIO to restore control of the robot. Looking at what is happening, it seems to me that the most likely culprits are the Dashboard and the FMS software. I am not saying that it could not be something else, but my CCNA training says look for the most likely culprits.

Number one would be physical layer problems. Pre-2011, this was obviously the power supply. Without the voltage regulator a gaming adapter or router could easily be induced to go offline and reset, making robots lose communications for significant fraction of a match. With the voltage regulator that is much less likely.

The next most likely physical layer culprit would be interference. This could be (when we do demos at places with lots of WiFi we have noticed a tendency for robot control lag) a significant factor. But it would seem more likely to be expressed as control lagging rather than lost comms, except that the FMS might see the lag and automatically disable the robot for safety reasons. But I am assuming if this were the case the FTAs would be able to see that this was done. (Maybe this is not warranted, but in helping get the field set up for our off-season event the last two years it seemed to be the case.)

While it is true, as some have said on CD, that TCP/IP is an off-the-shelf technology not designed for FRC, it is an amazingly robust technology that passes quite a bit of data around the world. (Remember what it was originally created for.) It is versatile and powerful. Even those little D-Links on a robot can process an amazing amount of information. And when configured correctly they have no trouble ignoring what they need to ignore and recognizing what they need to recognize.

My CCNA training says to look next for the biggest bandwidth hogs, which are probably camera streams. Here I have an observation. When practicing with a robot at home, with the router in access point mode with the camera stream not being processed by the cRIO, you can view the stream on another computer than the one running the DS software with no lag. But through the DS there can be a decent amount of choppiness and lag in the video stream. If a team is processing images on the driver's station computer, rather than just viewing them, then perhaps the lag might be causing the dashboard software to do something that results in the robot losing comms. This might well be a/the culprit.

We could go on and on speculating, but I think the best hope for a solution is to get lots of eyes to start analyzing. This is where the off-season events come in. There will likely be a lot of bright, experienced people helping at all of the off-season events. Some of them FTAs and some of them not. Which may mean some fresh eyes on the problem. My gut may be wrong, but it telling me that the problem is most likely in the FMS software or the driver's station software.