We were disturbed to see the increasing number of assaults on UW Campus. Starting from 1 reported incident in January 2016, there have been 3 reported incidents in a span of 20 days each month. 911 operators ask too many questions or are busy, and the chain of communication from the operator to the nearest cops standing-by is often time-consuming. The UWPD does not get to know about the crime until it has occurred. We observed that most of these crimes occurred at night when the victim was alone, but could have easily called for help. The mere arrival of a bystander could have scared the suspect away or could have provided an opportunity to inform UWPD immediately. Based on this insight, we created Beacon.

Beacon is very different from its counterparts like Life360, OnCampusOnWatch or Good2Go. These apps have complex interfaces that require some thought process on part of the victim at times of emergency. Some of these apps have been removed due to low usage or an unjustifiable price tag. Further, these apps require the user to enter a list of trusted contacts to be informed during emergencies. This is a limitation to those who are new to a place and do not yet have trusted contacts. It could also be that trusted contacts are un-reachable at the time of an emergency.

Beacon aims to reduce the number of assaults that could have been easily prevented

What it does

Beacon is an idea that relies on an established network of bystanders willing to help during emergencies. A bystander expresses his intent to offer help anytime by simply logging in to our app and letting it run in background. The app sends heartbeat messages periodically to a central server informing it of the bystander's location.

If a person needs help, she opens the Beacon app on her phone and taps on the screen to request for immediate help. This request from the victim contains the victim's location and is sent to the central server which selects as many logged-in bystanders as possible within 500 meters of the victim. All selected bystanders are informed and each such bystander receives a map indicating his location with respect to the victim. The bystander may choose to help.

During an emergency, a selected bystander is not informed about other selected bystanders. This is to avoid the well known Bystander effect. If a bystander is aware of other bystanders, then he is less likely to proceed for help assuming that others would help. But we want as much help as possible to reach the victim.

Beacon connects people together at times of emergency

How I built it

  • Built a central server for Beacon using node.js
  • Built a storage server leveraging redis that stores the locations of all bystanders.
  • Built the mobile side of Beacon using HTML, Javascript, CSS, Phone gap and google-maps API.

Challenges I ran into

We ran into 3 challenges.

First was the challenge of false alarms. A person may mistakenly tap Beacon requesting immediate assistance. To over come this, we added a delay of 10 seconds between when a victim taps our app and when the app sends the first request of help to the server. If the victim taps again before these 10 seconds expire, then no request for help is raised.

Second, we had to handle the situation when a bystander has more than one victim in his vicinity who needs help. We solve this problem by maintaining a list of bystanders who are already en route to help a victim. These are active bystanders. We ensure that every active bystander is assigned to exactly victim in his proximity. If there is more than victim who falls in the vicinity an active bystander, then we continue our search for other inactive bystanders in the victim's vicinity. If no inactive bystanders are found within 500 meters, we increase the range up to 1500 meters.

Third, we had to figure out how to inform the bystanders that there is a victim in their vicinity who needs help. We solved this by piggy-backing on the response to a heartbeat message sent by the bystander. We use it to inform the bystander that there is someone in his vicinity who needs help.

Accomplishments that I'm proud of

We are proud that we accomplished the idea we had in mind when we started.

  • Leveraged and connected node.js, redis and google maps API to build a useful application.
  • Solved several corner cases and race conditions involving heartbeats and requests for help that in node.js.

We are proud that the end result looks good and is useful

What I learned

  • Learnt to use several languages and interfaces in tandem
  • Design an intuitive UI and a light weight mechanism to accomplish some complex ideas.

What's next for Beacon

Future features.

  • Currently, a malicious user himself could get hang of the victim's phone and diffuse the request for help that the victim raised. To prevent this, we wish to have the victim's phone lock itself automatically after the 10 second window has expired and the first request for assistance has been raised. The phone must then be unlocked by code known only to the victim.

  • We wish to have the phone start audio and video recording after the first request for assistance has been sent.

  • We wish to add authentication to Beacon so that only those who are registered and successfully logged in can raise requests for assistance and/or provide assistance during emergencies.

We wish it to integrate Beacon in the UW-app to bring the campus one step closer to safety against rising assaults

Share this project: