How it started
We were brainstorming ideas, passionate about a project that had a social impact. The IBM and Microsoft sponsor challenges were especially interesting, and we began discussing problem areas during natural disasters. Communication is the most value asset during disaster. Not only do communication lines go down, and cell coverage get's congested, but phones break and lose battery. Knowing where people are, and a way of connecting with anyone that can help provides piece of mind for civilians, and priceless information for first responders.
What we made:
During natural disasters, friends and loved ones go missing. The phone networks go down and the first responders have no idea where to start looking or even if they need to. Did he/she leave and is safely in a hotel hundreds of miles away, or are they stranded in a flooded home in need of immediate help? It is critical for first responders to know if they should be looking for an individual and where to begin.
That is why we have developed Response, an app that will automatically and preemptively begin sending an encrypted packet of info containing the user's position, phone battery level, and other relevant info to a server. This server will provide tools for first responders to quickly generate a list of last known locations around a geographic point to begin their search with some knowledge of each individual’s context. One of our main concerns was the cellular network becoming congested or even going down, so we have also developed a hardware add on that enables peer to peer communication. This will allow these data packets to be cached locally on nearby devices and propagated outwards until the information reaches a node that is connected to the internet.
How we made it:
The project has two distinctive components, hardware and software.
The hardware was initially constructed using breadboards, Arduinos, and other simple hardware components. The RadioHead open-source library was utilized to facilitate radio communications. The hardware was then rebuilt on a soldered breadboard to create a neater demonstration package.
The software was the larger of the two components, utilizing SQL databases, Azure tools, and the Android Dev SDK. We connected user accounts, along with status updates, to the SQL database through the Azure webserver. No team members have used Azure before, which presented challenges integrated the SQL database and the server backend. Comically enough, one of the larger challenges was phones only having one port. It made impossible to simultaneously connect to a laptop for Android Development debugging, and attach to our hardware.
What we learned:
Inherently, the team became much more familiar with Azure and wireless communication. With Azure, we are now comfortable hosting web servers for database management and backend support. We also learned more about the challenging issues faced during disasters, and the current projects being done for relief efforts.
The next step is to develop a data visualization functionality on the server, so first responders can view the data on a map in an intuitive way and quickly judge a situation to create a plan. Additionally, using speech-to-text for the status updates would speed up the process in stressful situations, and allow users to continue evacuating as normal.
On the hardware side, we would like to integrate the hardware module with a battery pack to extend the phones battery life and support higher power transceivers for peer 2 peer communication. We would also like to add sensors to the hardware module to give more situational context. This includes things like air quality and integrating with a smartwatch for heart rate monitor.
Overall, we wish we had narrowed our scope more for this hackathon, but are looking to further develop this for future competitions.
Log in or sign up for Devpost to join the conversation.