[Rusttree]

Team 4146 has experienced a very difficult problem to debug. On very rare occasion, the robot starts up in a weird state. Some systems don't respond to controls but some do. We have a climber that extends in and out automatically. When this elusive problem occurs, the arm just oscillates back and forth forever until power is cut. Upon rebooting the cRIO (without changing anything else), the robot behaves normally.

Naturally, staying true to Murphy's Law, the problem happened at a very high frequency when connected to the FMS during our competition this passed weekend.

Right now, my biggest suspect is the robot-dashboard communication. We program in Labview, so we use the WPI library of "SD" VIs to transfer data between the cRIO and the Dashboard. Our final code had about 20 or so double precision values being sent back and forth.

The reason I suspect the data transfer is because in our attempt to fix the problem, I prevented all the code in Periodic Tasks from executing during autonomous mode except for the SD comms. The problem still occurred immediately in autonomous mode. At one point, we even had our autonomous code completely disabled. So the ONLY thing running during autonomous mode (besides all of the FRC background code) was the SD comms in Periodic Tasks.

I'm curious if Greg McKaskle or Mark McLeod (or any other Labview gurus) have any thoughts on this. The main problem is the inconsistency of the problem occurring. It happens much more frequently when connected to the FMS during a match, but we obviously can't test and develop in that environment.