Sep 13, 2018
Qualcomm products mentioned within this post are offered by Qualcomm Technologies, Inc. and/or its subsidiaries.
As covered in our Making Sense Out of Sensors in IoT Development blog, sensors provide key data from real world phenomena (like temperature, motion, pressure, etc.). There are many interesting examples of how sensors are being creatively used in different vertical industries.
For example, our Qualcomm Fingerprint Sensors ultrasonic technology is used in biometrics within extreme environments. The Smart Airport Demo by Chordant uses a DragonBoard 410c in conjunction with cameras to track luggage, and a Bluetooth Low Energy (BLE) sensor that provides temperature, air pressure, and humidity data for consumption by business logic. We also see sensors in automotive, where altitude information in conjunction with GPS and street map data is used to detect upcoming elevation changes so that automatic transmissions can make smarter gear shifts. Also, data collected from tracking devices that combine GPS location with other sensors like accelerometers and telemetry are used for Accident Reconstruction and assist in Automotive Forensic Services.
As we’ll cover in this blog, getting started in sensor development is fairly straight forward, but consuming sensor data comes with challenges and considerations to keep in mind.
Getting started with sensors
As developers, start by defining your data sampling rate, which is when an event instance takes place and how often your sensor is awake or ‘listening’. Usually, the level of accuracy and response time needed by the application plays an important role in defining this sampling rate. Once the sampling rate is sorted, you can move on to identifying the type of sensor and hardware interface (GPIO’s, I2C, SPI, etc.) that can support the sampling rate.
The next step is to identify the supported software libraries that work with the sensor interface which will depend on your target operating system. For more information, see the basic introduction on sensor development for Android devices, and MRAA library in Linux operating system on the DragonBoard 410c.
Finally, you’ll also need adequate storage for all that sensor data, which could include both on-device and cloud-based storage.
Making it powerful with power efficiency
One of the top challenges in sensor development, is managing power consumption. While sensors often require always-on monitoring, processing may only be required at certain times, such as when events occur. Therefore, it’s important to unregister a sensor when it’s no longer required, or if the activity is paused. Those developing on our Qualcomm Snapdragon mobile platforms have the benefit of utilizing our Qualcomm Sensor Engine. It can wakeup the appropriate processor as needed, using input from one or more sensors. In addition, utilizing our Qualcomm Snapdragon Heterogeneous Compute SDK can help manage the balance of power consumption and performance.
Handling sensor errors and bias
Almost all sensors bring with them inaccuracies and small errors that developers must account for.
GPS development for example, has many variables to consider including different forms of data (e.g., position, bearing, and speed), and different data sources (e.g. GPS satellites, Wi-Fi, or LTE). There are also issues with the data itself to be aware of.
“GPS drift” is a common issue with GPS data, which happens when information received from the satellites changes over time. There are many causes including changes to the GPS satellite constellation and even atmospheric effects. Similarly, issues like sudden large drifts in position can be attributed to multi-path reception where GPS signals bounce off structures and the receiver sees more than one signal from the same satellite.
A potential solution for GPS inaccuracies is to average out location data from as many sources as possible, or filter the inaccurate locations using the Dilution of Precision (DOP) value embedded within the data received from the GPS sensor. Another option is to use past positions, along with speed and acceleration data from other sensors, and apply them through an algorithm such as a Kalman filter to derive a stable estimate. You can use our Qualcomm Snapdragon Math Libraries to help implement the algorithm on our Snapdragon mobile platforms. See this whitepaper for an overview of Kalman filters using this library. Some advanced GPS sensors offer similar features like Dead Reckoning, where the current position is calculated using a previously determined position, and advancing that position based upon the known or estimated speeds and direction over time.
“Offset bias” is another type of sensor issue that can often occur when the orientation of a sensor (e.g., accelerometer or gyroscope) is not precisely aligned with the axis of the frame of the device on which it is mounted (e.g., smart phone). Other causes can include manufacturing anomalies of the sensor, lack of calibration, and physical changes in the sensor that occur with age.
When these inaccuracies accumulate over time, this can lead to larger errors in data called “bias accumulation”. One solution is to use a sensor data table, which lists the sensor’s properties such as measurement rates, accuracy, and deltas over time, to obtain or calculate the offsets necessary to correct the biased data. Another solution is to periodically calibrate sensors by placing them in the known correct orientation (e.g., a flat level surface), and record the differences from the sensor’s data versus known correct values. For example, when a mobile phone is lying on a table, the accelerometer data for the X and Z axis should be 0, and Y should be about 9.8 m/s2. Any differences detected can be used to correct the data by offsetting the values.
Voltage variations such as those from a discharging battery power source can cause sensors to scale output in a phenomenon known as ratiometricity. Here, voltage regulation is essential, but voltage sensors, in conjunction with an algorithm, may be necessary to calculate a compensation factor.
Finally, there are factors from the physical operating environment to consider. For example, an accelerometer can be affected by temperature. One solution is to collect output from a temperature sensor and use it to look up or calculate a compensation factor to apply to the accelerometer’s output. More generally, be sure to test your product in all target operating environments.
Overcoming challenges with sensor development
Sensors bring measurements of the real world into the digital world, but they also bring unique challenges. There are many creative ways to solve these challenges ranging from the use of additional sensor data to sophisticated algorithms. In a future blog, we’ll review some creative options and optimizations such as sensor fusion.
In the meantime, we have multiple opportunities for you to showcase your sensor integrations and solutions. If you’d like to get noticed, we invite you to share your success with our QDN community through projects or case studies. We also welcome anyone interested in being featured as a future Developer of the Month. If you’d like to be considered, please visit our Account Questions page.