I know the (pitch, yaw, roll) coordinate system has its own flaw mathematical-wise. However I really hope something instead or derived from this coordinates can be an alternative.
What I am try to do is moving the device (let’s say it’s an iphone) in the real world and trying to figure out the yaw and pitch regarding to user’s eye. Thus, the range of yaw should be (-180, 180) and range of pitch should be (-90, 90). While I move the iphone(always facing me) from bottom to front, the CMDeviceMotion gives me pitch changes from 0 to 90 and while I move the iphone(still facing me) from front to top, the CMDeviceMotion gives me pitch changes from 90 back to 0. These are good and I am perfectly happy about pitch data.
However, when pitch is close to 90, yaw is very shaky and unstable. Will, this is not the problem because I can ignore the change on yaw when pitch is around 90. However, the real problem is that the value of yaw changes dramatically before pitch increasing and after pitch decreasing. I mean it is not only shaky but the mean changes! changes something like 180(Pi). I guess that is because the coordinate totally changes. But I am lost on the coordinate transfering now.
This messy workaround you just described is exactly the reason why you should not use roll, pitch and yaw.
You either go on this road further and make the mess bigger or use rotation matrices or quaternions.