Aligning sensors with your app’s orientation

The sensors supported by Windows Store apps offer a powerful way to spice up your app’s functionality. Sensors let your app know the relationship between the device and the physical world around it; the direction, orientation, and movement in those realms. These sensors can help make your game, augmented reality app, or utility app more useful and interactive by providing a unique form of input such as using the motion of the tablet to arrange the characters on the screen or to simulate the user being in a cockpit with the device as the steering wheel.

In this blog post I’ll review the supported sensors and offer some guidelines and suggestions for their best use. Devices are now much more varied in size, shape, and native orientation, and making a bad assumption about how sensors behave in various situations could cause negative reviews for your otherwise killer app. Check out the Sensors Overview video to learn more.

For a sample that uses the logic contained in this blog post, see the Display Orientation sample.

Display orientation vs. device orientation

Think of display orientation as the direction the pictures on the screen face whereas device orientation describes the physical positioning of the device. Display orientation doesn’t necessarily conform to device orientation. Take, for example, this device, where the arrow represents the display orientation:

In this picture the device orientation is in landscape as well as the display orientation. However, take these two:

Both tablets have the same device orientation (LandscapeFlipped) but different display orientations. The tablet on the left has display orientation in LandscapeFlipped while the tablet on the right remains in landscape.

Sensor-related apps that match their display orientation to the device orientation like the left-hand example above must validate their sensor data before using it. For instance, if the display orientation LandscapeFlipped, then the accelerometer data will also be flipped, and you’ll need to negate the data to get appropriate values. Understanding these conversions are simple after you understand how reference axes work.

Manipulating reference axes based on display orientation

When manufacturers integrate components into PCs, they must do so in a unified and consistent way so that everyone operates within the same reference frame.

We use reference axes to define how sensors report their data. The device’s landscape orientation, not current orientation, sets these axes as seen below with natively landscape and natively portrait devices:

Current orientation relatively defines the horizontal and vertical axes. Thus, in the above picture the device has +X projecting from the right while in landscape orientation, but have –X projecting from the right while in LandscapeFlipped (pictured below).

You can use this chart to understand how the reference axes translate for each display orientation. Notice that the Z axis stays constant while the X and Y axes often switch and require negation in order to establish new relativereference axes based on a transform of the absolute reference axes.

Display orientation and accelerometer and gyrometer

Now to start applying your understanding of display orientation and reference axes to get to correct sensor data: let’s start with the accelerometer and gyrometer. Because both the accelerometer and gyrometer map directly to the X, Y, and Z axes, you can transform these in a straightforward manner. Simply use the chart above and draw +X coming out of the right of the device, +Y coming out of the top of the device, and +Z coming out of the front of the device and compare against the absolute reference axes.

Accelerometer and gyroscope thus follow the same basic logic in mapping. If your app needed to apply these conversions to the gyrometer, for instance, use the below code:

Compass heading returns 2D data by projecting 3D magnetometer data onto a 2D plane, making the transform slightly trickier than for the sensors mentioned earlier. You need to compensate the returned heading with your display orientation or your heading will face the wrong direction:

The API compass heading must be modified as shown in this table to correctly display the heading:

While the inclinometer sensor provides robust data in an easy to understand format, the nature of its bounds and discontinuities make it considerably harder to mathematically manipulate than other sensor data. To make your life easier, I recommend you support only landscape display orientation when using the inclinometer in your app. You can do this by setting only setting landscape in the InitialRotationPreference in the app’s manifest.

Display orientation and orientation sensor

The orientation sensor uses advanced mathematical constructs (quaternion and rotation matrix) to represent the absolute physical orientation of the device in space. The math for its transformation, while somewhat straightforward, isn’t easy to visualize or conceptualize. Keep in mind that these different orientations can be thought of as rotations counterclockwise to the Z axis, so we need to do the reverse of the rotation to get back the user’s orientation. For quaternion data, we can use Euler’s formula to define a rotation with a reference quaternion and use a reference rotation matrix as well:

To obtain the desired relative orientation, you must multiply the reference object against the absolute object (Note: this math is not commutative):

where the absolute object is returned by the sensor data.

Wrapping up

The wide array of sensors supported by Windows 8.1 Store apps offers you lots of options for making your apps more interactive. As more and more devices of various sizes become available, keep in mind that readings they get from sensors are rationalized against the display orientation and device orientation. By following the guidelines outlined in this blog post, your app will be able to run elegantly on any device and in any orientation.

Disclaimer: SDKNews.com only syndicates the blog entries from various SDK blogs.
We are not the creator/author of these entries (posts). Product names, brand names
and company names mentioned on this site may be trademarks of their respective owners.