• 

  Working

• 

  Front End

• 

Inspiration

During natural disasters such as floods, conventional communication networks can become unavailable, leaving affected people unable to contact emergency services. We were inspired to build SpaceAid to address this challenge by exploring how emergency communication could remain operational even when traditional networks fail. Our goal was to create a system that helps communicate critical information, prioritize emergencies, and support disaster-response coordination when every second matters.

What it does

SpaceAid is an emergency communication and disaster-response prototype designed for situations where conventional connectivity is disrupted.

• Emergency Reporting: Captures critical information about emergencies, including location, injured people, and individuals requiring rescue.
• Emergency Severity Assessment: Assigns severity scores to help demonstrate how emergencies can be prioritized.
• Resilient Communication Routing: Demonstrates alternative message-routing paths through a simulated mesh network.
• Failure Recovery: Reroutes messages when a network node becomes unavailable, reducing dependence on a single communication path.
• Alternative Connectivity: Incorporates satellite connectivity availability into the prototype's emergency communication scenarios.
• Disaster Simulation: Demonstrates how the system responds to flood emergencies when cellular connectivity is unavailable.

How we built it

We built SpaceAid using a Python-based backend and a web-based frontend.

• Python and FastAPI: Used to develop the backend and support the application's emergency-response functionality.
• Vite: Used as the frontend development tooling.
• Web Technologies: Used to build the user-facing interface for presenting emergency information and system status.
• Network-Routing Simulation: Used to demonstrate communication between network nodes and alternative routing when a node fails.
• Emergency Scenario Simulation: Used to test the prototype against disaster scenarios involving unavailable cellular connectivity and urgent rescue requirements.

One of our demonstration scenarios involved a flood in Peenya, Bengaluru. The simulation included injured and trapped individuals, unavailable cellular connectivity, and alternative communication paths. When Node B failed, the system demonstrated rerouting through Nodes C and D.

Challenges we ran into

One of our main challenges was designing a demonstration that clearly illustrated the consequences of communication failures during disasters. We needed to show how an emergency message could continue through an alternative route rather than depending entirely on one network node.

Another challenge was bringing the emergency reporting workflow, severity assessment, connectivity status, and routing simulation together into a coherent application. We also had to balance the project's ambition with the limited development time available during a hackathon.

We addressed these challenges by building a prototype around realistic emergency scenarios and demonstrating how the system responds to network failures.

Accomplishments that we're proud of

• Developed a working prototype that demonstrates emergency reporting and communication-routing scenarios.
• Demonstrated alternative message routing after a simulated network-node failure.
• Integrated emergency severity assessment into the disaster-response workflow.
• Created a web-based interface backed by a FastAPI application.
• Successfully demonstrated a flood-emergency scenario involving disrupted cellular connectivity.
• Turned an important real-world problem into a practical technology prototype and achieved recognition in a hackathon.

Most importantly, SpaceAid helped us explore how resilient communication systems could support emergency response when conventional infrastructure is unavailable.

What we learned

Through SpaceAid, we learned about backend development with FastAPI, frontend integration, emergency workflow design, and the importance of resilient network routing.

We also learned that disaster-response technology must consider more than just software functionality. Reliability, accessibility, clear information, and the ability to operate under difficult conditions are equally important.

The project reinforced the importance of rapid prototyping, testing failure scenarios, and communicating technical ideas clearly under hackathon time constraints.

What's next for SpaceAid

Our next goal is to evolve SpaceAid from a prototype into a more robust emergency-response platform.

Potential improvements include:

• Real Mesh Networking: Explore device-to-device communication using technologies such as Bluetooth Low Energy, Wi-Fi Direct, or suitable mesh-networking hardware.
• Offline-First Reporting: Enable emergency reports to be stored locally and forwarded when a connection becomes available.
• Real Connectivity Integration: Investigate practical integrations with appropriate communication hardware and services rather than relying solely on simulated connectivity.
• Smarter Emergency Prioritization: Develop and evaluate a transparent, data-driven approach to prioritizing emergency reports.
• Live Response Dashboard: Provide responders with a clearer view of reported emergencies, affected locations, and communication status.
• Field Testing: Test reliability, message delivery, and recovery behavior under controlled conditions before considering real-world deployment.

Our long-term vision is to make SpaceAid a reliable and accessible emergency communication solution that helps people stay connected and supports faster coordination when disasters disrupt conventional networks.

Built With

• artificial-intelligence
• css
• data-visualization
• disaster-management
• emergency-response
• fastapi
• html
• javascript
• mesh-networking
• network-routing
• python
• resilient
• rest-api
• satellite-communication
• vite