Why Motion Safety Matters
For blind and low-vision users, a fall is not just a momentary accident. It can mean injury, loss of independence, or delayed help when nobody is nearby. Smartphones already contain useful motion sensors, so they can become a practical safety layer without requiring a separate wearable device.
This project explores that idea through a Flutter API that detects falls and analyzes movement patterns using accelerometer and gyroscope data. The API is designed to run inside mobile applications, monitor motion in real time, and trigger callbacks when a dangerous event is detected.
The central challenge is reliability. Normal daily movement can be fast and irregular: sitting down, turning quickly, putting the phone in a pocket, or dropping the phone on a table can all create sensor spikes. A useful system must react quickly to real falls while avoiding unnecessary alerts.
Understanding Smartphone Motion Sensors
A smartphone can observe movement through two main sensors:
Accelerometer - measures linear acceleration along the three spatial axes. It tells us how strongly the phone is moving along \(x\) , \(y\) , and \(z\) .
Gyroscope - measures angular velocity. It tells us how quickly the phone is rotating or tilting around its axes.
Used separately, each sensor gives only part of the story. A fall usually includes both a strong acceleration change and a sudden orientation change. Combining both sensors gives a more complete picture of the motion.
To reduce dependence on phone orientation, the system often works with signal magnitudes instead of single-axis readings. For acceleration:
\[ SMV_a = \sqrt{a_x^2 + a_y^2 + a_z^2} \]For angular velocity:
\[ SMV_g = \sqrt{g_x^2 + g_y^2 + g_z^2} \]This helps the detection logic remain useful whether the phone is in a hand, pocket, or bag.
Fall Detection Fundamentals
Most fall detection methods can be grouped into two families.
Threshold-based methods compare sensor readings against predefined limits. They are fast, simple, and suitable for real-time use on a phone. Their weakness is that sudden normal movements may look like falls.
Machine learning methods learn patterns from recorded motion data. They can become more adaptive, but they require data collection, feature extraction, training, and evaluation.
This project uses a hybrid design. The completed real-time detector is threshold-based, while the data pipeline prepares motion windows that can be used by a machine learning model.[1][2]
The Detection Strategy
The threshold detector does not rely on one formula alone. Instead, it evaluates five independent methods inspired by smartphone-based fall detection in unconstrained phone positions, then combines their decisions.[1] If at least three methods agree that the motion looks like a fall, the event is confirmed:
\[ \text{fall} = \begin{cases} 1, & \sum_{i=1}^{5} d_i \ge 3 \\ 0, & \sum_{i=1}^{5} d_i < 3 \end{cases} \]where \(d_i \in \{0, 1\}\) is the decision returned by method \(i\) .
This voting approach is useful because each method observes a different part of the movement. Some focus on acceleration, others on rotation, and others on changes in phone orientation.
1. Accelerometer-Gyroscope Vector Signal Resultant
The first method combines accelerometer and gyroscope readings into one resultant value:
\[ AGVeSR = \sqrt{ (|A_x| + G_x)^2 + (|A_y| + G_y)^2 + (|A_z| + G_z)^2 } \]The use of absolute acceleration values helps reduce sensitivity to phone orientation. When \(AGVeSR\) exceeds its threshold, the method marks the window as a fall candidate.
2. Linear Acceleration Magnitude
Another way to isolate movement is to estimate linear acceleration:
\[ A_{li} = (A_x - G_x,\ A_y - G_y,\ A_z - G_z) \]The total magnitude is then computed as:
\[ A_{lim} = \sqrt{\sum_j |A_{li,j}|^2} \]where \(j \in \{x, y, z\}\) . A high value suggests a strong movement event.
3. Orientation Change
During a fall, the phone often changes angle sharply. The angle is estimated from the dominant acceleration axis:
\[ \alpha = \tan^{-1} \left( \frac{A_\alpha}{\sqrt{A_\beta^2 + A_\gamma^2}} \right) \]The detector compares angles across a short time interval:
\[ |\alpha_t - \alpha_{t-\Delta t}| > 60^\circ \]If the difference is large enough, the method raises a fall candidate.
4. Gyroscope Resultant Distance
The gyroscope resultant measures rotational intensity:
\[ GyroRe = \sqrt{G_x^2 + G_y^2 + G_z^2} \]The method then checks how quickly this resultant changes:
\[ GyroReDi = \frac{ (GyroRe_n - GyroRe_{n-2}) + (GyroRe_{n-2} - GyroRe_{n-4}) }{2} \]This captures sudden rotation, which is common during a fall.
5. Accelerometer-Gyroscope Peak
The last method checks whether both sensors peak in the same time window:
\[ Ac = \sum_{i=1}^{n}\sqrt{A_x(i)^2 + A_y(i)^2 + A_z(i)^2} \] \[ Gy = \sum_{i=1}^{n}\sqrt{G_x(i)^2 + G_y(i)^2 + G_z(i)^2} \]A fall candidate is raised only when both conditions are true:
\[ Ac > Th_a \quad \land \quad Gy > Th_g \]This is useful because many normal movements may create either acceleration or rotation, but not always both at a high level.
API Design
The API is built around a small public interface that can be integrated into a Flutter application:
startMonitoring();
stopMonitoring();
onFallDetected;
onAbnormalGaitDetected;startMonitoring() starts the accelerometer and gyroscope streams.
stopMonitoring() stops data acquisition and finalizes pending operations.
onFallDetected is triggered when the voting logic confirms a fall.
onAbnormalGaitDetected is used when movement patterns indicate abnormal gait behavior.
Internally, the system is split into five parts:
- Sensor acquisition streams timestamped accelerometer and gyroscope values.
- Signal processing prepares readings for detection by filtering and normalizing them.
- Fall detection applies the threshold methods and voting rule.
- Gait analysis studies walking stability from motion patterns.
- Event handling connects detection results to application actions such as alerts, vibration, or emergency notifications.
Motion Data for Learning
Threshold methods are valuable because they work immediately, but long-term improvement requires data. The API stores motion readings locally in daily files. These files can be uploaded to a server for model training and then removed from the device to save storage.
For each motion window, eight signals are considered:
- accelerometer axes: \(A_x\) , \(A_y\) , \(A_z\)
- gyroscope axes: \(G_x\) , \(G_y\) , \(G_z\)
- accelerometer magnitude: \(SMV_a\)
- gyroscope magnitude: \(SMV_g\)
Each signal is transformed into statistical and frequency-based features, following the same general idea used in machine-learning fall-detection pipelines.[2]
- mean
- variance
- median
- delta
- standard deviation
- maximum and minimum
- 25th and 75th percentiles
- power spectral density
- power spectral entropy
That gives an 88-dimensional representation:
\[ 8 \text{ signals} \times 11 \text{ features} = 88 \text{ features} \]The model can then classify a motion window as:
\[ y \in \{\text{fall}, \text{non-fall}\} \]This setup makes the API useful beyond immediate detection. It also creates a foundation for improving classification quality as more real-world motion data becomes available.
Practical Integration
A fall detection API should be easy to add to an existing mobile application. The host app should not need to know the details of every threshold formula. It only needs to start monitoring, stop monitoring, and react to events.
Possible reactions include:
- sending an emergency notification
- logging the event with a timestamp
- playing an audio cue
- vibrating the device
- showing a confirmation screen before contacting someone
This separation keeps the detection engine reusable while allowing each application to decide how alerts should behave.
