Consistent robot flicker every 64 seconds

[Jared Russell]

What language are you using?

Could be garbage collection.

[geomapguy]

Originally Posted by Jared Russell

What language are you using?

Could be garbage collection.

I think C++

Wind River

[k4mc]

Perhaps you have a memory leak that is causing the processor on the cRIO to reset every 64 seconds? That would explain why you don't loose communication but everything else resets and could be likely given C++ doesn't have a garbage collector.

You could at least easily test if this is the issue by downloading sample code onto the bot and waiting 64 seconds.

Edit: I just noticed you said that sample code removes the problem, so I now highly suspect something in your code is periodically crashing. If its not a memory leak, you could try first uploading an empty file and slowly adding one class/file/functionality at a time to see which part is causing the crash.

[Jared Russell]

Do you happen to have a 16-bit unsigned int that is counting milliseconds?

[Greg McKaskle]

If the flicker is short, this isn't caused by a crash or reboot. I agree with Jared that something in the code is probably overflowing.

Greg McKaskle

[E Dawg]

I concur with the above. Go through your code and make sure that there are no overflow warnings (hopefully WindRiver alerts you to that).

[MamaSpoldi]

Check the NetConsole output. There could be helpful messages being printed there that could point you in the right direction.

[William Kunkel]

Sorry for not responding quickly. We're using C++, and I'm compiling with -Wall -pedantic -Wextra and not getting any warnings or errors. I agree that it's probably an overflow error of some sort, but 64 seconds seemed like such a specific number that I was hoping it might be something in WPILib. There is no output over netconsole. Looking at the DS Log Viewer, there seem to be spikes in dropped packets that correspond to the flickering.

[PandaHatMan]

Where is your D-Link on your robot? Is it close to any noisy circuits?

[William Kunkel]

Our D-link is pretty isolated. I don't think it's the problem.

[Greg McKaskle]

Does the 64 seconds hiccup go away when disabled, if you stay in auto for 64 seconds, or in teleOp. If not, then what of your code is running in all of those cases? Start disabling things a chunk at a time. Use your intuition as to what is more likely to be responsible, but if you have no guess, just use binary search approach. Carefully take half your subsystems out of the system. Did the problem belong to the ones that remain or the ones you took out. Iterate on the right half until you identify it.

Do this in an experimental branch of your code, don't submit things or lose work doing this, but this type of debugging exposition is a very valuable skill in all forms of engineering.

Even if the issue is in WPILib, it may well be due to how your team is using it, and this narrowing of the root cause will be helpful to the people who will debug it. But there is a good chance that you will discover the bug yourself if you take this approach.

Greg McKaskle

[PhilBot]

Hi

I just posted a similar issue and got pointed here.

See my post:
http://www.chiefdelphi.com/forums/sh...d.php?t=127469

I've pretty much determined that it's related to the PC running the driver station. It's a new HP convertible laptop running Windows 8. My other personal Windows 8 laptop does NOT exhibit the problem.

What laptop are you using, and have you tried a different one?

Phil.