Quote:
Originally Posted by Jared
-Timertasks don't work properly if they are started before connecting to the driver station, but work if the reset button is pushed on the roboRIO. Troubleshooting this behavior is difficult, and it's never comforting when resetting or redeploying code puts the controller in a different state than a cold boot.
-Java timertask timing is worse than in previous years.
|
We ran into the first issue at CVR...the problem is that the scheduleAtFixedRate() method schedules execution relative to the timestamp of the first execution (and the RoboRIO initially assumes it is turned on at the beginning of the epoch), but when the robot connects to the driver station, the local clock is synched to the driver station time. Your code freaks out because it thinks it has ~45 years worth of work to do in order to catch up, and as a result your TimerTask hogs the entire CPU. TL;DR, never use scheduleAtFixedRate(). Thanks to Joe Hershberger for helping us to figure this out.
As for TimerTask timing being bad otherwise, this is because of some incomplete JNI between the HAL and WPIlibJ. Whereas LabView and C++ use the onboard hardware timer to generate interrupts for calling recurring tasks, the current implementation of TimerTask uses Thread.sleep(), which is quite unreliable. We would schedule 5 ms periods and get around 5 ms most of the time, but we would see several 10+ ms periods per second, and occasionally even 200+ ms periods.
We hacked our WPIlib JAR with some additional JNI to get to the FPGA timer and were much, much happier with our timing jitter. I think Tom submitted a patch to WPIlib, so hopefully this will be fixed for next year. It took us a long, long time to figure it all out...