Follows recent announcement that the FreeMotion Library is a finalist

for EE Times’ 2013 ACE Award

 SAN JOSE, CA  (May 13, 2013) – Sensor Platforms today announced that its FreeMotion™ Library sensor fusion software is now ported to, and optimized for, the NVIDIA® Tegra® 4 mobile processor reference platform and is available for licensing by smartphone and tablet makers.

Tegra 4 delivers record-setting performance and battery life to flawlessly power smartphones and tablets, gaming devices, auto infotainment and navigation systems. Tegra 4’s 72-custom NVIDIA GPU cores and a quad-core ARM Cortex-A15 CPU offer lightning-fast web browsing, stunning visuals and new camera capabilities through computational photography.

The FreeMotion Library now combines and processes data from installed sensors in Tegra 4 smartphones and tablets to better interpret users’ movements and situations, thereby inferring users’ intents. The software is sensor agnostic, enabling OEMs to purchase their sensors from multiple suppliers, and also optimizes sensor power consumption to enable longer battery life.

“Our software is fully integrated into NVIDIA’s powerful mobile processor platform,” said Dan Brown, CEO of Sensor Platforms. “Manufacturers who utilize the Tegra 4 reference design can license our FreeMotion Library with full confidence of compliance.”

Neil Trevett, vice president of mobile content, at NVIDIA, said:  “The FreeMotion Library produces an exceptionally high quality combined sensor data stream at low power levels.  This enables application developers to tap the full sensory potential of mobile devices without being deep sensor fusion experts.  Sensor Platforms then kicks things to the next level by generating true context awareness – so that applications can engage users through real-time insights into how the device is being used, carried and stored.”

This announcement follows recent news that the FreeMotion Library has been selected as a finalist for the EE Times and EDN 2013 Annual Creativity in Electronics (ACE) Awards in the category of Ultimate Products – Sensors.

About Sensor Platforms Inc (www.sensorplatforms.com)

Sensor Platforms is a venture-financed company located in Silicon Valley that develops, for licensing, algorithmic software enabling consumer applications to better understand user contexts and intent.

The company’s FreeMotion™ Library makes sensor fusion and user context awareness available in smartphones and tablets, to combine and process data from installed sensors and microprocessors, to better interpret users’ movements and situations, and infer their intents.

The library makes it easy for device OEMs to purchase their sensors and microprocessors from multiple suppliers without damaging user experience. It also automatically optimizes sensor and platform power consumption based on user movement and contexts, to enable longer battery life.

To create the breadth of the FreeMotion library, the company has assembled a multi-disciplinary engineering team with proven track records in control systems, machine learning, mixed signal design, motion kinematics, real-time systems, semiconductor device physics, and signal processing.

The company is located at 2860 Zanker Road, #210, San Jose, CA 95134. For information: info@sensorplatforms.com, or 408.850.9350.

###
For more information on Sensor Platforms, please contact :

Tom Mahon, Thomas Mahon Associates

tmahon3@gmail.com; (925) 200-5165
###

]]> http://www.sensorplatforms.com/867/feed/ 0 http://www.sensorplatforms.com/understanding-orientation-conventions-mobile-platforms/ http://www.sensorplatforms.com/understanding-orientation-conventions-mobile-platforms/#comments Wed, 24 Apr 2013 04:34:37 +0000 jsteele http://www.sensorplatforms.com/?p=816 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.

Background

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.

Frame Conventions

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.

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.

