ADIS16470 Not Working While ADIS16448 **DOES**


#1

Exactly what it says on the tin, when I change my imports to adis16448 and plug that device in to the MXP port, I get proper outputs from everything. However, when I go back to the adis16470 (and change nothing else) while plugging that device into the SPI port, I see a power light on the 16470’s board but that’s it. I get zeros for output on everything. If I need to, I can switch back to the 16448 on our bot but I wanted to move to the 16470 for its size.

Thanks for any help I get with this.


#2

You say:

Are you changing the port from SPI.Port.kMXP to SPI.Port.kOnboardCS0?


#3

Is the port handled by the driver because I’m not directly touching that in my code at all right now? I am changing the import from “import com.analog.adis16470.frc.*;” to “import com.analog.adis16448.frc.*;” and back everytime I change hardware.

I’m also changing the definition of the IMU from the 16470 class to the 16448 class and back when I change hardware.


#4

If I’m reading this correctly, you are creating the gyro with

ADIS16470_IMU(Axis yaw_axis, SPI.Port port)

Since this gyro is plugged into the top SPI port on the Rio, you will need to specify SPI.Port.kOnboardCS0.

I expect when using the MXP gyro you used SPI.Port.kMXP?


#5

I’m creating it using the empty constructor
chassisSensorsIMU = new ADIS16470_IMU();
since that’s what was in the readme for the driver. I’ll try explicitly defining its port when I get my hands on the robot again tomorrow though. (Our build group is spending most of today finishing our elevator.)


#6

Do you only see a Power light on the ADIS16470? Or does the “Ready?” light also turn on? If the data ready LED doesn’t light up you might have it plugged in slightly offset, although I think on the SPI port that’s actually harder to do than on the MXP port. Are you using the x/y/z funtions or are you trying to use the pitch/roll/yaw functions? Pitch/Roll/Yaw won’t work with the ADIS16470 since it doesn’t have a magnetometer unlike the ADIS16448.

Also, when using the explicit constructor, you should not define a yaw axis, as the 16470 does not support AHRS like the 16448 for the same reason. There are other more in-depth user guides at wiki.analog.com/first that explain this a little better.

@juchong might also be able to help out better than I can. I can also get one of the programmers on our team to look at it since he helped us write some of the libraries if you can share the relevant code somewhere.


#7

You’re right, I’ve never seen the “Ready” light on the 16470. However, I have made sure that it’s not offset in its port at all. I am using the x/y/z functions for the 16470. I’ll keep the constructor information in mind for tomorrow when I’m with the robot again.


#8

We are having the same exact issue with ours. I have been trying to troubleshoot the issue with their tech support but it is 4-5 days before I receive a reply, and then they ask something trivial that I already answered, so I have to answer them again and wait.

I’ve given up all hope for it, and I’m moving on to greener pastures, like a $35 IMU that actually works from Adafruit.

I do plan on revisiting this issue later in the semester, but for right now I have spent entirely too much time on a lost cause. If you figure this out let me know, and I promise to do the same.


#9

When you say you contacted tech support, did you contact FIRST or Analog Devices directly? The main/general support lines at ADI aren’t extremely familiar with the FIRST Choice boards since they aren’t formal products, they’re made specifically for FRC and FRC alone at this point.

@juchong might be able to provide more help than I can since he designed the board. I do know that my team has theirs working with no issues. Is the connector in the back loose at all, or is the IMU loose on the board? Do you get the driverstation message saying the IMU is calibrating or is there no response at all?


#11

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

Edit:

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


#12

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.


#13

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.


#14

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


#15

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.


#16

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.


2019 Team update 15
#17

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


#18

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.


#19

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


#20

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.


#21

@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