# IMU angle computation error

I am using MEMSENSE nIMU for getting only the Euler angles. However, i have a problem in the following case:

• When i try to rotate the IMU randomly and return to the initial position (i.e. lying still on a flat table), my data does not confirm that. (if i start from phi=0;si=0 and theta=0, at the end, my angles are not all zeros) as you can see except Phi angle, none of the angles returns to the "zero state".

Any suggestions?

• you need to use Directional Cosine Matrix or Quaternions Jun 1, 2014 at 2:26
• Why? My application is very simple right now i just want to check if my code is correct or not. I cant afford shifting to Quaternions just for that. Jun 1, 2014 at 2:30
• How are you calculating the angles (gravity vector, or gyro integration)? What is the part number for the IMU you are using? Jun 1, 2014 at 2:31
• I am using Gyro Integration. Part number is: NA02-0150F050 Jun 1, 2014 at 2:35
• For gyro integration, DCM is mandatory. Why don't you extract roll and pitch using the gravity vector? Yaw will require magnetic compass + DCM gyro integration. Jun 1, 2014 at 2:37

Congratulations. You've just discovered that Euler angles are not commutative. Consider the following scenarios.

You have 3 axes, roll, pitch and yaw. Take a sensor with the reference axis pointing straight up. Now pitch down 90 degrees. The sensor axis is now horizontal. Now rotate horizontally to the right (yaw right) 90 degrees. Your pitch axis is vertical and your reference angle is pointing 90 degrees to the right. Now do it again, but reverse the order. Yaw 90 degrees to the right, then pitch down 90 degrees. The reference axis is now pointing straight ahead, and the pitch axis is horizontal. You see the problem.

Now try a closed loop.

You have 3 axes, roll, pitch and yaw. Take a sensor with the reference axis pointing straight up. Now rotate vertically 90 degrees. The sensor axis is now horizontal. Pitch angle is -90. Now rotate horizontally to the right 90 degrees. Pitch angle is still -90. Rotate sensor 90 degrees clockwise around the reference axis. Pitch angle is -90. Rotate unit 90 degrees counterclockwise to bring the axis vertical again. The orientation of the unit is restored to its original state, but the pitch reads -90.

Euler angles are not commutative. That is, unlike translations, the order of the rotations matters. It's possible to deal with this but the math is unpleasant (although that's what computers are for). Quaternions are the most general framework to deal with the problem. Look up inertial navigation.

• But then what i can do now? I dont want to go to quaternions. My application is very simple. Right now i just want to check if my integration and code is correct or not. individually all the euler angles are working perfectly : i.stack.imgur.com/JsVZh.png i.stack.imgur.com/0oLC2.png i.stack.imgur.com/vhlyM.png (these are the image links to results from individual turns) Then why a combined movement should give errors? Jun 1, 2014 at 2:13
• Also My euler angles are according to navigation frame (fixed). These angles i get after transformation to the fixed frame of reference. Jun 1, 2014 at 2:37
• @UmerHuzaifa - I don't know what to tell you. Yes, the individual axes are working - you can move through one axis to some angle, then back again to the starting point, and your angles are zero, right? So you don't want to do quaterninons, there are less rigorous approaches. But you are going to have to do something, because this weirdness about angles is just the way the universe works, and you're going to have to learn the math to deal with it. Jun 1, 2014 at 2:53
• I think i have just understood you. Yes the issue is with the commutativity of the Euler Angles :) I have almost coded my whole way again checking every "variable" until coming up with this conclusion. Thank you very much. Although i still need a way out. (anyways, not very complex movements still give perfect results.. drive.google.com/file/d/0B2w3mmBOvQsIdjFrdWw1WkJ4cnM/…) Jun 5, 2014 at 2:16