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

  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: https://gist.github.com/balaji-venkatesh/8e6b60402d0cf63c5cb8d18c05150d2c
  2. This is our modified vendor library (the modifications are described in the file): https://gist.github.com/PCModeActivate/5ea62d85c74c09e4d9b38a8826461e2a
  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. https://github.com/juchong/ADIS16470-RoboRIO-Driver/commit/86981e6326749414ef5f8780a9363941591a3f69#diff-93f725a07423fe1c889f448b33d21f46

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.

Thanks!

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.