Mpu6050 gives me different values for same angular rotation ...

**Somehow i feel like this thread going to help people like me so i will try to share the things i found as much as possible. Please feel free to comment . I need all kinds of perspectives **

Ps: Since I am editing my topic constantly it is growing big but it has lots of information in it. As a non native English speaker it took my days . So please if there are some things against the forum rules let me know first. I will quickly fix it.

If i am to specify my objective for better understanding of the issue here it is ;
I am trying to make a rotation alert mechanism using mpu6050 inertial sensor . if there is certain amount of rotation occurs the led on the arduino turns on . Seems Very simple , very easy ...

However I am struggling for 2 weeks because i need certain degree of precision for my application .
I am using jeffs DMP code I can succesfully run "Teapot" example . And control 3D objects with mpu6050.
But i noticed something odd while i was debugging...
I saw that if i precisely rotate my mpu module 30 degrees and save that quaterion data ; and try to rotate 30 degree in the same direction again the two recordings were not mathing to each other.
I also noticed that when i only rotate arround y axis ; also x axis values are changing ....
Thats werent supposed to happen because in DMP code we are converting "quaternions" to "axis angle " values. So if i rotate arround x, it should just effect x values. Right? Am i missing something big here?

What do you think about it? What might be causing this ?

In here below are my belowed findings about this problem . I searched all internet. Every bit of information i stumble upon is here .And I am still digging .So please if you have any other informations about this share in this topic.

Edit 12 : This one outlines all the issues nicely , so make sure click the link and read all answers.

gyroscope - MPU-6050 - angle drift - Arduino Stack Exchange

T

Edit 11 : can we fuse magnetomer with dmp code ?

According to MPU-6050 6-axis accelerometer/gyroscope | I2C Device Library, " the DMP cannot produce fully fused 9-axis orientation data without some external computation done on the host processor. The DMP does not have the processing power necessry to do compute 9-axis fused data, even if the magnetometer is connected and properly configured as a slave device on the MPU-6050's AUX SDA/SCL lines." Hope you've already considered that!

Edit 10: Another question and another answer with use of magnetometer. Now how shall we calibrate magnetomer ....

The easiest way would be to add magnetometer support to this example. Algorithm is already there, you need to call method imu.getMotion9 and pass magnetometer values to it. Here is the tricky part - magnetometer axis are different from accelerometer and gyroscope, so you would need to rotate magnetometer values before passing them to match others. Take a look79 how they are placed relative to each other (page 38). Magnetometer calibration is another important step, there are different ways to do it, search for hard and soft iron calibration.
http://www.invensense.com/mems/gyro/documents/PS-MPU-9250A-01.pdf

and there is a lot of stuff about calibrating magnetometer..

Yaw value keeps decreasing? - #5 by larssoltmann - Hardware - Emlid Community Forum

Edit 9:

Correct. By far the best fusion algorithm for Arduino is RTIMUlib. Highly recommended!

There are more recent forks of that deposition, so look around for improved versions.

Edit 8: maybe thats all i need is a referance for yaw?

absolute yaw angle is not defined for that sensor. In order to determine yaw, you need a magnetometer to act as a North reference.

Edit 7 : dmp vs complimentary filter ..

Qualitatively, however, I can say that for pitch (rotation about the X-axis) and roll (rotation about the Y-axis), the calculations are fairly close, but the complementary filter seems to consistently lag the DMP. The DMP algorithm is able to calculate yaw, which the complementary filter cannot. I suspect that when the algorithms differ, the DMP is more accurate, however it is possible that a better implementation of the complementary filter might be able to reduce some of the lag.

Edit 6: there is this code and this is not effecting from yaw values but after 75 degree it gets crosstalk
between roll and pitch values. Very good code tho.

http://www.pitt.edu/~mpd41/Angle.ino

Edit 5: yaw and pitch vales changing together might be inevitable without a filter algoritm?

Yes, you will see this kind of cross talk when you are not feeding the
Madgwick filter the sensor data properly. It expects the data in a NED
format.

