On-device fall/crash detection: which tiny model + sensor fusion to tell bike crash, slip, and stairs apart?

[bytesbrains]

(A 💡 Idea — open discussion, not yet a scoped issue. If this firms up and touches a guardrail, the implementing PR gets an ADR.)

The question

Can a tiny on-device AI model fuse the phone's sensors and decide the fast-acute trigger — telling apart a bike crash, a slip on the road, a fall on the stairs, and a harmless phone-dropped? This is the fast path of the detection brain (#28 / #37; wearable depth in #8).

Short answer from early discussion: yes — and a small specialised model is the right tool (not a language model). It's a Human Activity Recognition / fall-classification problem, and it must run on-device so we keep the guardrail "liveness is one bit — process at the edge, never the content." The model eats the raw stream locally and emits only a verdict across the LivenessSource boundary — raw IMU/GPS never leaves the phone.

What we'd be building

• Model types: 1D-CNN / TCN / small LSTM-GRU over the IMU window — tens of KB to a few MB, on the low-power core (TFLite / Core ML / ONNX Runtime Mobile / ExecuTorch).
• Sensor fusion inputs: accelerometer + gyroscope (impact + orientation), barometer (the altitude drop is a strong stairs tell), GPS/speed (bike/vehicle vs. pedestrian), step/screen context.
• The tells: bike crash = high speed → sharp deceleration → tumble → stillness; stairs = barometric drop + impact + stillness; slip = single impact, often quick recovery (which should cancel the trigger).

Constraints that must hold (the guardrails)

• Edge-only / one bit out. No raw trace crosses the boundary; no logging or syncing of telemetry.
• Tiny & battery-cheap — it runs always-on; battery death is itself a failure mode.
• Determinism & a known false-alarm profile — every release should have a measured false-alarm rate via the simulation harness (app/test/sim/).
• The grace window does the safety work — a hard-fall guess just opens the "are you okay?" check (~10–30s). False alarm > no alarm, but keep it cheap — a slip you walked off cancels at rung 1.
• A small reasoner (rules / gradient-boosted) may sit above the detector to weigh context and trim false alarms — but the detector itself is the tiny sensor model.

Where you can help

• Prototype a fall/crash classifier and run it through (or extend) the sim harness — report your false-alarm + recall numbers.
• Argue for a model architecture and a per-tier sensor set.
• Point us at open fall / HAR datasets (SisFall, UMAFall, MobiFall, etc.) and labelling strategies — data is the real bottleneck.
• Mobile folks: real numbers on always-on inference battery cost per platform.

Bring experiments, papers, datasets, and war stories. "I tried X and it false-fired on speed bumps" is exactly as useful as a clean result.

[bytesbrains]

This now has grabbable issues — if you want to build rather than (or as well as) debate here:

• 🧭 Epic Epic: On-device acute fall/crash detector — synthetic data -> GPU training -> tiny on-device model #62 — On-device acute fall/crash detector (the full generate → train-on-GPU → push-to-device loop, with the guardrails).

Foundation issues, independent and pickup-able today (no GPU or ML depth needed — they unlock everything downstream):

• 🟢 feat(sim): synthetic IMU sensor-data generator for fall/crash scenarios (domain-randomised) #59 — Synthetic IMU sensor-data generator (domain-randomised)
• 🟢 feat(sim): fall/crash detection benchmark — fixed scenario suite + recall/false-alarm metrics #60 — Detection benchmark + recall/false-alarm metrics
• 🟢 feat(data): adapters for public fall/HAR datasets (SisFall, UMAFall, MobiAct) -> common format #61 — Public fall/HAR dataset adapters (SisFall / UMAFall / MobiAct)

Keep the architecture/dataset debate here in this thread; grab an issue when you're ready to build. 👁️