Rotation around Z-axis

[yKanayama]

In a literature, IMU_Wk8.key, I found this claim: "If the X-axis is aligned along the gravitational acceleration vector, it is impossible to compute rotaion around the Z-axis from the accelerometer"

I implemented MPU6050 for the very purpose of getting rotation around the Z-axis. Is it really true? If so, I am really sad!

Thanks in advance, yk

[RufusWein]

Yes, so is, you need a compass and combine it with the 6050 (or another 6050). This way you can get rotate X,Y,Z. A new challenge is presented to you, GO!! ;)

[yKanayama]

RufusWein, thank you for the quick clafification. But I was astonished to have found this. Now I have questions to you and Jeff Rowberg:

MPU-6050 Product Specification claims that: "The MPU-60X0 is the world's first integrated 6-axis MotionTracking defice that combines 1 3-axis gyroscope, ...."
Is this claim precise? From what I have known , it lookd like having only 5 axis. Also you prepared a function: accelgyro.getMotion6(&ax, &ay, &az, &gx, &gy, &gz); Then what does the part &gz mean?

I feel I was ripped off by InvenSense Jeff. Almost one year of hardware construction effort becomes meaningless. yk

[yKanayama]

Jeff, I was astonished to have found this. Now I have questions to you:

MPU-6050 Product Specification claims that: "The MPU-60X0 is the world's first integrated 6-axis MotionTracking defice that combines 1 3-axis gyroscope, ...."
Is this claim precise? From what I have known , it lookd like having only 5 axis. Also you prepared a function: accelgyro.getMotion6(&ax, &ay, &az, &gx, &gy, &gz); Then what does the part &gz mean?

I feel I was ripped off by InvenSense and Jeff. Almost one year of our hardware construction effort becomes meaningless.

Yutaka Kanayama

On Sep 29, 2015, at 3:19 AM, Rufus notifications@github.com wrote:

Yes, so is, you need a compass and combine it with the 6050 (or another 6050). This way you can get rotate X,Y,Z. A new challenge is presented to you, GO!! ;)

— Reply to this email directly or view it on GitHub https://github.com/jrowberg/i2cdevlib/issues/190#issuecomment-144015805.

In a literature, IMU_Wk8.key, I found this claim: "If the X-axis is aligned along the gravitational acceleration vector, it is impossible to compute rotaion around the Z-axis from the accelerometer"

I implemented MPU6050 for the very purpose of getting rotation around the Z-axis. Is it really true? If so, I am really sad!

Thanks in advance, yk

[jrowberg]

Hello @yKanayama,

The MPU-6050 is a 6-axis digital MEMS device, containing a 3-axis accelerometer and a 3-axis gyroscope. The accelerometer provides linear acceleration (e.g. meters per sec^2), while the gyroscope provides rotational velocity (e.g. degrees per sec). These properties are common to virtually any 6-axis digital motion sensor. The MPU-6050 does give perfectly valid data on all six axes (three axes from each of the two internal sensing cores)

The additional DMP contained in the device performs 6-axis motion fusion, which incorporates all of the available data and processes it into a quaternion which represents a unique orientation. A quaternion is a 4-value list made up of [Rotation about X axis, Rotation about Y axis, Rotation about Z axis, Rotation about X/Y/Z vector). This makes it possible to provide a quaternion for literally every possible orientation without encountering the problem known as gimbal lock, which occurs when you use simple trig functions with respect to gravity.

However, the MPU-6050 alone (including the DMP) cannot avoid the problem of yaw drift. This occurs around the axis that is parallel to the gravity vector, due to imperfections in the gyroscope sensor. The DMP relies primarily on gyroscope output for rotation detection, but augments this data with acceleration due to gravity to make sure that pitch and roll values are accurate and do not drift, since gravity is always straight down and provides a good reference point. But gravity has exactly zero effect on yaw (heading) data. So while the DMP still incorporates Z axis rotation to compute and report heading, it is mathematically impossible for obtain guaranteed accuracy over time, since there is no absolute reference point (like gravity) available.

This is why comprehensive AHRS devices incorporate 9-axis devices that include a magnetometer as well. The magnetometer (digital compass) provides the absolute reference of magnetic north to compensate for potential yaw drift. This is not an obscure requirement; it is fundamental to any 6-axis vs. 9-axis design.

