Robot disables immediately upon enable

While at competition and with a radio flashed for competition, when connected with an ethernet cable, the robot sometimes immediately disables itself a fraction of a second after you enable it. Restarting driver station fixes the problem, but it would be really bad if this happened in the field. Is there a way to prevent this? Driver station is 17.0.1 and computer is on Windows 10.

I have been having the same problem, usually after the computer goes to sleep and then wakes up with DS still running. Restarting the DS is the only way I’ve found to fix it. This would happen to me when connected via USB, Ethernet or wireless to a practice radio in our shop.

I’ve had this problem too. Does your driver station also e stop the robot after several tries to enable it?

I’ve seen this happen and it seemed to be linked to a sticky enter key or spacebar. We were able to fix it by tapping those keys a few times. You can tell if this is the issue if you turn on errors +warnings on the log messages and see continuous messages saying the robot is estopped.

Haha. This is funny. This just now happened to me, and I checked the warnings. Continuous spacebar estop. I pressed spacebar once, and the robot enabled just fine. My computer is relatively new, and the keys never stick, but somehow it was sending space commands. OP, this is your solution.

When I had another team looking at our code, that started happening. My computer is just over a year old and not prone to any kind of key sticking. I wonder if this is a bug in the software?

Thing is, when we used the team computer for a few minutes and then switched back, it worked perfectly fine without us doing anything.

we’ve had something like this too, and we also did the switching computers thing. I’ll have them check the logs next time it happens.

This fixed it, thanks! Our laptop is pretty new, so I’m pretty sure that the key is stuck in software, not hardware. Hopefully this gets fixed in the next Driver Station update.

Yep - same exact problem seen at the Troy District. Freaked us out in the middle of cheesecaking a climber. Closing and reopening the driver station fixed it - it’s definitely a code problem and not a hardware problem.

Just had this happen at the Hartford district. Freaked out for awhile, but I think we fixed it by restarting the Driver Station. Just to be safe I would always tether your robot before a match (you already should be just to fill the compressor anyway), and then don’t put the computer to sleep between then and the match. This also helps with various SmartDashboard bugs.