Roll and yaw angle confusion

[ct14872]

Hello Mr. Kris Winer

I have an issue with the filter updates that was bugging me for a few weeks now and I believe that you could provide me with a solution.

I started of by connecting 6 MPU9255 to an arduino UNO using an I2C expander. Producing an array of 6 MPU9250s as in your code, was filling up the memory so I trimmed a few variables and some functions that were used for SPI since I am using I2C communication. With the trim I was able to have all 6 sensors connected. The rate was something I had to trim out as well so I cannot tell for sure what rate this is working in.

Nonetheless, the problem I have did not depend as much on the number of MPUs for some reason. I noticed a very weird behaviour which, without much understanding, I believe it is gimbal lock. The problem occures when I rotate the IMU more than 90 degrees to the left. As soon as the yaw angle surpasses this value (-90 or 90) my roll is exploding from, e.g 10 to 160 in a matter of milliseconds. I am using the Madwick update filter passing in the raw data in this format:

MadgwickQuaternionUpdate(mpu[i].ax, -mpu[i].ay, -mpu[i].az, mpu[i].gx DEG_TO_RAD, -mpu[i].gy DEG_TO_RAD, -mpu[i].gz * DEG_TO_RAD, mpu[i].my, -mpu[i].mx, mpu[i].mz, mpu[i].deltat, i);

Which makes my yaw angle equal to 0 when the IMU is placed flat face up and facing north. At first i thought that the rate of update was not fast enough for 6 IMUs running on an arduino UNO. but then even with a single MPU i have this issue. The raw readings dont seem to show such an extreme behaviour.

I am also using these parameters:

Please any help would be kindly appreciated.

Thank you.

[kriswiner]

How do you calibrate the sensors?

On Wed, Aug 1, 2018 at 11:41 AM, Constantinos Theophilou < notifications@github.com> wrote:

Hello Mr. Kris Winer

I have an issue with the filter updates that was bugging me for a few weeks now and I believe that you could provide me with a solution.

I started of by connecting 6 MPU9255 to an arduino UNO using an I2C expander. Producing an array of 6 MPU9250s as in your code, was filling up the memory so I trimmed a few variables and some functions that were used for SPI since I am using I2C communication. With the trim I was able to have all 6 sensors connected. The rate was something I had to trim out as well so I cannot tell for sure what rate this is working in.

Nonetheless, the problem I have did not depend as much on the number of MPUs for some reason. I noticed a very weird behaviour which, without much understanding, I believe it is gimbal lock. The problem occures when I rotate the IMU more than 90 degrees to the left. As soon as the yaw angle surpasses this value (-90 or 90) my roll is exploding from, e.g 10 to 160 in a matter of milliseconds. I am using the Madwick update filter passing in the raw data in this format:

MadgwickQuaternionUpdate(mpu[i].ax, -mpu[i].ay, -mpu[i].az, mpu[i].gx DEG_TO_RAD, -mpu[i].gy DEG_TO_RAD, -mpu[i].gz * DEG_TO_RAD, mpu[i].my, -mpu[i].mx, mpu[i].mz, mpu[i].deltat, i);

Which makes my yaw angle equal to 0 when the IMU is placed flat face up and facing north. At first i thought that the rate of update was not fast enough for 6 IMUs running on an arduino UNO. but then even with a single MPU i have this issue. The raw readings dont seem to show such an extreme behaviour.

I am also using these parameters: [image: image] https://user-images.githubusercontent.com/10788292/43541629-c5b329ac-95c2-11e8-8c16-f70f4c0453d0.png

Please any help would be kindly appreciated.

Thank you.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/304, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qjzlK3-Y7Wb9G--gGKmj5jhFIgLwks5uMfZWgaJpZM4VrBnM .

[ct14872]

Thank you for your fast reply.

For accelerometer and gyroscope I use sparkfun's code which is identical to yours. As for the magnetometer, I created a new sketch where I connect it with matlab to get sketches of data while doing figure 8s. then I hardcoded these due to the problem i had with the memory of the Arduino UNO, as such:

