Calibrate Accelerometer

[Stips123]

Dear Kris,

thank you so much for this beautiful library! Anyhow, I have a small question. I only need acceleration data in my project, but I don't know how to calibrate the IMU. my Code so far:

#include <Wire.h>
#include <MPU9250.h>

MPU9250 myIMU1;

void setup() {
    Serial.begin(115200);
    Wire.begin();

    myIMU1.initMPU9250();

    myIMU1.writeByte(myIMU1.sensorAdresse, SMPLRT_DIV, 0);

    myIMU1.getAres();
    myIMU1.getGres();
}

void loop() {
    myIMU1.readAccelData(myIMU1.accelCount);
    myIMU1.ax = (float)myIMU1.accelCount[0] * myIMU1.aRes -myIMU1.accelBias[0];
    myIMU1.ay = (float)myIMU1.accelCount[1] * myIMU1.aRes -myIMU1.accelBias[1];
    myIMU1.az = (float)myIMU1.accelCount[2] * myIMU1.aRes -myIMU1.accelBias[2];

    Serial.print(myIMU1.ax);
    Serial.print('\t');
    Serial.print(myIMU1.ay);
    Serial.print('\t');
    Serial.println(myIMU1.az);
}

The problem is that sqrt(ax^2 + ay^2 + az^2) is not 1 when I don't move the IMU. Can you please tell me, how to calibrate the Sensor? (The problem is still there, if I use the "-myIMU1.accelBias[0];" or not!). Here are the values with respect to which axis is pointing into the direction of gravity: Thank you!!

Additionally, it would be nice if you could tell me, how to change the sensors full-scale-range to ± 8g. I changed the code in the MPU9250.cpp file, line185:

c = c & ~0x18;  // Clear AFS bits [4:3]
  Ascale = 3;
  c = c | Ascale << 3; // Set full scale range for the accelerometer 
  writeByte(sensorAdresse, ACCEL_CONFIG, c); // Write new ACCEL_CONFIG register value

but I don't feel that this is how it is meant to be ;)

Steffen

[kriswiner]

Check here for an accel/gyro calibration function:

https://github.com/kriswiner/MPU-9250/blob/master/MPU9250_MS5637_AHRS_t3.ino

and adapt as needed.

[Stips123]

Thanks for the fast reply! I really appreciate it. Do you mean, that I have to adapt the code for the MPU9250.h library, or do you advice to use the library in your link (cause it's more up-to-date)? btw you definitely get the beer if we'll ever meet =)

[kriswiner]

I don't use Sparkfun's library even though they based it one one of my sketches. They chose a really old sketch for some reason that had some errors and omissions. The sketch I linked to is more up to date, has accel/gyro as well as mag calibration and I recommend you use it.

Well, virtual beer is OK too!

[Stips123]

