## Inspiration

The need for faster and more reliable emergency communication in remote areas inspired the creation of FRED (Fire & Rescue Emergency Dispatch). Whether due to natural disasters, accidents in isolated locations, or a lack of cellular network coverage, emergencies in remote areas often result in delayed response times and first-responders rarely getting the full picture of the emergency at hand. We wanted to bridge this gap by leveraging cutting-edge satellite communication technology to create a reliable, individualized, and automated emergency dispatch system. Our goal was to create a tool that could enhance the quality of information transmitted between users and emergency responders, ensuring swift, better informed rescue operations on a case-by-case basis.

## What it does

FRED is an innovative emergency response system designed for remote areas with limited or no cellular coverage. Using satellite capabilities, an agentic system, and a basic chain of thought FRED allows users to call for help from virtually any location. What sets FRED apart is its ability to transmit critical data to emergency responders, including GPS coordinates, detailed captions of the images taken at the site of the emergency, and voice recordings of the situation. Once this information is collected, the system processes it to help responders assess the situation quickly. FRED streamlines emergency communication in situations where every second matters, offering precise, real-time data that can save lives.

## How we built it

FRED is composed of three main components: a mobile application, a transmitter, and a backend data processing system.

```
1.  Mobile Application: The mobile app is designed to be lightweight and user-friendly. It collects critical data from the user, including their GPS location, images of the scene, and voice recordings.
2.  Transmitter: The app sends this data to the transmitter, which consists of a Raspberry Pi integrated with Skylo’s Satellite/Cellular combo board. The Raspberry Pi performs some local data processing, such as image transcription, to optimize the data size before sending it to the backend. This minimizes the amount of data transmitted via satellite, allowing for faster communication.
3.  Backend: The backend receives the data, performs further processing using a multi-agent system, and routes it to the appropriate emergency responders. The backend system is designed to handle multiple inputs and prioritize critical situations, ensuring responders get the information they need without delay.
   4. Frontend: We built a simple front-end to display the dispatch notifications as well as the source of the SOS message on a live-map feed.

```

## Challenges we ran into

One major challenge was managing image data transmission via satellite. Initially, we underestimated the limitations on data size, which led to our satellite server rejecting the images. Since transmitting images was essential to our product, we needed a quick and efficient solution. To overcome this, we implemented a lightweight machine learning model on the Raspberry Pi that transcribes the images into text descriptions. This drastically reduced the data size while still conveying critical visual information to emergency responders. This solution enabled us to meet satellite data constraints and ensure the smooth transmission of essential data.

## Accomplishments that we’re proud of

We are proud of how our team successfully integrated several complex components—mobile application, hardware, and AI powered backend—into a functional product. Seeing the workflow from data collection to emergency dispatch in action was a gratifying moment for all of us. Each part of the project could stand alone, showcasing the rapid pace and scalability of our development process. Most importantly, we are proud to have built a tool that has the potential to save lives in real-world emergency scenarios, fulfilling our goal of using technology to make a positive impact.

## What we learned

Throughout the development of FRED, we gained valuable experience working with the Raspberry Pi and integrating hardware with the power of Large Language Models to build advanced IOT system. We also learned about the importance of optimizing data transmission in systems with hardware and bandwidth constraints, especially in critical applications like emergency services. Moreover, this project highlighted the power of building modular systems that function independently, akin to a microservice architecture. This approach allowed us to test each component separately and ensure that the system as a whole worked seamlessly.

## What’s next for FRED

Looking ahead, we plan to refine the image transmission process and improve the accuracy and efficiency of our data processing. Our immediate goal is to ensure that image data is captioned with more technical details and that transmission is seamless and reliable, overcoming the constraints we faced during development. In the long term, we aim to connect FRED directly to local emergency departments, allowing us to test the system in real-world scenarios. By establishing communication channels between FRED and official emergency dispatch systems, we can ensure that our product delivers its intended value—saving lives in critical situations.
## Inspiration

