Adis 16470

Our team was trying to configure and use our ADIS 16470, but we found a few issues. We used the sample Java code on Github. The data light does not turn on after the deployment of the program; the checksums are off about a few thousand, and the gyro dt drops down to zero when we turn off the checksum check (The code is supposed to output “Invalid checksum”, but we made the if condition always true, such that it will always output data regardless of checksum). We do, however, receive a few seconds of useful data before it dies. Our WPILib has been updated to 2019.4.1, and our image is 2019 v14.

We’ve been working on this since the beginning of build season and we’d appreciate any help on this topic. Thanks for the help!

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 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.

  1. Our vendor library is updated to 2019-r1, which is the linked version on the Github repository for the ADIS 16470 driver. This was our implementation before we modified the vendor library:
  2. This is our modified vendor library (the modifications are described in the file):
  3. The x-axis is the increment in time in which the gyro outputs data every time, which is usually 0.002s, however, it may not be precise as we did not procure the timestamp from the RioLog. The downward trend is normal, as we were physically move the robot manually before dt dropped to 0.
  4. We do not have data on CPU usage at the time, however, it was not too high (less than 80% most of the time).
  5. Yes, we are aware that the data is wrong and invalid when dt drops to 0, which is the problem. It is the cause of the straight line on the graph.
  6. Offset calibration is ran before any data spewed out.

Thanks for the help again.

Edit: the time increment is actually 0.002 secs, not 0.02 secs.

It looks like 2019-r2 adds the ready light and fixes a checksum issue, but there was not a new vendor library published for that version.

1 Like

Yep, Joe is right, although that bug applied specifically to LabVIEW. I know there was an issue with the libraries for the ADIS16448 but I don’t recall how similar the two implementations are to know if that might be going on here as well.

@juchong is more familiar with the sensor itself than I am so he may be able to chime in with something.

Do you have a plot of the data that’s seen with the robot still stationary? Are you seeing any indication on the driverstation that the calibration/initialization completed successfully before the data drops out?

This java commit (post r1) appears to change the checksum code slightly.

When is 2019-r2 going to be released? From what little knowledge I have on 16448, their implementation is pretty similar.

Here is the link to the raw data of the graph from above.

Here is a link to the behavior of ADIS 16470 at rest (mostly, we rocked it only once in it).

Yes, we do know that calibration is done before anything is spilled out.
System.out.println("Calibrated now."); was called at the end of the public void calibrate() function. We did receive this output at the beginning of the Riolog, before any angle data is released. It could only be released if it ran successfully.

dt usually drops to 0 after 5 - 10 seconds for inexplicable reasons. We did not find any particular patterns as to when it drops.

@Joe_Ross You have a point. Our code was outdated in that it did not include this commit. However, this change is not in a release, nor did our library auto-update. (The json file does not autochange?)

Hello again! We tried out the new library / new content in the commit. Unfortunately, this did not resolve our issue with the gyroscope. The issue of dt dropping to 0 is still occurring after roughly 20 seconds into running. Checksum issue seems to be fixed.

We also noted a few interesting new issues: 1. The product ID is occasionally fluctuating. We have noted that in three different attempts, the product ID of our ADIS 16470 had been 0, 22, and 16982. (Only the last one is correct.) This is a curious phenomenon, as it has never appeared before. 2. The CPU usage had no direct correlation to ADIS performance. We have noted that the CPU has almost always running at 75-85%, yet the relative peaks of CPU usage do not correlate with ADIS error. 3. The time of dt drop usually appears 20-30 seconds into running, without exception.

Exact data of this series of tests will be linked in a later post. We suspect issues in the firmware, yet we have no way of confirming this hypothesis, nor can we eliminate the possibility of hardware/software issues.


I promise I haven’t forgotten about this issue. Still trying to narrow down what it could be.

I do find it interesting that the device ID isn’t consistent though. Do you have any other devices on SPI or are you using the GPIO pain labeled CS0 for any other purpose? I wonder if there might be some other interference from something else garbling the signal.

Well, we don’t have any other devices on the Rio, so interference from pins is not possible. The ADIS is the only SPI device on the Rio.


We have tested the new ADIS 16470 chip on our robot. (Thanks for the chip!) Unfortunately, the issues still persisted. Most notably, we find the symptoms of the gyroscope as 3 main issues:

  • Incorrect device ID
  • Invalid checksum
  • dt=0.

We speculate that they may be caused by the same source of error.

Our first test ended in failure when we first tried to read data, using the original library. The new ADIS gyroscope is not found. Upon further investigation, we found that the product ID returned by the gyroscope is 88. In the next attempt, it returned 114. The source code registers the correct ID as 16982.

After bypassing the ID check in our (now modified) library, ‘invalid checksum’ was the next error that showed up. In two more tests, we output the values of the checksum to the following files: Test2.csv and Test3.csv. We observed that the calculated checksum is always incrementing, while the IMU checksum is generally constant.

After bypassing the checksum, we found that dt=0 is still occurring, as observed in the clip attached (smartdashboard recording). In the 4 seconds, we were actually moving the robot on the Z-axis. However, not only did the gyroscope reading remain unchanged, dt was at 0.0 most of the time, while occasionally jumping up to 9.7E-5.

We have compiled a number of different possibilities of the source of error. These possibilities are not equal in likelihood, however. They are merely our speculations.

  • Hardware:
    • Incorrect installation procedure
    • Damaged chip
    • Damaged RoboRIO
    • Bad Chip/Board design
  • Software:
    • Outdated driver/firmware (ADIS library, WPILib, RoboRIO image)
    • Algorithmic Error (Checksum)
    • High CPU usage/Interruption (*CPU usage is still never lower than 65%)
    • Corrupted Buffer

Software Versions used in the tests:

  • WPILib: 2019.4.1 (Java 8)
  • Driver: 2019-r2 (modified for debug)
  • RoboRIO image v14

Please review the data provided.

Thank you for your time.test2.csv (44.1 KB) test3.csv (49.1 KB) recording-20.27.47.sbr (10.6 KB)

Unfortunately I’m a bit stumped at this point. The new chip we sent has never been used and was tested before assembly on the board. I haven’t seen any other teams receive the errors you’re seeing, and the fact that the product ID is changing tells me it’s likely something is potentially wired incorrectly. Have you tried multiple Rio units? Outside of that, I’d make absolutely sure there is nothing interfering with the connection (metal shavings, etc.) or the code.

One other thing to try is if you have one of the ADXRS450 small boards around, try using one of those since it uses the same port. If that works okay, then there may be something software wise that’s not working okay. If it doesn’t, it’s likely something to do with the roborio or physical connection to the PCB.

I had another team experience a similar problem to yours recently. They were able to fix it by doing a full reinstall of LabVIEW and wpilib and that fixed their issue. Can you try this as well and let me know if it helps?