In case you haven’t heard, the FAA recently announced that airline flyers can now use phones/tablets/devices during landing and takeoff in addition to during the flight when the seatbelt sign is off. Full press release details available here.
This is good news for Robotic sensor hacker enthusiasts (like me) who have been scheming to use collected sensor data during this flying interval for some time. It also opens up the possibilities of developing new applications that leverage this new allowed capability to ensure a better flying experience. Maybe some of the functionality of the traditional black box can be crowd-sourced to help ensure flight safety (and secondary data in case of possible hardware failure). Maybe sensor data could be used as recourse by passengers against a pilot who provides a turbulent ride full of crazy maneuvers (sensor agreement between users could provide a joint class-action case!). The application possibilities are wide open.
I hacked up a quick Android application about a year ago to log sensor data (barometer, accelerometer, magnetometer, etc). While there are a variety of apps that do indeed showcase sensor data, it was challenging to find one that logged reliably w/ the fine-control over sensors and activity context switching. So if anyone wants the Android application optimized for data collection of sensor data, let me know.
For the past year, I have logged data on nearly every flight I’ve been on with my Android Galaxy S3. Here are some hacks of the sensor data for a particular flight from Pittsburgh to Boston this past summer.
Barometric Analysis
The Android barometer reports pressure in millibars. However, there is a simple conversion formula available for converting millibar pressure to expected altitude here.
The matlab code is:
function altitude = convToAltitude(mbar_readings)
%mbar to ft
altitude = (1 – (mbar_readings ./ 1013.25) .^(0.190284)) .* 145366.45;
%ft to m
altitude = 0.3048 * altitude;
Technically, you can get a better model of altitude taking into account other factors such as ambient temperature and weather conditions. For instance, air pressure is very dependent on temperature. The S4 actually contains additional thermometer and humidity sensors that might actually lead to a better inference of altitude. However, we will ignore such complexities here and use the simpler model that is just a function of atmospheric pressure.
The top plot shows the raw barometer pressure reading in millibars, while the bottom plot converts the sensor reading time series to altitude using the above formula.
The first thing to notice is that, after sensor calibration, the estimation of altitude is not far away off from the ground truth. Here is the table of comparisons with ground truth taken from Google Maps.
| Airport | Estimated Altitude (m) | Google Maps Ground Truth (m) | Error (m) |
| Pittsburgh International Airport | 378.152 m | 367 m | 11.15 m |
| Boston’s Logan International Airport | 4.428 m | 5.80 m | 1.17 m |
The second thing to notice is that the cabin pressurization limit is well-shown by the plot. Generally, the cabin pressurizes (source: Wikipedia on “Cabin Pressurization”) at 2400 m above sea level. We see that estimated altitude by the in-plane barometer increases during ascent, flat lines around that range, and then decreases during descent.
The fact that cabin pressurizes at a high enough altitude means that altitude of the plane cannot be estimated well at all times by a barometer inside the by plane. However, when the plane is taking off or landing, the cabin isn’t as pressurized, and altitude can be estimated well. Since plane troubles are most likely to happen during ascent or descent, this is perhaps the most interesting time to log and crowd-source barometer data collection.
Accelerometer Analysis
Here are the x,y,z axes of accelerometer data collected during the Pittsburgh-Boston flight.
The accelerometer can be used, to a first approximation, to identify periods of turbulence during flight. A straightforward way to do this is to use a k-sigma filter to find the data points k-sigma away from the mean in each dimension. This is a really easy way of finding global outliers as shown below.
This allows us to find the anomalous jerky behavior in the data from the normal noisy/oscillatory behavior. A more advanced way to process this data would be to filter out systematic oscillatory behavior explicitly in the frequency domain using FFT and band-pass filtering (subject of future work). Certainly if there is drift in the sensor, more advanced techniques need to be used.
Obviously, accelerometer data on phones is extremely noisy and my erratic fidgeting and moving around the cabin to go to the bathroom probably didn’t help things much. However, it is still neat to see systematic periods of anomalous jitter in the data. Given ground truth for actual air turbulence, it would be neat to train a supervised classifier to delineate between case of actual air turbulence vs. other instances of noise. There is certainly a lot of mountain of previous work identifying human behavior and activity recognition from motion sensors in homes, urban areas, etc that could be useful towards this new frontier of on-plane behavior.
Conclusion
This post hopefully shows you the promise of using cell phone sensors on planes. This is just the tip of the iceberg of what is possible with AI/Robotics today. This is very low hanging fruit as Intelligent Robotics goes, and there is certainly much more in the pipeline being developed. Stay tuned!
Dr. Prateek Tandon 