MPU-9150 (I2C) with Labview

Hello everyone,

This year, our team decided to go ahead and use an extra motion tracking devide. We opted for the MPU-9150, but we are having problems getting it to work with Labview.
It is connected to the roboRIO’s onboard I2C, and we based our Labview code on this Arduino example: http://playground.arduino.cc/Main/MPU-9150

After hours of trying to get a response from it, we haven’t had any success. I’ll upload the code later today

I used the MPU-9150 a few years ago on my senior design project for college. It was a pain in the butt to get the magnetometer working. The accelerometer and gyro were relatively easy though.

Please post your code and I’ll take a look at it.

Here are the relevant snippets of code:
Periodic Tasks:
http://i.imgur.com/M3Y6zWz.png

MPU Config VI:
http://i.imgur.com/4zMf2DG.png

Read HL VI:
http://i.imgur.com/x38Qha2.png

We’ve tried with MPU address 0x68 and 0x69, but no luck so far

Can you include your I2C Open code as well (probably stuck in the Begin.vi)?

Your config code looks messed up. Why are you re-opening so many times?

You only need to do one ‘open’. The device address is stored after that.

Your config should happen before you start your while loop. Currently, you’re trying to do two things at once. Use the Error block to control the order of execution.

Comment what your config code is doing at each point.

Monitor the error outputs. If it can’t communicate, it will tell you.

Yes, the config code is really messy right now. We used the Arduino example and then made it inside LabVIEW.
All we do inside the begin.vi is open the I2C with the I2C On-board bus and 0x69 address. I’ll post the code later on today.
About the error outputs, there’s no error at all.

We also tried to clear just the sleep byte at 0x6B inside the begin.vi and then read raw values from the temperature sensor at 0x41 and 0x42 while in timed tasks, but we got no response

What breakout board are you using?

My recommendation is to keep it as simple as possible. I think reading the temperature is a good start. Don’t try anything else until you get that working.

So, create a minimum programming sequence to get the temperature. Once you get that working, start implementing other stuff such as setting the gains.

