(Yet another one) Issue with Yaw

[markussen145]

Hi all,

First of all, I wanna thank @kriswiner for his amazing code. This piece of code together with the attention, time and effort you put on this topic is amazing, mainly for a hobbist like me who is starting to participate on communities like this one.

------------Short---------- I'm currently facing an issue with the yaw as it drifts and doesn't stick to a specific direction. These are my outputs when going through matlab for 1000 samples with an infinite shaped move (90º rotated eight shape): Raw output (readings from magnetometer)

Calibrated output (actual mx, my, mz that go into the Madgwick/Mahony function):

mx vs my = red my vs mz = blue mx vs mz = green

I also took into account the declination of my current location.

However, Yaw seems not to work at all. If I roll or pitch the MPU9250 (independently), yaw tends to move as well, even if it's pointing north all the time. Do you see anything wrong in the raw/calibrated outputs? I feel like they are not as spread as they should be. Is there any other action you'd suggest?

Next thing I'm trying is a different MPU9250 unit, just in case this one is deffective, but I have low expectations on this change to solve my issue.

----------More detail-----------

I modified the code to have different outputs: readable one, matlab one and teapot one. The readable is self explanatory; the matlab one is the one I use to calculate in matlab the scale and bias of the magnetometer to compare it with the actual output based on your easy and efficient way to calibrate the magnetometer (thanks for that too); in the teapot one I output the quaternions so I can draw them in the processing teapot code (based on the teapot code for processing used for MPU6050, which needs quaternions as input).

I tried different things to try to fix this issue or to find the root cause:

1. Changed code and tested a couple more scripts (your AHRS and AHRS_..._t3 code mainly as it has the magnetometer calibration function for MPU9250 in case I was doing it wrong)
2. I used a logical converter to feed SCL and SDA with 3.3v instead of the 5v my micro pro outputs. I also changed VCC of the MPU9250 from 5v to 3.3v, just in case too much voltage/current was causing magnetometer readings wrong (due to the way magnetometer field is read from physical perspective).
3. I moved the MPU9250 to a different location in the breadboard

and I have always had the same result.

Setup:

• Chinese Pro Micro
• MPU9250: http://www.winddeal.net/image/28473/28473-1.jpg
• Logical converter: chinese copy of this one: https://www.sparkfun.com/products/12009

[kriswiner]

It is to do with 1) the order with which you are feeding the fusion filter and 2) the speed of the fusion rate you can obtain with the Pro Micro.

Fix 1) and you will get better behavior, although sluggish and laggy.

On Mon, Jul 17, 2017 at 5:52 PM, markussen145 notifications@github.com wrote:

Hi all,

First of all, I wanna thank @kriswiner https://github.com/kriswiner for his amazing code. This piece of code together with the attention, time and effort you put on this topic is amazing, mainly for a hobbist like me who is starting to participate on communities like this one.

------------Short---------- I'm currently facing an issue with the yaw as it drifts and doesn't stick to a specific direction. These are my outputs when going through matlab for 1000 samples with an infinite shaped move (90º rotated eight shape): Raw output (readings from magnetometer) [image: raw_data_mpu9250] https://user-images.githubusercontent.com/29856809/28295486-2a05d59a-6b61-11e7-9a50-9e5cedd9ffaf.jpg

Calibrated output (actual mx, my, mz that go into the Madgwick/Mahony function): [image: calibrated_output_mpu9250] https://user-images.githubusercontent.com/29856809/28295539-8e6dc1b4-6b61-11e7-8b4a-b44c74312045.jpg

mx vs my = red my vs mz = blue mx vs mz = green

I also took into account the declination of my current location.

However, Yaw seems not to work at all. If I roll or pitch the MPU9250 (independently), yaw tends to move as well, even if it's pointing north all the time. Do you see anything wrong in the raw/calibrated outputs? I feel like they are not as spread as they should be. Is there any other action you'd suggest?

Next thing I'm trying is a different MPU9250 unit, just in case this one is deffective, but I have low expectations on this change to solve my issue.

----------More detail-----------

