Hi, I'm not sure if this is the correct place to post this issue, but I couldn't find a contact email for National Instruments technical support for the off season. If this post doesn't go here, please let me know so I can remove it!
Last Saturday, during a demo of our robot at an outreach event, the robot drove in reverse at full speed without responding to drive input. It crashed into a stand just next to ours but continued at full throttle until it was turned off. We know this because the driver station logs show an increased current consumption in the PDP channels corresponding to the drive motors, as well as a voltage drop from the battery. This all occurred after a couple of seconds where round trip latency increased (but not to a value at which the robot shouldn't have been able to communicate) but the great majority of packets were dropped.
We've already verified that this wasn't a coding error, nor a CAN bus error, nor a driver error. I've attached the roboRIO logs in case someone could check them out and see if the culprit was our roboRIO or not.
Are you using the safety setup for the motors? If those were left in the code, I'd expect the code to shut the roboRIO down if it wasn't getting any new values.
I can take a look at the logs. But, I'd want to get an idea of what you're doing first. I'd also want to know what we've done to verify this wasn't a coding error, CAN bus error, nor driver error. If we're thinking this is a roboRIO error, we're stating it is stuck sending out the voltage for "drive in reverse at x speed" electronically. That's something we can test. But, it's also something that's less likely than one of the other options. If we understand the troubleshooting steps taken to this point, that makes it easier to look at the big picture and try to help focus attention where we can find the most gain. It's quite possible something went wrong with the roboRIO and we'll want to focus our attention there.
Thanks for the answer BoKnows. The code uses a DifferentialDrive, which activates the safety setup with a 100 ms timeout by default. We've also verified that the PWM cables to the SPARK controllers are plugged in correctly. The issue presented itself again on Wednesday. I believe the fault may either be with the roboRIO or with the computer running the Driver Station software, due to the fact that motor safety is on. I'll try to get the logs from that driving session to see if the same error with dropped packets occurred.