Initial inertial gestures

As much as micromachined accelerometers enabled new applications for inertial sensors nearly two decades ago, it's been packaging innovations for MEMS (microelectromechanical-systems) devices that have multiplied those opportunities manyfold. This statement is not to suggest that the back-end process developments alone could have created the large emerging markets for MEMS inertial sensors but rather that the opportunities for inertial sensing had early on been somewhat hamstrung by limitations imposed by the packaging available at the time. Today's chip-scale MEMS-packaging technologies offer excellent angular alignment—on the order of ±1°—and fit three-axis devices in substantially smaller footprints than previous-generation single-axis sensors.

Among the most commonly touted new applications are free-fall detectors for disk drives in laptops and other portable equipment and gesture-based user interfaces for mobile phones. The demands such applications make on sensor performance are not necessarily obvious, and, from a systems-design perspective, they suggest that sensing-subsystem designers should carefully construct the rules that govern how the sensor interface interprets its source signal early in the development cycle. The laptop-drop detector, for example, could try to account for all six degrees of freedom—translation in x, y, and z axes and rotation in roll, pitch, and yaw—to calculate the instantaneous inertial state and, in so doing, determine a state of free fall. More simply, it could determine that any shift from the nominal state greater than, say, 0.5 to 0.7G along any axis is sufficient evidence of an event of interest to park the drive heads. The distinction is that of threshold detection versus measurement.

The end concern with free-fall detection obviously does not center on the free-fall event per se; it's not the fall, as the old joke goes, but the sudden stop at the bottom against which the system must guard itself. So the challenge is not to measure the instantaneous inertial state with precision but to quickly and sufficiently assess the inertial state to determine whether action is necessary.

Gesture inputs impose a more complex set of operating conditions and detection goals and, though they do not mitigate destructive events, once promised they are no less critical to customer satisfaction. Unlike a laptop computer, the orientation of which changes little over a brief period during normal operation, a mobile phone's orientation during use is arbitrary and subject to rapid change. Additionally, it is unlikely that parking a drive's heads for a short time while a laptop's orientation is changing would diminish the user's experience, but ending a mobile telephone call, for example, by confusing the normal range of user motion for the control gesture meaning hang up is unacceptable.

Mobiles must also accommodate a comparatively large number of operating modes, each of which requires its own set of control inputs. On-hook functions, dialing, call-in-progress functions, and the phone's ancillary subsystems, such as a camera or an MP3 player, all invite their own combination of common and unique gesture in puts. The fact that the handset could be simultaneously executing multiple functions only complicates further the design of gesture-interpretation hardware and software.

Admittedly, few of us design laptops or mobile phones; one could question the relevance of this line of thinking to the design tasks that engage us. Yet significant advances in user-machine interfaces—rare though they may be—invariably migrate from early-adopting applications to a much broader range of OEM products. Few traditional user-interface designs need to consider end-user-behavior variability to the extent that gesture-based interfaces do, and we can learn much by watching how the pioneers, who exploit these interface technologies early, address the challenges.