I modified the code to have different outputs: readable one, matlab one and teapot one. The readable is self explanatory; the matlab one is the one I use to calculate in matlab the scale and bias of the magnetometer to compare it with the actual output based on your easy and efficient way to calibrate the magnetometer (thanks for that too); in the teapot one I output the quaternions so I can draw them in the processing teapot code (based on the teapot code for processing used for MPU6050, which needs quaternions as input).

I tried different things to try to fix this issue or to find the root cause:

1. Changed code and tested a couple more scripts (your AHRS and AHRS_..._t3 code mainly as it has the magnetometer calibration function for MPU9250 in case I was doing it wrong)
2. I used a logical converter to feed SCL and SDA with 3.3v instead of the 5v my micro pro outputs. I also changed VCC of the MPU9250 from 5v to 3.3v, just in case too much voltage/current was causing magnetometer readings wrong (due to the way magnetometer field is read from physical perspective).
3. I moved the MPU9250 to a different location in the breadboard

and I have always had the same result.

Setup:

• Chinese Pro Micro
• MPU9250: http://www.winddeal.net/image/28473/28473-1.jpg
• Logical converter: chinese copy of this one: https://www.sparkfun.com/products/12009 https://www.sparkfun.com/products/12009

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qhhjQ11BdJwk10H3ZWeJklb-ifUOks5sPAGvgaJpZM4Oatke .

[markussen145]

I'll try that and I'll let you know the outcome, although for 1), I think I had done it in the right way: accel x, accel y, accel z, gyro x, gyro y, gyro z, magnet y, magnet x, -magnet z.

Thanks a lot.

[kriswiner]

Check the data sheet. It depends on which axis you choose for North. If it is Ax, then

MadgwickQuaternionUpdate(-ax, ay, az, gxpi/180.0f, -gypi/180.0f, -gz*pi/180.0f, my, -mx, mz);

works for me, although multiplying the accel by -1 is optional.

On Mon, Jul 17, 2017 at 6:51 PM, markussen145 notifications@github.com wrote:

I'll try that and I'll let you know the outcome, although for 1), I think I had done it in the right way: accel x, accel y, accel z, gyro x, gyro y, gyro z, magnet y, magnet x, -magnet z.

Thanks a lot.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-315934829, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qvAE5fZQHE4iNyF3N2xX-z8mReIxks5sPA-UgaJpZM4Oatke .

[markussen145]

Thanks a lot Kris.

I think I got it fixed, though I have to improve the magnetometer calibration now to be 100% sure. The root cause was related to my working area, more that to the code or device itself. I moved the device 1 meter away from my pc desk (screen+PC+subwoofer+other speakers+printer+phone...) and I have started to get reliable output.

I'm afraid the magnet of the subwoofer together with the rest of the electronics, although has not been used while calibrating or working, has been affecting the magnetic readings. Moreover, the room where I'm working on this thing is in the middle of the building, so magnetic field is probably pretty weak as there are several walls between the device and the outside.

------------------------- More detail -------------------- I followed your suggestions: 1) Checked and rechecked, and checked again the order in which I was feeding the filter. Everything was fine (it points towards +X) 2) Feed rate: I had ordered an arduino Due, and I switched from Micro Pro to Due (with some code rearragenments I wasn't expecting). The update rate increased to more than 1khz without code performance improvements, but the issue was still happening.

Other things I did: 1) Changed MPU9250 unit to a new one I calibrated; no changes. 2) Moved the MPU9250 to a different location in the breadboard, just in case there some connection that could be affecting the magnetic field (i.e., the VCC row could be doing something tricky); no changes. 3) Took the MPU9250 out of the breadboard and connected it to the wires directly; no changes. 4) Transformed the Madgwick function from .ino to .m so I could use it in a more flexible way in Matlab; no root cause found there. 5) I got a piece of code for matlab to move a sphere based on quaternions; same result as when I was using the teapot-adapted code for my analysis.

For everyone: please, check your surroundings when calibrating or using the IMU, as like in issue #26 , my IMU was behaving as a "needle" or kind of compass: after rotating, the MPU9250 slowly returns to a fixed position, as in this video (when changing the yaw):

https://www.youtube.com/watch?v=8Lw_MjzM0Xs

[afnan]

@kriswiner well i was wondering what is the process of passing parameters to madwick or mahony function? i have seen different configurations at different website on your code. Is there something i can study on this?

[kriswiner]

