8  Mobile Sensing & Activity

In 60 Seconds

Mobile sensing uses smartphone accelerometers and gyroscopes to recognize human activities like walking, running, and climbing stairs with 92%+ accuracy. The pipeline segments continuous sensor data into 2-second overlapping windows, extracts time-domain and frequency-domain features, and feeds them to classifiers like Random Forest. Duty cycling at 50Hz with 50% sleep achieves 95% accuracy while doubling battery life to 16 hours.

8.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Compare Sensing Approaches: Differentiate between mobile/wearable sensing and traditional sensor networks
  • Design Activity Recognition Pipelines: Implement human activity recognition using accelerometer/gyroscope data
  • Apply Transportation Mode Detection: Apply multi-sensor fusion for detecting transportation modes
  • Diagnose Mobile Sensing Challenges: Handle heterogeneity, noise, and resource constraints

Key Concepts

  • Activity recognition: Classifying human or device physical activities (walking, running, driving, idle) from accelerometer, gyroscope, and magnetometer readings using sliding-window feature extraction and classification.
  • Sensing opportunism: Using sensors that happen to be available on a mobile device (microphone, camera, GPS, accelerometer) for additional inferences beyond their primary purpose.
  • HAR (Human Activity Recognition): A specific application of mobile sensing that uses wearable IMU data to classify physical activities and transitions between them, used in health monitoring, eldercare, and sports analytics.
  • Continuous sensing trade-off: The tension between high-frequency sensing (better accuracy) and battery drain (high-frequency sampling kills battery life); resolved by adaptive sampling or always-on low-power sensor fusion.
  • Context inference: Deriving higher-level situational understanding (commuting, working, sleeping, exercising) from the fusion of multiple mobile sensor streams and their temporal patterns.

Mobile sensing uses the sensors built into smartphones – accelerometers, GPS, microphones, cameras – to understand the world around us. Think of how your phone automatically counts your steps or a traffic app shows congestion. Machine learning analyzes these sensor signals to recognize activities like walking, driving, or exercising without you pressing any buttons.

8.2 Prerequisites

  • ML Fundamentals: Understanding training vs inference and feature extraction
  • Basic understanding of smartphone sensors (accelerometer, gyroscope, GPS)
Chapter Series: Modeling and Inferencing

This is part 2 of the IoT Machine Learning series:

  1. ML Fundamentals - Core concepts
  2. Mobile Sensing & Activity Recognition (this chapter)
  3. IoT ML Pipeline - 7-step pipeline
  4. Edge ML & Deployment - TinyML, quantization
  5. Audio Feature Processing - MFCC
  6. Feature Engineering - Feature design
  7. Production ML - Monitoring

8.3 Mobile/Wearable Sensing vs. Sensor Networks

Comparison diagram showing mobile wearable sensing characteristics on left versus dedicated sensor network characteristics on right, covering use cases, sensor types, resources, and cost
Figure 8.1: Mobile Wearable versus Dedicated Sensor Network Comparison
Aspect Mobile Sensing Sensor Networks
Use Case Well suited for human activities Well suited for sensing the environment
Sensors General purpose sensors, often not well suited for accurate sensing Specialized sensors, designed to accurately monitor specific phenomena
Resources Multi-tasking OS. Main purpose is to support various applications All resources dedicated to sensing
Cost Low cost of deployment and maintenance (millions of users charge their devices) High cost deployment and maintenance

8.4 Mobile Sensing Applications

Three-tier diagram showing mobile sensing applications at individual scale such as fitness and sleep tracking, group and community scale such as neighborhood safety, and urban scale such as disease tracking and pollution monitoring
Figure 8.2: Mobile Sensing Applications at Individual, Group, and Urban Scales

8.4.1 Individual Sensing

  • Fitness applications: Step counting, calorie tracking, workout monitoring
  • Behavior intervention applications: Sleep tracking, habit formation, wellness coaching

8.4.2 Group/Community Sensing

  • Groups sensing common activities and helping achieve group goals
  • Examples: Assessment of neighborhood safety, environmental sensing, collective recycling efforts

8.4.3 Urban-Scale Sensing

  • Large-scale sensing, where a large number of people have the same application installed
  • Examples: Tracking speed of disease across a city, congestion and pollution monitoring

