Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
459 views
in Technique[技术] by (71.8m points)

iphone - Drifting yaw angle after moving fast

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:

Start Position Same place after 15 seconds

        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.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

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.

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...