Choose which sensor axis will align with North. Then pass NED to the algorithm. Or ENU, but it must be consistent.

On Tue, Sep 12, 2017 at 5:07 AM, afnan notifications@github.com wrote:

@kriswiner https://github.com/kriswiner well i was wondering what is the process of passing parameters to madwick or mahony function? i have seen different configurations at different website on your code. Is there something i can study on this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-328832709, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qg-k8y72hVRHmuMYekLU9x-BvUnHks5shnQUgaJpZM4Oatke .

[afnan]

Well I have tried different options but they do not work correctly. I can get Pitch and Roll angles with reasonable accuracy but Yaw is something i cant understand its behavior.

Problems:

1. I can get Roll and Pitch values but rotating for any one also changes the value of other.
2. Yaw is not correct either.

What should I look into?

I have tried all three but no suitable results from following NED combinations MahonyQuaternionUpdate(myIMU.ax, myIMU.ay, myIMU.az, myIMU.gx * DEG_TO_RAD,myIMU.gy * DEG_TO_RAD, myIMU.gz * DEG_TO_RAD, myIMU.my,myIMU.mx, myIMU.mz, myIMU.deltat);

MahonyQuaternionUpdate(-myIMU.ax, myIMU.ay, myIMU.az, myIMU.gx * DEG_TO_RAD, -myIMU.gy * DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.my, -myIMU.mx, myIMU.mz, myIMU.deltat);

MadgwickQuaternionUpdate(-myIMU.ay, -myIMU.ax, myIMU.az, myIMU.gy * DEG_TO_RAD, myIMU.gx * DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.mx, myIMU.my, myIMU.mz, myIMU.deltat);

[afnan]

I have seen your code and other examples on internet as well. The problem I am facing is that Processor: Node MCU Running at 160 MHz and rate comes out to be 923Hz. I get angles correct for Roll and Pitch but Yaw is disturbed.

If you think this is due to rate what MCU do you suggest me to use?

1. If i rotate across one angle others change as well.
2. I cant make sense for Yaw it wont rotate full 360.

I have tried following

MahonyQuaternionUpdate(myIMU.ax, myIMU.ay, myIMU.az, myIMU.gx * DEG_TO_RAD,myIMU.gy * DEG_TO_RAD, myIMU.gz * DEG_TO_RAD, myIMU.my,myIMU.mx, myIMU.mz, myIMU.deltat);

MahonyQuaternionUpdate(-myIMU.ax, myIMU.ay, myIMU.az, myIMU.gx * DEG_TO_RAD, -myIMU.gy * DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.my, -myIMU.mx, myIMU.mz, myIMU.deltat);

MadgwickQuaternionUpdate(-myIMU.ay, -myIMU.ax, myIMU.az, myIMU.gy * DEG_TO_RAD, myIMU.gx * DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.mx, myIMU.my, myIMU.mz, myIMU.deltat);

//MahonyQuaternionUpdate(myIMU.ay, myIMU.ax, -myIMU.az, myIMU.gy * DEG_TO_RAD, myIMU.gx * DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.mx, myIMU.my, myIMU.mz, myIMU.deltat);

[kriswiner]

Is your sensor calibrated? How do you know?

Which accel axis points North?

On Wed, Sep 13, 2017 at 4:54 AM, afnan notifications@github.com wrote:

I have seen your code and other examples on internet as well. The problem I am facing is that Processor: Node MCU Running at 160 MHz and rate comes out to be 923Hz. I get angles correct for Roll and Pitch but Yaw is disturbed.

1. If i rotate across one angle others change as well.
2. I cant make sense for Yaw it wont rotate full 360.

I have tried following

MahonyQuaternionUpdate(myIMU.ax, myIMU.ay, myIMU.az, myIMU.gx DEG_TO_RAD,myIMU.gy DEG_TO_RAD, myIMU.gz * DEG_TO_RAD, myIMU.my,myIMU.mx, myIMU.mz, myIMU.deltat);

MahonyQuaternionUpdate(-myIMU.ax, myIMU.ay, myIMU.az, myIMU.gx DEG_TO_RAD, -myIMU.gy DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.my, -myIMU.mx, myIMU.mz, myIMU.deltat);

