[gnunes]

I will be very sad if this thread ends like this, because I don't think the the problem is resolved. It is true that we made it to the Lenape finals (where we were crushed by DuPont Engineering), but we did so for two reasons:
1. The absolutely absurd ritual of never recompiling the code as described in my first post.
2. Exactly BECAUSE of the while loop in Teleop that Greg objects to.

We know that you are not supposed to do that, and at our first competition we didn't. But the actual reality of communications on the FRC field are such that we had a totally un-drivable robot: the robot stops responding to the controls because it stops getting packets. Then they all arrive, and the robot leaps ahead, and extra far because of all the joystick action the driver made when the robot stopped responding in the first place. It's a mess. But put your Teleop in a while loop, and all those problems simply disappear.

I am convinced that our corrupt data problem is a completely separate issue. Unfortunately (from this perspective) we can't try to resolve this on the actual robot. But we have a second cRIO (both are the old 8-slot versions, at least 3 years old, but probably more), and I am going to load the code onto that and see if I can reproduce the problem. I will definitely be taking the wait out of the loop that receives UDP packets. I see why that could be a problem.

I like the idea of some kind of stack overflow or memory violation causing the corruption. Is it possible for my code's to get "out of bounds" and compromise the deployed code? This seems unlikely to me, but it would explain the need to redeploy between every match...