Chief Delphi - IterativeRobot Race Condition

We were testing our autonomous lockin procedure tonight and noticed a pretty bad race condition within the IterativeRobot class.

Traditionally, our lockin procedure consists of switches at the driver station to select the program to run and a lockin switch to confirm the selection. If the switch is set to "unlock" we will run our "sleeper" program in which nothing moves. If the switch is "locked" we will run whatever program is desired.

The lockin function is called within DisabledPeriodic and has the following flow

Code:

if switch == unlocked

    program = number based on switches

else

    program = 0

Then, in AutonomousInit we read the program number and instantiate the correct autonomous program class

Code:

if program == 0

    prog = new Sleeper()

else if program == 1

    prog = new Program1()

else

    prog = new Sleeper() // For safety in case there is an invalid combination

With that explained, we noticed that there were times where we would take our robot from Autonomous/Disabled to Autonomous/Enabled and the Sleeper program would run even though we confirmed the program to be run when we locked in.

After investigation, we found that the lockin switch state was being transitioned from locked to unlocked within the DisabledPeriodic function. This caused our lockin procedure to set the program number to 0.

We believe that the issue is due to the fact that new driver station data is being read while we are in DisabledPeriodic and the driver station is in Autonomous/Enable, thus zeroing out the inputs.

We worked around this by limiting the chance that we'll hit the race condition by checking IsDisabled before calling the lockin function and reading the switch states immediately upon entering the function (we were doing this from the start).

If this can be fixed within WPILib we would really appreciate it. Until then, teams should be aware of this situation and guard against it.