8.5 Human Activity Recognition (HAR)

Flow diagram showing human activity recognition pipeline: smartphone with accelerometer and gyroscope sensors feeds motion data through feature extraction to machine learning classifier that outputs activity labels

Human activity recognition pipeline showing smartphone accelerometer and gyroscope sensors feeding motion data through feature extraction to ML classifier
Figure 8.3: Human activity recognition system using accelerometer and gyroscope

Sensors Used:

  • Accelerometer (3-axis linear acceleration)
  • Gyroscope (3-axis angular velocity)

Example Inferences:

  • Walking, running, biking
  • Climbing up/down stairs
  • Sitting, standing, lying down

Applications:

  • Health and behavior intervention
  • Fitness monitoring
  • Sharing within a community
  • Fall detection for elderly care

8.6 Activity Recognition Implementation

The activity recognition pipeline processes sensor data through several stages:

8.6.1 How It Works: HAR Pipeline in Detail

Human Activity Recognition transforms continuous accelerometer/gyroscope streams into discrete activity labels through a multi-stage pipeline:

Stage 1: Continuous Sampling

  • Accelerometer samples at 50-100 Hz producing [X, Y, Z] vectors representing linear acceleration
  • Gyroscope samples at same rate producing [Gx, Gy, Gz] vectors representing angular velocity
  • Data arrives as endless stream—no natural segmentation

Stage 2: Windowing & Segmentation

  • Sliding window extracts fixed-duration chunks (1-3 seconds = 50-300 samples)
  • Overlap (typically 50%) ensures transitions between activities are captured
  • Example: 2-second window with 1-second step creates new window every second

Stage 3: Feature Extraction (Per Window)

  • Time-domain features: Mean, std, min, max, zero-crossings per axis (5 features x 3 axes = 15)
  • Frequency-domain features: Apply FFT to detect periodic patterns – walking has clear 2 Hz peak, running 3–4 Hz. Extract dominant frequency, spectral energy, frequency entropy per axis (3 features x 3 axes = 9)
  • Cross-axis features: Signal magnitude area (total energy across all axes), correlation between axis pairs (up to 3 additional features)
  • Output: 27–45 dimensional feature vector per window depending on feature set complexity

Stage 4: Classification

  • Feature vector → ML model (Random Forest, SVM, or Neural Network)
  • Model outputs probabilities for each activity class [sitting: 0.05, walking: 0.85, running: 0.10]
  • Argmax selects highest probability as predicted activity

Stage 5: Temporal Smoothing

  • Apply majority voting over last N predictions (e.g., 3-5 windows) to filter outliers
  • Walking → brief sit misclassification → walking becomes walking → walking → walking

End-to-End Latency: 50ms sampling + 10ms feature extraction + 5ms classification + buffering = ~100-200ms total, acceptable for real-time fitness tracking.

Performance: Random Forest achieves 85–92% accuracy on common activities with under 200 ms end-to-end latency on smartphones.

8.7 Case Study: Human Activity Recognition Pipeline

This case study demonstrates a complete end-to-end machine learning pipeline for HAR using wearable accelerometer sensors.

8.7.1 End-to-End HAR Pipeline

Pipeline diagram showing HAR stages from raw accelerometer data through windowing, feature extraction with time and frequency domain features, to Random Forest classification outputting activity labels
Figure 8.4: Human Activity Recognition Pipeline from Accelerometer to Classification

Pipeline Parameters:

  • Sampling Rate: 50 Hz (20ms between samples)
  • Window Size: 2 seconds (100 samples per window)
  • Window Overlap: 50% (1-second slide for smooth transitions)
  • Features per Window: 45 features (15 per axis)
  • Model: Random Forest with 100 decision trees
  • Output: 5 activity classes (Walk/Run/Sit/Stairs/Stand)

8.7.2 Feature Engineering for HAR

8.7.2.1 Time Domain Features (per axis: x, y, z)

Feature Category Features Extracted What It Captures
Statistical Mean, Standard Deviation, Min, Max Overall motion intensity and variability
Signal Shape Zero Crossings Frequency of direction changes
Energy Signal Magnitude Area (SMA) Total energy expenditure across axes

