Gyro 10 DOF IMU

[Bpk9p4]

Has anyone had any luck getting the adafruit 10 dof imu (http://www.adafruit.com/product/1604) working with this 2015 labview. I found a great program on how to do it on the old system (http://www.chiefdelphi.com/forums/sh....php?p=1431829) but i can not get it to work in 2015. Has anyone got it to work?

[Dexterium]

I would just use the I2C port on the rio and mess around with the settings until you get it right. Labview has built in I2C reads so with a little experimentation you shouldn't have any (many?) problems. The adafruit page states that all values can be read through I2C so it shouldn't be too difficult to get the array to populate correctly.

[Levansic]

We used a Pololu IMU last year that had the predecessor L3GD20 gyro to what is on that Adafruit IMU. It worked great! We posted our digital gyro library here last spring, here.

Unfortunately, we have not been able to get anything working with the roboRIO, and either of its two i2c ports with LabView. We aren't sure if our gyro is damaged, or if the new WPI implementation with the new roboRIO is the culprit.

We have seen that the i2c library vi's have a lot of coercion dots inside, where U8 inputs are coerced to I32 for some other things, only to be re-coerced back to U8. Also, we see that the library functions are not set to be re-entrant, so we have no idea where errors are being generated (they show up on all instances within our program for reading i2c). Because of this, my eyes are squinting at the new WPI libraries for i2c, and wondering how much testing went on before release.

[Bpk9p4]

This post might be able to help you guys with your i2c problem. http://www.chiefdelphi.com/forums/sh....php?p=1431829
i was able to get it running with my adafruit 10dof imu and it worked great

[Levansic]

Ah ha! Thank you so much!

I forgot that we had to do a bit shift on the addressing to get it to work last year. Can't wait to get to the lab to see if that's all we need to do.

This is a good change for new code, in that you can just use the address printed in the data sheet without having to morph it to what the vi expects. Unfortunately, it highlights one of the more frustrating things about the WPI library, in that it is not easy to find documentation of these changes, and the thrown errors indicate little of what is actually wrong.

[Richard100]

I scanned the Pololu specs sheets for their breakout boards for both the L3GD20 and L3GD20H, and I believe the RoboBees code referenced by Bkp9p4 should interface correctly (with either) over the I2C bus. You would just want to disable the Accelerometer and Magnetometer devices using the settings available in the IMU OPEN vi. I have not tested this so let us know how it works if you try it. Be advised the code works on the On-Board I2C
bus only, until I resolve the MXP issue.

Yes, the WPI I2C library changed this year, moving to the 7-bit address spec convention (among other things). This likely removes a barrier to success for teams attempting this interface.

[RufflesRidge]

Originally Posted by Levansic

Unfortunately, it highlights one of the more frustrating things about the WPI library, in that it is not easy to find documentation of these changes

http://wpilib.screenstepslive.com/s/...e-2014-to-2015

[Richard100]

Yes, but that information (I2C address change) on the WPI site is less than 10 days old ... 《grin》

[Levansic]

I had looked over that site in the first week, and hadn't seen that. Now I know why.

Anyway, the 7-bit address was the key for us. We got it working through the MXP port this evening, and everything looks good.