Robot Restart and Reset Issues

[ozrien]

Does this happen when tethered as well? Usb or Eth?

[ozrien]

I tried to reproduce what's in your capture, deplyed, power boot and cycled teleOpEn and teleOpDis. Screenshot attached. The +90CPU seems to drop off quickly, maybe I'm missing something.

[Jared]

Originally Posted by ozrien

So when you power boot (like in the *_06_11_Sun capture), does it hold CPU +90 % indefinitely? Or does it eventually settle? It sounds like you watched it for 20min. Does it do this everytime? (I can't seem to reproduce it).

Robot setup looks like a bunch of PWMs, a few encoders, PDP on CAN bus (no other CAN devices), and four joysticks (Logitech Attack 3,Logitech Attack 3,Gamepad F310 (Controller),Logitech Dual Action) on the DS right?

The high CPU usage happens only sometimes. When it does happen, I have never seen it go down, even after waiting 20 minutes. After reimaging, the high CPU usage went away, but it has since come back. The screenshot you've posted looks like us right after we've reimaged.

Even without the high CPU usage, the robot still has jerky movement.

You're correct about the encoders, PWMs, and the PDP, but we've only got three joysticks.

Originally Posted by ozrien

Does this happen when tethered as well? Usb or Eth?

This happens when connected to the field, wirelessly connected at home, or ethernet tethered at home. I've never tried it with USB.

Originally Posted by ozrien

I tried to reproduce what's in your capture, deplyed, power boot and cycled teleOpEn and teleOpDis. Screenshot attached. The +90CPU seems to drop off quickly, maybe I'm missing something.

This is what will likely happen to us if we reimage and try again.

[Kevin Sevcik]

Have we confirmed that the Timer.scheduleAtFixedRate() is the problem and it's running multiple events to catch up from 1970 to 2015?

If not, the easiest thing to do is add a loop counter and watch it in SmartDashboard. Just create a static unsigned int or long, initialize it to 0, and increment it every time your Timer.scheduledAtFixedRate event is executed. That counter and (maybe) a stopwatch should make it obvious if the issue is the scheduleAtFixedRate thing or not.

If we HAVE confirmed that, then we should be talking about fixes and mitigation options, yes?