[Greg McKaskle]

I marked my comments with **.

a) comm data from the DS is latched. This pushes more code out of TeleOp and nto PeriodicTasks, which seems like a good thing

** During autonomous, joystick and cypress values are latched to retain the last value of the disabled period. Additionally, it is possible to read joystick and other data multiple times from anywhere in the program you want. To me, this doesn't push code out of teleOp, but it does allow you to place it in Periodic.

b) The robot project remembers too much - on the Dashboard in Test mode, I saw old and new motors after I had changed the names. Blasted the build directory, old refs went away.

** SmartDashboard doesn't have a way to delete variables, so if you were to leave it running and change the robot code to have new SD variables, it would show old and new until you restarted the dashboard. But there shouldn't be any need to rebuild or blast.

c) I see good axis data (after eliminating the globals) going into WPI Arcade Drive, but the wrong stuff out. I am beginning to suspect that Arcade Drive and Tank Drive cannot coexist on the same hardware connections at the same time. Tomorrows testing will probably reveal that ya cannot switch between Arcade and Tank on the fly.

** I still don't understand what was wrong in the first place. Globals are thread safe and are perfectly fine for asynchronous transfer of data provided you don't cause your own race condition by having multiple writers that aren't coordinated. Arcade and Tank simply perform different math on the axis before updating the motors. Plenty teams use tank for TeleOp and Arcade for Autonomous. You should be able to open a 2 or 4 motor DriveSet and use either arcade or tank on it at will. They have no effect except to update the drive motors.

Greg McKaskle