Wierd roboRIO lag spike

[abraker]

Hi teams!

We are trying to debug encoders to get an accurate reading, and determined that some sort of lag spikes happen randomly. I stripped the loop so that it only checks for a raw value (for debugging purposes), and stops the motor when the value is >=1440 (360 deg rotation using k4X encoding type) and prints the number of milliseconds it took. Most of the time it runs for ~630 ms, but when the random lag spike hits, it runs for anywhere between 700 ms to 800 ms.

Our loop:

t1.set(0.15);
t2.set(0.15);
while(isAutonomous() && isEnabled()){
   if(encoder.getRaw())>=1440-56){  // it overshoots everytime, so -56 to compensate
      t1.set(0.0);
      t2.set(0.0);
      clock.stop();
      SmartDashboard.putNumber("Timer: ", clock.get());
   }
}

[Joe Ross]

Does the driver station log show anything when this happens?

[abraker]

Where do I find the log files?

[Team3266Spencer]

Where is this code segment located?

[abraker]

inside

public void autonomous()

the logs just read "Warning" and "WARNING" messages and nothing else

Edit: The warning are just for events like Driver station loosing communication, and other network communication events probably from reloading the code.

[Team3266Spencer]

Try putting a

Timer.delay(0.05);

in the loop. That will reduce the load on the roboRIO.

Edit: Sorry

Timer.delay(0.005);

is what I meant to put, 50 ms of delay is probably extensive.

[abraker]

When I put in the timer delay, it's not updating fast enough and overshoots inconsistently.

EDIT: I tried the 0.005 timer delay. It's more consistent, but still hiccups. Every 6-12 times we test it, it overshoots by a lot, somewhere from 100 ms to a second longer overshoot.

[Team3266Spencer]

When you say it overshoots, are you saying the encoder data is correct but the motors do not respond until 100 ms after they should have stopped?

[abraker]

Yes the encoder data is correct, and yes the motor randomly stops later than intended.

[Team3266Spencer]

I don't see any reason in the code for that to happen. I would ensure the encoder is providing proper feedback, maybe adjust oversampling rates, etc. You should also try using a PID loop and see if smarter code can compensate for the lag.

[abraker]

Note that it happens randomly. Most of the time it does a beautiful 360 and is deadly accurate.