[Greg McKaskle]

A couple observations:

A voltage sag that reboots the cRIO should look almost identical to pushing the reset button on the cRIO. Forty seconds seems way too long for the cRIO to reboot, load user code and start driving again. Sometimes more than one device will reboot.

The default voltage monitoring of the battery is sorta slow and doesn't have any logging or history. If you are using LV, you can open up the Start Communications VI, scroll to the right and find the code that reads the analog. You can either change that to run faster and publish the value, or you can publish the refnum and read it in a periodic task or tele and monitor the batter more closely. I'm not certain where this is done in the other languages, but I suspect a similar monitor is pretty easy to add.

At events, it is pretty common to see reboots attributable to each type of fault. Some are due to exposed wiring at the cRIO or PD that shorts when a bump shifts wires on the robot. Some are due to opened circuits due to a loose crimp or connector and shifting wires. Some are due to sagging voltage often made worse by wiring layout or gearing and tire choices. Some are due to code issues.

Robots that stop moving, but don't reboot are another matter and are typically either code or a radio issue with a cable or a switch/button being changed due to movement on the robot.

Obviously there are lots of other failure types, but these are the ones that i've seen most often with robots that move for awhile, but then stop entirely.

Pure speculation leads me to believe that motor shorts may contribute to some of these this year.

Greg McKaskle