EmergencyExit

An green technology application that gathers live data regarding fires and uses multi-stage data processing, A* (dijkstra's) algorithm, and LLMs to return the best route in an evacuation scenario.

Comment 1

Inspiration

We were inspired to create Emergency Exit after the recent wildfires all members of our team experienced in our home state of California. We realized that during wildfire emergencies, commonly used mapping services are unable to provide safe routes, even sometimes directing users straight through dangerous areas. We wanted to create a tool that provides people safe, reliable directions that actively avoid wildfire zones. With the increasing severity of natural disasters due to climate change, we saw an opportunity to make a difference by building a directions app that prioritizes safety first and foremost.

What it does

Emergency Exit provides real-time directions that avoid active fire zones. Users enter a start and end location, and the app calculates the safest route possible, dynamically rerouting away from danger zones. The app takes into account real-time fire data from the CAL FIRE API and user-reported incidents, making sure the generated routes are safer than traditional GPS services. Additionally, the app integrates hotel availability through the Bookings.com API, generates route summaries using the Together AI API, and provides audio directions for the visually impaired using the Eleven Labs API.

Hardware Integration

Additionally, users can create and broadcast their very own radio station using the code in /radio in the GitHub. It utilizes a simple Raspberry Pi, a cable, and a fm_transmitter library to broadcast a low power FM radio frequency (Allowed by Part 15 of the FCC's rules & limited to 200ft or less). The Raspberry Pi can download results live and only requires power for users to tune in. Users can listen to this radio, which verbally broadcasts the app's results, in their vehicle as they are evacuating from the fire; an extremely practical application that is personalized for each person. This simple hardware addition expands this project's bounds.

How we built it

We built Emergency Exit with a focus on both the frontend and backend to ensure a seamless and efficient experience for users.

Frontend

  • HTML, CSS, JavaScript - Used to create a simple and intuitive user interface.
  • Flask - Served the frontend pages, allowing easy interaction with the map and location input.
  • Leaflet.js - Integrated for interactive maps to display routes and visually indicate dangerous areas.
  • Together AI API - Provided concise and informative summaries of routes for easier understanding during emergencies.
  • Eleven Labs API - Delivered audio directions for visually impaired users to enhance accessibility.
  • Svelte - Used to create reactive user interface components that provide a smooth user experience.
  • Tailwind CSS - Styled the application with utility-first classes to ensure a clean and responsive design.

Backend

  • Python - The primary language used to build the backend logic.
  • OpenStreetMap (OSM) - Used for obtaining detailed road information for route calculations.
  • OSMnx - Leveraged to preprocess and convert OpenStreetMap data into a usable format.
  • NetworkX - Created a graph representation of the road network, allowing us to manipulate edges to avoid fire-prone areas.
  • A* Algorithm - Implemented to find the safest path between locations, avoiding active fires.
  • Flask - Handled user requests and communicated between the frontend and backend.
  • CAL FIRE API - Integrated real-time fire data to avoid active fire zones in route calculations.
  • Matplotlib - Used to visualize routes during development to ensure the routing algorithm was functioning correctly.
  • Bookings.com API - Helped users find available hotels near their destination, providing safe places to stay during evacuations.
  • LLMs - Used for data processing as well as GPT prompt engineering for the voice feature.
  • AI Voice Assistant - Allows visually impaired users and those who may not have access to real-time information to receive the same news, thereby promoting equity.

Challenges we ran into

Creating a routing system that could reliably avoid fire zones was one of our biggest challenges. Initially, we tried using existing services like the Open Route Service API and Google Maps API, but neither allowed the level of customization we needed. After weeks of testing workarounds, we decided to build our own routing system using OpenStreetMap and NetworkX. This gave us the flexibility we needed but came with its own challenges, such as integrating and preprocessing OpenStreetMap data, handling inconsistencies, and dynamically updating the graph based on incoming fire data without impacting performance. These were all hurdles we had to overcome to make sure our app was accurate and efficient.

Another challenge was integrating multiple APIs to enhance functionality. We faced difficulties in synchronizing data from the CAL FIRE API, Bookings.com API, and Together AI API, as well as managing rate limits and ensuring that all APIs worked seamlessly together to provide real-time information without delays.

Accomplishments that we're proud of

We're really proud of building a custom routing algorithm that successfully avoids active fire zones, providing a solution where existing mapping services fell short. We were able to incorporate real-time fire data and create an easy-to-use interface, making it accessible for users during emergencies. The integration of hotel booking, audio directions, and route summaries added significant value, making the app more comprehensive and useful. Most importantly, we created a tool that has the potential to save lives during natural disasters, which is an accomplishment we're all incredibly proud of.

What we learned

Throughout this project, we learned a lot about routing algorithms and how to use graph theory to solve real-world problems. We learned how to implement the A* algorithm while dynamically adjusting edge weights to reflect real-time data. We also learned the importance of efficient geospatial data processing, especially when working with large datasets like those from OpenStreetMap. Additionally, we learned how to integrate multiple third-party APIs to enhance user experience and ensure the app was both functional and accessible. Finally, we learned about the value of user experience in safety-critical applications, ensuring that our tool is not only effective but also easy to use during stressful situations.

What's next for Emergency Exit

In the next version, we want to expand the map area beyond Southern California. To do this, we'd need more computational power and possibly cloud-based distributed computing to handle larger datasets. We also want to integrate crowdsourcing, allowing users to report new fire incidents or road closures, which would help improve the app's real-time accuracy. Beyond wildfires, we'd like to add data for other natural disasters like floods or earthquakes to make the app more versatile. Lastly, we plan to enhance the user interface to include interactive map features and implement machine learning to predict fire spread patterns, making the app even more powerful and user-friendly. We also envision improving the hotel booking feature to provide more options and adding more languages to the audio directions to ensure accessibility for a broader audience.

Professionalism and Presentation Style

We take pride in making each hackathon submission unique, with the best effort being put forward. We decided to go on a video shoot at a relevant location for our application, aiming to create the most compelling video possible. Our video not only has a description on how the application works, it also features news clips and other mediums that show the significance of the issue we are addressing.

We have also included a 1 minute long blooper reel (link -- we want the judges and the participants of the hackathon to be immersed in the personal experience and story of our submission. Please check out our bloopers! It can be found in the "Try It Out" links section, along with our GitHub Repository.

Disclaimer

We are very sorry to be unable to host the service live due to API costs being high and none of us being able to keep our main computers strained 24/7 while having the OSM data loaded into memory.

Built With

Share this project:

Updates