Edit 4 :Might be hardware related..?

The MPU-6050 is outdated and the modules on Ebay could have a wrong capacitor making it even more noisier. Can you give a reference for those formulas ? Without reference I have a lot of doubts. Looking at the code, I even have doubts about the 4ms delay. Your loop is probably more slowed down by the full output buffer of Serial than by micros(). I strongly suggest to use a library and you might consider to buy a MPU-9250. Are you perhaps using a 5V Arduino without I2C level shifter ?

Edit 3: Offsets are more important than you think ...!!

Offsets are usually necesary to run DMP, if not its measures fluctuate. It is not a startup thing, it will not work if offsets are very different from what should be.

Faster way maybe is to read raw values from sensors, and change offsets iteratively until you get that raw measures from every gyro and Xaccel and Yaccel are 0, and Zaccel is 16384. Then use those offsets with DMP

Edit 2: Some information about limitations . Does not apply to my problem but good to know if you are shaking your mpu and wondering what went wrong

Bad Fast rotation effect for Arduimu, MPU6050, 9150, 9250 - Discussions - diydrones
Best AHRS algorithm available for a moving application - Discussions - diydrones
might be usefull if you have same problem as me . Simply they are saying that there is a threshold for measuring rotation over time. İf ypu were to cross it you will lose data and wont able to return zero values . thats 2000 degree per second. But in my case i move my mpu slowly and still i have my issues

Edit 1: i found this topic but not much of a use ...

Edit 0 : about multiplying with 180 to get real angles...

At the same time I discovered this problem, I also realized that converting from radians to degrees was unnecessary, as the gyro output was already in units of degrees (just scaled by a sensitivity factor). After that big face-palm, I revised my rate formula to the following: rollRate = (0.7 * rollRate) + (-0.3 * gx / 16.4);. You will notice the scale factor has changed from 131 to 16.4. That is because the gyro range is actually +/-2000 deg/s by default, not 250 deg/s. I

Edit -1 : can i filter dmp data with kalman ?

The DMP data from the MPU6050 is already filtered, and while I have not expirimented with the DMP data much myself I believe it is pretty clean. If there is a calibration process you can do to improve it, that is probably worth expirimenting with, but you should not filter the values a second time.

Try getting calibration for your mpu6050?

Z

MPU6050_calibration.ino (7.64 KB)

zhomeslice:
Try getting calibration for your mpu6050?

Z

thanks alot for your reply , i have already tried that . no luck with that :frowning:

i am running out of time . Let me edit my question .

I'm using this version I created.it resolves several issues and its eat to adapt to you code. Try it out :slight_smile:
Not sure what else I can do with what you've given me to work with.
I'm familiar with the mpu6050 and use it often in my projects
Z

MPU6050_Latest_code.ino (7.95 KB)

zhomeslice:
I'm using this version I created.it resolves several issues and its eat to adapt to you code. Try it out :slight_smile:
Not sure what else I can do with what you've given me to work with.
I'm familiar with the mpu6050 and use it often in my projects
Z

I am greatfull for your response. I am trying right now . I will also edit my question since i discovered some possible leads to the issue i am having.

edit: i have tried your code . It is well coded but when i tilt mpu various angles only yaw value is changing . other are for example roll value cahnges back a little but immidiately returns back to certain value which is 0.64.

now i will try again with changing offsets with calibration . Any advice ?

karaposu:
I am greatfull for your response. I am trying right now . I will also edit my question since i discovered some possible leads to the issue i am having.

edit: i have tried your code . It is well coded but when i tilt mpu various angles only yaw value is changing . other are for example roll value cahnges back a little but immidiately returns back to certain value which is 0.64.

now i will try again with changing offsets with calibration . Any advice ?

I'm Struggling following your updates. Create a new post sharing your progress rather than updating the first post. this will help me in spotting your success or struggles rather than having to re read the entire first post.
Thanks.
Z

