Would you mind sharing the code you’re using? In the meantime, we have a user guide for the ADIS16470 as well as the other ADI sensor boards for FIRST at wiki.analog.com/FIRST if you haven’t looked at those already. But you’re already on the right track making sure you have the latest Rio image and WPILIB versions. Are you also using the absolute latest library for the IMU?
Also, what is the scale of the x-axis in the graph you posted? I’m assuming that’s over time, but knowing how long and when that data reading starts (is it as soon as the robot is turned on or is it right after it gets enabled, is the time window in seconds or milliseconds, etc.) will also help diagnose where things are going wrong.
I will say there was a known issue with high CPU usage with the Java implementations of the library for the ADIS16470 and the ADIS16448 related to the JNI bindings being used by Java on the Rio due to the use of byte buffers. We fixed this for the ADIS16448, but I don’t think the fix has been implemented for the ADIS16470 yet. But unless the CPU is locking up somehow, I doubt this is causing the problem.
If dt drops down to zero, then the gyro angles will not be calculated correctly. For the best accuracy, the Rio needs to know the exact time difference between each measurement since timing on the Rio is not easy to control. This is important because the ADIS16470 is a rotation rate sensor, and does not measure raw angle change - it must be calculated by integrating each of the readings over time, hence the dt term.
Looking at the data, I’m guessing the few seconds of data you are seeing might be the data being taken for offset calibration, which the library should be doing for you automatically on start-up, especially since it seems to drifts off very quickly (although again, having an idea of time scale will help determine this). This could also be a product of the dt term dropping to zero, though.