Drifting yaw angle after moving fast

Question

In my current project I ran into trouble regarding the quaternion provided by Core Motion's CMAttitude. I put the iPhone 5 (iOS 6.0.1) at a well defined start position. Then I start to move the device quickly around like in a fast pacing game. When I return to the start position after 10-30 seconds the reported yaw angle differ from the start position for 10-20 degrees (most of the time ≈11°).

I used the old (and sadly no longer available) Core Motion Teapot sample to validate the effect. The Euler Angles for logging are read directly from CMAttitude:

        NSLog(@"pitch: %f, roll: %f, yaw: %f",  attitude.pitch * 180 / M_PI, attitude.roll * 180 / M_PI, attitude.yaw * 180 / M_PI);

I found this on two different iPhone 5 devices manufactured at different times in different factories. But really weird is that my iPhone 4, running iOS 5.1.1, is working as expected. It seems to me an iOS bug and I filed a bug report already, but on the other hand I can hardly imagine that nobody had yet stumbled upon it. I suspect it might has to do with the redesigned Core Motion API. Starting with version 5 the magnetometer (compass) is considered for sensor fusion as well. Console shows that bias estimations from locationd are provided to CoreMotion:

locationd[41] <Notice>: GYTT inserted: bias,-0.196419,1.749323,-1.828088,variance,0.002644,0.004651,0.002527,temperature,31.554688

My question(s): Is there chance to block magnetometer readings when using Device Motion? I tried deactivating location services but it doesn't affect Core Motion. If not possible, what is the alternative / workaround, Accelerometer based gravity estimation?

PS: As we are dealing with quaternion based models this is not related to Gimbal Lock

EDIT: After doing some more measurements it seems clear that only yaw is affected. Pitch and roll show deviations within tolerance (<= 1°) while yaw is drifting regardless of the starting position. CMDeviceMotion.gravity appears to be clean too.

EDIT (2): I could reproduce the problem with the MotionGraphs sample attached to recent XCode versions. The yaw graph is reproducibly drifting away from origin.

Answer 1

Not the definitive solution but at least a workaround for my own question (I leave it as unanswered to invite you). It turned out that at least DeviceMotion.gravity is not affected by the bug. So I decided to redesign this pretty simple part of motion detection and use arcsin (gravity.x/||gravity||) for moving the main player character to the side when tilting the device.

This is definitely the second best solution as it destroys information about the full rotation status contained in a quaternion. I decided to it that way for strategical considerations:

1. I think most developers do tilt motion detection with the gravity vector rather than CMAttitude.quaternion because most people are not that amused about quaternion maths ;-) Thus any future bugs related to the gravity vector will probably be fixed during the beta phase because of a larger number of users.
2. If it is a software bug and not related to hardware issues, what I assume, and if the bug will be fixed ASAP, there is still a number of devices that might not get updated for what reason ever. Thus the risk that a potential future customer will run into trouble is small but > 0. So the second best solution might be sometimes the best.

Answer 2

I've done something similar in my own code and found the same z-axis rotational drift (yaw). I've applied a balanced filter. At each motion manager time interval, I grab the current quaternion (z-component) and then save that after calculations as oldZ, for use in the next set of calculations. My filter simply balances the NEW z value with the z value immediately preceeding it, preventing it from moving too much too quickly. Depending on your hardware and the exact tolerance in your program, you can manage drift quite well in this way. You will see the gyro drift slightly, but then begin to be corrected as the filter continues to act. My filter looks something like this and prevents more than 0.5 degree of "stray":

filtZ = 0.65 * oldZ + 0.35 * z;

The 0.65 and 0.35 values were determined experimentally and I would advise you to play with those as you have time. Output will still be scaled 0-1 and can then be utilized in the same way you've been doing (or re-introduced to the quaternion if you must retain all 4 dimensions throughoutf).