
Figure 1: Integrating MEMS sensors—which have become essential building blocks of consumer electronics—is called “sensor fusion.”
Micro-electromechanical systems (MEMS), tiny machines that add intelligent sensing and actuation to countless mobile devices, have had a huge worldwide impact over the past several years. The adoption of MEMS has expanded far beyond the use of MEMS accelerometers to other types of MEMS sensors, including gyroscopes, pressure sensors, and altimeters. While these sensors have increasingly become critical building blocks within a variety of mobile operating systems, each carries its own set of unique challenges — challenges that sensor suppliers must resolve.
Consumer Apps Driving Sensor Demand
Consumer electronics has and continues to drive the broad adoption of sensors to enable a host of clever and useful functions, such as screen rotation, gesture recognition, and user-interface control.
Thanks to sensors, a simple single- or double-tap on the side of a smartphone can advance the cursor on a text input line, call home, or access voicemail. Gesture recognition can allow a user to teach his/her smartphone, tablet PC, or IPTV controller to recognize and respond to a variety of input motions.
ADVERTISEMENT
Video game controllers, the hottest market for MEMS sensors, deliver a more exciting and more realistic game experience through the use of MEMS gyroscopes and accelerometers.
Personal navigation minimally requires sensors for pedometry, which is a simple method of determining distance traveled. However, they are also required to complete the much more complex task of attaining accurate global positioning, regardless of conditions. As a result, a common motion-sensor suite (Figure 1) has evolved in these electronic systems. It includes the use of tri-axis accelerometers, magnetometers, gyroscopes, and, even more so, pressure sensors, to augment the global positions or location-based service solution.
For example, accelerometers, magnetometers, and gyroscopes working together can give you pitch, roll, and yaw orientation in various data formats, but the inclusion of a pressure sensor can help with measuring altitude. A race to combine these sensors quickly, efficiently, and at competitive price points is underway.
Integration Challenges
Combining accelerometers — MEMS sensors that have been used the longest in handheld devices and mobile operating systems (OSs) — with gyroscopes and magnetometers is full of integration challenges.
For example, an accelerometer can easily measure static pitch and roll orientation, but has limitations such as high noise and dynamic conditions.
During movement or rotation, the gyroscope and magnetometer are able to work together to filter some of this noise. However, this comes at the cost of a slower response and excessive filtering that can lead to significant lag time.
A magnetometer delivers an absolute heading reference, which is very useful, although it has some limitations as well. It measures the X, Y, and Z magnetic field strength, and is often used to calibrate yaw of the gyroscope. However, the magnetometer is susceptible to local magnetic field interference. It also has a typically slower response than other motion sensors and has placement limitations on a PCB.
A gyroscope outputs a rate of angular rotation, not to be confused with an angle, in degrees per second. The response is very fast and smooth, requiring integration to occur at a very high rate. As such, time intervals and references are critical. Furthermore, gyroscopes have a very high current draw because they are typically active sensors.
Pressure sensors, which measure atmospheric pressure to determine altitude, are very useful for location-based services inside buildings, for example.
All of these sensors have their strengths and weaknesses, but are now an integral part of sensor fusion for mobile systems. The gyroscope gives you X, Y, and Z rotation; the magnetometer, with the help of the accelerometer, tells you where your device is oriented with respect to magnetic north; and the accelerometer gives you the gravitational component and linear acceleration. Through proper sensor fusion, you can differentiate your devices’ orientation in and translation through 3D space.
Sensor Fusion & the Mobile OS
Sensor fusion is used to convert the combined raw signals from multiple sensors to create new, more-useful sensor types. These new sensor types may represent orientation in quaternion, rotation matrix, Euler formats, or a differentiation of the earth’s gravitational pull from input linear acceleration. In the operating system, these new sensor types should be passed through the application interface (API) and made available to application developers. This approach takes the place of passing raw acceleration data, rate, or heading through the API, and expecting that the application developers will understand the physics behind it all.
Each mobile platform — whether Google Android, Microsoft Windows, or Apple iOS — has its own set of sensor integration challenges that must be overcome to maximize sensor functionality and user experience. The platforms are diverse, and the software stacks and sensor interfaces are different from one other. Consequently, sensor companies typically obtain early access to development hardware and software in order to write drivers and program solutions for these various platforms. We then collaborate with our customers and their technology partners to integrate device hardware, embedded algorithms and software applications, and the OS platform.
 |
Figure 2: Integrating MEMS sensors with Windows requires initializing the sensors and passing their data to the Windows sensor framework via a USB device.
|
Microsoft Windows
Microsoft Windows’ many benefits are well known. It provides a widely used application development platform with liberal code reuse that allows many people to develop in it adeptly. However, a major sensor integration drawback has been a lack of native I²C support.
Sensors tend to be wedged into USB format, which is overkill, particularly when the design includes a low-current accelerometer paired with a dedicated USB node. With motion sensors typically at the bottom of the Windows system stack, it is difficult to get the data from the sensors up to a PC application (Figure 2). Utilizing I2C or SPI, an extra processing device is needed to initialize all of the sensors and pass their data to the Windows sensor framework as a USB Human Interface Device.
 |
Figure 3: Google’s Android sensor stack conveniently offers native I²C support through the application processor’s integrated Southbridge.
|
Google Android
Kionix sensors reside at the bottom of Google’s Android software stack as well. However, this platform conveniently offers native I²C support through the application processor’s integrated Southbridge (Figure 3). There are multiple I²C iterations and readily available source code examples, but, with Android’s accelerated evolution, the priority for developers is to stay current with its builds and procure new hardware development kits as they are released.
Fortunately, Google’s OS runs on a wide range of devices and they all have supported sensors. From the beginning, sensors have interacted directly with Linux Kernel drivers that pass data through the hardware abstraction layer (HAL) and up into the application layer. The challenge lies in identifying the ideal location for sensor-fusion computations going forward.
Apple iOS
Apple’s widely-used iOS platform also has many benefits, including block handling for sensor data through the core motion framework. It also has a very stable, unchanging hardware platform. However, as a sensor supplier, the major drawback is the platform’s unique closed system. Software is custom-developed for a specific piece of hardware and, thus, cannot be repurposed for other applications.
The Future of OS Integration
While we are making great strides in sensor fusion and integration with mobile OSs, there is still room for improvement. For example, the sensor industry would like to see native I²C or system-management (SM) bus support. One goal is to aggregate all of the sensors, process the computations, format the solution and pass it through the I2C to user space. This approach has many integration paths, although combining the solution in one piece of hardware has been preferred historically.
To reduce time-to-market, device manufacturers have supported sensor fusion through their own custom extensions of an existing API or HAL. However, the optimal solution is for device manufacturers to push the algorithms lower into hardware so that a sensor-fusion algorithm developed for one manufacturer will also apply to another. Standardizing the fusion solution would allow design teams to do more with the technology and better differentiate their products in the marketplace.
For more information visit www.kionix.com.
This story first appeared in the PD&D Motion Control & Transmission Supplement, check it out here: http://bit.ly/ruEEGz