8.7.2.2 Frequency Domain Features (FFT-based)

Feature Calculation Activity Insight
Dominant Frequency Peak FFT bin Walking ~2Hz, Running ~3-4Hz
Spectral Energy Sum of FFT magnitudes High for running, low for sitting
Frequency Entropy Shannon entropy of FFT Regular patterns (walk) vs irregular (stairs)
Why These Features Matter

Time-domain features capture the overall intensity and variability of motion: - Mean acceleration: Sitting has mean near 9.8 m/s2 (gravity only, no additional motion), while running produces higher peak magnitudes well above gravity - Standard deviation: Walking has regular patterns (low std), stairs have irregular patterns (high std)

Frequency-domain features reveal periodic patterns: - Dominant frequency: Walking has a clear 2Hz peak (2 steps/second), running has 3-4Hz - Spectral energy: High-intensity activities have more energy spread across frequencies

8.7.3 Duty Cycling Trade-offs: Energy vs Accuracy

Sampling Strategy Battery Life Accuracy Use Case
50 Hz (always on) 8 hours 98% Research studies
10 Hz continuous 24 hours 94% Fitness trackers
50 Hz, 50% duty 16 hours 95% Smartwatches (optimal)
10 Hz, 25% duty 4 days 88% Long-term monitoring

8.7.4 Explore: HAR Duty Cycling Calculator

Adjust sampling parameters and battery capacity to see how duty cycling affects battery life and estimated classification accuracy for a wearable HAR system.

Duty Cycling Power Savings for Accelerometer Sampling:

Quantifying power savings from duty-cycled sensing on a smartphone.

Continuous sampling power:

  • Accelerometer active power: \(P_{\text{active}} = 200 \text{ µA}\) at 3.3 V
  • Power consumption: \(P = 200 \times 10^{-6} \times 3.3 = 0.66 \text{ mW}\)
  • Energy per hour: \(E_{\text{continuous}} = 0.66 \times 3600 = 2{,}376 \text{ mWs} = 0.66 \text{ mWh}\)

Duty-cycled sampling (5s every 60s = 8.3% duty cycle): \[ E_{\text{duty}} = E_{\text{continuous}} \times \text{duty cycle} = 0.66 \times 0.083 = 0.055 \text{ mWh} \]

Battery life extension (3000 mAh battery at 3.7 V = 11.1 Wh): - Continuous: \(11{,}100 / 0.66 = 16{,}818\) hours = 701 days (unrealistic, other components dominate) - Duty-cycled: \(11{,}100 / 0.055 = 201{,}818\) hours (sensing only)

In practice, duty cycling reduces sensing power by 12× while retaining 80% activity classification accuracy—critical for wearables where battery life must exceed 24 hours.

Key Insights:

  1. The 50% Duty Cycle Sweet Spot: Sampling at 50Hz for 1 second, then sleeping for 1 second, achieves 95% accuracy with 16 hours of battery life.

  2. Lower Sampling Rate Trade-off: Reducing from 50Hz to 10Hz saves 3× battery but loses only 4% accuracy because most activities have motion patterns below 5Hz.

  3. Context-Aware Duty Cycling: Modern wearables use adaptive duty cycling—sampling at 50Hz during motion and 1Hz during rest. This achieves 3-day battery life with 96% accuracy.

8.7.5 Classification Results

Activity Precision Recall F1-Score Notes
Walking 97% 96% 96.5% Regular 2Hz gait pattern
Running 95% 97% 96.0% High-energy, high-frequency
Sitting 94% 92% 93.0% Low signal magnitude
Standing 91% 90% 90.5% Similar to sitting
Stairs 87% 83% 85.0% Confused with walking

Overall Model Performance:

  • Macro-Average F1-Score: 92.2%
  • Inference Latency: 8ms per window (on smartphone CPU)
  • Model Size: 2.4 MB (100 trees, 45 features)
Improving Classification Performance

For Stairs Detection (currently 83% recall): - Add barometer sensor to detect altitude changes - Extract step irregularity features - Result: Stairs recall improves from 83% → 91%

For Sitting vs Standing (currently 8% confusion): - Add gyroscope data to measure postural sway - Use context features (sitting episodes last longer) - Result: Confusion drops from 8% → 3%

