## Inspiration

During global disasters, it is imperative to have an efficient and reliable system in place for providing emergency support to first responders. We wanted to address this challenge by ensuring the availability of satellites to collect and transmit data in and out of regions in crisis.

## What it does

During a disaster, Disaster Relief Infrastructure For Tracking and Safety (Drifts) looks at 10,000+ satellites currently orbiting above the disaster region. It then builds the optimal constellation from these by considering the current needs, as well as the motion/position of the satellites. Specifically, we look at the capabilities of each potential satellite and ensure that the constructed constellation has, at a minimum, capabilities for weather monitoring, GPS/navigation, high-resolution imaging, and ground communication. We then select a configuration of these satellites that will be overhead the longest based on their current position/velocity in order to maximize the reliability of the constellation. Additionally, as satellites pass out of range of the disaster region, the constellation will be automatically reconfigured with new satellites.

## How we built it

Drifts.space’s frontend was built using Next.js, Tailwind CSS, and Globe.GL to visualize the constellations on an interactive globe. The backend and constellation construction algorithm were built in Node.js, where we query the N2YO Satellite API. Finally, we hosted our webapp using Vercel.

## Challenges we ran into

Over the duration of the hackathon we ended up pivoting our idea several times as we struggled to find data sources that were reliable, easy to use, and expansive enough to build an impactful project with the data. Once we settled on satellite constellations, we faced some challenges in designing an efficient algorithm to build the optimal constellations without exceeding the quite restrictive API rate limit on N2YO. One improvement we made for this was caching static satellite information instead of sending API requests each time. We also faced a lot of challenges with the globe visualizations. We had to extend Globe.GL with custom functionality in order to allow users to input the disaster region(s) and add our constructed constellations. Finally, we had a lot of challenges with sending API requests to N2YO. We had to setup a secondary Heroku proxy server in order to get the requests to go through.

## Accomplishments that we're proud of

We were exceptionally proud of the UI we built to visualize the disasters and satellite constellations. This functionality was not built-in to Globe.GL, and took a lot of hard work to get working smoothly. We were also proud of the real-time updates of satellite positions/constellations.

## What we learned

While building the frontend, we learned a lot about 3D design and visualizations in Javascript. We also learned a lot about satellite systems and the various challenges of satellite communication when designing our constellation construction algorithm.

## What's next for Drifts.space

Some future directions for Drifts.space could be automatically determining and predicting future disasters based on real-time data such as satellite weather data or seismic activity and preconfiguring constellations in advance of disasters occurring. We would like to clean up some of the front-end functionality in order to provide a smoother experience.
## Inspiration

When our team first came together in the days preceding HackHarvard, we agreed that if nothing else, our project would focus on helping society. Hannah told us about the nerve-wracking experience of watching from afar as her loved ones in Tampa prepared for and dealt with hurricanes Helene and Milton. It takes a significant amount of time, effort, and money to plan for the storm’s devastation. We were inspired to consolidate verified and reliable information about the steps needed before, during, and after an impending hurricane to minimize damage and cost, and be able to find resources, shelters and evacuation routes anytime.

## What it does

Once we decided on the issue to tackle, we spent a couple of hours planning the implementation to best serve our audience—people planning for and affected by hurricanes. We decided to design and build an app available on both Android and iOS devices to enhance accessibility.

The app features:

* A **homepage** with general hurricane preparation guides.
* A **map interface** using user latitude and longitude, displaying:
	+ Flood, tropical storm, and hurricane affected areas nearby.
	+ Toggles for nearby clinics, shelters, FEMA disaster relief centers, and supply drops.

## How we built it

We divided our team into roles:

* **Backend Development:** Led by Anmol and Hannah.
* **Frontend Development:** Led by Deep
* **Fullstack Support:** Naunidha

The frontend team developed in **ReactNative** for cross-platform compatibility (iOS and Android).
The backend team implemented services with **Python**, **Flask**, and **cloud hosting** using **Defang** and a backup **Linode** server for optimal performance. We containerized the backend using **Docker** to ensure a stable, continuous and high-quality experience that would scale without issue.

## Challenges we ran into

Some challenges we encountered include:

* **API access and costs:**
	+ We initially wanted to include power outage data on a county level. However, the only service compiling this data, **poweroutages.us**, charges over $500 per month for API access, making it infeasible for us to include.