MadgwickQuaternionUpdate(-myIMU.ay, -myIMU.ax, myIMU.az, myIMU.gy DEG_TO_RAD, myIMU.gx DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.mx, myIMU.my, myIMU.mz, myIMU.deltat);

//MahonyQuaternionUpdate(myIMU.ay, myIMU.ax, -myIMU.az, myIMU.gy DEG_TO_RAD, myIMU.gx DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.mx, myIMU.my, myIMU.mz, myIMU.deltat);

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-329144532, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qmwFZ4cx20x6xNSgo3qOyVScVnPrks5sh8KIgaJpZM4Oatke .

[afnan]

Well i ran the routine which was in your code to calibrate magnetometer and used their biases. Also I have compensated for inclination at my place. I will again calibrate and draw graphs and post here.

I am not sure how to see which accel axis points to north any idea how i can find that?

[kriswiner]

"I am not sure how to see which accel axis points to north any idea how i can find that?"

This is something you choose.

On Wed, Sep 13, 2017 at 5:10 PM, afnan notifications@github.com wrote:

Well i ran the routine which was in your code to calibrate magnetometer and used their biases. Also I have compensated for inclination at my place. I will again calibrate and draw graphs and post here.

I am not sure how to see which accel axis points to north any idea how i can find that?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-329332031, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qjeyuwA9dJyA7_lat57haxW7fkTxks5siG8MgaJpZM4Oatke .

[afnan]

Sorry for being dumb, board has printed x,y and x axis. Do i need to place the board such that x axis of the board points true north?

[kriswiner]

Only if you want the yaw to be zero.

On Wed, Sep 13, 2017 at 5:36 PM, afnan notifications@github.com wrote:

Sorry for being dumb, board has printed x,y and x axis. Do i need to place the board such that x axis of the board points true north?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-329335435, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qpc7KuSa89usy3_LcvuCqQwMAHxBks5siHUTgaJpZM4Oatke .

[afnan]

Okies so what about second problem which is getting variation in angles when moved along single axis? is it due to fusion rate below 1000Hz?

[kriswiner]

three typical problems:

1) sensors not properly calibrated 2) feeding sensor data into Madgwick filter in wrong order 3) too slow fusion rate

Probably all three in your case.

On Wed, Sep 13, 2017 at 5:52 PM, afnan notifications@github.com wrote:

Okies so what about second problem which is getting variation in angles when moved along single axis? is it due to fusion rate below 1000Hz?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-329337659, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qmbVbJbhFUnD_F6Mj-2IYOG3pxUhks5siHjkgaJpZM4Oatke .

[afnan]

Hmm Okies so going point by point this is what i get after calibration. Does these pictures seem correct? Process:

1. call magcalMPU9250 function to get values of bias and scale and swing sensor in form of vertical 8 which also rotates the sensor upside down during motion to cover all angles

2. Use parameters as

   myIMU.readMagData(myIMU.magCount);  // Read the x/y/z adc values
   myIMU.getMres();
   myIMU.mx = (float)myIMU.magCount[0] * myIMU.mRes * myIMU.magCalibration[0] -
              myIMU.magbias[0];
   myIMU.my = (float)myIMU.magCount[1] * myIMU.mRes * myIMU.magCalibration[1] -
              myIMU.magbias[1];
   myIMU.mz = (float)myIMU.magCount[2] * myIMU.mRes * myIMU.magCalibration[2] -
              myIMU.magbias[2];
   
   myIMU.mx *= myIMU.magScale[0];
   myIMU.my *= myIMU.magScale[1];
   myIMU.mz *= myIMU.magScale[2];

3. print mx,my,mz values and draw graph. Does it seem rite?

[kriswiner]

Hard to say, might be as good as you can do with this simple method but a soft iron correction still needs to be made.

On Wed, Sep 13, 2017 at 7:04 PM, afnan notifications@github.com wrote:

Hmm Okies so going point by point this is what i get after calibration. Does these pictures seem correct? Process:

1. call magcalMPU9250 function to get values of bias and scale and swing sensor in form of vertical 8 which also rotates the sensor upside down during motion to cover all angles