8.7.6 Mid-Chapter Check

8.8 Transportation Mode Detection

Architecture diagram showing multi-sensor transportation mode detection using accelerometer, GPS, and Wi-Fi inputs fused into a classifier that distinguishes bus, bike, tram, train, car, and walking modes
Figure 8.5: Multi-Sensor Transportation Mode Detection Architecture

Sensors Used:

  • Accelerometer/Gyroscope for motion patterns
  • GPS for speed and location tracking
  • Wi-Fi localization for indoor/outdoor context

Example Inferences:

  • Bus, bike, tram, train, car, walking

Applications:

  • Intelligent transportation systems
  • Smart commuting recommendations
  • Carbon footprint tracking
  • Urban mobility planning

8.9 Challenges in Mobile Sensing

Diagram showing three main mobile sensing challenges: complex heterogeneity across devices, noisy measurements from environmental interference, and resource constraints including battery and processing limitations, with mitigation strategies for each
Figure 8.6: Mobile Sensing Challenges and Mitigation Strategies

Complex Heterogeneity:

  • Sensors vary in sampling frequency and sensitivity
  • Different device models and manufacturers
  • Inconsistent calibration

Why heterogeneity matters in practice: A HAR model trained on Samsung Galaxy accelerometer data may drop from 92% to 74% accuracy when deployed on an iPhone, because the two phones use different MEMS accelerometer chips with different noise floors, sampling jitter, and axis orientations. Mitigation strategies include training on data from 10+ device models, normalizing sensor readings to unit variance, and using transfer learning to adapt pre-trained models to new hardware.

Noisy Measurements:

  • Environmental interference
  • Sensor drift over time
  • Motion artifacts

Real-world noise example: A step counter tested in a laboratory achieved 99% accuracy but dropped to 82% when users carried phones in handbags (irregular motion), placed them on car dashboards (vibration counted as steps), or walked while texting (phone orientation constantly changing). Robust systems use multiple sensors (accelerometer + barometer for altitude confirmation) and temporal smoothing (a single “step” reading is ignored unless followed by at least 4 more within 5 seconds).

Resource Constraints:

  • Limited processing power
  • Battery life concerns
  • Storage limitations

Balance Required:

  • Amount of resources needed vs. accuracy of detection
  • Continuous sensing vs. duty cycling
  • Local processing vs. cloud offloading

Practical energy budget: On a typical smartphone, continuous 50 Hz accelerometer sampling consumes approximately 35 mW. Adding gyroscope increases this to 75 mW. GPS sampling at 1 Hz adds 120 mW. For a 3,000 mAh phone battery (11.1 Wh), continuous triple-sensor monitoring would drain the battery in under 6 hours. Selective sensor activation – using the accelerometer as a low-power trigger for GPS only during transportation detection – extends this to 18+ hours.

Tradeoff: Population Models vs Personalized Models

Option A: Population model trained on diverse user data (works for everyone)

Option B: Personalized model fine-tuned for individual users

Decision Factors: Population models achieve ~92% accuracy across all users with zero user effort. Personalized models can reach ~96% accuracy but require 15-30 minutes of user calibration.

Choose population models for consumer apps where ease-of-use matters; choose personalization for medical or professional applications where accuracy is critical.

8.10 Knowledge Check

You’re building a fitness tracker that must classify 5 activities (walk, run, stairs, sit, stand) using a 3-axis accelerometer. Battery life target is 24 hours with a 250 mAh battery. Let’s design the complete pipeline with realistic power calculations.

Step 1: Choose sampling strategy

  • Option A: 50 Hz continuous sampling, 1-second windows (50 samples per window)
  • Option B: 50 Hz with 50% duty cycle (sample 1s, sleep 1s), 1-second windows
  • Option C: 10 Hz continuous sampling, 2-second windows (20 samples per window)

Step 2: Power consumption calculations | Component | Power Draw | Duty Cycle | Average Power | |———–|————|————|—————| | Accelerometer @ 50 Hz | 180 µA | 100% (Option A) | 180 µA | | Accelerometer @ 50 Hz | 180 µA | 50% (Option B) | 90 µA | | Accelerometer @ 10 Hz | 50 µA | 100% (Option C) | 50 µA | | MCU active (processing) | 5 mA | 2% (20ms every 1s) | 100 µA | | MCU deep sleep | 10 µA | 98% | 10 µA | | Display refresh (1 Hz) | 15 mA | 10% | 1.5 mA | | Bluetooth advertising | 8 mA | 5% | 400 µA |