[yKanayama]

Dear Jeff,

Thank you so much for teaching me the deep thought and analysis.

We have been constructing a table-top science robotic vehicle for the purpose of (eventually) mass producing a novel IT product, which I call MATH MIND. This prototype robot, currently, uses an iPhone or iPad as both human-interface and the main CPU with BLE113. It has the odometry function (keeping the best estimation of current ((x, y), theta)) using only the incremental motions of the two motors. But the values drift over time. That is why I wanted at least the absolute yaw through your MPU 6050. And my expectation was wrong.

After reading your email, I found you announced MPU 3300 and published its data sheet. (Years ago I learned the basics about quaternion a little.) I believe this chip has the AHRS capacity that satisfies our purposes. Since the physical dimensions of 60X0 and 3300 looks the same, we could be able to replace the former with the latter. Right now it cost $65 a piece, but in the future it will be reduced i hope.

I have a few more questions; please educate me.

How can I get a header files for 6050/3300 for Arduino? Right now I cannot use the function "setFullScaleGyroRange(MPU6050_GYRO_FS_2000)” in my code, for instance. What is DMP and which one do you recommend for me?

Just FYI, this is a picture of our current prototype robot MATH MIND. Its diameter is about 13 cm:

Thank you so much for your help in advance, Yutaka.

Yutaka Kanayama, Ph.D. MotionLab, LLC; President and CEO 501 Camino Aguajito #114, Monterey, CA 93940 kanayama@motionlab.com 831-375-9641; Cell 831-383-9495 Skype: yutakakanayama https://www.youtube.com/user/motionlabLLC/videos https://www.youtube.com/user/motionlabLLC/videos http://www.motionlab.com http://www.motionlab.com// http://www.vehiclemotion.net http://www.vehiclemotion.net//

On Sep 29, 2015, at 8:16 PM, Jeff Rowberg notifications@github.com wrote:

Hello @yKanayama https://github.com/yKanayama,

The MPU-6050 is a 6-axis digital MEMS device, containing a 3-axis accelerometer and a 3-axis gyroscope. The accelerometer provides linear acceleration (e.g. meters per sec^2), while the gyroscope provides rotational velocity (e.g. degrees per sec). These properties are common to virtually any 6-axis digital motion sensor. The MPU-6050 does give perfectly valid data on all six axes (three axes from each of the two internal sensing cores)

The additional DMP contained in the device performs 6-axis motion fusion, which incorporates all of the available data and processes it into a quaternion which represents a unique orientation. A quaternion is a 4-value list made up of [Rotation about X axis, Rotation about Y axis, Rotation about Z axis, Rotation about X/Y/Z vector). This makes it possible to provide a quaternion for literally every possible orientation without encountering the problem known as gimbal lock, which occurs when you use simple trig functions with respect to gravity.

However, the MPU-6050 alone (including the DMP) cannot avoid the problem of yaw drift. This occurs around the axis that is parallel to the gravity vector, due to imperfections in the gyroscope sensor. The DMP relies primarily on gyroscope output for rotation detection, but augments this data with acceleration due to gravity to make sure that pitch and roll values are accurate and do not drift, since gravity is always straight down and provides a good reference point. But gravity has exactly zero effect on yaw (heading) data. So while the DMP still incorporates Z axis rotation to compute and report heading, it is mathematically impossible for obtain guaranteed accuracy over time, since there is no absolute reference point (like gravity) available.

This is why comprehensive AHRS devices incorporate 9-axis devices that include a magnetometer as well. The magnetometer (digital compass) provides the absolute reference of magnetic north to compensate for potential yaw drift. This is not an obscure requirement; it is fundamental to any 6-axis vs. 9-axis design.

— Reply to this email directly or view it on GitHub https://github.com/jrowberg/i2cdevlib/issues/190#issuecomment-144270345.

[RufusWein]

DMP(Digital Motion Processor - Trademark of Invensense) is part of the MPU which is responsible for translating the values of motion sensors in values that can be processed by the user(to FIFO). MPU-6050(X,Y) + Digital Compass (for example HMC5883L)(Z)= (X,Y,Z) or MPU-6050(X,Y) + MPU-6050 (Z) = (X,Y,Z) or (more expensive) MPU-9150 (9axis, MPU6050 + Compass).