2. Use parameters as

   myIMU.readMagData(myIMU.magCount); // Read the x/y/z adc values myIMU.getMres(); myIMU.mx = (float)myIMU.magCount[0] myIMU.mRes myIMU.magCalibration[0] - myIMU.magbias[0]; myIMU.my = (float)myIMU.magCount[1] myIMU.mRes myIMU.magCalibration[1] - myIMU.magbias[1]; myIMU.mz = (float)myIMU.magCount[2] myIMU.mRes myIMU.magCalibration[2] - myIMU.magbias[2];

   myIMU.mx = myIMU.magScale[0]; myIMU.my = myIMU.magScale[1]; myIMU.mz *= myIMU.magScale[2];

3. print mx,my,mz values and draw graph. Does it seem rite? [image: capture new] https://user-images.githubusercontent.com/2023923/30408804-804e3274-9944-11e7-8d43-b2179116034f.PNG

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-329347725, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qguLqKuF7dyh2ZOrOY07jqoQOewpks5siIm1gaJpZM4Oatke .

[afnan]

Soft Iron cores are being calculated in magcalMPU9250function as per your code So with these parameters after calibration Yaw seems to be zero at north (from mobile campus app north). Works perfectly if rotated at y axis of the board which results change in Roll (does not make yaw and pitch to change).

But upon rotation along x axis pitch and yaw change.

I am using following configuration MadgwickQuaternionUpdate(-myIMU.ay, -myIMU.ax, myIMU.az, myIMU.gy * DEG_TO_RAD, myIMU.gx * DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.mx, myIMU.my, myIMU.mz, myIMU.deltat);

[kriswiner]

Try negating accel.

What does your board look like?

On Wed, Sep 13, 2017 at 7:48 PM, afnan notifications@github.com wrote:

So with these parameters after calibration Yaw seems to be zero at north (from mobile campus app north). Works perfectly if rotated at y axis of the board which results change in Roll (does not make yaw and pitch to change).

But upon rotation along x axis pitch and yaw change.

I am using following configuration MadgwickQuaternionUpdate(-myIMU.ay, -myIMU.ax, myIMU.az, myIMU.gy DEG_TO_RAD, myIMU.gx DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.mx, myIMU.my, myIMU.mz, myIMU.deltat);

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-329354121, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqDFvwfAQolPHBeL5_bkg1rFV_20ks5siJQKgaJpZM4Oatke .

[kriswiner]

OK, according to the data sheet, if Mx is North, then

Ay, Ax, -Az, Gy, Gx, -Gz, Mx, My, Mz should be NED.

Then you might need to check to make sure you are constructing the yaw, pitch and roll correctly from the quaternions. This is what I do:

// Define rotation matrix from quaternions
a12 =   2.0f * (q[1] * q[2] + q[0] * q[3]);
a22 =   q[0] * q[0] + q[1] * q[1] - q[2] * q[2] - q[3] * q[3];
a31 =   2.0f * (q[0] * q[1] + q[2] * q[3]);
a32 =   2.0f * (q[1] * q[3] - q[0] * q[2]);
a33 =   q[0] * q[0] - q[1] * q[1] - q[2] * q[2] + q[3] * q[3];
pitch = -asinf(a32);
roll  = atan2f(a31, a33);
yaw   = atan2f(a12, a22);
pitch *= 180.0f / pi;
yaw   *= 180.0f / pi;
yaw   += 13.8f; // Declination at Danville, California is 13 degrees 48

minutes and 47 seconds on 2014-04-04 if(yaw < 0) yaw += 360.0f; // Ensure yaw stays between 0 and 360 roll *= 180.0f / pi; lin_ax = ax + a31; lin_ay = ay + a32; lin_az = az - a33;

On Wed, Sep 13, 2017 at 7:51 PM, Kris Winer tleracorp@gmail.com wrote:

Try negating accel.

What does your board look like?

On Wed, Sep 13, 2017 at 7:48 PM, afnan notifications@github.com wrote:

So with these parameters after calibration Yaw seems to be zero at north (from mobile campus app north). Works perfectly if rotated at y axis of the board which results change in Roll (does not make yaw and pitch to change).

But upon rotation along x axis pitch and yaw change.