switch (i) { case 0: mpu[i].magBias[0] = 254.71; mpu[i].magBias[1] = 251.17; mpu[i].magBias[2] = -383.09; mpu[i].magScale[0] = 1.01; mpu[i].magScale[1] = 1.03; mpu[i].magScale[2] = 0.96; break; case 1: mpu[i].magBias[0] = 295.72; mpu[i].magBias[1] = 273.31; mpu[i].magBias[2] = -365.80; mpu[i].magScale[0] = 1.01; mpu[i].magScale[1] = 1.02; mpu[i].magScale[2] = 0.97; break; case 2: mpu[i].magBias[0] = 204.50; mpu[i].magBias[1] = 412.13; mpu[i].magBias[2] = -233.50; mpu[i].magScale[0] = 1.00; mpu[i].magScale[1] = 1.04; mpu[i].magScale[2] = 0.96; break; case 3: mpu[i].magBias[0] = -33.50; mpu[i].magBias[1] = 218.61; mpu[i].magBias[2] = -262.48; mpu[i].magScale[0] = 0.96; mpu[i].magScale[1] = 0.96; mpu[i].magScale[2] = 1.09; break; case 4: mpu[i].magBias[0] = 226.41; mpu[i].magBias[1] = 255.55; mpu[i].magBias[2] = -145.37; mpu[i].magScale[0] = 1.03; mpu[i].magScale[1] = 1.03; mpu[i].magScale[2] = 0.94; break; case 5: mpu[i].magBias[0] = 69.21; mpu[i].magBias[1] = 63.89; mpu[i].magBias[2] = -126.56; mpu[i].magScale[0] = 1.05; mpu[i].magScale[1] = 1.00; mpu[i].magScale[2] = 0.96; break; }

The results of calibration of magnetometer look perfect:

It is worth mentioning that between yaw -90 to 90 (roughly) i get good results from the sensors.

[kriswiner]

Not sure I would call the mag calibration perfect but this is likely not your problem.

Are the sensor data fed to the fusion filter in NED orientation?

On Wed, Aug 1, 2018 at 12:06 PM, Constantinos Theophilou < notifications@github.com> wrote:

Thank you for your fast reply.

For accelerometer and gyroscope I use sparkfun's code which is identical to yours. As for the magnetometer, I created a new sketch where I connect it with matlab to get sketches of data while doing figure 8s. then I hardcoded these due to the problem i had with the memory of the Arduino UNO, as such:

switch (i) { case 0: mpu[i].magBias[0] = 254.71; mpu[i].magBias[1] = 251.17; mpu[i].magBias[2] = -383.09; mpu[i].magScale[0] = 1.01; mpu[i].magScale[1] = 1.03; mpu[i].magScale[2] = 0.96; break; case 1: mpu[i].magBias[0] = 295.72; mpu[i].magBias[1] = 273.31; mpu[i].magBias[2] = -365.80; mpu[i].magScale[0] = 1.01; mpu[i].magScale[1] = 1.02; mpu[i].magScale[2] = 0.97; break; case 2: mpu[i].magBias[0] = 204.50; mpu[i].magBias[1] = 412.13; mpu[i].magBias[2] = -233.50; mpu[i].magScale[0] = 1.00; mpu[i].magScale[1] = 1.04; mpu[i].magScale[2] = 0.96; break; case 3: mpu[i].magBias[0] = -33.50; mpu[i].magBias[1] = 218.61; mpu[i].magBias[2] = -262.48; mpu[i].magScale[0] = 0.96; mpu[i].magScale[1] = 0.96; mpu[i].magScale[2] = 1.09; break; case 4: mpu[i].magBias[0] = 226.41; mpu[i].magBias[1] = 255.55; mpu[i].magBias[2] = -145.37; mpu[i].magScale[0] = 1.03; mpu[i].magScale[1] = 1.03; mpu[i].magScale[2] = 0.94; break; case 5: mpu[i].magBias[0] = 69.21; mpu[i].magBias[1] = 63.89; mpu[i].magBias[2] = -126.56; mpu[i].magScale[0] = 1.05; mpu[i].magScale[1] = 1.00; mpu[i].magScale[2] = 0.96; break; }

The results of calibration of magnetometer look perfect:

[image: image] https://user-images.githubusercontent.com/10788292/43542358-aab74b86-95c4-11e8-838f-3e6747b2ca08.png