Total power budget:

  • Option A: 180 + 100 + 10 + 1500 + 400 = 2,190 µA → Battery life: 250 mAh ÷ 2.19 mA = 114 hours (4.8 days)
  • Option B: 90 + 100 + 10 + 1500 + 400 = 2,100 µA → Battery life: 250 mAh ÷ 2.1 mA = 119 hours (5.0 days)
  • Option C: 50 + 100 + 10 + 1500 + 400 = 2,060 µA → Battery life: 250 mAh ÷ 2.06 mA = 121 hours (5.0 days)

Step 3: Accuracy analysis (from literature and testing)

  • 50 Hz sampling: 98% accuracy (captures high-frequency running motion)
  • 50 Hz with 50% duty: 95% accuracy (occasional missed transitions between windows)
  • 10 Hz sampling: 92% accuracy (marginal for detecting rapid stair climbing)

Step 4: Feature extraction (for 50 Hz, 50% duty)

  • Time-domain: mean, std, min, max, zero-crossings (5 features × 3 axes = 15 features)
  • Frequency-domain: FFT dominant frequency, spectral energy (2 features × 3 axes = 6 features)
  • Total: 21 features per 1-second window

Step 5: Classifier selection

  • Random Forest (100 trees): 2.4 MB model, 12 ms inference on ARM Cortex-M4
  • Decision Tree (depth 8): 48 KB model, 2 ms inference
  • Naive Bayes: 8 KB model, 1 ms inference, but 88% accuracy (too low)

Final design: Option B with Random Forest

  • Sampling: 50 Hz with 50% duty cycle
  • Window: 1 second (50 samples)
  • Features: 21 features (time + frequency domain)
  • Model: Random Forest (100 trees, quantized to 8-bit for 600 KB model size)
  • Accuracy: 95%
  • Battery life: 5 days
  • Inference latency: 12 ms (acceptable for 1-second windows)

This demonstrates the complete design process from power budget through feature selection to model deployment.

Activity Type Optimal Sample Rate Window Size Feature Set Justification
Walking 10-20 Hz 2-3 seconds Time-domain only Gait cycle is 0.5-1 Hz, 10× sampling sufficient
Running 20-50 Hz 1-2 seconds Time + frequency Higher frequency gait (2-4 Hz), need FFT for cadence
Cycling 5-10 Hz 3-5 seconds Time + gyroscope Pedaling frequency ~1 Hz, longer windows for smoothness
Stairs 20-50 Hz 2-3 seconds Time + barometer Vertical acceleration + altitude change confirms stairs
Transportation 1 Hz GPS + 10 Hz accel 10-30 seconds GPS speed + accel variance Speed differentiates bus/car/train, accel patterns for stops
Sleep tracking 1 Hz accel 30-60 seconds Movement magnitude, posture Low-frequency motion, long windows reduce false wakes
Fall detection 50-100 Hz 0.5 seconds Peak acceleration, impact duration Must capture sudden impact (<100ms), high sampling critical

General rules:

  • Sample rate: 5–10x the highest frequency of interest (Nyquist requires minimum 2x; 5–10x is the practical recommendation for noisy sensor data)
  • Window size: Long enough to capture 2-3 repetitions of periodic motion (2-3 gait cycles for walking)
  • Duty cycling: Use when accuracy loss <5% and activity frequency <1 Hz
  • Feature complexity: Add frequency-domain features only when time-domain accuracy <90%
Common Mistake: Training HAR Models on Controlled Lab Data, Deploying to Real Users

Researchers train human activity recognition models using lab volunteers walking on treadmills, climbing stairs in controlled buildings, and sitting in fixed chairs. When deployed to real users, accuracy drops from 95% to 70% because real-world conditions differ vastly from lab settings.

