## Inspiration

As a team, we're all close with our grandparents. As they get older, we want to be able to support them in any way that we can, even when we can't be there. Our ideation focus started out on elderly care homes--we wanted to devise a system to help keep an eye out for elderly patients, especially those who could be prone to falling or wandering off due to a condition like Alzheimer's.

But we realized that interactive and accessible security isn't just limited to elderly care homes. From consumer usage with parents, to enterprise-level usage at companies that need real-time security monitoring, interactive security is largely lacking.

## What it does

Our pipeline takes in live stream of videos, and leveraging zero-shot action recognition, we're able to provide real time feedback on chunks of videos that are of interest. Users are able to input with natural language, what they would consider "flaggable" behavior. We match chunks with flaggable behavior, and then, if an incident is flagged, real-time deployment of Twilio API calls the user who deployed the software. The user is then notified of the incident, and able to talk to Twilio about
 1. Context of the incident
 2. Possible next steps to take
 3. Extractive video

## How we built it

1. Computer Vision.

Azure integration, to provide holistic view on people actions during frame, with natural language. Multi-threading allows us to achieve this in real-time without much latency. Chunking video into actions from the stream to be saved into our cache. Cache detection runs through GPT, and submits a POST request to our flask server when an action is deemed to be flaggable.

Twilio retrieves.

1. Twilio

Separate tunneled local server on ngrok so Twilio can access. Then, server receives live requests that uses TwixML to give appropriate responses to users. Utilizing whisper, users are able to have real-time conversation with Twilio, which has access to custom defined toolkits.

## Challenges we ran into

A lot of networking challenges. Some API keys disappeared here and there (we reached our limit), and spent like 2 hours debugging for no reason.

## Accomplishments that we're proud of

As beginners at our first hackathon, we really got to get hands on with building a project, and become a super cohesive team!

This was a lot of our first times fully building out a deployable application, and it was really great just learning how to take our skills in class to apply to the real world. It's super inspiring to know that what we make can change the world.

## What we learned

So so much. From multi-threading to lightsaber-duels, the knowledge was everywhere.

## What's next for Horus

Huge emphasis on stopping implicit bias, especially in CV algorithms.
We planning to focus on the ethical implications of software like Horus, stressing that implicit biases don't make their way into the input, detection, or communication pipelines.
## Inspiration

According to the US Census Bereau, the elderly population—persons 65 years or older—numbered 52 million in 2018, and approximately 5.6 million are living with Alzheimer's disease in 2019. However, since they are less tech-savvy and might face problems updating their family of their situation, they often cannot receive timely assistance.

Therefore, we hope to build an app that improves this situation and establishes a better communication system between the elderly and their families in case of emergency.

## What it does

This App aims to provide more timely help to the elderly, especially those with dementia. When an elder person encounters emergency situations, namely 1) falling and 2) getting lost, their family members will be alerted through text messages using the Twilio API.

1. Falling
​ When the person falls, the app detects it through the phone's gravity sensor and shows an emergency page. If he/she does not stand up or long-press the button within 1 minute, a message will be sent to the emergency contact and 911 will be dialed. Otherwise, the action will be cancelled.
2. Getting lost
​When setting up the account, an address (location coordinates) and a "safety range" will be entered into the app. If the person goes out of the safety range (e.g. 10 blocks from home address), the emergency contact will be alerted via text message.

Whenever an emergency occurs, the elderly user's app shows his personal information including 1) name, 2) Age, 3) Contact and 4) Condition, so that the emergency medical services (EMS) personnel can learn about the situation even if the elder user is unable to explain it clearly.

Besides, the real-time location of the user is readily available on the interface, in case the user has any difficulty locating him/herself.

## How we built it

We used Swift to design the iOS application. Moreover, we had a Python-Flask backend that used Twilio to establish communications such as text messages and phone calls. The justification for using a Python-Flask backend is that this backend can store information in a database more efficiently. The Swift application is connected to a GPS locator and an accelerometer to detect changes in location and falls, respectively. When a fall is detected by Swift, Swift sends a request to the Python-Flask backend, which then calls the emergency contact through Twilio. When a GPS location change beyond the boundary is detected, Swift sends a request to the Python-Swift backend which then texts the location of the elderly person to the emergency contact through Twilio.

## Challenges I ran into

The Python-Flask backend and the Swift frontend were difficult to connect together, as the ports oftentimes did not work. Ultimately, we resolved this issue. A few buttons on the Swift frontend application also was difficult to optimize. Moreover, texts involving a non-shortened Google Maps URL sometimes did not send successfully through Twilio for unknown reasons. We tried our best to fix it, but it appears to still send inconsistently.

## Accomplishments that I'm proud of

Getting the Twilio interface to connect seamlessly to the iOS application was a great achievement, as now a falling accelerometer and a significant location change automatically activate Twilio's communications system. Moreover, we are very happy with the layout of our iOS application and the smoothness of the buttons and options within it.

## What I learned

We learned a lot about application development and also Twilio and the Python-Flask backend, as well as ways to connect frontend systems with backend systems.

## What's next for Helderly

We will attempt to create a database for the names entered into the application. Moreover, we can potentially experiment with paid versions of Twilio and increased amounts of phones.
## Inspiration

In a world where finance is extremely important, everyone needs access to **banking services**. Citizens within **third world countries** are no exception, but they lack the banking technology infrastructure that many of us in first world countries take for granted. Mobile Applications and Web Portals don't work 100% for these people, so we decided to make software that requires nothing more than a **cellular connection to send SMS messages** in order to operate. This resulted in our hack, **UBank**.

## What it does

**UBank** allows users to operate their bank accounts entirely through **text messaging**. Users can deposit money, transfer funds between accounts, transfer accounts to other users, and even purchases shares of stock via SMS. In addition to this text messaging capability, UBank also provides a web portal so that when our users gain access to a steady internet connection or PC, they can view their financial information on a more comprehensive level.

## How I built it

We set up a backend HTTP server in **Node.js** to receive and fulfill requests. **Twilio** with ngrok was used to send and receive the text messages through a webhook on the backend Node.js server and applicant data was stored in firebase. The frontend was primarily built with **HTML, CSS, and Javascript** and HTTP requests were sent to the Node.js backend to receive applicant information and display it on the browser. We utilized Mozilla's speech to text library to incorporate speech commands and chart.js to display client data with intuitive graphs.

## Challenges I ran into

* Some team members were new to Node.js, and therefore working with some of the server coding was a little complicated. However, we were able to leverage the experience of other group members which allowed all of us to learn and figure out everything in the end.
* Using Twilio was a challenge because no team members had previous experience with the technology. We had difficulties making it communicate with our backend Node.js server, but after a few hours of hard work we eventually figured it out.

## Accomplishments that I'm proud of

We are proud of making a **functioning**, **dynamic**, finished product. It feels great to design software that is adaptable and begging for the next steps of development. We're also super proud that we made an attempt at tackling a problem that is having severe negative effects on people all around the world, and we hope that someday our product can make it to those people.

## What I learned

This was our first using **Twillio** so we learned a lot about utilizing that software. Front-end team members also got to learn and practice their **HTML/CSS/JS** skills which were a great experience.

## What's next for UBank

* The next step for UBank probably would be implementing an authentication/anti-fraud system. Being a banking service, it's imperative that our customers' transactions are secure at all times, and we would be unable to launch without such a feature.
* We hope to continue the development of UBank and gain some beta users so that we can test our product and incorporate customer feedback in order to improve our software before making an attempt at launching the service.