Call to DriverStation getAlliance() appears to have returned ::INVALID during command initialize() during autonomous?

[sataylor000]

My team ran into an issue at the Bedford NH district event yesterday that is either a subtle bug in the DriverStation query of alliance color, or (more likely) is a Java programming error on our part.

Quick summary:
We have code in the initialize() function of a Command (for driving) that queries the DriverStation for the alliance color (because of the mirrored field this year). We use this to invert our turn directions based on the side of the field we are occupying. Essentially, the autonomous is coded assuming the red alliance, and we invert the direction if and only if we are on the Blue side. But once in a while, we end up running the "red" code when we are on the "blue" side of the field. Given that we only invert if the return type is Blue, it is likely (though unconfirmed) that the call returned ::invalid and we basically fall through and behave as if the response was Red.

More details:
Most of the time this code has worked fine. But, we hit two cases this weekend where we are on the Blue side and the code ran the Red routine. We don't have a ton of debug information, but here's what we have tried to rule out:

1. We have freshly booted code before the match (we power on both robot and the driverstation laptop just before going on the field, so there is no stale state anywhere on either end)
2. The first time we saw this, we had queried the FMS system in the CONSTRUCTOR of the Command object. Assuming that we might not have been connected properly to FMS (though this apparently worked the majority of the time), we moved the code to the initialize() routine, which is only called after we have started the Autonomous routine and thus MUST have connected to the FMS. We still had a failure in a subsequent match of the same nature.
3. When trying to reproduce in the pits, we used the pulldown in the DriverStation to select an alliance color/position and run the autonomous routine repeatedly... sometimes rebooting robot code between autonomous code runs, and sometimes not (just disabling and re-enabling). We hit one case of this reversed behavior in the pits, and the live console log file showed the getAlliance() call returned ::Invalid for that case... and this is without the interaction with FMS itself. In this particular case, we were tethered to the robot using a USB connection directly to the RoboRio.

We have our code up on GitHub, so if someone believes this is a user code issue, I'll be happy to point to our routine if the programming error could be pointed out. In a nutshell, the basic invocation in initialize() was this:

	// All program control assumes that we are the RED alliance (boiler is to the drivers' right).
	// If we are the BLUE alliance, angles and crab need to be negated! (Unless we are centering on a gear, of course)
	if (DriverStation.getInstance().getAlliance() == DriverStation.Alliance.Blue)&& (!Robot.gearVision.isVisionEnabled())) {
		System.out.println("DriveWithProgram thinks alliance color is Blue");
            // Invert our turn directions if we are on the Blue side of the field due to mirrored layout
		m_turnAngle = -m_turnAngle;
		m_crabMagDir = -m_crabMagDir;
	}
	else {
		System.out.println("DriveWithProgram thinks alliance color must be Red");
            // No change to turn directions because code is written assuming Red alliance...
	}

[333fred]

@Kevin-OConnor, seen anything like this before?

[ThadHouse]

This seems like a bug in dependency, since we just return the value straight from netcomm.

[ThadHouse]

Has anyone seen this issue again? Unless it shows up again, I'm inclined to close this, as its definitely nothing on our end.