Max’s Status Update for 2/22

The main goal for this week was finalizing design & obtaining the rest of the parts for the portable system. While I do have all parts picked out and most in hand, I missed the window to order the battery for the device. However, that shouldn’t be a problem since we have a couple of weeks before we anticipated having a mobile hardware platform.

I looked over the available libraries for our two main interfaces (Bluetooth and I2C) and came to the following conclusions:

Bluetooth:

The pybluez Python library explicitly supports Raspberry Pi, which should make bringup that much easier. The Bluetooth Low Energy support is listed as “Experimental”, but we don’t need to make use of any of the fancier features, so it shouldn’t be an issue. Also, our power budget is seeming more and more generous now that we’ve decided on a 3000mAh battery.

I2C:

The smbus2 Python library is pure Python, so it should simplify setup. While it does not seem to support the full System Management Bus protocol (a derivative of I2C), the implemented features easily cover our use case (reading and writing from registers at low speed).

Both solutions are Python since we would like to be able to do our ML on the RPi, and Sojeong/Jacob are more comfortable doing that in Python than C, which seemed to be a more obvious choice for interfacing over I2C/Bluetooth.

Sojeong’s Status Update for 02/22/2020

This week, I collected accelerometer data and started working on the fall detection algorithm. Before we get our pi set up, I will use my iPhone to collect the data. When collecting the data, I put my phone in the pocket as our final device will also be used that way. I collected the 3-axis accelerations of me falling forward, backward, sideways, and walking, jumping, running, sitting down, and bending down.

For feature selection, I first tried using the vector magnitude of the three accelerations. Using the magnitude instead of using a list of three accelerations simplifies the algorithm, and I expect that it would give similar results because the graphs of xyz accelerations do not differ a lot from each other as shown in the below graphs.

I calculated the magnitude of the acceleration data ((x^2 + y^2 + z^2)^0.5) and split up the data series into a window of size 10. I chose 10 because it covered the peaks in the fall data. However, this could differ from person to person, so I will have to collect more data to make sure that this interval works.  I trained the svm using forward fall, side fall, and walking data, and tried testing it. The algorithm detects the all kinds of falls, and classifies sitting and bending as non-falls, but it classifies jumping and running as falls.

For the next week, I will collect more training data from my teammates to compare how the acceleration data differ among people. To improve the accuracy of the algorithm, getting more data for the train set might help. I will also try using the magnitude and angle of the accelerations as a feature. For running and jumping, the magnitude of the acceleration may be similar with the falls but the angle will definitely be different, so it is possible that the algorithm will be able to classify them properly.

Status Update Jacob Hoffman 2/22/2020

This week, we decided a good way to collect preliminary data for designing our machine learning pipeline would be to use our smartphones. I took some falls in the hallway to collect some preliminary accelerometer data. I also began the design process for the RNN.

We also took our design phase discussions and fleshed them out into a visual presentation.

Nick’s Status Update for 02/22/2020

This week, we focused on and discussed how we should collect the fall data with different strategies. Also, the requirements for the mobile application features are set with details. Searching proper APIs and tools for the application features will be continued, and implementation for sending a message should be set up next week. The current project progress is on schedule, and we will bring the initial environment up for each component next week.

Max’s Status Update for 2/15/2020

This week we narrowed down our hardware platform to a specific model RPi (Zero W) and picked out a plug-in accelerometer from the 18-500 inventory. I picked up the parts at the end of the week. Still need to get some components (portable power source, some means of attaching it to a person), but those won’t be necessary until we have a system working. Next task is to setup an OS and figure out how to talk to the IMU over I2C.

Jacob Hoffman Status Update for 2/15/2020

This week, we determined possible ways to process the input data into features. We determined that we will break the time series data into overlapping segments which we will manually label and classify with a machine learning method.

We determined we would try the following machine learning approaches :
RNN , SVM

Sojeong’s Status Update for 02/15/2020

This week, I spent time reading existing research papers about different fall detection algorithms. The main points that I was looking for in those papers were what kinds of data they collected to train their algorithm and how they tested it. One of the papers only used accelerations in three axes to train their algorithm, and got 99.14% accuracy for their best results. This was surprising because I thought we would need more than just accelerations to build an accurate algorithm. Seeing the results, we decided to start our project by collecting acceleration data first, and if the results are not satisfying enough, we will combine other data such as angular velocity. For testing, I came up with different types of activities for fall and non-fall categories to clearly define what falls are and to narrow down the types of activities that the algorithm is going to detect. For the next week, we will get the accelerometer and Raspberry Pi, so I am planning to get some data and start writing the fall detection algorithm using SVM. Because the accelerometer data might not be accurate and include some noises, I would also have to think about some ways to preprocess the data.

Team Status Update for 02/15/2020

  • Discussed about our solutions for each area:
    • Design of the device:
      • Pin to your belt or body to fix the location of the device, which keeps the fall detection data consistent
    • Fall detection:
      • Listed types of normal activities (ordinary behavior) for fall and non-fall categories (unusual fall) for testing
      • ML algorithm selection design decision
    • Mobile App:
      • Decided to change from iOS to Android application
  • Picked up core hardware, determined approximate specs for the remainder
  • We have a new team member (Jacob) joined our team. He will help work on the machine learning portion of the fall detection system.

Nick’s Status Update for 02/15/2020

Accomplishments this week:

  • New plan for mobile application from iOS app to Android app since some of us have Windows laptops, which prevents us download Xcode (development tool for iOS app)
  • Setup a new initial environment for the Android application

Progress for schedule:

  • On schedule

Deliverables I hope to accomplish next week:

  • Finish setting up a new environment for the application
  • Start adding features for sending a message to the first responders

Introduction and Project Summary

For many elderly people,  walking safely is especially important for the elders because fall-related injuries are common and can lead to severe health problems. However, there are concerns that they may be left alone in a dangerous situation or get lost without any assistance near them. To resolve such problems, we came up with a smart attachable device connected with a mobile application that detects a fall and sends alerts to the first responders. The main feature of our smart cane is sending an alert to the user’s first responders when there is an unusual fall detection on the device.