Sudden loss of control, upon resume Controller Ports were shuffled

At the beginning of Stemley, our robot was behaving normally. We play Quals 2 without issue.

In Quals 7 is where misbehavior begins. Auton went weird, but we root caused it to a broken sensor in the coral mech.

Field clock 1:09:
Halfway through teleop, the driver swings the robot around to the back of the reef, and suddenly, the robot stops responding to driver input. I find it unusual that the robot didn't properly align to the reef given our in-season driver is on the sticks, but I'm not convinced it is related.

Field clock 0:52
20 seconds later, control is restored. The drivers controls now manually operate the arm, which is a behavior bound to the operator's controller.

This entire time, the RSL is blinking consistently (Seen just above the FIRST logo on the scorebug). There's no sign that it ever disabled.

After the match, the team took the robot back to the pit w/o restart to replicate. They were able to replicate the loss of control across multiple driver stations (including loaners), across multiple controllers, across power cycles.

Another symptom observed by those in attendance was that the SC's internal storage had reached 50MB remaining. It is unknown if it had been like that for some time, or if this just occurred.

The resolution to this issue was to re-deploy code.

Video: https://youtu.be/wlQgRg98SpY?si=hSFOWLQAol9_Zesm (1:25 is the incident)

Canbus logs + Wpilogs for this incident are lost. I will be getting dmesg logs this week.

Start with the linked video at 1:25 and the incident timeline, then review the dmesg logs once they are provided alongside any available CANbus and WPILogs. The issue mentions reproduction across driver stations, controllers, and power cycles, with re-deployment restoring control; done would be identifying a reproducible cause for the controller-port shuffle.