MPU-9150 (I2C) with Labview

[Ian R.]

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

[RyanN]

Originally Posted by Ian R.

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.

[Ian R.]

Originally Posted by RyanN

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:


MPU Config VI:


Read HL VI:


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

[RyanN]

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.

[Ian R.]

Originally Posted by RyanN

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

[RyanN]

Originally Posted by Ian R.

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.

[Ian R.]

Originally Posted by RyanN

What breakout board are you using?

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

[RyanN]

Originally Posted by Ian R.

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.

[Ian R.]

Originally Posted by RyanN

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.

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

[Ian R.]

Originally Posted by RyanN

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.

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.

[RyanN]

Originally Posted by RyanN

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.

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: https://github.com/sparkfun/MPU-9150...50/MPU6050.cpp

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 https://github.com/sparkfun/MPU-9150...6050/MPU6050.h

[Ian R.]

Originally Posted by RyanN

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: https://github.com/sparkfun/MPU-9150...50/MPU6050.cpp

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 https://github.com/sparkfun/MPU-9150...6050/MPU6050.h

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!

[Ian R.]

Originally Posted by RyanN

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: https://github.com/sparkfun/MPU-9150...50/MPU6050.cpp

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 https://github.com/sparkfun/MPU-9150...6050/MPU6050.h

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.

[RyanN]

Originally Posted by Ian R.

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:

Originally Posted by Section 8.1

Addresses from 00H to 0CH and from 10H to 12H are compliant with automatic increment function of serial interface respectively.

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?

[Ian R.]

Originally Posted by RyanN

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