SAN JOSE, CA  (March 18, 2013) – Sensor Platforms Inc, a venture-financed company that develops, for licensin g, algorithmic software enabling consumer applications to better understand user contexts and intent,today announced it was named a finalist in UBM Tech’s EE Times and EDN Annual Creativity in Electronics (ACE) Awards (http://ubm-ace.com) in the category of Ultimate Products – Sensors.

Sensor Platform’s technology was selected a finalist due to the ability of its FreeMotion™ Library of algorithmic software to enable context aware applications on mobile devices to proactively engage with the user, and not merely interact with that user.

“We are delighted to receive this recognition as a finalist for an ACE award. The multi-disciplinary engineering team at Sensor Platforms has worked very hard, and worked very creatively, to make context awareness available to users of smartphones and tablets,” said Dan Brown, CEO of Sensor Platforms. “And we’ll be rolling the results of that effort out to the marketplace in the coming months.”

Context awareness builds on, but requires more than, sensor fusion which results from combining the outputs from two or more sensors recording a common event, so that the fused result better captures the event than any single sensor input. The capability of the company’s FreeMotion Library to enable context aware applications sets it apart from others in the sensor space.

The Ultimate Products of the Year Award – awarded to the most significant product introduced in the last 12 months in 11 categories – is determined by large-scale peer review. Finalists in each category are chosen by expert editors from both EE Times and EDN with accompanying editorial reviews.

EE Times and EDN ACE Awards are presented in 22 categories and are judged by a blue-ribbon panel of industry experts, comprised of the leading voices of academia and the industry. The judges will choose winners in seven categories. Winners in the additional 15 categories are either peer-to-peer or editorially selected.

“Our contest showcases the unique best of breed products that have been brought to the market this year,” said Patrick Mannion, Brand Director, EDN.  “The 2013 finalists represent the execution of forward-thinking technologies and creativity that captures the imagination of consumers, illustrating the influence that electronics and embedded design professionals have on today’s culture.”

The Annual Creativity in Electronics (ACE) Awards celebrates the creators of technology who demonstrate leadership and innovation in the global industry and shape the world we live in. These creators, and their innovations, will be recognized at the EE Times and EDN ACE Awards ceremony on April 23, 2013, as part of UBM Tech’s DESIGN West and ESC Silicon Valley Conference.

About UBM TechUBM Tech is a global media business that provides information, events, training, data services, and marketing solutions for the technology industry. Its media brands and information services inform and inspire decision makers across the entire technology market — engineers and design professionals, software and game developers, solutions providers and integrators, networking and communications executives, and business technology professionals. UBM Tech’s industry-leading media brands include EE Times, Interop, Black Hat, InformationWeek, Game Developer Conference, CRN, and DesignCon. The company’s information products include research, education, training, and data services that accelerate decision making for technology buyers. UBM Tech also offers a full range of marketing services based on its content and technology market expertise, including custom events, content marketing solutions, community development and demand generation programs. UBM Tech is a part of UBM (UBM.L), a global provider of media and information services with a market capitalization of more than $2.5 billion.

About Sensor Platforms Inc (www.sensorplatforms.com)
Sensor Platforms is a venture-financed company located in Silicon Valley that develops, for licensing, algorithmic software enabling consumer applications to better understand user contexts and intent.

The company’s FreeMotion™ Library makes sensor fusion and user context awareness available in smartphones and tablets, to combine and process data from installed sensors and microprocessors, to better interpret users’ movements and situations, and infer their intents.

The library makes it easy for device OEMs to purchase their sensors and microprocessors from multiple suppliers without damaging user experience. It also automatically optimizes sensor and platform power consumption based on user movement and contexts, to enable longer battery life.

To create the breadth of the FreeMotion library, the company has assembled a multi-disciplinary engineering team with proven track records in control systems, machine learning, mixed signal design, motion kinematics, real-time systems, semiconductor device physics, and signal processing.

The company is located at 2860 Zanker Road, #210, San Jose, CA 95134. For information: info@sensorplatforms.com, or 408.850.9350.

# # #

For more information on UBM Tech please contact:

Felicia Hamerman
Vice President, Marketing, UBM Tech, Electronics
T: 516.562.5652, E: felicia.hamerman@ubm.com

For more information on Sensor Platforms, please contact :

Tom Mahon, Thomas Mahon Associates
tmahon3@gmail.com; (925) 200-5165

###

• Gestures are defined as a form of non-verbal communication based on an action or movement. They are instantaneous and self-contained, for example a hand-wave.

• Context is defined as the set of circumstances surrounding a particular event or situation. It takes advantage of historical information not always described by gestures. For example distinguishing that the hand-wave is someone waving goodbye at a train station.

Although motion sensors can be used to identify both gestures and contexts, the techniques needed are different. Gesture algorithms often use sensor fusion to match a 3d trajectory or a deterministic pattern. Use of gestures such as “shake to undo” on the iPhone can lead to a poor user experience. Learning these artificial gestures are ad-hoc and false positives are frustrating to a user.

A context aware platform takes in more of the situation to better understand user motion in a natural way. The foundation is a good mechanism to encompass the multitude of variations in signals which does not rely on a user learning prescribed gestures. Still, gestures can assist in indicating a change of context. For example, standing up from a chair is a type of natural gesture and could point to the Posture context of standing or walking. Taking a phone out of a pocket is another natural gesture and could point to the Carry context of being held in hand or placed on a table.

Our FreeMotion Library incorporates a very power-efficient architecture to determine the underlying context. By utilizing low-power sensors and efficient algorithms, we are enabling always-on mobile platforms which will better understand the user’s intent.

There are multiple ways these monitors can be faked-out, leading to an inaccurate result. Some examples include:

• false steps: for example, swinging the device in hand can register false steps,
• non-user motion: for example bumps in a car ride are often registered as user activity,
• anomalous pressure changes: pressure often changes for reasons other than vertical displacement, for example entering an air conditioned building from outside.

These misidentifications happen with algorithms that only treat motion instantaneously. However, activity is not an instantaneous event. No one would go from a swim stroke to a tennis swing from one second to the next. Instead, a contextual understanding of the activity is more appropriate.

Our FreeMotion Library utilizes multiple aspects of the sensor data to build a consistent context history. One way this can be used is to improve activity identification. First, user context can be matched with the instantaneous signal. For example, if the user is sitting or is in a car when a step is detected, then it can be discarded as a false step. Second, knowing where the device is located on the user (in hand, in pocket, or on arm) allows a tailored activity monitoring algorithm to be built for each case. Overall, the inclusion of user context allows for a more accurate determination of user activity, which would be welcomed by those striving to better quantify themselves.

HTML5 is more than a web-only language. It also allows the browser to have access to local device resources, such as high performance audio and video, the ability to locally store assets offline, and sensors which is the focus here.

The sensor API as currently defined by the W3C supports DOM (document object model) events for device orientation, device motion, and whether the compass needs calibration:

• deviceorientation: provides events as Euler angles without the ability to access the underlying quaternion. Events are only provided when a “sufficient” change has occurred or the browser has determined that the last value used by the application is “stale”. The definition of “sufficient” and “stale” is browser-implementation-specific. (The W3C recommendation for sufficient change is one degree.) There is no way to access orientation confidence level or modify/query the change sensitivity threshold. Furthermore, when setting the “absolute” attribute to false the orientation is defined with respect to an arbitrary reference frame. The use case for this option seems limited, more likely leading to confusion for the developer.

• devicemotion: provides events for acceleration, accelerationIncludingGravity, rotationRate, and interval. The HTML5 spec is cloudy with regard to inclusion of effects of gravity and acceleration, leaving ways for cross-platform variations which would only hurt developers. If the effects of gravity cannot be removed, the browser is free to populate the acceleration attribute with an acceleration value that includes gravity (rather than null). This could lead to false assumptions by developers and code that may work on some browsers and platforms but not others. The interval is a constant containing the report sampling interval in milliseconds. There is no access to magnetometer or more useful virtual sensors such as altitude.

• compassneedscalibration: even if this event is not subscribed to, some browsers provide a pop-up window notifying the user to calibrate without any additional javascript code. This could lead to potential conflicts in handling this event. There is no way to access calibration confidence level.

Although browsers claim HTML5 compatibility, our experience with sensor support is varied. Opera and the default Android browser support all the sensor aspects above, whereas Google Chrome on Android did not support rotationRate, and compatibility on Internet Explorer 10 required installation of experimental ActiveX components which lead to browser hang-ups.  Given time, browser support for HTML5 should only improve.  One way to accelerate adoption is developer interest in using sensors within browser apps to enable interesting consumer use-cases.  Sample use-cases could be using device orientation to navigate e-commerce merchandise and context awareness virtual sensors such as Carry and Posture.

Indoor navigation using pedestrian dead reckoning has received much academic and commercial interest over the years. To such an extent that if that is all that people read on the subject, they would conclude that pedestrian dead reckoning has been reduced to “walking while balancing a piece of cake.” That is, the user is expected to keep his mobile device stationary with respect to his body at all times. But let’s face it; we don’t walk like we are balancing a piece of cake.

Pedestrian dead reckoning on smartphones has to be independent of how the phone is carried. The user could be talking on the phone; walking while holding the phone in her hand; keeping her phone in a pocket or a purse; or transitioning between positions. In fact, the user could go through several of these scenarios in the space of a few minutes. She could start with the phone in her purse, then answer a brief phone call, and then keep the phone in her hand. Indoor navigation has to work through all the carrying locations and the associated transitions.

A pedestrian dead reckoning algorithm designed for smartphones has to be able to differentiate between the user’s body travel and her hand movement. In other words, it has to know the difference between a user sweeping her hand to the right versus her making a right turn. We call the direction of travel of the user’s body the “user’s bearing.”

This is one of the key features of our FreeMotion™ Library, the ability to recognize  a CARRY context. Our context awareness algorithm informs our bearing detector how the user is carrying the phone. CARRY can, for example, tell if the phone is in a pocket/container, or held in front of the user, or held at the user’s side, or transitioning from one position to another.

This knowledge allows us to optimize the bearing detection algorithms we are developing that are based on how the phone is carried. Combining user bearing with gait estimation will take us a step closer to the  implementation of an indoor navigation app useful to smartphone users.

Las Vegas, NV, January 7, 2013 – Sensor Platforms will appear in three venues at the 2013 International CES this week:

• in the MEMS TechZone: LVCC South Hall 2, Booth 25321;
• CEO Dan Brown will speak on a panel on “How to Never Get Lost in a Mall or a Museum: Indoor Navigation and the Smartphone,” in the MEMS Conference Track, Tuesday January 8th at 9:00 am, LVCC North Hall, Room N264;
• and in a private suite.

The booth demo addresses the concern of OEMs who need to design one mobile device, whether smartphone or tablet, to work in an Android environment, and another to work in a Windows 8 environment. Software in the company’s FreeMotion™ Library, which allows OEMs to use sensors from any component supplier, enables the same sensor hub to work in either environment.

The booth demo also includes a short video addressing Context Awareness. Interested visitors can then make appointments to visit the suite.

The company’s FreeMotion Library, implemented in a sensor hub, supports the Human Input Device (HID) framework required for Windows 8 systems. Sensor Platforms’ FreeMotion Library for Android can accept HID Sensor inputs so the same sensor module works in either operating system environment.

According to Ian Chen, EVP at Sensor Platforms, “Our customers look to Sensor Platforms not only for sensor fusion performance but also to improve their engineering efficiency. This ability we provide to use the same hardware design and software code base for either operating system makes the OEM’s job of system integration and validation much more efficient. In addition to being operating system agnostic, our single code base also supports sensor components from all key suppliers, and processor instruction sets of all key microprocessors.”

The video at the booth shows how the FreeMotion Library also enables context aware applications on mobile devices to proactively engage with, and not merely interact with, the user. This capability is in beta this quarter, and in production later this year.

About Sensor Platforms
Sensor Platforms is a venture-financed company located in Silicon Valley that develops, for licensing, algorithmic software enabling consumer applications to better understand user contexts and intent.

The company’s FreeMotion™ Library makes sensor fusion and user context awareness available in smartphones and tablets, to combine and process data from installed sensors and microprocessors, to better interpret users’ movements and situations, and infer their intents.

The library makes it easy for device OEMs to purchase their sensors and microprocessors from multiple suppliers without damaging user experience. It also automatically optimizes sensor and platform power consumption based on user movement and contexts, to enable longer battery life.

To create the breadth of the FreeMotion library, the company has assembled a multi-disciplinary engineering team with proven track records in control systems, machine learning, mixed signal design, motion kinematics, real-time systems, semiconductor device physics, and signal processing.

The company is located at 2860 Zanker Road, #210, San Jose, CA 95134. For information: info@sensorplatforms.com, or 408.850.9350.

Media Contact:
Tom Mahon
Thomas Mahon Associates
tmahon3@gmail.com
(925) 200-5165

The most distinguishing feature of a sensor driver is the framework it uses to communicate back to user space services and applications. A consumer-grade sensor driver interface should provide the following features:

• A control interface to query and set hardware capabilities and configurations:
  • enable/disable the sensor,
  • available output rates and measurement ranges,
  • precision (quantization) and resolution (noise),
  • device name with hardware and firmware versions,
  • unit conversion and axis alignment,
  • power modes (deep sleep, low power idle, full),
  • power usage and wake/sleep latencies for different modes,
  • special capabilities: e.g. an accelerometer that can detect taps;
• isochronous data events: regular samples with accurate timestamp available at various rates from 10Hz-250Hz (nominal 50Hz), e.g. acceleration in x, y, and z;
• asynchronous data events: triggered events, e.g. proximity detect, free-fall detect; and
• FIFO data buffering.

The commonly used frameworks, Input Event (also known as evdev), Industrial I/O (IIO), and HID Sensor all work for today’s sensor applications, but none of them encompass all the above features.

Input Event was designed for devices like mouse, keyboard, and joystick. It is a mature standard which can be used to quickly bring up a polled driver.  It has an easy command-line interface and supports bi-directional communication between the system processor and sensor.  Together with the uinput framework, user space applications such as virtual sensors can produce events in the same form as hardware devices.

Some downsides to the Input Event framework are that there is no provision for hardware timestamps and its control interface is limited. There is not even a simple way to indicate multi-sensor data is sampled simultaneously.

Industrial I/O, or IIO, was introduced more recently to enable efficient high data throughput (e.g. sample rates greater than 500Hz) and has been adopted by Google in the recent Android Jelly Bean release. It includes facilities to publish sensor metadata, such as measurement scale factor.  Data is exposed as sysfs giving a simple text interface to control the devices.

The main criticism of IIO is that it is over-engineered.  Eventhough a version has been upstreamed since the later 2.6 kernel series, no standard userland interfaces are yet developed.  Permission management in Android is moved outside of the stock udev interface into a dynamically generated one.

HID sensor is an extension of the human-interface device framework and adopted by Microsoft in Windows 8. It is a transport interface similar to I2C or SPI and can be wrapped in any standard driver framework such as input event or IIO. However, on Windows 8, the framework is proprietary and leads to difficulty in debugging and possible latency due to overhead.

Other frameworks exist, such as ALSA for high data-rate sound or hwmon for low-level sensors such as fan temperature. Pressure, temperature, and relative humidity sensors often use these frameworks, but they are less widely adopted for inertial sensors.  Sometimes, a simple interface is implemented which has direct readings over a device node or sysfs.

It is important to stress that, no matter which driver framework is used, it can be made compatible with the list of features mentioned here.  It is beneficial as a community, however, to move towards a complete non-proprietary sensor driver standard across platforms in order to increase the integration of sensor solutions across sub-systems.  Multiple working groups are attempting to do just that from various angles.  We at Sensor Platforms, being power-users of sensors, contribute to these initiatives to ensure they are compatible with the many possible use cases without over-engineering.

Context awareness results from a layer of sophisticated algorithms that interpret sensor data to infer higher-level information, such as whether the device is in motion; how the device is being carried; the posture of the user; and the mode of transportation, such as train, auto, or airplane.

These algorithms distill a context, for example “the user is walking,” into a series of characteristic features in sensor data. The presence of these and other features inform the context detection algorithm if the “walking” context is valid. And more than one single context is usually valid at the same time; for example, a user could be walking with his phone in his pocket.

Context awareness, as presented in the examples above, builds on, but requires more than, sensor fusion which results from combining the outputs from two or more sensors recording a common event, so that the fused result better captures the event than any single sensor input.

According to Ian Chen, EVP at Sensor Platforms, “We are very happy that our FreeMotion Library is being accepted by OEMs, and now adding the ability to deliver context awareness to mobile devices moves us closer to the time when such devices proactively support our lives, without intruding on our activities for their operation.”

Because all these sensors must work in the background on mobile devices, preserving battery life has to be the core principle of any context detection architecture. To address that, Sensor Platforms has created a proprietary layered framework to conserve sensor and computation power required to understand user contexts.

Thus the context aware framework preserves battery life, and can actually contribute to prolonging that battery life by allowing more aggressive system power management.

Finally, Sensor Platforms presents user contexts in a simple-to-use applications programming interface (API) in its upcoming FreeMotion Library Version 2 release. The API leverages the same structure which programmers are already familiar with from calling up sensor fusion functions.

About Sensor Platforms (www.sensorplatforms.com) 

Sensor Platforms is a venture-financed company located in Silicon Valley that develops, for licensing, algorithmic software enabling consumer applications to better understand user contexts and intent.

The company’s FreeMotion™ Library makes sensor fusion and user context awareness available in smartphones and tablets, to combine and process data from installed sensors and microprocessors, to better interpret users’ movements and situations, and infer their intents.

The library makes it easy for device OEMs to purchase their sensors and microprocessors from multiple suppliers without damaging user experience.  It also automatically optimizes sensor and platform power consumption based on user movement and contexts, to enable longer battery life.

To create the breadth of the FreeMotion library, the company has assembled a multi-disciplinary engineering team with proven track records in control systems, machine learning, mixed signal design, motion kinematics, real-time systems, semiconductor device physics, and signal processing.

The company is located at 2860 Zanker Road, #210, San Jose, CA 95134.  For information: info@sensorplatforms.com, or 408.850.9350.

Contact:
Tom Mahon
Thomas Mahon Associates
tmahon3@gmail.com
(925) 200-5165