ADIS16470 Not Working While ADIS16448 **DOES**

We seem to have the same issue.

  • On the v13 Roborio image and the v6.0.0 firmware (we even reflashed once with no avail)
  • WPILib is on v2019.3.2 (extension + gradle is updated)

getAngle() getAngleX() getAngleY() and getAngleZ() methods always gives us 0.0

We always seem to get the Power light but never the “Data Ready” light.
For some reason, the FRC Driver Station always tells us the “Lib” version is 2019.1.1 when gradle and our WPILib extension is on 2019.3.2. We have pushed since updating to 2019.3.2. I have a hunch this is related to the issue but I’m not sure what to do about it

We are using Java, using the 2019-r1 libadis16470imu library. We’re initializing the ADIS16470_IMU object with the default constructor.

Any ideas? cc: @ImAnEngiNERD @juchong


Do you get the driverstation message saying the IMU is calibrating or is there no response at all?

Never see a message like this in the console.

Is the connector in the back loose at all, or is the IMU loose on the board?

Connector is great, IMU is solid

Can you post the Rio log output or the full driver station output when prints are shown? The fact that it isn’t even calibrating is really odd.

Creating an instance with an empty constructor should set everything to default. Are you sure that you’re running the latest WPILib release? If your code is open source, I’d be happy to take a look.

@Kusha @CardcaptorRLH85 @jsmit6 are you still having issues with reading data? I’m guessing all of you are using Java?

We stopped messing with it since we were closing in on bag day. We left it off of the robot and have a test bed set-up that I can get going later today and try this again. I’ll let you know later today how I fare.

I’m sorry for not being able to respond recently but, yes. I’m still having trouble with the 16470. Right now we’ve bagged the robot with the 16448 and, since we’ve coded that one before it should work fine but…since the rules concerning cost accounting changed this year and, as you noted, these boards are only made for FRC, I may have an issue using the 16448 from a few years back in competition if I can’t figure out how much it would cost at retail.

So, to make a long story short, I’ll be back on our testbed tomorrow trying to figure out this 16470. Hopefully in time for Competition Week 2. We do use Java by the way.

@CardcaptorRLH85 @jsmit6 @Kusha I think we may have found the issue with the Java implementation for the ADIS16470 and we’re working on the fix. I’ll let you guys know when we have the fix available.

We’re also looking into this issue as well. I’ll let you know when I have more information.


Thanks for the update. I haven’t had as much time with our test chassis as I want but, I was still stumped on this one.

The fix for the ADIS16470 has been released: WPILib 2019.4.1 Update

1 Like

We discovered an issue deep in the WPILib interrupt implementation that was resolved in 2019.4.1. After you install the latest release, the IMU should work correctly without any changes to the driver we’ve supplied.

1 Like

@CardcaptorRLH85 we also have an update on the cost rules. See Team Update 15 or this post: [IMPORTANT] Updates Involving the Functionality and Legality of Analog Devices IMUs and Gyro Boards

1 Like

Thanks for the update y’all. We now get the initialized/calibration message! The problem we’re running into is that we get tons of cpu load and “Invaild Checksum” printed in the console now. Sometimes we’ll get one static angle in between the invalid checksum messages. There’s another local team that is using java running into the same issue. We tried running both reset and calibrate with no avail and we’ve tried running without reset and calibrate.

Any ideas?

The Java implementation is known to have some nasty CPU usage. A good portion of that is the handoff between the C++ code underneath and the Java environment.

We were able to get a good bit of the CPU usage down and I think the library has been updated on github and on Maven with the fix.

How many CRC errors are you getting? It’s normal to get one every few seconds or so. This is just the library throwing out data that was corrupted, which is normal. If you’re seeing no good data at all, you might want to double check your connection between the board and the RIO.

That’s where the “Invalid Checksum” errors were coming from!? This thing killed our robot at Kettering #2 and none of the CSA’s could figure out where the errors were coming from. I’ll try to figure out if we still get errors today at Gull Lake.

EDIT: I’m still getting Invalid checksums today. For now, I think I’ll switch to the ADIS16448 since I can do so legally (thanks for that by the way ^_^).

@CardcaptorRLH85 and @Kusha make sure you have the absolute latest version of the IMU libraries. We posted an update to them just this morning which should fix the CPU usage issue, and might alleviate some of the Invalid Checksum messages.

I don’t see this update on Github, where do I find it?

Ah, my mistake, the CPU usage was fixed on the ADIS16448 but not on the ADIS16470 yet, sorry for the confusion. But, since you did swap to the ADIS16448 for now, I would still strongly recommend updating to the latest library for that one since it will fix the CPU usage issue for that IMU.

I’ve included both release pages below, which will always list the latest available version for the libraries.


Thanks for all the information! I am also trying to use the ADIS16740 with my team, do you have an idea when the CPU usage update will be available for that library?

I don’t have an exact time frame for the fix for the 470 library but I will definitely post here and other places when that fix is available.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.