Band Aid Together

Using physiological sensors and mobile app connection through Firebase, Band Aid Together helps create links for loved ones and EMS for women suffering panic attacks and anxiety-induced seizures.

Comment

Inspiration

Nearly a month ago, we had a close friend experience a panic attack in an isolated area. When we saw the unfortunate effects of this incident on him, we were inspired to find a way to link one to their loved ones and help them get through it. Upon further research, we found out that women and mothers are disproportionately more likely to suffer from routine panic attacks and anxiety, especially in the Pandemic Era. Panic attacks and anxiety have also been linked to an increase in seizures.

What it does

Our project is a system that provides an immediate method of communication for someone experiencing a panic attack or seizure. We achieve this via a wearable armband which measures muscle contraction. If a panic attack or seizure is detected, the band securely sends an alert to the cloud. We have an app which will automatically detect this information from the cloud and contact emergency personnel/loved ones. A panic attack will lead to breathing instructions and messages to trusted contacts who can be added in the app. If the situation escalates to a seizure, the app will automatically call emergency personnel. In both cases, the app will send the person's location and coordinates. The app is also device-agnostic, allowing the user to directly contact trusted contacts and emergency personnel without the need for the armband.

How we built it

We first began by studying the problem in detail, iterating through various approaches and eliminating several of them. Once we discovered the link between muscle contraction and panic attacks/seizures, we narrowed our idea down to creating an armband with an EMG sensor (muscle sensor) that could detect panic attacks. As soon as we had this idea, we realized that we needed to develop an app which could interface with calling a set of trusted contacts. We then fleshed out this idea, adding both essential and optional features to the armband and app. For software, we decided to use Android Studio. For hardware, we decided to integrate our EMG sensor with an Arduino Nano 33 IoT.

Based on our individual strengths, we split into three groups, with two people working on designing the circuit and collecting EMG graphs, one person working on the app/backend, and another working on bridging the gap between the Arduino and Android. For communication between Arduino and Android, we started by attempting to implement a Bluetooth Low Energy (BLE) solution due to its potential for efficient energy use and low latency. However, we ran into implementation issues, and ended up pivoting to a cloud-based solution. We’d pass data directly from the Arduino via Firebase, a Google Cloud offering, to the app, bypassing BLE entirely. This also had the added benefit of increased security, which is critical in a health-related application. We initially struggled with connecting the Arduino Nano to the Firebase due to compatibility issues and had to switch out the Arduino Nano for an Arduino MKR WiFi 1010. We then created code to transfer real time data gathered from the Arduino into Firebase, and integrated Firebase with the Android app, allowing it to receive any updates it detects from the cloud. We prioritized basic functionality above all. After all the key components were set in place, we worked on various extensions, including UI cleanup, access to breathing guides inside the app, and cancellable timers to act as a failsafe for potential false positives.

Challenges we ran into

Bluetooth Low Energy (BLE)

Our initial method of creating the communication link to the mobile application was through the Arduino Nano 33 IoT’s BLE module. For our implementation needs, BLE seemed perfect, especially because of its low latency and longevity. During our implementation of the BLE, though, we ran into several issues from both the code side and the security side. On the code side, securing a GATT connection with a mobile phone proved to be difficult, as the MAC address for the phone would change periodically. Even when connected, there were issues with reading in UUID characteristics properly. On the security side, the Nano wasn’t that secure in a central-to-peripheral framework, as anyone could connect with the MAC address and read the values from the BLE’s characteristics. We initially considered encryption, but eventually pivoted to a cloud-based solution, which ultimately solved all our problems. In doing this, we also had to switch to the Arduino MKR WiFi 1010 board for its ability to quickly streamline communicate with the mobile app via communication with the cloud. This helped with decreasing latency and also fixed our security issue.

Firebase

One of the biggest challenges that we faced was with implementing Google Firebase was figuring out how to implement it. While we knew that the potential for a cloud-based solution could avoid several of the issues BLE plagued us with, we ran into issues, especially with the Nano itself. The Nano was not compatible with Firebase, forcing us to switch to an alternative, the Arduino MKR WiFi 1010. Using special libraries, we were able to connect Arduino with Firebase. We were able to do the same with Android Studio, creating a system where the Arduino would send time/sensor data to the cloud in a secure fashion and the app would read the data and act accordingly.

Kotlin

When faced with the choice to develop in Android Studio using Java or Kotlin, we went with Kotlin, since Kotlin seemed to integrate better with the functions were trying to use, especially with regard to our version of Android. However, none of us had experience with Kotlin, and understanding Kotlin’s syntax became an issue early on. However, we were able to make good progress over time, and ended up writing code more efficiently towards the end of development.

Accomplishments we're proud of

We are very proud of our ability to be able to be flexible when an idea doesn’t seem to be working. Throughout this project, we ran into numerous roadblocks. In every case, we were able to surmount them by taking a step back and thinking about our approach in a new day. On some occasions, we would pivot to different solutions; on other occasions, we would go all-in on a particular idea. This created an environment of rapid prototyping/testing, allowing our three teams to work in unison. We are also happy with our efficiency, especially in the context of our project, since it involved hardware, software, frontend, middleware, and backend. When it came to splitting up these problem areas, we also found that we were proud of our ability to delegate tasks to each other as a team and create an efficient workflow. We all were able to come to a consensus on a topic and figure out a way to approach our problem of interest in a manner that was feasible, desirable, and even sustainable.

What we learned

Our takeaways from this project were a mix of technical and soft skills. In terms of technical improvements, we were able to learn a lot about Android Studio and Kotlin’s role in Android development. Kotlin’s efficiency over Java was fascinating, and will surely be a language of choice when we choose to pursue mobile app development in the future. None of us had experience with cloud architecture, making the Firebase implementation particularly interesting. We were able to learn about the utilities Firebase offers, and learned how to implement it in an embedded system. For circuitry, we learned how to debug a circuit using basic equipment such as LEDs and resistors.

In terms of soft skills, our biggest learning came in the form of understanding the design process. While hackathons may be different from long-term development, one key quality shared between both is the idea of iterative design. If something works, we continue to improve and optimize. If something doesn’t work, we go back and reevaluate our approach/success conditions, and either change our approach or reframe our goals to be successful. While this may seem intuitive, having the opportunity to understand this design framework in a practical way helped all of us, and will surely be useful in our future engineering endeavors.

What's next for Band Aid Together

There are several avenues for improvement in the future. Our first step would be to improve the capabilities of our mobile app. One extension would be implementing artificial intelligence which could possibly predict events like panic/attacks and seizures in advance. This could be correlated with a user’s location, and could also be improved by integrating information from other sensors such as EKGs (heart sensors). In general, there are several things in the app which could be improved, such as a dedicated Settings tab for app permissions and more complex analytics (which would be aided by the AI). Next, we plan on implementing a higher-level encryption algorithm to better secure the medical data being transmitted by the EMG sensor. We have done research into secure hash algorithms and the use of cryptographic salts. We’d also want to isolate the circuit and integrate a power source to minimize the size of the system and reduce the bulk of the armband. Finally, we want to improve the armband to maximize elegance and comfort.

Built With

Share this project:

Updates