Abnormality in Elderly Fall using Android Smartphone
1. "Abnormality of Elderly Fall using
Android Smartphone"
Enrol. No. – 10503888
Name of Student – SHIVI TANDON
Name of supervisor – Ms. Sangeeta
Mittal
2. Introduction
• The prime objective of "Abnormality of Elderly Fall" application is
to create a full fledged Android application which would detect the
abnormality/normality of elderly fall using accelerometer data and
heart rate, which is collected from android sensors. In the case of
an abnormal fall, an SMS would be sent to the nearest doctor.
• The project is developed in Java Programming Language by using
Eclipse Integrated Development Environment (IDE). We use Android
Software Development Kit (SDK) which includes a variety of custom
tools that help us develop mobile applications on the Android. The
data is collected using android sensors(accelerometer and camera).
Classifier is trained using this data with the help of the machine
learning tool Weka.
3. Problem Statement
• Problem statement can be phrased as follows:
• The 'Abnormality of Elderly Fall' system is a specialized application designed to
monitor human activity, alerting to falls using the Android phone facilities. This
application is designed to observe the abnormality of user Falls and is the result of
extensive research on the subject of human activity and movement.
• This system constantly monitors the users motion and the heart rate of the user,
trying to determine when 'normal activity' is occurring, and alerting when activity
indicating the abnormality in the fall of the user occurs.
• In addition, users can choose to send an SMS Alert message to a caregivers
telephone number when abnormal Fall events occur. Fall Detection is a key
component of healthy, secure motion - for the elderly and those on the repair.
With this system, individuals can feel free to move about their environment, with
an electronic guardian ensuring that their physical activities are monitored in case
of danger. The aged and elderly can use it to act as a safety switch, alerting family
members and caregivers in the case of a fall during a walk or life at home.
4. Overview of proposed solution
• This is achieved by equipping the user with two android smart
Smartphone, from which the activity and the heart rate of the user are
determined. The user of this system will keep one android Smartphone in
his/her pocket and the other Smartphone would be tied to his/her wrist.
Since tying a Smartphone is not a feasible option, the other smart phone
can be replaced by a custom made wrist band which can provide the same
functionality as the phone would.
• I have extensively made use of these sensors for data collection. In this
work accelerometer sensor is listened for identifying and tracking the
physical activities of the user such as walking, running, stand idle. The
phone kept in the pocket provides the activity dataset. Our Heart
condition can be measured by heartbeat. The heart rate of the user is
measured by recording a video, with the flash on, while the camera lens is
place just below the wrist creases at the base of the thumb. Further
processing the video can give me the heart rate.
5. • Benefits -
• This application ensures that the elderly can live longer
independently with minimal support of the working-age
population.
• The user does not need specialized hardware to detect
heart rate and he/she can take a measurement in virtually
any place under almost any circumstances.
• The users can feel free to move about their environment,
with an electronic guardian ensuring that their physical
activities are monitored in case of danger. The aged and
elderly can use Fall Detector to act as a safety switch,
alerting family members and caregivers in the case of an
abnormal fall during a walk or life at home.
6. Details of Empirical Study
• Android SDK - The most important SDK tools include the Android SDK Manager (android sdk), the AVD
Manager (android avd) the emulator (emulator), and the Dalvik Debug Monitor Server (ddms). Some
frequently-used SDK tools are:-
• Dalvik Debug Monitor Server (ddms) - Lets you debug Android applications.
• Android Emulator (emulator) - A QEMU-based device-emulation tool that you can use to design, debug,
and test your applications in an actual Android run-time environment.
• sqlite3 - Lets you access the SQLite data files created and used by Android applications.
• Eclipse 4.2.0 - This software is OSI Certified Open Source Software. It is a cross-platform, multi-language
Integrated development environment (IDE) comprising a base workspace and an extensible plug-in system
for customizing the environment. It can be used to develop applications in Java and, by means of various
plug-ins, other programming languages. Eclipse supports a rich selection of extensions and is hence used
for Android development via Google's ADT.
• Weka - (Waikato Environment for Knowledge Analysis) is an open source suite of machine learning
software written in Java. It contains a collection of visualization tools and algorithms for data analysis and
predictive modelling.
7. Functional requirements and Non Functional
requirements
• The project involved analyzing the design of few applications so as to make the application more user friendly. To do so, it
was really important to keep the navigations from one screen to the other well ordered and at the same time reducing the
amount of typing the user needs to do. In order to make the application more accessible, the android version had to be chosen
so that it is compatible with most of the Android devices. Hence Android 2.3.3 Gingerbread version was chosen.
• Graphical User interface which the user will see
• Provide accessibility to the application through Wi-Fi or cellular network.
• For developing the application the following are the Software Requirements:
• Operating System: Windows 7
• Language: Android SDK, Java
• Tools: Eclipse IDE, Android Plug-in for Eclipse, Machine learning tool Weka, MATLAB
• Technologies used: Java, MATLAB.
• Debugger: Android Dalvik Debug Monitor service
• External APIs: CSV write
• For running the application the following are the Software and Hardware Requirements:
• Operating System: Android 2.3 or higher versions
• Network: Wi-Fi Internet or cellular Network
• Phone camera with flash
• Android phone with built in accelerometer
• Blood pressure monitor
8. • Non-functional requirements
• Efficient camera with a flash is required.
• Efficient network bandwidth over Wi-fi or 3G is required for
smooth working of the application.
• The smart phone should be tied tightly on the wrist so that
the entire camera lens id covered otherwise the readings
might be very noisy.
• Phone call, SMS or any type of notification floated in the
mobile environment will be handled by Broadcast receivers.
• All the user data is stored on the SD card of the user's
device. In case the SD card's memory is exhausted the user
is asked to delete some content from his SD card.
10. Implementation details and issues
• Accelerometer
• This module will log the accelerometer data and save the
data in a csv file on the SD card of the device. The raw data
for walking, running and stand idle are collected seperately
by activating the application on the phone and place it on
trouser’s pocket. Raw data at this moment is collected
continuously. The accelerometer values are the change in
position with respect to time. That is it is not exact
acceleration values. So these values are converted to actual
acceleration. The accelerometer in the android phone
returns three acceleration values i.e. acceleration in X,Y,Z
directions. X axis gives sideways accelerations, Y axis gives
forward or backward acceleration and Z axis gives upward
or downward accelerations.
16. • Heart Rate
• This module will log the heart rate data by capturing the
video and save the data in a csv file on the SD card of the
device. The raw data is collected separately by activating
the application on the phone and tying it to the subject's
wrist. Raw data at this moment is collected continuously.
The video extracted are processed using MATLAB. As a
result of the video processing we have the red channel,
green channel and blue channel of each frame in the video.
This data coupled with the ground truth calculated using
blood pressure monitor is saved in a CSV file. This CSV file is
used to train various classifiers using weka.
17. Video taken for calculating heart rate by tying the phone on the wrist
27. CLASSIFICATION ACCURACY OF ACCELEROMETER
DATASET FOR ALL THE ALGORITHMS
S.NO ALGORITHM RELATIVE ACCURACY
1. C4.5 Decision Trees 98.20%
2. RIPPER Decision Rules 98.34%
3. Naive Bayes 91.74%
4. 3-Nearest Neighbour 97.34%
5. Random Forest 98.39%
6. Bagging 98.48%
7. Adaboost M1 boosting 96.26%
28. CLASSIFICATION ACCURACY OF HEART RATE
DATASET FOR ALL THE ALGORITHMS
S.NO ALGORITHM RELATIVE ACCURACY
1. C4.5 Decision Trees 94.60%
2. RIPPER Decision Rules 94.15%
3. Naive Bayes 69.81%
4. 3-Nearest Neighbour 95.74%
5. Random Forest 95.71%
6. Bagging 94.95%
7. Adaboost M1 boosting 25.35%
29. Average build-time for Accelerometer
dataset
Timetobuild(seconds)
Classifier
Figure 7. Average build-time for Accelerometer dataset
Buildtime(seconds)
30. Average build-time for Heart-rate
dataset
Classifier
Figure 8. Average build-time for Heart-rate dataset
Buildtime(seconds)
31. RELATIONSHIP BETWEEN PHYSICAL ACTIVITY
AND HEART RATE FOR AN ELDERLY PERSON
Heart rate ≤ 60 60 ≤ Heart Rate
≤ 100
77.5 ≤ Heart
Rate ≤ 108.5
108.5 ≤ Heart
Rate ≤ 131.75
Heart Rate ≥
131.75
Resting Normal Abnormal Abnormal
Moderate-
intensity
physical activity
Abnormal Normal Normal Abnormal
Vigorous-
intensity
physical activity
Abnormal Abnormal Normal Normal
32. S.No List of Various
Components
(modules) that require
testing
Type of Testing Required Technique for writing test
Cases
1. Home Screen Performance White Box
2. Acquire X,Y,Z coordinates Performance White Box
3. Open Camera and record
video
Unit White Box
4. RGB value calculation Unit White Box
5. HeartRate CSV Unit White Box
6. Accelerometer CSV Unit White Box
7. Send CSV files over
Bluetooth
Unit White Box
8. Classification using rule
based classifier
Unit White Box
33. • Item Pass/Fail Criteria
• Passing criteria of any test plan at lower level will be
completion of all test cases and only 10% cases to fail. As
our program is complex type that is output of one module
is input to other so we can’t take risk of high percentage of
failure only exceptional cases should fail else it should pass.
If a program tend to have too many fail test cases then it’s
considered to be failed
•
• Passing criteria at high level would be completion of all
lower level module successful implementation of test plans
and none fails. In case lower level test plan fails then upper
level plan too will fail.