Gyroscope on iPhone

[Completely revised]

(1) Strange Angles

At a first glance I mistook the situation as running into some typical problems related to Euler Angles. Because they are close to this problem area and really important to bear in mind, I leave this part of the original answer. Euler Angle problems are:

• Ambiguity, as the relationship between rotation state and Euler Angles representation is not bijective i.e. a set of angles describes one rotation but a rotation can be represented by more than one set of Euler Angles. In your question's Fig. 3 you can achieve the same rotation by either 1: Yaw=30°, 2: Pitch=90° or by 1: Pitch=90°, 2: Roll=30°
• Gimbal Lock problem: You may loose one degree of freedom and the device cannot rotate around one of the axes any longer. The solution is to use quaternions or rotation matrices.

But as you stated in your comment the true culprit seems to be the reference frame. Starting with iOS 5.0 Apple enhanced the sensor fusion algorithm and considers magnetic field data as well to calculate CMAttitude. Although there is still the old method startDeviceMotionUpdates, it now uses a default reference CMAttitudeReferenceFrameXArbitraryZVertical so that all measurement is related to "Z axis is vertical and the X axis points in an arbitrary direction in the horizontal plane".

In order to get your data in respect to the reference at start (or any other rotation) you need to store the CMAttitude instance you want as reference and then use CMAttitude's multiplyByInverseOfAttitude method to transform every new attitude i.e. at the beginning of your handleDeviceMotion method.

(2) Yaw Drifting

I think this is related to a bug in iOS 6 like the one I described in Drifting yaw angle after moving fast as it used to work fine in previous version. I filed a bug - let's see when they gonna fix it.

UPDATE 2

As comments and chat showed the goal was to control a robot by just tilting the device. In this case knowing the full rotation state of the device is messing up control when changing the walking direction. Thus a pure accelerometer based approach using CMDeviceMotion.gravity is far more convenient.