zhomeslice:
I'm Struggling following your updates. Create a new post sharing your progress rather than updating the first post. this will help me in spotting your success or struggles rather than having to re read the entire first post.
Thanks.
Z

I simply edited all topic . You do not need to re read all . My current problem is that yaw and pitch values are changing together. I need them to be individual.

The absolute yaw angle is not defined for that sensor. In order to determine yaw, you need a magnetometer to act as a North reference.

jremington:
The absolute yaw angle is not defined for that sensor. In order to determine yaw, you need a magnetometer to act as a North reference.

so will that solve my issue ? after mag referance if i rotate arround pitch the yaw angle will stay the same ? if thats the case that would help me a lot

Correct. By far the best fusion algorithm for Arduino is RTIMUlib. Highly recommended!

There are more recent forks of that deposition, so look around for improved versions.

Since my first post is full i will continue on here. this part is mostly about "magnetometer calibration " since i cant find decent code for it.

Edit 15:

If you are looking for some precision I would not use the function in world coordinates. This is because the yaw measure from the MPU is not really good, as it is not using a magnetometer measure. You can try but it didn't work for me.

So I suggest you use the real accel function, in local coordinates. In case you want to rotate the measures to another coordinate system, I would use pitch and roll from the DCM and yaw from the DCM fusionated with another reading from a magnetometer, for example.

In my experience, if there are many vibrations where your MPU6050 is located, you will need an extra calibration for the accel measures that return the realaccel function. I have found that this function returns a little offset depending on the frecuencies of this "environmental" vibrations. This is a bit complex and maybe far from your intentions....

Edit 16: ypr we shouldnt use them i think...

Roll, pitch, and yaw only make sense as relative to the vehicle. Unfortunately, if you convert your pose quaternion to RPY, you get RPY of the vehicle relative to the identity pose. As you deviate from the "straight ahead" heading, your pitch and yaw will become interrelated, and likely not represent what you think they represent.

Much better is a 3x3 rotation matrix that gives you the vectors that X, Y, and Z vehicle directions point in identity world space. You can then dot your own X with world up to see whether you're pitching down or up, and dot your own Y with world up to see whether you're canting left or right. (Assuming local X forward, Y left, Z up -- adjust for whatever convention you use.)

Similarly, if you can get your local X, Y and Z vectors in world space (which is what a rotation matrix is) then you can simply multiply the force vector you get from the acceleration sensor by that, multiply by time, and integrate into position. In column-vector-on-right systems, the first column of the pose rotation matrix P will be the world direction of your X vector, and thus P * acceleration A turns into the math of A.x scaling column 1 of P, A.y scaling column 2 of P, and A.z scaling column 3 of

Edit 17 : so much information ....cant take it anymore guys . But thats the only way

If you are just interested in roll, pitch and yaw then I did some work on AHRS with the Razor. SF made various revisions of the board using different chips any they all suffer from point 2 above (and each board revision is also different). The AHRS code or DCM (directional cosine matrix - google it for a great paper) has been part of webbotlib for a while. If its of interest then see http://webbot.org.uk/iPoint/49.page as it gives some examples

Edit 18 : here a very good video wihch uses quaternions and kalman . and code is there also ..

https://www.youtube.com/watch?v=p8H2-vkUM0I#

GitHub - danicomo/9dof-orientation-estimation: Orientation estimation algorithms based on IMUs and MARG sensors

Edit 19 :