What goes wrong: A university research team builds a step counter using 20 volunteers (college students aged 18-24) walking on a treadmill at 3-6 km/h. The accelerometer is mounted on a tight waistband. Model achieves 98% accuracy in cross-validation. When released as a consumer app, accuracy plummets: - Elderly users (slower gait, shuffling): 65% accuracy - Users with phones in loose pockets: 72% accuracy (irregular motion) - Users walking while texting: 58% accuracy (unusual posture) - Users on uneven terrain (hiking): 61% accuracy

Why it fails:

  1. Population mismatch: Lab volunteers are not representative of actual users (age, fitness, gait patterns)
  2. Device placement variation: Lab uses fixed waistband mount; real users carry phones in pockets, bags, armbands (different accelerometer orientations)
  3. Environmental diversity: Treadmills provide constant speed and flat surface; real-world walking includes hills, stairs, crowded sidewalks, stopping at traffic lights
  4. Activity context: Lab separates activities cleanly (“now walk for 5 minutes”); real users transition frequently (walk → stand at crosswalk → walk → sit on bus)

The correct approach:

  1. Collect real-world training data from diverse users:

    • 100+ users across age 18-75, different fitness levels
    • All common phone placements (pocket, bag, hand, armband)
    • Multiple surfaces (treadmill, sidewalk, trail, stairs)
    • Include transition periods between activities

  2. Use data augmentation to simulate real-world variation:

    # Simulate phone orientation variation (rotation matrices)
rotated_data = rotate_3d_vector(accel_data, random_angle)

# Simulate slower/faster gait by time-warping
time_warped = resample(accel_data, speed_factor=random.uniform(0.7, 1.3))

# Add Gaussian noise to simulate different sensor hardware
noisy_data = accel_data + np.random.normal(0, 0.1, accel_data.shape)

  3. Test on held-out real-world data:

    • Never evaluate on lab-collected data if deploying to real users
    • Reserve 20% of real-world data for final validation
    • Track per-demographic accuracy (age groups, device placements)

  4. Implement feedback loop for continuous improvement:

    • Add “Was this classification correct?” prompt in app
    • Collect user corrections to retrain model monthly
    • A/B test model versions with 10% of users before full rollout

Real consequence: Fitbit’s early step counters (2010-2012 era) famously over-counted steps because training data was biased toward steady walking. Users discovered that vigorous hand-waving while sitting triggered step counts—prompting the “shake your Fitbit to fake steps” workaround. Later models added gyroscope data and trained on hand-waving scenarios to filter false positives. The lesson: lab-perfect models fail in the messy real world unless training data includes real-world diversity.

8.11 Concept Relationships

Mobile Sensing bridges theoretical ML concepts and practical IoT deployments:

  • Builds On: ML Fundamentals provides the training/inference framework applied here to real sensors
  • Prerequisite For: IoT ML Pipeline formalizes this HAR workflow into a systematic 7-step process
  • Complements: Feature Engineering explains why time/frequency domain features work for motion data
  • Enables: Edge ML & Deployment shows how to fit these models on smartphones and wearables
  • Real-World Context: Healthcare Applications demonstrates real-world applications of mobile sensing and HAR systems

The key pattern is that mobile sensing represents a sweet spot: enough compute on smartphones for local ML inference, rich sensor suites (accel, gyro, GPS, microphone), and ubiquitous deployment (billions of devices).

8.12 See Also

Related Chapters:

External Resources:

8.13 Try It Yourself

Hands-On Challenge: Build a simple step counter using your smartphone accelerometer

Task: Implement a walking detection algorithm using basic feature engineering (no ML model required):

  1. Data Collection:
    • Use a sensor logging app (e.g., Physics Toolbox Sensor Suite) or write simple code
    • Record 30 seconds of accelerometer data while walking normally (50-100 Hz sampling)
    • Record 30 seconds while standing still as a control
  2. Feature Extraction:
    • Calculate magnitude: sqrt(x² + y² + z²) for each sample
    • Apply sliding 1-second window (50-100 samples)
    • Per window, compute: mean magnitude, variance, peak count (local maxima)
  3. Threshold Logic:
    • Walking detection rule: variance > 0.5 AND peak_count > 1 per second
    • Standing has low variance (<0.2) and few peaks
  4. Validation:
    • Test on your walking data—should detect ~90% of windows correctly
    • Test on standing data—should reject as non-walking

