Comments/Complaints on NI control system

[apalrd]

Comments/Complaints/Annoyances of NI . I am not trying to complain, but it seriously bugs me when there are 10 minutes to get ready for the next match and I have to boot the robot, tether, download new code, reboot it,test it, and change a battery and possibly bumpers. The NI/WPI code dosen't totally suck, but it has many issues that make it clear that the author of the code obviously has never been on a pit crew at a FIRST competition. They have no idea what sort of timing pressure we are under, and I am sure they would have designed their software differently if they did.

I. Timing:
A. Boot-up: The old IFI system could boot and establish radio communication un under 5 seconds. The new system takes aproximately 1.5 minutes to establish communication, begin code execution, and be ready to use.
B. Code: The Old IFI+MPLAB system could build,deploy,and reboot in under a minute. The new system takes aproximately 2-3 minutes to do a full build, plus another 2-3 minutes to download, plus must completely reboot, which is another 1.5 minutes.
C. Network delay: The old IFI system had a simple processor on the OI communicating over 900mhz radios directly to another simple processor, with one level of communication via RS422. The new system has a PC running software, communicating via Ethernet to the FMS, which is communicating wirelessly to the robot, which is translating it back to Ethernet, and then unbundling the giant data packet. This leads to much hetwork delay, as the entire alliance station must share a single Ethernet line.

II. Operator Interface:
A. Boot times: The old OI could boot and establish comm in 5 seconds. The new system must do a full boot, plus run several large applications which take a long time to load. If you have to reboot your operator console on the field, you are seriously screwed.
B. Cypress board and related communication: The cypress board runs on 3.3v which is annoying since everything else runs on 5v. In addition, should the Cypress board loose connection, the Classmate will continue to send old data to the robot, making it impossible to detect the loss of the box. In addition to all of this crap, booting up the Classmate while connected to the FMS will lead to a loss of the Cypress board, which is only fixable with TWO reboots of the classmate, meaning teams faced with this must choose between risking it and possibly not playing because it took them too long to setup, or not having their Cypress board. On Friday of our first district we encountered this scenario twice, and went without the Cypress board.
C. FMS Lockout: On the old IFI system, removing the Competition cable would lead to a robot that would be happy and ready for use. Now, after connecting to the FMS, the Classmate must be logged out and logged back in (to re-launch Driver Station) which takes too long.

III. Radio communication:
A. The IFI system had RS422 radios that communicated on 900mhz on a DEDICATED CHANNEL!! The new system shares bandwidth between teams, and we have found the 802.11 communication to be unreliable during matches, although that could be related to all of the FMS problems at Kettering this year. In addition, on loss of the radio, you are screwed for the rest of your match. If the IFI system were to hang and loose comm, it would reboot in 5 seconds and be happy again.

IV. Robot Processor:
A. The old IFI processor had a PIC which was powerful enough to do complex things without using much program space at all. The new system has a giant heavy cRio with a 400mhz PowerPC which has far more power than we could ever possibly need, like trying to gently tap something with a sledgehammer. It's far too big for its application.
B. Download times: They suck. It takes far too long to download code.
C. Boot time: Too long. The people who wrote the code that runs on boot up obviously have never been on a pit crew and had to reset a robot in only a few minutes.

V. LabVIEW:
A. Probe things while the code is initializing: This causes a LabVIEW crash which is really annoying. Same with downloading before the already-deployed code initializes, it will lock you out and you will have to reboot the robot, which is also really annoying.
B. Build times: Really annoying again. We have encountered many instances where we cannot fix a small code issue because that would require waiting 10 minutes to boot the robot, build, download, and reboot again.


Anything else?