What problem did I see?
Falls are one of the leading causes of serious injury for elderly people — and the risk is compounded by how long someone can lie on the ground before help arrives. Existing solutions are either expensive medical alert devices or smartphone apps that require the phone to be on the person at all times.
I wanted to ask: can a small, low-cost embedded system reliably detect a fall and send an alert? And specifically — at what cost, and with what tradeoffs?
Why did I care?
The problem felt concrete and solvable with accessible hardware. An accelerometer that costs a few dollars can measure acceleration in three axes at high frequency. A fall produces a very specific acceleration signature — a brief period of free-fall followed by a high-impact event. This seemed like a well-defined signal to detect.
I was also interested in the question of false positives. A system that alerts when someone sits down quickly is useless. Designing a reliable classifier for human motion — on a microcontroller, in real time — felt like a genuinely hard problem.
What did I build?
I built a wearable prototype using:
- An
ESP32microcontroller as the central processing unit - An
MPU-60506-axis accelerometer/gyroscope module - A threshold-based fall detection algorithm running on the ESP32
- A WiFi-based alert system to send a notification when a fall was detected
- A simple housing to make the device wearable for testing
The algorithm worked in two stages: detecting a free-fall phase (acceleration below a low threshold for a minimum duration) followed by a high-impact phase (acceleration spike above an upper threshold). Only if both phases occurred within a time window would an alert be triggered.
Bill of Materials
What went wrong?
The two-stage algorithm sounded elegant in theory. In practice, the free-fall phase was extremely brief — often 50–80 milliseconds — and my initial polling rate was too slow to consistently catch it. I was essentially missing the most diagnostic part of the signal.
False positives were also a problem. Dropping into a chair, bending over quickly, or placing the device on a hard surface all triggered alerts in early testing. Tuning the thresholds reduced false positives but also reduced sensitivity — I was constantly trading one error for the other.
The WiFi alert system added latency and dependency on network availability — a real limitation for the use case I had in mind.
What did I learn?
The core lesson was about the tradeoff between sensitivity and specificity in real-world classifiers. This isn't an abstract ML concept — it's something I experienced physically while watching my device misfire. You can't optimize for both simultaneously with a simple threshold approach.
I also learned that sensor selection matters more than algorithm complexity. A better IMU with higher sample rate would have given me cleaner data to work with. The constraint wasn't my algorithm — it was the resolution of my input.
If I rebuilt this today, I would use interrupt-driven sampling instead of polling, add a local Bluetooth alert (less latency, no WiFi dependency), and collect real fall data to train a lightweight machine learning classifier rather than relying on hand-tuned thresholds.