One thing you could check is the value of beta if you are using the Madgwick
sensor fusion algorithm. I found that larger values of beta (~3) would
produce a more rapid convergence than the value recommended by Madgwick
(beta ~0.04) in his paper. A +/- 0.2 degree swing or jitter is not too bad
considering that the inherent accuracy of the MPU-9250 (or any) motion
sensor is at best a few degrees absolute and maybe a degree at best on a
relative basis. The other things you could try is to adjust the data sample
rates, especially the magnetometer. Try the 8 Hz setting, which should be
less jittery. You could adjust the accelerometer and gyro bandwidths lower
to get smoother behavior from these devices. Usually one should keep the
bandwidth about one-tenth the data sampling rate. So if you are sampling at
200 Hz, you should reduce the bandwidth to 20 - 40 Hz to get less jitter.
Lastly, you could write your own smoothing or averaging algorithm to reduce
jitter. Invensense suggests using the FIFO to reduce errors to to time
misalignment between data register reads. The sketch I wrote does not do
this yet but I think this is the right way to go to eliminate this source of
potential error. All in all I would say that if you are getting +/- 0.2
degree repeatability in your yaw, the sensor and the sensor fusion
algorithms are working properly.

edit 20 look here also

https://learn.sparkfun.com/tutorials/mpu-9250-hookup-guide?_ga=2.225372122.1124681611.1513648154-1486562402.1510876149

here is alek code somehow important that is

https://github.com/alex934/MPU9250Alek

Edit 21 : about pitch value being between -90 and +90 , and not between +180 -180

The convention RTIMULib(2) uses is that roll and yaw vary between -180 degrees and +180 degrees but pitch varies between -90 degrees and +90 degrees. Why doesn’t pitch also vary between -180 degrees and +180 degrees? It’s because a sphere is fully represented by these ranges and so it is unnecessary for all three axes to have the full range.

EDIT 22 : Here is another very good explanations about everthing realted to mpu's . Dont miss it..

[http://www.olliw.eu/2013/imu-data-

fusing/#refSM2](OlliW's Bastelseiten » IMU Data Fusing: Complementary, Kalman, and Mahony Filter)

Edit 23 : hardware tutorial /discussion about mpu's ... check to see what should you use for aplication of yours

[url=Create new page · kriswiner/MPU6050 Wiki · GitHub

https://github.com/kriswiner/MPU6050/wiki/Affordable-9-DoF-Sensor-Fusion[/url]
[/quote]

Edit 24 : some bad news about ahrs algoritm .And i am using pro mini 8mhz so....

I am generating the gyro, accel and mag samples at 300Hz sample rate,
which is what I configured the madgwick filter to use."

This is a problem. You will never get convergence of these kinds of
steepest-descent algorithms unless the fusion rate is 4-5x the gyro sample
rate. You will likely have to move to an ARM CORTEX M4F processor to get
adequate fusion results, assuming your calibration and sensor are up to the
task.

Edit 25 : information about magnetometer calibration....againnn .
enough of it already .

Best way to check mag calibration is to plot Mx vs Mz, then Mx vs My, then
My vs Mz from data collected while moving the mag all around like in
calibration. Do you get a cloud of points arranged in a circulat shape
centered on the origin? If yes, your mag is well calibrated. If not, you
have more work to do.

Edit 26 : location based magnetic values of earth, you will use this values for yaw offset

http://geomag.nrcan.gc.ca/calc/mdcal-en.php

Edit 27 : there area 2 tyes calibration for magnetometer

For more accurate orientation output, the magnetometer needs to be adjusted to compensate for offset errors (meaning a shift in either direction on the X/Y/Z axis), as well as something called 'soft iron error', which causes what should be spherical output of the magnetometer to actually be an elongated 'pill' shape or something similar.

Edit 28 : this is getting out of my control now....there is no standart method for calibration.

first of all here some good 9250 code with raw reading from 3 sensor

secondly
there is this video , i am now trying to make it work with 9250 ..hope it works

My advice is to just buy the BNO055, a more modern device which has none of these problems and can be used out of the box.

jremington:
My advice is to just buy the BNO055, a more modern device which has none of these problems and can be used out of the box.

hmmm does that mean this module automaticly fusion betweeen magnetometer accelometer and gyroscope values? or just uses accelometer and gyroscope values?

does that mean this module automaticly fusion betweeen magnetometer accelometer and gyroscope values

Yes. There is a lot of discussion on the Adafruit forums. Some people hate this IMU for reasons I do not really understand. I am not an expert and only use IMUs for demos like the teapot demo but wireless.

gdsports:
Yes. There is a lot of discussion on the Adafruit forums. Some people hate this IMU for reasons I do not really understand. I am not an expert and only use IMUs for demos like the teapot demo but wireless.

i believe bn0O55 needs you to convert magnetic values to something complicated.

here are the quotes i stumple upon (i literally read all posts realated to inertial sensors...)

kriswiner:
I am in the process of doing just that between the MAX2110X (no magnetometer), MPU9250, LSM9DS0, and BMX055. I will eventually get around to testing the LSM9DS1 and AK9912, et al. but I am starting detailed comparison testing with the four integrated motion sensors listed above.

I don't know what kind of error you are getting but my experience with the AK8963A embedded in the MPU9250 is that with proper bias calibration the data are pretty good. I have also had no problem with the LSM9DSX magnetometers nor the BMX055 but the latter is an odd duck in that the data are magnetic sense data plus a Hall resistance and the magnetic field has to be constructed out of these in software. Still, the resulting data seem OK. All qualitative. I will do quantitative comparisons in the next few weeks of accel, gyro, and mag as well as testing the different data inputs on the resulting open source sensor fusion quaternions, etc.

Right now I can tell you the MPU6500 (accel/gyro in the MPU9250) accelerometer has much lower jitter than the BMX055 accelerometer. I can't say much about the magnetometer relative performance yet but I would ask if your problem with the MPU9250 mag is that you have neglected the bias calibration; this will produce very bad results in any fusion solution.

from another discussion from github .
kriswiner:
If you have only a small amount of memory for programming you might want to use the BNO-055. It is slightly more expensive but has an embedded Cortex M0 processor that uses a pretty sophisticated Kalman-filter-based sensor fusion to output Quaternions and Euler angles directly from register reads. It also has most of the motion-triggered interrupt capability of the BMX-055. You can think of the BNO-055 as BMX-055 with a dedicated processor for sensor fusion. I think this is the way to go for most people unless you want to write your own sensor fusion for a specific application.

this is my edit, for calib there is steps . 1 each axis should aline so a sphere shapess
sec is that north must be north .

I think you are confusing two modes of operation: 1) fusion mode where the BNO055 reads the raw sensor data and computes the orientation and 2) open source fusion code mode where the BNO055 is only used to provide raw sensor data and the main CPU does the fusion computations. The discussion is about doing mode 2.

