Inspiration
Fall detection today is almost always a premium hardware feature, a paid wearable, a medical-alert pendant, or a smartwatch. For someone living alone or at risk of falling, that's real cost and setup friction before any protection exists. Every phone already carries an accelerometer, a gyroscope, a microphone, and a speaker, the same sensors a dedicated device would need. We wanted to see how far those could actually go.
What it does
Motion Sense watches a phone's live motion for a fall-like signature, an acceleration spike followed by real stillness, and confirms it over 5 seconds before doing anything, so an ordinary bump doesn't become a false alarm. If confirmed, the phone speaks out loud and asks "are you okay?", listening for a spoken or tapped response for 15 seconds. If there's no answer (or the person says "help"), it escalates: repeating vibration, a slow non-strobing flashlight blink, and a text message pre-addressed to an emergency contact with the person's live GPS location. A separate, always-on "listen for help" mode can trigger the same flow from a spoken phrase alone, with no motion involved at all.
How we built it
Everything runs in a single self-contained HTML file, vanilla JavaScript, no frameworks, no build step. The "AI" is a one-hidden-layer neural network written by hand, trained with backpropagation directly in the browser on the user's own recorded motion. Before shipping it, the backprop math was gradient-checked — the analytical gradient compared against a numerical estimate — rather than trusted blind. Since real motion data was hard to collect at volume, we built a simulated bootstrap dataset covering falls, walking, sitting, hard set-downs, and car braking, so the model has a reasonable prior even with only a handful of real recorded samples.
Challenges we ran into
The hardest problem wasn't the neural network, it was telling a real fall apart from a phone simply being set down. Both produce the same raw shape: a motion peak followed by stillness. Our first fix required a loud sound alongside the peak, which solved the false alarms — but simulation testing showed it would also miss real falls that happen quietly, like a landing on carpet with no scream. We removed the hard sound requirement and instead trained the model on a wider range of fall sub-cases (quiet falls, falls with a cry, tumbling rotation) so it could learn when sound matters instead of always requiring it. We also had to design around real platform limits with no physical device to test on directly — iOS Safari doesn't support programmatic flashlight control at all, and its speech recognition is known to be inconsistent, so every voice or hardware feature needed a fallback path that didn't depend on it working.
Accomplishments that we're proud of
A neural network that trains and runs entirely in the browser, with zero external ML dependencies and its backpropagation math verified by hand (analytical vs. numerical gradient checking) before it ever touched real data. Four sensors: accelerometer, gyroscope, microphone, and orientation — genuinely fused into one model rather than a single threshold. A response flow that mirrors real commercial fall-detection UX (the check-in-before-escalating pattern used by Apple Watch) instead of firing an alarm on the first signal. And catching our own worst bug — a phone set down on a table reading as a fall — through actual simulated testing before shipping a fix, rather than guessing at a new threshold and hoping.
What we learned
Tuning a safety feature's sensitivity is a genuine trade-off, not a bug to fix away — every change that reduces false alarms risks missing a real event, and the honest answer is usually "fuse more signals" rather than "pick a better number." We also learned to simulate before shipping: several of the trickiest bugs (a table set-down passing as a fall, a car brake looking like a tumble) were caught by testing the feature-extraction code against synthetic edge cases before ever touching a real phone.
What's next for Fall Detector
Real-world validation is the honest next step; every threshold in this project was tuned against simulated data, not a large set of real recorded falls, because there was no physical device to test against during the build. Next would be collecting real motion data across different phones, body types, and carry positions to replace the simulated bootstrap set with the real thing. Beyond that: a companion mode for a household with multiple phones checking in on each other, and exploring whether the same on-device training approach could run on a smartwatch for continuous wear instead of needing the phone nearby.
Built With
- accelerometer
- backpropagation
- canvas-api
- css3
- device-motion-api
- device-orientation-api
- geolocation-api
- gyroscopre
- html5
- javascript
- machine-learning
- mediastream-api
- neural-networks
- sms
- web-audio-api
- web-share-api
- web-speech-api
Log in or sign up for Devpost to join the conversation.