We’ve recently started having this problem where the cRIO connects to the driver station - we can ping it fine - but when we go to Enable it, we encounter some issues:
The driver station indicates that it’s enabled
The compressor doesn’t turn on, and no user messages appear
After a few seconds, the driver station loses communication
During this time, however, the battery voltage is displayed correctly
When we try to ping it while the communications seem to be down, it times out for a bit and then comes back. We concluded that this is because the cRIO reboots whenever Teleop is started. Even worse, however, is that this behavior is completely inconsistent - sometimes when we hard reset the cRIO, we have this problem, and sometimes we don’t. We’ve tested it further and found that the problem seems to happen in the exact same way regardless of how we’re connected, wireless or tethered. We can’t find anything in our code that would cause the cRIO to reboot, and we even tried reverting to a previous version of the code that definitely worked and we still had the same problems. We got the most recent v28 image and the latest Windriver update – no luck.
I’ve posted our code to a pastebin, hopefully someone here can help us out.
Are you using the M1011 camera? It seems that the C++ camera stuff has a long-standing bug that is hit way more often with the M1011. The Python thread talks about a fixed version. If you do not init the camera and the problem goes away, that would be another clue to suspect the camera code.
If not, try to connect the serial cable or netconsole and view the output to see why the cRIO is resetting.
We are using the Axis 206 camera, although it isn’t connected yet. At the moment the problem seems to have gone away, although we have no idea why – which is very worrying. When it comes back up I’ll try commenting out the camera code and seeing if it works better.
Have you checked your power connections? We had a similar problem where everything looked fine when disabled, but we lost all comms with the digital I/O. I’d check there first before looking for something more complex.
Another issue we found today at a local scrimmage was that if your stop button is loose, the tiniest jostle will disable the robot. I would not imagine that this would cause communication to be lost, but when we had teams disable the stop button from the diagnostics tab, the problem stopped occurring. Some teams were experiencing communication lost though and others weren’t, but the stop button seemed to fix both for some reason.
The whole problem disappeared until today, and now the cRIO is just rebooting whenever it feels like it, regardless of whether or not there is communication. The RSL is staying in a steady on state, even while the cRIO reboots.
We really have no idea what’s going on at this point – the frame isn’t shorting to the cRIO. One possibility is a bad PDB, but since this is a new one it seems very unlikely.