Posted on

Sojeong’s Status Update for 3/7/2020

This week, I realized that using the phase of the accelerations as a feature can be problematic because it depends on the orientation of the device in the pocket. I was using the angle between the xy-plane and z-axis, but the axes could change if the user puts the device in different orientation. It could also lead to inaccuracy if the orientation of the device changes when the user moves. To handle this problem, I decided to use the change in phase over time instead of using the actual values of the phase.

Also, I added the magnitude and phase calculation to the code instead of doing it manually on excel for feature extraction. This was done to prepare for the  integration with the RPi, as we would not be able to move the data received from the RPi to excel and do calculations there.

In terms of schedule, we are still on track.

After spring break, I will continue collecting more data and I hope to start getting data from the RPi and integrate them together.

Posted on

Max’s Status Report for 3/7

This week I worked on the Bluetooth interface for the RPi.

As it turns out, Bluetooth supports a mode in which it behaves like a serial port — something I have experience working with. After some minor consternation in setting that up, I was able to get a simple two-way serial program working in Python which forwarded data to a phone and received commands back from it.

Along the way, I made an important compromise which simplified implementation: I manually paired the phone to the RPi rather than automatically. As it turns out, pairing is only really accomplished with the bluetoothctl CLI, which I couldn’t figure out how to automate nicely. Pairing only needs to happen once per device, so this doesn’t impact our testing.

At the end of the week, I handed the device off to Nick after verifying that he could access the RPi over WiFi.

This week is spring break, and so I won’t be doing any major work; I’ll probably be acting as remote tech support if something with the RPi doesn’t work for Nick, who may be working over break.

After break, I’ll work out any discovered issues with the device and begin work on data collection when we have the infrastructure to support it.

Currently on-track.

Posted on

Jacob Hoffman Status Update Saturday 3-7-2020

This week, we looked at further design trade studies and decided to shift from focusing on RNN’s and SVM’s to working entirely on SVM’s due to power requirements of RNN’s on a Raspberry Pi chip.

Because the SVM design doesn’t have frequency domain features such as STFT and wavelet transform, I started working on feeding and tuning the paramaters of those features into the pipeline.

As well, SVM can sometimes benefit from PCA compression at the beginning of the SVM, so I started working on implementing and tuning the PCA compression.

Posted on

Team Status Update for 2/29/2020

The most significant risk in our project for now is the discrepancy between the real and test data. We have the RPi set up and we ordered a gym mat and a dummy last week, so we are planning to collect data of us falling and the dummy falling. We are also going to collect data by placing our device in positions other than the users’ pocket, just to check whether a pocket is the best place and whether placing the device on other positions (necklace, belt) affect the collected data.

We also worked on design documents this week, and we are planning to incorporate the feedback we got from the instructors and our peers. We got a feedback that it would be helpful to add a help button instead of relying only on the fall detection, and this feature can easily be added to our app. There were some concerns about data collection during the design review, and we definitely need to collect much more data for our fall detection algorithm to work accurately. We will start collecting data from our device as soon as we get the RPi ready, and as we ordered the dummy, we will be able to collect a much larger data set when it arrives.

Posted on

Sojeong’s Status Update for 2/29/2020

This week I tried using the angles of the acceleration as new features to the SVM. I decided to use the angle between the xy-plane and the z-axis because that would be the angle that changes the most when a person falls. However, I should think more about which axis to use after collecting some data from our device as the orientation of the accelerometer in our device and the phone would be different. I should also consider that the device will be placed inside a pocket, which can also change the orientation.

The angle was defined as: atan(az/(ax^2+ay^2)^0.5) The graph below shows that the angle fluctuates a lot for a fall, while it stays mostly constant for walking.

forward fall
walking

In terms of schedule, we are on track. For next week, I would really need to start collecting and using the data from our actual device as the RPi will be ready to use. All the data that I collected this week and last week were all done in the same position, but I should also try collecting them from different positions and see if they make any difference.

Posted on

Nick’s Status Update for 02/29/2020

This week, we mainly analyzed and researched how we can collect the fall data effectively. Instead of we physically fall, we decided and ordered a dummy object to collect metadata for the fall detection. On the mobile application side, we’ve been working on sending an alert with a text message. The current progress is on schedule, and we are expecting to complete the notification feature and connect with RPi.

Posted on

Max’s Status Update for 2/29

This week I collected the necessary bits and got the RPi/IMU set up, as well as placing the order for the battery. It turns out that the manufacturer of the IMU addon board has their own demo code which manages their subset of I2C cleanly — this was much easier to use than the full smbus suite.

The data rate defaults to 100Hz which should be fine for us. The chip also exposes an interface to calibrate the accelerometers, but that’s only for adjusting the resting measurements. We can’t count on the orientation of the device to remain constant, so we probably won’t care to use the feature.

As of now, the RPi is configured to run headless (i.e. only talked to over wireless SSH), so it’s not going to do much more than sit in my room where it knows the WiFi password. Next steps are to set up Bluetooth and to see if there’s a better way to talk to it — preemptively adding WiFi networks by SSID/key is obnoxious.

Our Gantt chart has this as the first of two weeks for bringup, so the project is still fully on-time.

Posted on

Jacob Hoffman Status Update 2-29-2020

This week, we gave our design review. I also worked on the conceptual understanding of RNN’s. I looked at examples of RNN’s from Github used in different scenarios to better understand the inner workings. I talked to professor Chi (ECE) about potential strategies for tackling this problem with machine learning and she said that it would be worthwhile to try an RNN. After conceptually understanding the fundamentals, I began design for a fall detection RNN strategy.

Posted on

Team Status Update for 2/22/2020

We decided to run the ML algorithm on the RPi instead of the phone, because we want the ML work to be done in Python. Some of us use Android and some of us use iOS, so it would also be hard for us to test if we do it on the phone. Other than this, there wasn’t much change to our project. We also got our Pi and the accelerometer, so Max is working on setting them up.

The most significant work for now is understanding our data. We have to check whether a person’s height or weight has impact on the data collected, and work on choosing the features that will work best with our algorithm. If the data that we collect has too much noise, we might have to smooth it out using a Kalman filter.