See reply #9. A problem with the BNO055 is that the sensor calibration is not described by Bosch and no one knows what the calibration status means. It works reasonably well, though.

RTImulib works better, and it works with the MPU9250, as well as several other sensors. Example here.

EDİT 27 :

Here is some codes for magnetometer calibration

[http://www.camelsoftware.com/2016/03/13/imu-maths-calculate-orientation-pt3/](http://www.camelsoftware.com/2016/03/13/imu-maths-calculate-orientation-
pt3/)

here is freeimu related calibration stuff

GitHub - mjs513/FreeIMU-Updates: IMU - FreeIMU Library Zero Drift, Altitude & LSM303 Heading Stability
https://www.youtube.com/watch?v=G6EtAeidDXk
http://www.varesano.net/blog/fabio/freeimu-magnetometer-and-accelerometer-calibration-gui-alpha-version-out

this one is the one which once i accidently lose and now found again. uses magnetometer with dmp check it out

https://www.youtube.com/watch?v=1UX-3ryOVH4

here exist a matlab code for finding calibration values. I once try to do calibration with matlab 3d skecth and succesfully implement that but i was stuck after that becauese i couldnt write the algoritm for how to mathematicly understand if all 3 shapes are spheres or ellipses. this code uses least mean square for that and might be usefull. idk

imu - Magnetometer ∞ shaped calibration - Electrical Engineering Stack Exchange

Now this one is excellent source. too much detailed information in here. also some codes for implamentation. maybe for such a detailed topic we need to go deep and deepest.. should you decide to solve all this here some very good source.good luck with that

excellent source here !!!