thanks for the link! is the calibration permanently stored in the MPU, or do I have to calibrate every single time I (re-)start the Arduino? Or is it necessary to place the IMU on flat ground at all? I'm asking because I can't place the IMU on solid ground everytime in my application (it's rigidly attached to sth). Cheers! =)

[kriswiner]

Thanks for the beer. You can calculate the offset bias calibrations and store them in your sketch to avoid calibrating each time.

For gyro and accel the device should be motionless and flat. Fir mag calibration, you have to move the device around to sample all of the 3D response surface. If you print out the calibration values on the serial monitor, you can just subtract these from your data stream on subsequent startup without having to calibrate anymore unless the environmental conditions (location and temperature, mostly) change.

[Stips123]

hey, thanks for your answer. Something strange is happening here: The x- and y-axes are working fine. Sometimes the z-axis is working correctly which means it is +1 g or -1 g, if the +z or -z-axis is parallel to gravity, respectively. But sometimes, the output is 0 g and -2 g at rest, and I don't know why (as you see in the graphs above). Have you ever observed such a behaviour? Thanks!

[kriswiner]

Yes, there is a bug in the calibration code. The calibration has to be done with the sensor facing up in order to get the correct calibration.

[Stips123]

lol, that's good to know.

[NickMortimer]

Hi I'm looking through your excellent calibration information. I'm trying out the sketch from above. I have installed the library but I'm getting this compile errors. Mainly round wire not being defined. I see that the wire.h is commented out but un-commenting still gives errors. Am I missing something?

[iamchrisb]

@NickMortimer can you post the exact error message after uncommenting the header file?

[kriswiner]

i2c_t3.h is only for the Teensy 3.X MCU. Is that what you are using?

On Fri, Jul 21, 2017 at 7:55 AM, Christopher B notifications@github.com wrote:

@NickMortimer https://github.com/nickmortimer can you post the exact error message after uncommenting the header file?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-317023498, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qsEpkcf1JXJ63Hl54rN9jQsyvNKWks5sQLvtgaJpZM4MPt3I .

[NickMortimer]

Ah sorry for the delay I have been what we say here in Australia out in the bush! I'm using Pro mini but I'm ordering Teensy right now!

[NickMortimer]

So I have un-commented the wire and taken out i2c_t3.h and get the following, seems to be a problem with I2C_MASTER not being defined. could be me?

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'void setup()':

myIMU:312: error: 'I2C_MASTER' was not declared in this scope

Wire.begin(I2C_MASTER, 0x00, I2C_PINS_16_17, I2C_PULLUP_EXT, I2C_RATE_400);

          ^

myIMU:312: error: 'I2C_PINS_16_17' was not declared in this scope

Wire.begin(I2C_MASTER, 0x00, I2C_PINS_16_17, I2C_PULLUP_EXT, I2C_RATE_400);

                            ^

myIMU:312: error: 'I2C_PULLUP_EXT' was not declared in this scope

Wire.begin(I2C_MASTER, 0x00, I2C_PINS_16_17, I2C_PULLUP_EXT, I2C_RATE_400);

                                            ^

myIMU:312: error: 'I2C_RATE_400' was not declared in this scope

Wire.begin(I2C_MASTER, 0x00, I2C_PINS_16_17, I2C_PULLUP_EXT, I2C_RATE_400);

                                                            ^

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'void loop()':

myIMU:521: error: 'MadgwickQuaternionUpdate' was not declared in this scope

 MadgwickQuaternionUpdate(-ax, ay, az, gx*PI/180.0f, -gy*PI/180.0f, -gz*PI/180.0f,  my,  -mx, mz);

                                                                                                ^

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'void MS5637PromRead(uint16_t*)':

myIMU:1219: error: 'I2C_NOSTOP' was not declared in this scope

       Wire.endTransmission(I2C_NOSTOP);        // Send the Tx buffer, but send a restart to keep connection alive

                            ^

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'uint32_t MS5637Read(uint8_t, uint8_t)':

myIMU:1233: error: 'I2C_NOSTOP' was not declared in this scope

     Wire.endTransmission(I2C_NOSTOP);        // Send the Tx buffer, but send a restart to keep connection alive

                          ^

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'uint8_t readByte(uint8_t, uint8_t)':

myIMU:1340: error: 'I2C_NOSTOP' was not declared in this scope

Wire.endTransmission(I2C_NOSTOP); // Send the Tx buffer, but send a restart to keep connection alive

                    ^

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'void readBytes(uint8_t, uint8_t, uint8_t, uint8_t*)':

myIMU:1352: error: 'I2C_NOSTOP' was not declared in this scope

Wire.endTransmission(I2C_NOSTOP); // Send the Tx buffer, but send a restart to keep connection alive

                    ^

exit status 1 'I2C_MASTER' was not declared in this scope

[kriswiner]

You'll need i2c_t3.h if you use i2c_t3 function calls. This will only work on a Teensy 3.X though.

On Tue, Jul 25, 2017 at 5:31 AM, Nick Mortimer notifications@github.com wrote:

So I have un-commented the wire and taken out i2c_t3.h and get the following, seems to be a problem with I2C_MASTER not being defined. could be me?

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'void setup()':

myIMU:312: error: 'I2C_MASTER' was not declared in this scope

Wire.begin(I2C_MASTER, 0x00, I2C_PINS_16_17, I2C_PULLUP_EXT, I2C_RATE_400);

      ^

myIMU:312: error: 'I2C_PINS_16_17' was not declared in this scope

Wire.begin(I2C_MASTER, 0x00, I2C_PINS_16_17, I2C_PULLUP_EXT, I2C_RATE_400);

                        ^

myIMU:312: error: 'I2C_PULLUP_EXT' was not declared in this scope

Wire.begin(I2C_MASTER, 0x00, I2C_PINS_16_17, I2C_PULLUP_EXT, I2C_RATE_400);

                                        ^

myIMU:312: error: 'I2C_RATE_400' was not declared in this scope

Wire.begin(I2C_MASTER, 0x00, I2C_PINS_16_17, I2C_PULLUP_EXT, I2C_RATE_400);

                                                        ^

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'void loop()':

myIMU:521: error: 'MadgwickQuaternionUpdate' was not declared in this scope

MadgwickQuaternionUpdate(-ax, ay, az, gxPI/180.0f, -gyPI/180.0f, -gz*PI/180.0f, my, -mx, mz);

                                                                                            ^

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'void MS5637PromRead(uint16_t*)':

myIMU:1219: error: 'I2C_NOSTOP' was not declared in this scope

   Wire.endTransmission(I2C_NOSTOP);        // Send the Tx buffer, but send a restart to keep connection alive

                        ^

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'uint32_t MS5637Read(uint8_t, uint8_t)':

myIMU:1233: error: 'I2C_NOSTOP' was not declared in this scope

 Wire.endTransmission(I2C_NOSTOP);        // Send the Tx buffer, but send a restart to keep connection alive

                      ^

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'uint8_t readByte(uint8_t, uint8_t)':

myIMU:1340: error: 'I2C_NOSTOP' was not declared in this scope

Wire.endTransmission(I2C_NOSTOP); // Send the Tx buffer, but send a restart to keep connection alive

                ^

C:\Users\mor582\Documents\Arduino\myIMU\myIMU.ino: In function 'void readBytes(uint8_t, uint8_t, uint8_t, uint8_t*)':

myIMU:1352: error: 'I2C_NOSTOP' was not declared in this scope

Wire.endTransmission(I2C_NOSTOP); // Send the Tx buffer, but send a restart to keep connection alive

                ^

exit status 1 'I2C_MASTER' was not declared in this scope

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-317722623, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqXoICadG4txnzIjhExQx_EsII2hks5sReAMgaJpZM4MPt3I .

[Bobur23]

Hello Kris! I have been wondering how to calibrate MPU9250 on Unity. I am using Serial, Madgwick source codes

[kriswiner]

Just use the calibration functions from one of my sketches.

On Wed, Aug 16, 2017 at 12:44 AM, Bobur23 notifications@github.com wrote:

Hello Kris! I have been wondering how to calibrate MPU9250 on Unity. I am using Serial, Madgwick source codes

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-322692406, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qkzjkfJW0r_9ZecUbz5Q87JY1Txuks5sYp3TgaJpZM4MPt3I .

[NickMortimer]

Hi Kris, Sorry to bother you again I'm having real problems getting my calibration to work. I have a 9 DOF using on the inside of a large and very magnetic statue of the Moon. The 9 DOF is on the lighting system inside the moon.

I have attached some output. I would really value your opinion!

It's a standard ax,ay,az,gx,gy,gz,hx,hy,hz format

Thanks moon2.zip

Nick

[NickMortimer]

Ok I think my problem is that the statue is fixed and my light assembly moves that is the worst possible combination

"It is also important to recognize that effective compensation of hard- and soft-iron distortions is dependent upon the distorting material(s) rotating/moving with the sensor. An example would be mounting the sensor in an aircraft; any materials that are part of the aircraft that exhibit a distorting effect would move as the aircraft and mounted sensor move, and it would generally be possible to compensate for the associated hard- and soft-iron effects. In contrast, it is much more difficult—if not impossible—to compensate for distorting effects exhibited by material external to the aircraft/sensor platform. Thus, it is important to understand not only how compensation may be applied, but also to recognize those conditions under which effective compensation techniques are not possible."

So that leaves me with a bit of a problem!

Nick

[kriswiner]

I think you might want to try this then:

https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/

we use for small quadcopters with brushed dc motors pulling variable 0 - 2 Amps each so there is a stron fixed and variable magnetic field, yet we maintain accurate orientation estimation.

On Mon, Oct 2, 2017 at 7:35 AM, Nick Mortimer notifications@github.com wrote:

Ok I think my problem is that the statue is fixed and my light assembly moves that is the worst possible combination

"It is also important to recognize that effective compensation of hard- and soft-iron distortions is dependent upon the distorting material(s) rotating/moving with the sensor. An example would be mounting the sensor in an aircraft; any materials that are part of the aircraft that exhibit a distorting effect would move as the aircraft and mounted sensor move, and it would generally be possible to compensate for the associated hard- and soft-iron effects. In contrast, it is much more difficult—if not impossible—to compensate for distorting effects exhibited by material external to the aircraft/sensor platform. Thus, it is important to understand not only how compensation may be applied, but also to recognize those conditions under which effective compensation techniques are not possible."

So that leaves me with a bit of a problem!

Nick

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-333553437, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qiHHqFPUTeUPvOJ4u6jHP0vNBztNks5soPS1gaJpZM4MPt3I .

[NickMortimer]

Thanks once again your input. Here's a picture of the structure, I don't need to be too accurate but as you can see there is a lot of steel on the supports, the light system is inside the globe!

[kriswiner]

Can you calibrate the mag inside the globe? There is auto mag calibration on the EM7180 so might not even be an issue, but if you can manually calibrate inside it would be easier. No guarantees, but if you can't do an adequate job with the MPU9250+EM7180 them I would suppose an inexpensive IMU solution is hopeless.

On Mon, Oct 2, 2017 at 4:26 PM, Nick Mortimer notifications@github.com wrote:

[image: 19621396_10212892259760688_2032012674_n] https://user-images.githubusercontent.com/4338975/31103852-d97f20c6-a80b-11e7-89c8-7a8ff7e5bfe3.jpg

Thanks once again your input. Here's a picture of the structure, I don't need to be too accurate but as you can see there is a lot of steel on the supports, the light system is inside the globe!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-333693662, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qlQiKZuAnjAddDdeIwkiENb5FUVbks5soXE4gaJpZM4MPt3I .

[NickMortimer]

Yep I was not involved with the design, I wanted shaft encoders on the axis but it was built before I was on board! Yep The cal data I posted is the sensor mounted on the light system. Checking with a standard compass you can get needle reversals at points close to the bottom of the structure!

[NickMortimer]

So this is the problem. This was a vertical circle!

[kriswiner]

Yes, but is a fixed field so can be calibrated out

On Wed, Oct 4, 2017 at 7:51 AM Nick Mortimer notifications@github.com wrote:

[image: figure_5-1] https://user-images.githubusercontent.com/4338975/31182464-82b098b4-a956-11e7-9e2b-628525832ffc.png So this is the problem. This was a vertical circle!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-334181578, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qrU6sn3JtauoZyQiko4F5oHufwOaks5so5uLgaJpZM4MPt3I .

[NickMortimer]

No at this time I can fix the calibration if I'm only interested in one plain as soon as I change the orientation of the sensor and sweep it a gain I get a completely different result mainly because the thing causing the deviation is in a fixed location and thus it's distance to the sensor is varying. I'm going to tell them to get some shaft encoders! Thanks once again for your replies and information!

[PatelKishanJ]

Hello kris,

  I have used your code with mpu9250 and testing data.

I had some doubt that how can verify data.So,i have verify with android application.

I have comparing data with SENSOR KINETICS (app),and its very different readings.

So,what should be issue?

[kriswiner]

One or both are wrong?

Did you calibrate the sensors?

Are you using an MCU to give a fusion rate > 1 kHz?

Are you feeding the Madwick filter the data in the proper order?

On Tue, Jan 9, 2018 at 3:53 AM, jenextech notifications@github.com wrote:

Hello kris,

I have used your code with mpu9250 and testing data.

I had some doubt that how can verify data.So,i have verify with android application.

I have comparing data with SENSOR KINETICS (app),and its very different readings.

So,what should be issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-356263490, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnkxoYHzKVIblNPMH7spazR1OhNsks5tI1NTgaJpZM4MPt3I .

[PatelKishanJ]

I dont know which one is wrong but one of the two is wrong. I have used your code as it is,no any additional configuration has done.

So,how can i verify raw data as well as all result of code.(yaw,pitch,roll 9 axis data with particular units)?

And below lines of code shows that sample rate is 1 kHz.

// Configure MPU9250 gyro and accelerometer for bias calculation i2c_write_data_byte_kt(MPU9250_ADDRESS, CONFIG, 0x01); // Set low-pass filter to 188 Hz i2c_write_data_byte_kt(MPU9250_ADDRESS, SMPLRT_DIV, 0x00); // Set sample rate to 1 kHz i2c_write_data_byte_kt(MPU9250_ADDRESS, GYRO_CONFIG, 0x00); // Set gyro full-scale to 250 degrees per second, maximum sensitivity i2c_write_data_byte_kt(MPU9250_ADDRESS, ACCEL_CONFIG, 0x00); // Set accelerometer full-scale to 2 g, maximum sensitivity

And i have also one another doubt about quaternions.

quaternion is represented by qw + i qx + j qy + k qz.

In your code we can get q[0], q[1], q[2], q[3]. So,can you match this array with w,x,y and z.

Thanks in advanced.

[kriswiner]

You didn;t answer any of my questions, hard to help without this info.

On Wed, Jan 10, 2018 at 2:44 AM, jenextech notifications@github.com wrote:

I dont know which one is wrong but one of the two is wrong. I have used your code as it is,no any additional configuration has done.

So,how can i verify raw data as well as all result of code.(yaw,pitch,roll 9 axis data with particular units)?

Thanks in advanced.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-356565550, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qjNij-DXEqDobhCspsVljmqHVp3Zks5tJJSKgaJpZM4MPt3I .

[PatelKishanJ]

Sorry if i had not respond your question.But i told you.

As you asked me about which one is wrong? I told that one of two platform can wrong.

I want to verify IMU data.So,from android application we can measure 9-axis data. And data which we getting from IMU and APPLICATION.Both are different.

So,how can i verify it?.

[nanoTitan]

Hi Kris,

I went through your accel/gyro calibration with the device at rest, and the magnetometer calibration while performing figure eights. If I rotate the device parallel to the ground, the yaw seems to work well. However, I'm seeing that a change in the roll of the device also causes a large change in the yaw.

Any ideas of what might be causing this or where I can look to fix it?

Thanks so much for putting this library together! I've modified it from your Stm32 Mbed code to use Stm's HAL library for the Stm32f401. If you would like, I can provide that code for you.

[kriswiner]

I will assume you verified that your sensors are properly calibrated.

How are you passing the sensor data tot he Madgiwck or Mahony fusion filter? NED?

On Tue, Feb 27, 2018 at 7:01 AM, Hushel Roberts notifications@github.com wrote:

Hi Kris,

I went through your accel/gyro calibration with the device at rest, and the magnetometer calibration while performing figure eights. If I rotate the device parallel to the ground, the yaw seems to work well. However, I'm seeing that a change in the roll of the device also causes a large change in the yaw.

Any ideas of what might be causing this or where I can look to fix it?

Thanks so much for putting this library together! I've modified it from your Stm32 Mbed code to use Stm's HAL library for the Stm32f401. If you would like, I can provide that code for you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-368906768, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qn0bSSDpwdhTWNRfqPTvLYHsQluxks5tZBjNgaJpZM4MPt3I .

[nanoTitan]

Yes, I can verify my magnetometer data with a 2-D plot like you have in your magnetometer calibration article. I'm not sure of how I would verify accel/gyro data though after running the calibration on those. Any tips on that would be great. I do see that the accel/gyro trims are within roughly 1-2% of factory settings.

Yes, I believe the data is provided in the N.E.D. orientation. I'm using your example code from here: https://os.mbed.com/users/onehorse/code/MPU9250AHRS/file/4e59a37182df/main.cpp/

[kriswiner]

mpu9250.MahonyQuaternionUpdate(ax, ay, az, gxPI/180.0f, gyPI/180.0f, gz*PI/180.0f, my, mx, mz);

This is wrong, not NED.

Filter needs, (An, Ae, Ad, Gn, Ge, Gd, Mn, Me, Md).

For gyro and accel calibration. Place sensor flat and motionless. Is gyro 0, 0, 0? Is accel 0, 0, 1?

On Tue, Feb 27, 2018 at 1:18 PM, Hushel Roberts notifications@github.com wrote:

Yes, I can verify my magnetometer data with a 2-D plot like you have in your magnetometer calibration article. I'm not sure of how I would verify accel/gyro data though after running the calibration on those. Any tips on that would be great. I do see that the accel/gyro trims are within roughly 1-2% of factory settings.

Yes, I believe the data is provided in the N.E.D. orientation. I'm using your example code from here: https://os.mbed.com/users/onehorse/code/MPU9250AHRS/ file/4e59a37182df/main.cpp/

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-369029515, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qpyWRgxC8KMoILoDVyII5khyyHCfks5tZHE-gaJpZM4MPt3I .

[nanoTitan]

Ok, I've remapped those ax, ay, az, etc to the order that the filter expects. It looks like it is working much better now. Thanks for that!

For the accel calibration, I'm getting 0.02, 0.01, 1.00 which looks about right. The gyro is giving me values around 0.2, 0.3, 0.01. Are those close enough to zero consider accurate? I'm trying to get this within the 2 degrees of accuracy.

[kriswiner]

You might get 4 degrees rms heading accuracy. In part it depends on the fusion rate your MCU is capable of. What are you using again?

On Wed, Feb 28, 2018 at 9:16 AM, Hushel Roberts notifications@github.com wrote:

Ok, I've remapped those ax, ay, az, etc to the order that the filter expects. It looks like it is working much better now. Thanks for that!

For the accel calibration, I'm getting 0.02, 0.01, 1.00 which looks about right. The gyro is giving me values around 0.2, 0.3, 0.01. Are those close enough to zero consider accurate? I'm trying to get this within the 2 degrees of accuracy.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-369312214, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqkbVzua_1WUcdB-SaGKo4kmR0eFks5tZYm9gaJpZM4MPt3I .

[nanoTitan]

I'm using a stm32f401 running at 84Mhz. It looks like the Teensy runs at 180Mhz, and I'm guessing I need something close to that to get greater precision.

[kriswiner]

F401 has an FPU so you will be able to get fusion rates >20 kHz which is more than enough.

On Wed, Feb 28, 2018 at 11:41 AM, Hushel Roberts notifications@github.com wrote:

I'm using a stm32f401 running at 84Mhz. It looks like the Teensy runs at 180Mhz, and I'm guessing I need something close to that to get greater precision.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-369358588, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qhasWL9PmsEv2QZ_aJKBI5KEHNveks5tZav7gaJpZM4MPt3I .

[aabdulkadar]

I have problem with my mpu 9250 .I use this code( https://github.com/kriswiner/MPU-9250/blob/master/MPU9250_MS5637_AHRS_t3.ino) to calibrate .But the values are not changing and I used to get these in serial monitor

Gyro temperature is 30.8 degrees C Digital temperature value = 20.00 C Digital temperature value = 68.00 F Digital pressure value = 0.00 mbar Altitude = 145366.45 feet Yaw, Pitch, Roll: 13.80, 0.00, 0.00 Grav_x, Grav_y, Grav_z: 0.00, 0.00, 1000.00 mg Lin_ax, Lin_ay, Lin_az: 0.00, 0.00, -1000.00 mg rate = 6978.08 Hz ax = 0.00 ay = 0.00 az = 0.00 mg gx = 0.00 gy = 0.00 gz = 0.00 deg/s mx = 0 my = 0 mz = 0 mG q0 = 1.00 qx = 0.00 qy = 0.00 qz = 0.00

Please help me.I am new

[aabdulkadar]

always zero irrespective of the movements !!

[kriswiner]

Are you using the data ready interrupt?

On Wed, Jun 20, 2018 at 6:47 AM, aabdulkadar notifications@github.com wrote:

always zero irrespective of the movements !!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-398754374, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qoiH3IpBevKtbk5Cx4uYGqzgzVTnks5t-lJ9gaJpZM4MPt3I .

[aabdulkadar]

Thank you for the fast response.

I am reading like what I written below

/ If intPin goes high, all data registers have new data if(newData == true) { // On interrupt, read data newData = false; // reset newData flag readMPU9250Data(MPU9250Data); // INT cleared on any read readAccelData(accelCount); // Read the x/y/z adc values

// Now we'll calculate the accleration value into actual g's
ax = (float)MPU9250Data[0]*aRes - accelBias[0];  // get actual g value, this depends on scale being set
ay = (float)MPU9250Data[1]*aRes - accelBias[1];   
az = (float)MPU9250Data[2]*aRes - accelBias[2];  

readGyroData(gyroCount); // Read the x/y/z adc values

// Calculate the gyro value into actual degrees per second
gx = (float)MPU9250Data[4]*gRes;  // get actual gyro value, this depends on scale being set
gy = (float)MPU9250Data[5]*gRes;  
gz = (float)MPU9250Data[6]*gRes;   

readMagData(magCount);  // Read the x/y/z adc values

// Calculate the magnetometer values in milliGauss
// Include factory calibration per data sheet and user environmental corrections
if(newMagData == true) {
  newMagData = false; // reset newMagData flag
  mx = (float)magCount[0]*mRes*magCalibration[0] - magBias[0];  // get actual magnetometer value, this depends on scale being set
  my = (float)magCount[1]*mRes*magCalibration[1] - magBias[1];  
  mz = (float)magCount[2]*mRes*magCalibration[2] - magBias[2];  
  mx *= magScale[0];
  my *= magScale[1];
  mz *= magScale[2]; 
} 

}

[kriswiner]

" int intPin = 8;"

Are you using interrupt pin on Teenst pin 8?

On Wed, Jun 20, 2018 at 10:24 PM, aabdulkadar notifications@github.com wrote:

Thank you for the fast response

// If intPin goes high, all data registers have new data if(newData == true) { // On interrupt, read data newData = false; // reset newData flag readMPU9250Data(MPU9250Data); // INT cleared on any read // readAccelData(accelCount); // Read the x/y/z adc values

here is my reading part

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/120#issuecomment-398979931, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtohQkQUmwss3heWLpW60IaXV2_uks5t-y32gaJpZM4MPt3I .

[aabdulkadar]

yes..I checked with 2 and 12 also ..No change

[aabdulkadar]

I changed intpin to 3 and it works

Digital temperature value = 20.00 C Digital temperature value = 68.00 F Digital pressure value = 0.00 mbar Altitude = 145366.45 feet Yaw, Pitch, Roll: 280.96, -24.25, -144.30 Grav_x, Grav_y, Grav_z: 532.09, -410.65, -740.44 mg Lin_ax, Lin_ay, Lin_az: -480.34, 1387.70, -1310.83 mg rate = 96.03 Hz

but even it is at rest,acceleration values are not zero..? Thank you for your patience