[Greg McKaskle]

As Alan stated, it is difficult to respond to this post point by point, but I'll try instead to get us to the productive stage of understanding what is going on and coming up with solutions.

But first, while it is natural and healthy to make comparisons to the previous system(s), let's use the correct terms. NI donates a few key elements that make up the control system, but there are many additional suppliers and developers involved. It is called the FRC Control system for a reason. Myself and other NI folks are involved in support, but we don't deserve all the credit, good or bad.

My timings are with the default code, camera to dashboard and vision processing on. Classmate was used as the development laptop.

I.A. 1.5 minutes seems long. While tethered, these are the times I see. At 8 seconds, the cRIO TCP stack is up, ping succeeds, and the yellow LED goes off. At 20 seconds, the DS Connection light goes off, meaning that the communications task is sending back Status packets as a reply to the control packets. At 30 seconds, the Robot Code DS light is good, meaning that the Robot Main is running and communicating with the DS. The odd thing I cannot explain is why the vision to the PC will often take another fifteen seconds or so to go live, but at thirty seconds, the robot can be enabled and I can control a solenoid and other I/O.

I.B. Using the Classmate as the laptop, I get a bit over two minutes to build. I really really wish I could speed this up, and traditional LV builds are really quite fast, but with the introduction of libraries, the build times went way up and haven't improved yet. In my measurements, it took about 2:40 to build with the Robot Main VI window open, but 2:10 to build with it closed. Also note that the robot isn't needed for building. If you have known changes, you can build while the robot powers up, while it is coming back from the field, etc. Once the app is built, my deploy takes eighteen seconds. This means that a boot and deploy should take less than a minute, and a reboot and test of the code should take another minute.

I.C. The DS measures the round trip time to send control packets to the robot and get a status return. The robot typically receives the packet about 2 to 4 ms after it is sent. The "giant" data packet sent to the robot is only about 1KB, mostly padded zeroes, as wifi frames have a minimum size that is larger than the packet size. This is the same technology used for Skype and plenty of other near-real-time uses. I'm not sure what speed the 422 ran over the 900MHz modems, but the N speed is likely 1000 times higher bandwidth. If you have actual measurements of latency, please share.

II.A. What is the process you are following? I'd expect that the DS would be in sleep mode which takes about ten seconds to awaken. Yes, rebooting the computer should be avoided when you can.

II.B. This seems to be the biggest issue that you faced. But for what it is worth, the DS doesn't send data if the FirstTouch board is removed. The WPI robot code that wraps the comms does return back the latest known good values. It would be possible to return timestamps or other status data if this is really necessary. I don't really know of interference between FMS and Cypress recognition. This hasn't been reported before, but it is certainly something that we'll test more thoroughly. The indication of whether the board is plugged in is the LED on the DS I/O button and LEDs on the I/O board itself.

II.C. This feature was requested and implemented in beta to provide additional safety. Since the laptops are self-powered, it helps to prevent a team from being able to drive a robot at the field until the FMS allows it. It does mean Exiting and restarting driver again, but that took 45 seconds in my test?

III. I know that the FMS does quite a bit of monitoring and logging. The 5GHz channel being used for N is not commonly used. As for rebooting during a match and being up again, I'd avoid that unless asked directed to do so by a coach or FTA.

IV.A. This system is indeed far more capable than the previous one and yet, it is one of the smallest and slowest systems NI makes. I'm pretty sure your metaphor could be used for every cell phone, laptop, and electronic device at the event. All of them were once done with less computational power, but does that make them sledgehammers?

IV.B. Since my stopwatch isn't marked with "They suck", what numbers are we talking about?

IV.C. Some people have been on pit crews, some haven't. Can you be more specific about what you'd fix first?

V. If you can describe how to reproduce the probe crash, please post it in the LV section. As for times, I know of some things that annoy me, but not in the 10 minute range. Try to measure your times rather than guess, and exaggerations cause confusion.

Greg McKaskle