I am using following configuration MadgwickQuaternionUpdate(-myIMU.ay, -myIMU.ax, myIMU.az, myIMU.gy DEG_TO_RAD, myIMU.gx DEG_TO_RAD, -myIMU.gz * DEG_TO_RAD, myIMU.mx, myIMU.my, myIMU.mz, myIMU.deltat);

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-329354121, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqDFvwfAQolPHBeL5_bkg1rFV_20ks5siJQKgaJpZM4Oatke .

[afnan]

Yes this technique works fine Yaw is working fine and zeros when MX points to north Interesting thing is Rotation across Board X axis (ax and gx but my) results in interesting variation.

Offset at rest is 8deg pitch while yaw and roll is Zero. Upon rotation Yaw (slight a 3-4 deg) and roll does not change, BUT once board is above 80 degree Roll increases and at 90 degree roll becomes 112 degrees which is senstive to rotation. If you rotate to zero Roll it will swing from +100 something to -100 something by just change of degree.

Is this some sort of limitation of the board or this system as it deals with spherical or 923Hz is not enough?

[kriswiner]

Can't remember which is which but roll is +/- 90 and pitch is +/- 180, so they should both "jump" from -89 to +89 or -179 to +179 with a few degrees change.

The other point is, at high pitch (or roll) angles, the yaw is indeterminate. You can see this by answering the question, At the North pole, which way is South?

On Thu, Sep 14, 2017 at 2:28 AM, afnan notifications@github.com wrote:

Yes this technique works fine Yaw is working fine and zeros when MX points to north Interesting thing is Rotation across Board X axis (ax and gx but my) results in interesting variation.

Offset at rest is 8deg pitch while yaw and roll is Zero. Upon rotation Yaw (slight a 3-4 deg) and roll does not change, BUT once board is above 80 degree Roll increases and at 90 degree roll becomes 112 degrees which is senstive to rotation. If you rotate to zero Roll it will swing from +100 something to -100 something by just change of degree.

Is this some sort of limitation of the board or this system as it deals with spherical or 923Hz is not enough?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-329426830, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qirUPmAdIPEbPB08M0QfM2lxWSFtks5siPG7gaJpZM4Oatke .

[mohitkhajuria]

@kriswiner Hi sir, I have built my own MATLAB implementation of Sensor fusion Algorithm using Kalman filter and steepest gradient descent based on IEEE conference paper.My results are pretty much accurate , in 100 percent correlation with the results given in paper based on Public data set( on which they have also tested ) When I run my code using my own Sensor Data(acc, gyro, mag), results are fine. But there are some issues which I am facing these two problems 1) In static position, YAW is always zero irrespective of its direction wrt to north. 2) I rotated device 360 degree along all axis using my hand.ROLL and YAW weird behavior is expected when PITCH approaches +/-90. This is fine. What i am worried about ROLL has impacted my YAW angle. YAW angle increases slighty when I start ROLLING the device.

I have done basic magnetometer calibration and removed gyro bias. How to go about it. Your help will really be appreciated.

Regards Mohit

[Patrickyp]

Kris I'm new to the whole concept of mpu could you elaborate this statement? "I am not sure how to see which accel axis points to north any idea how i can find that?" This is something you choose.

I know the accel has x y z axis? Is there a variable in code to set one of the axis to north?

[kriswiner]

No, it is a choice for the NED orientation convention. Select which board edge you want to point to true North. Now hwicj accel axis points in that direction? Whicj gyro and finally wich magnetometer axis. Good, all North axes are sotered. Nor since you now where Noth is, which ard edge points East? Again, which sensor axes does this correspond to. Finally, repeat the excversize for Down. Then once you know which sensor axes corrwespond to NED, input the sensor data into the Madgwick or Mahony algoruthms as NED data, so accelNED, gyroNED, magNED), remebering to formulate gyro data as radians per second. That's the magic formula...Repeat for a different choice of board edge as North or a different convention, like the ENU that Android uses...

On Wed, May 16, 2018 at 6:25 PM, Patrickyp notifications@github.com wrote:

Kris I'm new to the whole concept of mpu could you elaborate this statement? "I am not sure how to see which accel axis points to north any idea how i can find that?" This is something you choose.

I know the accel has a x y z axis? Is there a variable in code to set one of the axis to north?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/164#issuecomment-389715320, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qp2KwIfCTZg7y8dU1AIDDkVkaHIEks5tzNGXgaJpZM4Oatke .