Posted on April 24, 2013
Does YOUR phone have correct algorithms for Yaw-Pitch-Roll?
There is a lot more involved with rotation angles than evident at first glance. Use-cases for mobile devices necessitate a different set of conventions for mobile systems compared to aerospace systems. Implementations of yaw-pitch-roll conventions on a number of mobile platforms fail to meet the conventions laid out or are outright inconsistent. This can only frustrate developers.
To see the native convention for orientation on your mobile device:
- Install an app such as AndroSensor that displays sensor data, specifically “ORIENTATION”,
- Watch the pitch angle as you perform a full rotation in pitch — Did pitch go through the full range of -180° to 180°?
- Watch the roll in the same way — Did the Roll flip sign at the ±90° points, with yaw and pitch both flipping by 180° at the same time?
To see how your mobile browser implements the HTML5 sensor conventions, we put together this webpage to test it. Sometimes the native convention differs from the browser convention.
In general, consistent and clear conventions and a better certification process to ensure platforms follow these conventions will help to remove fragmentation in sensor implementations. The rest of this blog post serves to clarify the existing conventions and assist the developer and platform provider to ensure compliance.
Sensors measure values in the device or “body” frame, whereas developers are normally interested in quantities in the user or “world” frame. Transformations between frames, in particular world to body, can be accomplished in multiple ways: yaw-pitch-roll rotation angles, rotation matrices, or quaternions.
In three dimensions, Euler proved that any orientation of a device can be expressed in terms of up to three elemental rotations around coordinate axes, commonly called yaw, pitch, and roll. These rotation angles have a tradition in aerospace to describe the motion of a ship or plane, but contain ambiguities (also called gimbal lock). Problem-free representations of the transformation can be done using rotation matrices, which use 9 numbers, or even better using normalized quaternions, which use only 4 values with a unit-norm constraint.
Still, there are times yaw-pitch-roll is a useful representation to developers, and given these orientation angles are exposed by the OS, it would be nice if every device was consistent on these conventions. We therefore explain the conventions adopted in mobile devices and how they compare to aerospace conventions. Since the majority of references on this topic are based on aerospace, there has been general confusion and, in fact, many erroneous implementations on mobile devices.
In aerospace, there are a number of different conventions used to define world frame. One of the most common is “East North Up” (see Table 1). The world frame definition in mobile platforms (including Android, Win8, and HTML5 Web Standards) is defined differently but ends up being the same (up to magnetic vs. true North).
For body frame, the aerospace convention has the aircraft flown towards the positive x-axis with the y-axis port-side. Since mobile devices are not typically flown like aircraft, the notion of port-side and pointing ahead are at best tenuous. Instead, the notion of “natural orientation” is used, which is the default orientation of holding the device when interacting with it and the screen is on. Note the body definitions are different from aerospace, essentially rotating the x\- and y-axes definitions.
So why the difference? Why not make life simpler and choose a mobile convention with body axes the same as aerospace? The answer lies in system engineering and understanding the typical use-case of the device. Ask a user, holding their device in its natural orientation, how they would draw a graph on the screen. The vast majority would choose to draw the y-axis point out the top of the device and the x-axis pointing right. Screen conventions have long been established to obey this as well.
Yaw, Pitch, and Roll Conventions
Yaw, pitch, and roll motions are transformations from world to body frame with motions performed relative to body-frame axes. There is a difference between aerospace and mobile conventions as shown in Table 2.
|Rotation angle||Aerospace||Mobile (except Android has clockwise)|
Android’s method uses a flipped world frame convention which is equivalent to using the standard mobile world frame (Table 1) but with clockwise rotations. Otherwise all mobile conventions for yaw-pitch-roll are the same.
However, when compared to aerospace, there is an important difference. It should be noted there is an ambiguity that needs to be resolved by restricting one of the three angles to less than a 360° range. Consider the following exercise: Lay your phone flat on a table. Rotate in yaw (around the z-axis) 180° then rotate in pitch (around the x-axis) 180° and finally rotate in roll (around the y-axis) 180°. You should arrive at the same exact orientation as when you started. Yet the yaw-pitch-roll angles all differ by 180° from the starting point.
In order to remove this ambiguity — i.e., to ensure a one-to-one mapping of all possible yaw-pitch-roll angles to all possible orientations — one of the rotation angles must be restricted to a 180° range. This is where another important difference in conventions arises. For aerospace conventions, pitch is restricted to the range of -90° to 90°. For mobile conventions, the roll angle is the angle restricted to -90° to 90°. This makes computation of pitch and roll a little more tricky, and indeed some mobile devices implement this incorrectly.
Again, one might ask: why adopt a different convention in mobile? The answer again lies in a system perspective. For phone or tablet use in natural orientation, the pitch motion is far more prevalent than roll motion. Rolling passed 90° means the user is looking at the back of their device whereas someone while interacting with the phone can lean back in bed and look up towards the sky, going through a full 180° in pitch. So to avoid discontinuities in angle when a user is looking at the screen, the conventions are to allow a full continuous range in pitch. In general, pitch gives the full “tilt angle.” Even in landscape mode of a phone, rolling passed 90° will cause the pitch to flip by 180°, allowing it to be used to to determine the device is being used “upside down.” This provides a strong enough case to deviate from traditional aerospace conventions.
Notes of Caution when Using Yaw-Pitch-Roll
There is one more convention, the order in which yaw, pitch, and roll are applied to determine an orientation. For example, applying yaw, pitch and then roll can lead to a vastly different orientation compared to being applied in the reverse order. As an exercise, with a phone flat on the table, pitch it 90° (around x-axis) then roll it 90° (around y-axis). Now reverse those, applying roll first then pitch. This shows completely different final orientations. Here both aerospace and mobile conventions agree to apply yaw, then pitch, then roll. This means, for example, if a pitch motion is performed first, then yaw cannot be subsequently applied.
Also, a word on the ambiguity often referred to as gimbal lock. At this point, the difference of yaw and roll is completely undetermined for a pitch of 90°. Slightly away from a pitch of 90°, there is still an exact solution for yaw and roll. But small changes in orientation can lead to rather large changes in yaw and roll angles separately while keeping changes to the sum small. In noisy sensor systems, it is possible small fluctuations in quaternion can show up as large changes in yaw and roll. Similar issues occur at pitch of -90°. Therefore, one must be careful in interpreting differences in YPR values.