## Inspiration

While biking this week a member of our team fell onto the street, injuring his chin and requiring stitches. This experience highlighted how unsafe a fallen biker may be while lying in pain or unconscious on a busy street. Also, as avid hikers, our team recognizes the risk of being trapped or knocked unconscious in a fall; unable to call for help. We recognized the need for a solution that detects and calls for help when help is needed.

## What it does

HORN uses motion tracking to detect falls or crashes. If it detects an accident and then the user falls still within 60 seconds, it will provide a warning. If the user does not indicate that they are not incapacitated HORN contacts emergency services and notifies them of the time and location of the accident.

If anyone texts HORN while the user is incapacitated it provides a loud horn sound to help nearby searchers. Because HORN relies on the emergency service network it is capable of sending and receiving messages even while out of range of regular coverage.

## How we built it

The HORN prototype is controlled on a Raspberry Pi 4 which interfaces with the sensing and acting devices. It uses a BNO055 inertial measurement unit to track the acceleration of the user, a BN 880 GPS to track the location, a SIM800L GSM to send and receive SMS messages, and a modified car horn to honk.

To detect impacts, there is a thread that measures when the user experiences very high G-forces in any direction (>10 Gs, ) and also monitors if the user is completely still (indicates that they may be unconscious).

## Challenges we ran into

Communicating over SMS required us to learn about AT commands which are essentially an antiquated interface for server communication.

Finding a horn loud enough to be useful in a search and rescue situation meant we needed to branch out from traditional buzzers or speakers. After 3D printing a siren design found online, we realized a makeshift whistle would not be nearly loud enough, so we brainstormed to select a car horn - a very nontraditional component - as the main local notification device.

The accelerometer sometimes peaks at very high erroneous values. To avoid this setting off the impact detection, we limited the maximum jerk so if the acceleration value changes too much, it is considered erroneous and the previous data point is used for calculations.

## Accomplishments that we're proud of

Making the GSM work was very difficult since there was no library to use so we had to write our own serial interface. Getting this to work was a huge victory for us.

## What we learned

We learned how to parse NEMA sentences from GPS modules which contain a large amount of difficult-to-read information.

We also learned about programming systems as a team and getting separate subsystems to work together. Over the course of the hack, we realized it would make it much easier to collaborate if we wrote each of our subsystems in separate classes with simple functions to interact with each other. This meant that we had to use threading for continuous tasks like monitoring the accelerometer, which is something I did not have a lot of experience with.

## What's next for High-impact Orientation Relocation Notification system

In the future instead of only detecting high G-forces, it might be more useful to collect data from normal activity and use a machine learning model to detect unusual behaviour, like falls. This could let us apply our device to more complicated scenarios, such as a skier getting stuck in a tree well or avalanche. Also, for use in more remote areas, integration with satellite networks rather than cellular would expand HORN’s safety capabilities.
## Inspiration

Our team wanted to hack something that would promote public safety. A discussion on the length of the bus ride from UCLA to Cal introduced a discussion on how to safely drive long distances. There were two big problems to tackle: staying awake, and safely communicating.

## What it does

The MyoMessenger offers two safety features. The first harnesses Myo technology and allows you to send common text messages to any person on a predetermined emergency list (e.g. text "I'll call you back later" to Mom) using hand gestures. This allows you to communicate your whereabouts safely with friends and family without needing to deviate your eyes from the road.

The second safety feature uses the Muse headband's accelerometer to detect when a driver's head starts bobbing in exhaustion or fatigue. When the driver is detected to be falling asleep, it will send an audiovisual signal for the driver to wake up.

## How I built it

For the Muse accelerometer, we obtain the accelerometer's position points and calculate the acceleration at those points. If there is a peak in the acceleration curve, surpassing a threshold, it indicates the head is bobbing, suggesting the driver has fallen asleep.

## Challenges I ran into

We were trying to connect many components together (Myo, Twilio text messaging, Muse headband, etc) and this proved difficult to provide a smooth continuous user experience between all devices.

## What's next for MyoMessenger

We want to eventually upgrade the MyoMessenger to be able to send one of the predetermined text messages to whomever called or texted last. The limitation of the current model is the user must take initiative to select which contact to send a message to first. We would also like to incorporate a speech to text functionality as well. Lastly, we want the Muse accelerometer to ping the Myo when it receives a spike in acceleration to create a seamless user experience rather than outsourcing the signal.
## Inspiration

Every year hundreds of thousands of preventable deaths occur due to the lack of first aid knowledge in our societies. Many lives could be saved if the right people are in the right places at the right times. We aim towards connecting people by giving them the opportunity to help each other in times of medical need.

## What it does

It is a mobile application that is aimed towards connecting members of our society together in times of urgent medical need. Users can sign up as respondents which will allow them to be notified when people within a 300 meter radius are having a medical emergency. This can help users receive first aid prior to the arrival of an ambulance or healthcare professional greatly increasing their chances of survival. This application fills the gap between making the 911 call and having the ambulance arrive.

## How we built it

The app is Android native and relies heavily on the Google Cloud Platform. User registration and authentication is done through the use of Fireauth. Additionally, user data, locations, help requests and responses are all communicated through the Firebase Realtime Database. Lastly, the Firebase ML Kit was also used to provide text recognition for the app's registration page. Users could take a picture of their ID and their information can be retracted.

## Challenges we ran into

There were numerous challenges in terms of handling the flow of data through the Firebase Realtime Database and providing the correct data to authorized users.

## Accomplishments that we're proud of

We were able to build a functioning prototype! Additionally we were able to track and update user locations in a MapFragment and ended up doing/implementing things that we had never done before.