[jrowberg]

Note also that the DMP does make use of the Z gyro and accel data on the MPU-6050 even without a magnetometer (compass) attached. However, it just cannot correct for yaw drift in the same way it can correct for roll/pitch drift on the axes perpendicular to the gravity vector. This is not a shortcoming of the DMP, as noted above; it is a mathematical impossibility.

[yKanayama]

Dear Rufus and Jeff,

Thank you so much to educate me about DMP and the principle of 6050 capacity. Since we cannot implement new hardware in this prototype vehicle, we will obtain the yaw with the software even drift is expected.

I have another question:

1. What is the default 6050 Gyroscope sensitivity when we purchase it? Among FS_SEL=0, … , FS_SEL=3?
2. To change the default sensitivity, I need to use "setFullScaleGyroRange(MPU6050_GYRO_FS_xxxx)” I guess. However, when I call the function in my Arduino code, I get an error message. Please let me know what header file I need to download, and from where? Currently we have installed:

   include // I2C

   include // UART

   include // GYRO SENSOR

   include // RGB LED

Thanks in advance,

Yutaka

[carycode]

yKanayama wrote:

How can I get a header files for 6050/3300 for Arduino? Right now I cannot

use the function "setFullScaleGyroRange(MPU6050_GYRO_FS_2000)" in my code, for instance.

I'm pretty sure what you really want is 'How do I get the library that will let me use the function "setFullScaleGyroRange(MPU6050_GYRO_FS_2000)" in my code.'.

A brief skim of the descriptions of these libraries makes me think either one of these libraries would work for you:

https://github.com/zrecommerce/freeIMU

https://github.com/mjs513/FreeIMU-Updates

After properly installing that library (I hope someone else will go into details), you should be able to call the setFullScaleGyroRange() function in your code.

I personally find it very useful to look at the "Examples" directory that comes with most Arduino libraries (including the above libraries).

In particular, I hope you find the following example files that call the setFullScaleGyroRange() useful:

https://github.com/spanner888/AirMousePlus/blob/master/MPU6050_DMP6_Interrupts/MPU6050_settings.ino

https://github.com/mjs513/FreeIMU-Updates/blob/master/libraries/MPU60X0/Examples/MPU6050_raw_temp/MPU6050_raw_temp.ino

https://github.com/zrecommerce/freeIMU/blob/master/libraries/MPU60X0/examples/MPU6000_DMP6/MPU6000_DMP6.ino

https://github.com/zrecommerce/freeIMU/blob/master/libraries/MPU60X0/MPU60X0_6Axis_MotionApps20.h

p.s.: While it is impossible to completely eliminate yaw drift using only gyros and accelerometers, with a table-top robot it is often possible to cancel out a lot of the yaw drift by taking advantages of the times when the robot "knows" it is sitting motionless on the table to re-calibrate the zero-rotation offset bias of the gyros.

As you probably already know, humans lost in the woods often accumulate yaw drift and end up walking in circles. You may be able to use some of the many sensors and techniques humans use to compensate for that.

A library in many programming languages includes both a header file and an implementation file; the header file alone won't work. Also, the header file and the implementation must be the same version -- the programmer who maintains that library often must fix bugs by changing both the header and the implementation, and if you somehow get the pre-fixed version of one and the post-fixed version of the other, that leads to very difficult-to-debug problems.

"Downloading Header Files" http://stackoverflow.com/questions/4387862/downloading-header-files

"Where can I download a missing header file?" http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1043806235&id=1043284385

David Cary http://OpenCircuits.com/ http://david.carybros.com/

[PatelKishanJ]

Hello jeff,

I have using atan formula to find magnetic direction.But its working good if Device put in position by which magnetic- z direction will vertically down. So,if i change the device position like that magnetic x direction will vertically down.So,below formula to find the direction will be wrong. heading_dir = 90 - ( atan ( mx / my ) ) * ( 180 / PI ) - 23.5; //here, 23.5 is a declination angle.

So,any idea by which i can find that which direction is vertically down?.