Sensors let your app know the relationship between a device and the physical world around it. Sensors can tell you the direction, orientation, and movement of the device. 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 device to arrange the characters on the screen or to simulate the user being in a cockpit with the device as the steering wheel.
As a general rule, decide from the outset whether your app will depend exclusively on sensors, or if sensors will just offer an additional control mechanism for you app. For example, a driving game using a device as a virtual steering wheel could alternatively be controlled through an on-screen GUI – this way, the app works regardless of the sensors available on the system. A marble tilt maze, on the other hand, could be coded to only work on systems that have the appropriate sensors. You must make the strategic choice of whether to fully rely on sensors or not. Note that a mouse/touch control scheme trades immersion for greater control.
The Accelerometer sensor measures G-force values along the X, Y, and Z axes of the device and is great for simple motion-based applications. Note that “G-force values” include acceleration due to gravity. If the device has the SimpleOrientation of FaceUp on a table, then the accelerometer would read -1 G on the Z axis. Thus, accelerometers do not necessarily measure just coordinate acceleration – the rate of change of velocity. When using an accelerometer, make sure to decipher between the gravitational vector from gravity and the linear acceleration vector from motion. Note that the gravitational vector should normalize to 1 for a stationary device.
The following diagrams illustrate:
- V1 = Vector 1 = Force due to gravity
- V2 = Vector 2 = -Z axis of device chassis (points out of back of screen)
- Θi = Tilt angle (inclination) = angle between –Z axis of device chassis and gravity vector
Apps that might use an accelerometer include a game where a marble on the screen rolls in the direction you tilt the device (gravitational vector). This type of functionality closely mirrors that of the Inclinometer and could be done with that sensor as well by using a combination of pitch and roll. Using the accelerometer’s gravity vector simplifies this somewhat by providing an easily mathematically manipulated vector for device tilt. Another example would be an app that makes a whip’s cracking sound when the user flicks the device through the air (linear acceleration vector).
The Gyrometer sensor measures angular velocities along the X, Y, and Z axes. These are very useful in simple motion-based apps that do not concern themselves with device orientation but care about the device rotating at different speeds. Gyrometers can suffer from noise in the data or a constant bias along one or more of the axes. You should query the accelerometer to verify if the device is moving to determine if the gyrometer suffers from a bias. and then compensate accordingly in your app.
An example of an app that could use the gyrometer is a game that spins a roulette wheel based on a quick rotational jerk of the device
The Compass sensor returns a 2D heading with respect to magnetic north based on the horizontal plane of the earth. The compass sensor should not be used in determining specific device orientation or for representing anything in 3D space. Geographical features can cause natural declination in the heading, so some systems support both HeadingMagneticNorth and HeadingTrueNorth. Think about which one your app prefers, but remember that not all systems will report a true north value. The gyrometer and magnetometer (a device measuring magnetic strength magnitude) sensors combine their data to produce the compass heading, which has the net effect of stabilizing the data (magnetic field strength is very unstable due to electrical system components).
Apps that want to display a compass rose or navigate a map typically would use the compass sensor.
The Inclinometer sensor specifies the yaw, pitch, and roll values of a device and work best with apps that care about how the device is situated in space. Pitch and roll are derived by taking the accelerometer’s gravity vector and by integrating the data from the gyrometer. Yaw is established from magnetometer and gyrometer (similar to compass heading) data. Inclinometers offer advanced orientation data in an easily digestible and understandable way. Use inclinometers when you need device orientation but do not need to manipulate the sensor data.
Apps that change their view to match the orientation of the device can use the inclinometer sensor. Also, an app that displays an airplane that matches the yaw, pitch, and roll of the device would also use the inclinometer readings.
Device orientation is expressed through both quaternion and a rotation matrix. The OrientationSensor offers a high degree of precision in determining how the device is situated in space with respect to absolute heading. The OrientationSensor data is derived from the accelerometer, gyrometer, and magnetometer. As such, both the inclinometer and compass sensors can be derived from the quaternion values. Quaternions and rotation matrices lend themselves well to advanced mathematical manipulation and are often used in graphical programming. Apps using complex manipulation should favor the orientation sensor as many transforms are based off of quaternions and rotation matrices.
The orientation sensor is often used in advanced augmented reality apps that paint an overlay on your surroundings based on the direction the back of the device is pointing.
The SimpleOrientationSensor detects the current quadrant orientation of the specified device or it’s face-up or face-down. It has six possible SimpleOrientation states (NotRotated, Rotated90, Rotated180, Rotated270, FaceUp, FaceDown).
A reader app that changes its display based on the device being held parallel or perpendicular to the ground would use the values from the SimpleOrientationSensor to determine how the device is being held.
Build date: 11/16/2013