It is worth mentioning that between yaw -90 to 90 (roughly) i get good results from the sensors.

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

[ct14872]

I believe so. As I said this is the format that I am passing the arguements of the filter:

MadgwickQuaternionUpdate(mpu[i].ax, -mpu[i].ay, -mpu[i].az, mpu[i].gx DEG_TO_RAD, -mpu[i].gy DEG_TO_RAD, -mpu[i].gz * DEG_TO_RAD, mpu[i].my, -mpu[i].mx, mpu[i].mz, mpu[i].deltat, i);

For simplicity: AX , -AY, -AZ, GX, -GY -GZ, MY, MX, MZ

As for the mag calibration I even got better results. that is the first one I saved.

I am passing pitch roll yaw to Unity and i thought that the problem was from that side, but i realised that the sketch was causing this issue apparently.

[kriswiner]

This is not right. I East is -Ay, the East is - Mx, no?

On Wed, Aug 1, 2018 at 12:21 PM, Constantinos Theophilou < notifications@github.com> wrote:

I believe so. As I said this is the format that I am passing the arguements of the filter:

MadgwickQuaternionUpdate(mpu[i].ax, -mpu[i].ay, -mpu[i].az, mpu[i].gx DEG_TO_RAD, -mpu[i].gy DEG_TO_RAD, -mpu[i].gz * DEG_TO_RAD, mpu[i].my, -mpu[i].mx, mpu[i].mz, mpu[i].deltat, i);

For simplicity: AX , -AY, -AZ, GX, -GY -GZ, MY, MX, MZ

As for the mag calibration I even got better results. that is the first one I saved.

I am passing pitch roll yaw to Unity and i thought that the problem was from that side, but i realised that the sketch was causing this issue apparently.

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

[ct14872]

Sorry that was a mistake.when i was rewriting it for simple visualisation. Yes it is -MX

AX , -AY, -AZ, GX, -GY -GZ, MY, -MX, MZ

[kriswiner]

OK, then the only other thing left is speed. I woul;d use gyro/accel sample rates of 1 kHz, and then make sure you are iterating the fusion at 5 - 10 x of this rate. Can you do this on the UNO? I doubt it.

On Wed, Aug 1, 2018 at 12:41 PM, Constantinos Theophilou < notifications@github.com> wrote:

Sorry that was a mistake.when i was rewriting it for simple visualisation. Yes it is -MX

AX , -AY, -AZ, GX, -GY -GZ, MY, -MX, MZ

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

[ct14872]

So you are suggesting that even for a single MPU the UNO does not have the speed to do this?

Which microcontroller would you suggest using with the same dimensions as the UNO? I dont want the bulkyness of something bigger like the Mega

[kriswiner]

I would suggest this https://www.tindie.com/products/TleraCorp/ladybug-stm32l432-development-board/ (or its larger variants) if you want to do fusion on the host, otherwise I would (and do) use this https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution-mpu9250/ .

On Wed, Aug 1, 2018 at 12:47 PM, Constantinos Theophilou < notifications@github.com> wrote:

So you are suggesting that even for a single MPU the UNO does not have the speed to do this?

Which microcontroller would you suggest using with the same dimensions as the UNO? I dont want the bulkyness of something bigger like the Mega

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

[ct14872]

Would it be better if I were to send the raw data and the deltaT to Unity and perform filter update on the host computer?

[ct14872]

So that I can still use the UNO? This is a university project with a budget set and already reached.

Thank you for your help by the way.

[kriswiner]

No idea, just try it and see...

On Wed, Aug 1, 2018 at 1:19 PM, Constantinos Theophilou < notifications@github.com> wrote:

So that I can still use the UNO? This is a university project with a budget set and already reached.

Thank you for your help by the way.

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

[kriswiner]

See here https://github.com/kriswiner/MPU6050/wiki/Affordable-9-DoF-Sensor-Fusion for why the UNO will not work well.

On Wed, Aug 1, 2018 at 1:20 PM, Tlera Corporation tleracorp@gmail.com wrote:

No idea, just try it and see...

On Wed, Aug 1, 2018 at 1:19 PM, Constantinos Theophilou < notifications@github.com> wrote:

So that I can still use the UNO? This is a university project with a budget set and already reached.

Thank you for your help by the way.

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