In response to recent tragic events in Turkey, where the rescue efforts for the Earthquake have been very difficult. We decided to use Qualcomm’s hardware development kit to create an application for survivors of natural disasters like earthquakes to send out distress signals to local authorities.

## What it does

Our app aids disaster survivors by sending a distress signal with location & photo, chatbot updates on rescue efforts & triggering actuators on an Arduino, which helps rescuers find survivors.

## How we built it

We built it using Qualcomm’s hardware development kit and Arduino Due as well as many APIs to help assist our project goals.

## Challenges we ran into

We faced many challenges as we programmed the android application. Kotlin is a new language to us, so we had to spend a lot of time reading documentation and understanding the implementations. Debugging was also challenging as we faced errors that we were not familiar with. Ultimately, we used online forums like Stack Overflow to guide us through the project.

## Accomplishments that we're proud of

The ability to develop a Kotlin App without any previous experience in Kotlin. Using APIs such as OPENAI-GPT3 to provide a useful and working chatbox.

## What we learned

How to work as a team and work in separate subteams to integrate software and hardware together. Incorporating iterative workflow.

## What's next for ShakeSafe

Continuing to add more sensors, developing better search and rescue algorithms (i.e. travelling salesman problem, maybe using Dijkstra's Algorithm)
## Inspiration

Approximately **half** of the United States’ annual violent crimes are reported each year. Much of this discrepancy can be attributed to a widespread fear of calling 911. To provide a safeguarding mechanism for situations precluding conventional means of communication, our project undertakes the development of a sophisticated real-time monitoring and alerting system.

Identifying the difficulty of talking aloud in many situations showed us the immense potential that an audiocentric emergency reporting app has to reduce this statistic. This system is predicated upon intricate audio data analysis for the explicit purpose of crime detection and the facilitation of swift emergency response.

## What it does

At the heart of this convenient app lies a high-level architectural framework for audiocentric crime detection. The crux of our technical infrastructure is the application of advanced deep learning paradigms, notably the integration of stacking classifiers, which consists of multiple classifiers such as RandomForestClassifier, SGDClassifier, Support Vector Classifier, etc.

Augmenting this neural architecture is the strategic deployment of integration of classification models as well as data transformation and dimension reduction, thereby optimizing the intricate classification of audio clips based on the nature of the crime they encapsulate.

## How we built it

The backend of the pipeline was written in Python, using Flask and Django as the backbone. The backend is supported by a pipeline of stacking classification models that determines the type of crimes the users ran into by collecting the surrounding ambient sounds that could signal a dangerous environment.

For the frontend, we utilized Android Studio to create the interactive user interface of the project, which will enhance the user experience when using the application. The minimalist design for the frontend ensures that the users can spend the least amount of time interacting with our product as it is designed for emergency use, thus requiring minimum initiation steps. The integration of the interactive frontend with a convolutional, yet efficient backend are the characteristics of our product.

## Challenges we ran into

*ML Model*:
We struggled to find the right parameters for the classification model that resulted in a notable amount of time spent on adjusting minor values to maximize accuracy.

*Android Studio*:
It was difficult to create a minimal user interface that would recognize a finger holding the record button in loops of 5 seconds. There was some unexpected difficulty in using the “Audio Recorder” constructor of Android Studio that provides live feedback as the audio is being fed in.

## Accomplishments that we're proud of

The foundation of our app depends on the pipeline developed to classify types of violent crimes. Though the accuracy of the model could be improved on in the future, it was a fundamental step towards knowing that we could bring safety many steps closer to individuals in such dangerous situations.

## What we learned

Among others, we learned that it’s important to achieve the overall goal first - regardless of how well it was reached. We struggled to maximize our accuracy with the pipeline - having switched from CNN to our original method largely due to a lack of computation power - but had to realize that it is better to walk away with something over nothing.

## What's next for SilentSignal

Shorter timeframe & location
In the future, it would be greatly beneficial to be able to shorten the required timeframe of 5 seconds so that we can identify and report situations where even that is too long. Additionally, it is crucial to know where the user is located as we will be contacting local officials, so this is also an area of interest.