* **API integration:** Each API provided data in unique ways, requiring us to develop different methods to fetch and integrate endpoints.
* **ReactNative difficulties:** Working with ReactNative introduced challenges related to syntax and the nuances of deploying mobile apps.
* **Backend hosting:** With limited networking capabilities, we didn't want this to be a client-side app. So, we utilized **Defang** to host our backend with Docker containers.

## Accomplishments that we're proud of

We are incredibly proud of the project we built. Though our primary focus for now, was to provide immediate assistance in hurricanes, the name **"Crisis Companion"** stands for our goals to extend the product’s capabilities to support responses for other natural disasters. We aim to unify disparate datasets to serve under-duress people and communities more effectively.

## What we learned

Our team learned:

* The importance of early planning to align all project elements.
* How to navigate the complexities of **ReactNative** development.
* Strategies for **API management** and balancing accessibility with cost limitations.
* The value of **cloud-based solutions** to overcome device hosting restrictions.

## What's next for Crisis Companion

Moving forward, we aim to:

* Expand the app to assist with more types of natural disasters beyond hurricanes and floods.
* Integrate more **real-time data feeds** from live news sources.
* Explore partnerships with services like **poweroutages.us** or similar organizations to enhance the information available to users.
* Provide offline solutions (Bluetooth net like AirTags, Local caches, etc.).
## Inspiration

Our inspiration came from a common story that we have been seeing on the news lately - the wildfires that are impacting people on a nationwide scale. These natural disasters strike at uncertain times, and we don't know if we are necessarily going to be in the danger zone or not. So, we decided to ease the tensions that occur during these high-stress situations by acting as the middle persons.

## What it does

At RescueNet, we have two types of people with using our service - either subscribers or homeowners. The subscriber pays RescueNet monthly or annually at a rate which is cheaper than insurance! Our infrastructure mainly targets people who live in natural disaster-prone areas. In the event such a disaster happens, the homeowners will provide temporary housing and will receive a stipend after the temporary guests move away. We also provide driving services for people to escape their emergency situations.

## How we built it

We divided our work into the clientside and the backend. Diving into the clientside, we bootstrapped our project using Vite.js for faster loadtimes. Apart from that, React.js was used along with React Router to link the pages and organize the file structure accordingly. Tailwind CSS was employed to simplify styling along with Material Tailwind, where its pre-built UI components were used in the about page.

Our backend server is made using Node.js and Express.js, and it connects to a MongoDB Atlas database making use of a JavaScript ORM - Mongoose. We make use of city data from WikiData, geographic locations from GeoDB API, text messaging functionality of Twilio, and crypto payment handling of Circle.

## Challenges we ran into

Some challenges we ran into initially is to make the entire web app responsive across devices while still keeping our styles to be rendered. At the end, we figured out a great way of displaying it in a mobile setting while including a proper navbar as well. In addition, we ran into trouble working with the Circle API for the first time. Since we've never worked with cryptocurrency before, we didn't understand some of the implications of the code we wrote, and that made it difficult to continue with Circle.

## Accomplishments that we're proud of

An accomplishment we are proud of is rendering the user dashboard along with the form component, which allowed the user to either enlist as a subscriber or homeowner. The info received from this component would later be parsed into the dashboard would be available for show.

We are also proud of how we integrated Twilio's SMS messaging services into the backend algorithm for matching subscribers with homeowners. This algorithm used information queried from our database, accessed from WikiData, and returned from various API calls to make an "optimal" matching based on distance and convenience, and it was nice to see this concept work in real life by texting those who were matched.

## What we learned

We learned many things such as how to use React Router in linking to pages in an easy way. Also, leaving breadcrumbs in our Main.jsx allowed us to manually navigate to such pages when we didn't necessarily had anything set up in our web app. We also learned how to use many backend tools like Twilio and Circle.

## What's next for RescueNet

What's next for RescueNet includes many things. We are planning on completing the payment model using Circle API, including implementing automatic monthly charges and the ability to unsubscribe. Additionally, we plan on marketing to a few customers nationwide, this will allow us to conceptualize and iterate on our ideas till they are well polished. It will also help in scaling things to include countries such as the U.S.A and Mexico.