IMU (MPU6050) behaving Strangely on Teensy only

Status
Not open for further replies.
K

KE7JLM

New member
Hey Guys,

I've got an MPU6050 wired to an Teensy 3.2. Its being powered via the Teeny's 3.3 bus and its ground (not AGND). SDA is connected to pin 18 and SCL is on pin 19. The initial connection works and all seems well until you look at the data. Take a look at the picture. Capture1.jpg

The red line is the Accel's X axis data. It cycles from 70 to 180 then wraps back around at a constant time period. Its a behavior I've never seen. This same code works great on a 2560 Mega. I was wonder if there are any common problems when transfering I2C code from Arduino to Teensy that I may be missing. This is my first Teensy project.

Here is the code -

https://dl.dropboxusercontent.com/u/20568745/Kalman.h

https://dl.dropboxusercontent.com/u/20568745/Sensor_Only.ino

Sample Data -

https://dl.dropboxusercontent.com/u/20568745/sample data.txt


Attached a picture of the hardware set up - 2015-10-14 18.46.58.jpg
 
Instead of :

Code: 
/* Set kalman and gyro starting angle */
  while (i2cRead(0x3B, i2cData, 6));
  accX = (i2cData[0] << 8) | i2cData[1];
  accY = (i2cData[2] << 8) | i2cData[3];
  accZ = (i2cData[4] << 8) | i2cData[5];

Try something like:

Code: 
accX = (int_16_t) (((int16_t) i2cData[0] << 8) | i2cData[1]);
,etc.

I have an MPU6050 sketch that works well on the Teensy if all else fails.
 
Tried Changes.. No Luck

onehorse said:
Instead of :

Code: 
/* Set kalman and gyro starting angle */
  while (i2cRead(0x3B, i2cData, 6));
  accX = (i2cData[0] << 8) | i2cData[1];
  accY = (i2cData[2] << 8) | i2cData[3];
  accZ = (i2cData[4] << 8) | i2cData[5];

Try something like:

Code: 
accX = (int_16_t) (((int16_t) i2cData[0] << 8) | i2cData[1]);
,etc.
Click to expand...

I am going to integrate some filtering (Kalman) and angle outputs to your code.
 
Its a bit hard to see exactly what you are printing in that code full of comments, but it seems that the third column, the one increasing to 180 and then wrapping down to 70 is gyroXAngle that gets reset to the value of kalAngleX after drifting to above 180.

gyroXAngle is the integrated, non Kalman filtered, X angle obtained by integrating gyroXrate. This is not the acceleration data and it seems that the gyroXrate, the acceleration data, is not correctly calibrated to 0 in stationary position.
 
Last edited:
Paul has said that for Teensy 3.0 you need "to use real pullup resistors on both SDA and SCL." It's probably the same for T3.2. I believe 1k is required.

Pete
 
el_supremo said:
Paul has said that for Teensy 3.0 you need "to use real pullup resistors on both SDA and SCL." It's probably the same for T3.2. I believe 1k is required.

Pete
Click to expand...

I have never used actual pullups for I2C on my T3.1...everything has worked fine in the past, is that just pure coincidence that I got lucky?
 
Probably luck. I had problems with I2C on T3.0 until I installed the 1k pullups. I can't remember if the pullups are required on T3.1 or 3.2 but if there's something odd going on, give them a try, can't hurt :)

Pete
 
el_supremo said:
Probably luck. I had problems with I2C on T3.0 until I installed the 1k pullups. I can't remember if the pullups are required on T3.1 or 3.2 but if there's something odd going on, give them a try, can't hurt :)

Pete
Click to expand...

Ha, I guess I have just been getting lucky :) Thanks for the head's up, good information to know!
 
mlu said:
gyroXAngle is the integrated, non Kalman filtered, X angle obtained by integrating gyroXrate. This is not the acceleration data and it seems that the gyroXrate, the acceleration data, is not correctly calibrated to 0 in stationary position.
Click to expand...

Good observation. I just don't know why its happening on the Teensy and not the Mega 2560 that it was developed it on and I don't know how to fix it.

Also, I tired a couple of pull ups on the data and clock line, no dice...

Thanks guys.
 
If I am not mistaken, the whole point of the Kalman filtering is to use the filter to combine the accelerometer and the gyro, using the accelerometer to remove the gyro rate drift, effectively calibrating out the gyro offset, and the gyro signal for faster and more precise response to small angles with short integration times.
 
mlu said:
If I am not mistaken, the whole point of the Kalman filtering is to use the filter to combine the accelerometer and the gyro, using the accelerometer to remove the gyro rate drift, effectively calibrating out the gyro offset, and the gyro signal for faster and more precise response to small angles with short integration times.
Click to expand...

From my limited understanding of Kalmen filtering I do think you are correct. The issue is why is it drifting so fast. Before, on the Mega, it would drift somewhere around 1 degree per minute. Now its well past that in the hundredsof degrees per minute.

Thanks you all for giving some input.
 
Ooops. Sorry. I was repeating what @onehorse had already suggested.
But I'll just note that (int_16_t) should be (int16_t)

Pete
 
Last edited:
Status
Not open for further replies.
Back
Top