We’re using Sparkfun’s SEN-11486 (https://www.sparkfun.com/products/11486)
We also tried the temperature reading using address 0x68 instead of 0x69, but we got the same result

The breakout board has the A0 pin connected to ground, so you are correct in using 0x68.

I have no idea if my code works since I no longer have an MPU-9150, but maybe it’ll point out your problem.


MPU-9150 Read Temperature.vi (17.5 KB)



MPU-9150 Read Temperature.vi (17.5 KB)

Thanks, I’ll give it a try later today and post the results

Ok, did some tweaking and it worked. I added the gyro and accelerometer too, BUT the magnetometer is still an issue. According to the Arduino code I was refering to, as well as the GitHub example linked in the Sparkfun page, you have to open a new channel with device 0x0C, which is the magnetometer, and then set the register 0x0A to 0x01, but the issue is there is NO 0x0C device.

Told ya so!

It’s been three years since I messed with it.

So the magnetometer is a 3rd party sensor. InvenSense doesn’t make it… they just buy the silicon and wire it up inside the little chip you have, then slap black plastic and their logo on top. (I think it’s really an MPU 6050 core with a magnetometer wired up).

The magnetometer is hidden behind the auxiliary I2C bus on the IMU. You have to talk through the auxiliary bus in order to talk to the magnetometer. You can setup the IMU to go into pass-through mode.

I wish I had access to my old code (Thanks IT for deleting it).

This might get you started: MPU-9150_Breakout/firmware/MPU6050/MPU6050.cpp at master · sparkfun/MPU-9150_Breakout · GitHub

void MPU6050::getMotion9(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx, int16_t* gy, int16_t* gz, int16_t* mx, int16_t* my, int16_t* mz) {
    
	//get accel and gyro
	getMotion6(ax, ay, az, gx, gy, gz);
	
	//read mag
	I2Cdev::writeByte(devAddr, MPU6050_RA_INT_PIN_CFG, 0x02); //set i2c bypass enable pin to true to access magnetometer
	delay(10);
	I2Cdev::writeByte(MPU9150_RA_MAG_ADDRESS, 0x0A, 0x01); //enable the magnetometer
	delay(10);
	I2Cdev::readBytes(MPU9150_RA_MAG_ADDRESS, MPU9150_RA_MAG_XOUT_L, 6, buffer);
	*mx = (((int16_t)buffer[1]) << 8) | buffer[0];
        *my = (((int16_t)buffer[3]) << 8) | buffer[2];
        *mz = (((int16_t)buffer[5]) << 8) | buffer[4];		
}

You can find those register constants in MPU-9150_Breakout/firmware/MPU6050/MPU6050.h at master · sparkfun/MPU-9150_Breakout · GitHub

I’ve already got the register constants from the register sheet, but this line of code should perform all the magic:

I2Cdev::writeByte(devAddr, MPU6050_RA_INT_PIN_CFG, 0x02); //set i2c bypass enable pin to true to access magnetometer

I thought the mag was wired as an additional I2C device, and not behind the IMU.
Thanks for pointing it out!

Ok, I tested it out today, and we finally got a response from the mag.
But anither issue arised. While we can read from all the low byte registers, the high ones always return 0.
We tried communicating with the mag directly, as well as through the MPU, but it’s the same problem.
I’m not sure if we have to read each independent register and then shift the high one and add the low one to it, or if we should read the low register and ask for 2 bytes.

Sparkfun’s example code does a 6-byte burst read. I just checked the AK8975’s datasheet and it says is compatible with burst read:

The AK8975 returns a signed 16-bit integer, so negative numbers should return something in the MSB. That’s pretty easy to replicate by rotating the sensor 180 degrees.

I’m not sure what’s going on from your description. Mind sharing your current LabVIEW code?

Sure, I’ll upload it later today.
We tried to rotate the sensor all the way around, but the MSB wasn’t returning anything, and the LSB is just ranging from 20 to 50

Alright, we just rested it and we get values from 79 to -21 when rotating it a full 360 degrees. There’s another problem too, the mag returns two equal values for each orientation and it’s oposite. So, for instance, if the mag is pointing at 90º, it returns, say, 30. But if it’s pointing at -90º, it also returns 30.

Here’s the code. We are setting the mag as a slave so we can read the values from the MPU. We alsot tried reading the values directly from the mag, but it’s the exact same issue:

Periodic tasks:
http://i.imgur.com/bgHmUXx.png

MPU Initialize:
http://i.imgur.com/EbURVlC.png

Read Compass VI:
http://i.imgur.com/CWlEKSZ.png

Read Burst VI:
http://i.imgur.com/tPF2qnd.png

Man that config is long and scary…

The way you’re reading the magnetometer looks fine. Just to note, it’s not going to give you degrees, but rather, magnetic flux. The data sheet says the values can range from -4096 to +4095 (13-bit signed integer). 4095 represents 1229 µT, and 1 represents 0.3 µT. (micro Teslas) Unless you use a magnet, you’re not going to see any readings near those extremes.

http://mythopoeic.org/magnetometer/

It’s been a while since I’ve messed with this stuff, but there is a NOAA calculator that you can use to get an idea of how strong the magnetic flux is in your area.

http://www.ngdc.noaa.gov/geomag-web/

I wouldn’t expect anything over 50 µT in our area unless an external source is applied (such as a magnet, motor, electromagnet).

Well, we fixed the magnetometer communication at last… But we’re having a lot of trouble interpreting the data it gives back. It just doesn’t make much sense, even though it reacts as it should.

It might be easier to use use the example Arduino code and hook the sensor up to an Arduino and communicate over serial port with Arduino which would read the sensor values and send them to your LabView program.

The 9150 has more than 100 registers and the compass on it is a separate I2C device which the 9150 accesses over its own internal I2C bus.

I recommend code from Kris Winer on github.
Also the 9150 is no longer available and got replaced with 9250 which is mostly compatible except for some of the calibration.

You can also use my code on github (uutzinger). Teensy works well as Arduino replacement.

Making USB serial communication work with RoboRIO is not trivial either.

Thanks.
At the moment we’re sticking with the normal gyro, but we already had the Arduino in mind. One thing that will make that process complicated is opening a communication with the sensor AND the rio at the same time.