"A step counter that is off by twenty percent still sells. A fall detector that is off by twenty percent gets someone hurt. Same accelerometer, entirely different job."
A Deployment-Weary AI Agent
Prerequisites
This section assumes the inertial signal model of Chapter 23 and the HAR pipeline built across Sections 26.1 through 26.3. Because every application here is a decision under uncertainty, the calibration and conformal ideas of Chapter 18 are load-bearing, and the personalization of Section 26.4 and fairness of Section 26.6 are assumed rather than re-derived. The code example uses only basic peak detection on an acceleration magnitude signal.
The Big Picture
The previous six sections built a machine that turns motion into labels. This one asks the only question that finally matters: what decision does the label drive, and what does a wrong label cost? The same wrist accelerometer and the same recognition model serve four very different masters. A fitness app wants to motivate, so it tolerates noise and optimizes for engagement. A healthcare tool wants to inform a clinician, so it must be validated, reproducible, and honest about uncertainty. A safety system wants to intervene in real time, so latency and false-negative cost dominate everything else. An accessibility system wants to expand what a person can do, so it must adapt to bodies and movements that no benchmark ever sampled. Choosing the application fixes the loss function, the evaluation protocol, and the regulatory burden all at once. Getting the model right is a third of the job; getting the objective right is the other two thirds.
Fitness: motivation tolerates error, engagement does not
Consumer fitness is where HAR first reached a billion wrists, and it is the most forgiving of the four domains. A step counter that undercounts by fifteen percent still nudges a user toward more walking, because the target metric is trend and consistency, not clinical truth. The canonical pipeline is deliberately cheap: band-pass the acceleration magnitude to the human cadence range (roughly \(0.5\) to \(3\) Hz), detect peaks, reject peaks that are too close together, and count. From step count you derive cadence, and from cadence plus an estimate of stride length you derive distance and speed. Energy expenditure is reported in metabolic equivalents (METs), where one MET is resting metabolism (about \(3.5\) mL O\(_2\) per kg per minute) and an activity of intensity \(m\) METs over \(t\) hours for a person of mass \(w\) kilograms burns roughly \(m \cdot w \cdot t\) kilocalories. Walking is about \(3.5\) METs, running about \(8\) to \(12\).
What makes fitness engineering interesting is not the accuracy target but the breadth of activities and the cost asymmetry. Misclassifying a spin-bike session as "elliptical" barely matters; failing to notice a workout at all breaks the streak that keeps the user coming back. So modern fitness stacks bias toward high recall of the generic "exercising" state, then refine the specific modality when confident, exactly the coarse-to-fine hierarchy of Section 26.1. Automatic workout detection, rep counting for strength training, and swim-stroke classification are all HAR problems whose ground truth is fuzzy and whose users forgive the occasional miss, provided the system never nags them during a meeting they spent sitting still.
Key Insight
The application, not the model, sets the operating point. Fitness optimizes an expected-engagement objective and lives near high recall; safety optimizes a bounded false-negative rate and lives near high recall for a different reason (a missed fall is unacceptable); healthcare optimizes reproducible agreement with a clinical reference and cares about calibration; accessibility optimizes per-user adaptation and cares about coverage of the long tail. One accelerometer, four loss functions. Reporting a single "accuracy" number across them is a category error.
Healthcare: the reference standard is a clinician, not a benchmark
The moment a movement metric informs a medical decision, the rules change. Gait speed derived from a hip or wrist sensor is a validated vital sign that predicts fall risk and mortality; sedentary-time and step-count trajectories track recovery after surgery; tremor and bradykinesia scores from wrist inertial data quantify Parkinson's disease progression between clinic visits. The defining feature of the healthcare domain is that the ground truth is an external clinical reference (an instrumented gait mat, a rated motor exam, a supervised six-minute walk test) and the deliverable is agreement with that reference across a defined population, not accuracy on a held-out slice of the same recording. That distinction, and the regulatory apparatus around it, is the whole subject of Chapter 34; here we only flag its consequences for how you build.
Three consequences dominate. First, evaluation must be on held-out patients and, ideally, held-out sites, because a model that memorizes a rehab clinic's flooring or a cohort's demographics will collapse in the next hospital. Second, the model must emit calibrated uncertainty, because a clinician acting on a confident wrong number is worse than one who sees "low confidence, please retest." This is where the conformal prediction of Chapter 18 earns its place: a prediction set with a guaranteed coverage rate is a defensible clinical output in a way a bare softmax is not. Third, motion is rarely the only signal. Pairing inertial activity with the photoplethysmography of Chapter 30 lets you separate "elevated heart rate because exercising" from "elevated heart rate at rest," the difference between a workout and an arrhythmia alert.
In Practice: freezing of gait and the alarm that had to be instant
A research group building an assistive wearable for Parkinson's patients tackled freezing of gait, the sudden, dangerous inability to take the next step. The intervention was a rhythmic auditory cue played through an earpiece the instant a freeze began, which physiologically helps the patient restart walking. The Daphnet dataset made the recognition tractable: a spectral feature (the ratio of energy in the \(3\) to \(8\) Hz "freeze band" to energy in the \(0.5\) to \(3\) Hz "locomotion band" on the shank accelerometer) separates freezing from normal gait cleanly. The hard part was never accuracy on a held-out window; it was the closed loop. Detection latency had to stay under a second or the cue arrived after the patient had already stumbled, and false positives that blared music during smooth walking eroded trust until patients removed the device. The team fixed the operating point by a cost-weighted threshold that valued a missed freeze far above a spurious cue, then validated on held-out patients rather than held-out windows. The lesson generalizes: a healthcare HAR system is a control loop with a human in it, and its real metric is the outcome of the intervention, not the F1 of the classifier.
Safety: latency and the false negative that cannot happen
Safety applications invert the fitness cost structure. Fall detection for older adults, worker-down alarms on industrial sites, and crash detection in vehicles all share one property: a missed event can be fatal, so the false-negative rate is the primary constraint and everything else is negotiated around it. A wrist or pendant fall detector watches for the acceleration signature of a fall, a brief free-fall dip (magnitude toward \(0\,g\)) followed by a high-impact spike (often exceeding \(3\) to \(6\,g\)) and then a period of stillness in a new orientation. Threshold detectors on those three phases are the classic baseline; learned models improve them, but only if trained on realistic falls, which are ethically hard to collect and therefore usually simulated, a data-provenance caveat you must carry into any claim.
The safety engineer's real adversary is the false alarm, because a fall detector that cries wolf gets switched off and then protects no one. So the design lives on an explicit trade curve: push the decision threshold to catch every fall and you drown the user in alarms during sitting-down-hard and dropping-the-device events; back it off and you start missing real falls. Because the intervention is time-critical, this inference runs on the device itself under the edge and streaming constraints of Chapter 60, often with a location fix from Chapter 25 so the emergency call carries a position. Many shipping systems add a confirmation dwell: on a suspected fall they wait for user cancellation for a few tens of seconds before escalating, which converts some false positives into no-ops without materially delaying real emergencies.
Accessibility: the long tail is the whole point
Accessibility is the domain where the benchmark most badly misleads you, because its users are exactly the people whose movement the training data underrepresents. HAR here powers gesture-based control for people who cannot use a touchscreen, activity monitoring calibrated to wheelchair users and gaits altered by amputation or spasticity, and context detection that lets a screen reader or a prompting system act at the right moment. The clinical vignette in Section 26.1, where a model trained on healthy gait labeled a stroke patient's shuffle as "standing," is the accessibility failure mode in miniature: a taxonomy and a training set built around typical bodies erase atypical ones.
The fix is architectural and social at once. Personalization (Section 26.4) lets a model adapt to an individual's idiosyncratic movement from a short calibration, which for accessibility is not a refinement but a requirement, because the population variance dwarfs the between-activity variance. Fairness auditing across bodies and demographics (Section 26.6) is what keeps "works for me" from meaning "works for people like the developers." And the whole enterprise sits under the responsible-deployment norms of Chapter 70, because an accessibility device that fails silently removes an ability its user had come to rely on. The engineering commitment is to design for the tail first and treat the median user as the easy case.
import numpy as np
def count_steps(acc_xyz, fs, cadence_hz=(0.6, 3.0), min_prominence=0.15):
"""Count steps from a triaxial accelerometer window (m/s^2), gravity-agnostic.
acc_xyz: (N, 3) array; fs: sample rate in Hz. Returns (steps, cadence_hz)."""
mag = np.linalg.norm(acc_xyz, axis=1) # orientation-free magnitude
mag = mag - np.mean(mag) # remove the ~9.81 gravity offset
# Simple band-limiting: moving-average smoother at the upper cadence period.
win = max(1, int(fs / cadence_hz[1]))
smooth = np.convolve(mag, np.ones(win) / win, mode="same")
# Peak = local max above a prominence floor and respecting a refractory gap.
min_gap = int(fs / cadence_hz[1]) # steps cannot be faster than this
peaks, last = [], -min_gap
for i in range(1, len(smooth) - 1):
if smooth[i] > smooth[i-1] and smooth[i] >= smooth[i+1] \
and smooth[i] > min_prominence and (i - last) >= min_gap:
peaks.append(i); last = i
duration_s = len(mag) / fs
steps = len(peaks)
return steps, (steps / duration_s if duration_s > 0 else 0.0)
# 8 seconds of synthetic ~1.8 Hz walking (a step every ~0.55 s) plus noise.
rng = np.random.default_rng(0); fs = 50
t = np.arange(0, 8, 1 / fs)
signal = 9.81 + 1.2 * np.sin(2 * np.pi * 1.8 * t) + 0.2 * rng.standard_normal(t.size)
acc = np.stack([signal, 0.1 * rng.standard_normal(t.size), 0.1 * rng.standard_normal(t.size)], axis=1)
steps, cadence = count_steps(acc, fs)
print(f"steps={steps} cadence={cadence:.2f} Hz") # ~14 steps, ~1.8 Hz
Right Tool: peak detection you should not hand-roll in production
The refractory-gap peak loop above is a teaching device. In practice scipy.signal.find_peaks(mag, distance=min_gap, prominence=min_prominence, height=...) replaces the entire hand-written loop (about 10 lines) with one call, and it handles plateau peaks, edge cases, and vectorized prominence correctly, which the naive loop does not. For the band-limiting, scipy.signal.butter plus filtfilt gives a proper zero-phase band-pass in two lines instead of a crude moving average. Reach for these the moment step counts feed anything a user or clinician will see.
Exercise
You are given one accelerometer model and must ship it into two products: a fitness step counter and a fall detector. (1) Write the objective each product optimizes and name the metric you would report to a product manager for each. (2) The fall detector must guarantee at most one missed fall in a thousand; sketch how you would set and validate its decision threshold, and state what data you would need that the fitness product does not. (3) Explain, in two sentences, why a single ROC operating point cannot serve both products even though the sensor and features are identical.
Self-Check
1. Why is held-out-window accuracy an actively misleading metric for a healthcare gait tool, and what should replace it?
2. A fall detector and a fitness app both live at high recall. Why are the reasons different, and how does that difference show up in what each is willing to tolerate?
3. Accessibility is called the domain where benchmarks mislead most. Which two techniques from earlier in this chapter are the primary remedies, and why is personalization a requirement rather than a refinement here?
Lab 26
build user-independent vs user-adapted HAR models; compare generalization on held-out subjects.
Bibliography
Foundational HAR and benchmark datasets
The paper that established multi-accelerometer activity recognition and the leave-one-subject-out protocol every application in this section inherits.
The reference tutorial connecting the HAR pipeline to its deployment concerns; the NULL-class and evaluation guidance underpins the fitness and safety sections.
A multi-sensor, MET-annotated dataset that ties activity labels to energy expenditure, the substrate for the fitness intensity estimates here.
The ExtraSensory study: in-the-wild, multi-label context, the realistic messiness accessibility and fitness apps actually face.
Clinical, safety, and accessibility applications
The Daphnet freezing-of-gait system and dataset behind the closed-loop clinical vignette; a canonical latency-critical intervention.
The Apple Heart Study: what large-scale clinical validation of a consumer wearable claim looks like, and why held-out-patient evidence matters.
A survey mapping HAR methods to clinical use, documenting the reproducibility and validation gaps this section warns about.
Wearable foundation models
Narayanswamy, G. et al. (2024). Scaling Wearable Foundation Models (LSM). arXiv:2411.02737.
Google's Large Sensor Model, showing that self-supervised pretraining on massive wearable data improves downstream activity and health tasks, the direction fitness and health HAR is heading.
What's Next
In Chapter 27, we zoom from whole-body activities down to the fine motor scale: gestures, full-body pose, and the neuromotor interfaces that read intent from muscle and nerve. The accessibility applications sketched here (gesture control for people who cannot use a touchscreen) become the central problem, and the recognition target shifts from "what is this person doing" to "what does this person intend to do."