What to Observe:

  • Walking creates periodic peaks (~2 Hz) visible in magnitude signal
  • Variance distinguishes motion from stillness better than mean alone
  • Simple thresholds work surprisingly well before resorting to ML

Bonus: Try walking while carrying the phone in a pocket vs. holding it—notice how pocket introduces more noise but the pattern remains detectable.

Common Pitfalls

A model trained exclusively on data from young, healthy adults will misclassify activities for elderly users, children, or people with mobility limitations. Collect training data from representative populations.

Accelerometer readings from a phone in a front pocket, back pocket, handbag, or hand all look very different for the same physical activity. Either normalise for placement or collect training data across all expected positions.

Running inference at 50 Hz continuously will drain a smartphone battery in hours. Use a lightweight classifier to detect activity onset, then activate a more accurate classifier only during periods of interest.

Raw accelerometer values depend on device orientation. Always transform to a body-frame or world-frame coordinate system using gravity estimation before extracting features for activity recognition.

8.14 Summary

This chapter covered mobile sensing and human activity recognition:

  • Mobile vs Sensor Networks: Mobile sensing is cost-effective for human activities; dedicated networks excel for environmental monitoring
  • HAR Pipeline: Raw data → Windowing → Feature extraction → Classification → Post-processing
  • Feature Engineering: Time-domain (mean, variance) and frequency-domain (FFT peaks) features capture motion patterns
  • Duty Cycling: Balance energy savings (60-80%) with detection accuracy through adaptive sampling
  • Transportation Detection: Multi-sensor fusion combines accelerometer, GPS, and Wi-Fi for mode classification
Key Takeaway

Mobile sensing using smartphone accelerometers and gyroscopes achieves 92%+ accuracy for human activity recognition through a five-stage pipeline: data collection at 50-100 Hz, segmentation into 2-second overlapping windows, time-domain and frequency-domain feature extraction, ML classification, and temporal smoothing. The optimal duty cycling sweet spot – sampling at 50 Hz for 1 second then sleeping for 1 second – achieves 95% accuracy while doubling battery life to 16 hours.

How does your phone know if you are walking, running, or riding a bus? The Sensor Squad is on the case!

Inside every smartphone lives a tiny team of sensors. Sammy the Accelerometer can feel every bump, shake, and tilt. His friend Gerry the Gyroscope can tell which direction the phone is spinning.

One day, their owner goes for a jog. Sammy feels the phone bouncing up and down in a steady rhythm: bump-bump-bump, about 3 times per second.

“That is running!” Sammy announces. “When they walk, it is only 2 bumps per second, and much gentler.”

But there is a problem: Sammy and Gerry are sending 50 measurements EVERY SECOND. That is 3,000 numbers per minute! Max the Microcontroller cannot process all that.

So Max invented a clever trick called windowing: “Every 2 seconds, I look at 100 measurements and ask three questions: 1. How bouncy was it? (variance) 2. How fast were the bumps? (frequency) 3. How much total energy was there? (magnitude)”

“That turns 100 numbers into just 3 clues!” says Lila the LED. And those 3 clues are enough to tell walking from running from sitting.

But Bella the Battery is worried: “If Sammy measures 50 times per second ALL DAY, I will run out of power in 8 hours!”

Max has a solution: “Sammy, measure for 1 second, then nap for 1 second. Repeat!”

With this clever nap schedule (called duty cycling), Bella lasts 16 hours instead of 8, and they still get 95% of activities right!

“And if someone is on a bus?” asks Lila.

“Easy!” says Sammy. “The GPS shows we are going 50 km/h, but the bumps are tiny and smooth. That means we are in a vehicle, not running really fast!”

8.14.1 Try This at Home!

Put your phone in your pocket and walk across the room. Then run across the room. Then sit down. If your phone has a fitness app, check the step counter – it uses exactly this trick to count your steps! The bouncing pattern of walking is totally different from running, and sitting has almost no bouncing at all.

8.15 What’s Next

Direction Chapter Focus
Next IoT ML Pipeline Systematic 7-step approach for building production ML models
Previous ML Fundamentals Core ML concepts: training, inference, feature extraction
Related Multi-Sensor Data Fusion Combining accelerometer, GPS, and Wi-Fi for improved accuracy