Robot Restart and Reset Issues

[Greg McKaskle]

Jared, can you find two log files of the two states? One that is the correct procedure with the warm boot and another with the code start.

Post all three files, .dslog, .dsevent, and .pdplog. If it isn't easy to post to CD, PM me and I'll give you a place. I think they may help indicate what ran differently.

Greg McKaskle

[Jared]

Originally Posted by Greg McKaskle

Jared, can you find two log files of the two states? One that is the correct procedure with the warm boot and another with the code start.

Post all three files, .dslog, .dsevent, and .pdplog. If it isn't easy to post to CD, PM me and I'll give you a place. I think they may help indicate what ran differently.

Greg McKaskle

Currently, I've only got the log files I've saved to my home computer.

From those, I've found one sequence of events that may help.

The first log file (2015_03_01 13_06_11 Sun) shows the robot connecting while tethered (cold boot), and enabled in teleop for a few seconds to adjust the elevator. There was a significant amount of control lag here, and if we had run autonomous, we would have had a problem. The dsevents file shows that I requested robot code restart at the end.

The next log file is when the code restarts and connects while I was tethered and in line, but is saved at the school computer.

Finally, I have the connection to the field (warm boot), where we play our match and things run well. This is the 2015_03_01 13_23_59 Sun file.

It makes sense that the CPU usage is high, as the controller is attempting to run the PID and drive controllers as fast as possible to catch up.

https://drive.google.com/folderview?...1U&usp=sharing

[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?

[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?