-
-
Crash testing data
-
The fully setup
-
State diagram
Inspiration
While biking this week a member of our team fell onto the street, injuring his chin and requiring stitches. This experience highlighted how unsafe a fallen biker may be while lying in pain or unconscious on a busy street. Also, as avid hikers, our team recognizes the risk of being trapped or knocked unconscious in a fall; unable to call for help. We recognized the need for a solution that detects and calls for help when help is needed.
What it does
HORN uses motion tracking to detect falls or crashes. If it detects an accident and then the user falls still within 60 seconds, it will provide a warning. If the user does not indicate that they are not incapacitated HORN contacts emergency services and notifies them of the time and location of the accident.
If anyone texts HORN while the user is incapacitated it provides a loud horn sound to help nearby searchers. Because HORN relies on the emergency service network it is capable of sending and receiving messages even while out of range of regular coverage.
How we built it
The HORN prototype is controlled on a Raspberry Pi 4 which interfaces with the sensing and acting devices. It uses a BNO055 inertial measurement unit to track the acceleration of the user, a BN 880 GPS to track the location, a SIM800L GSM to send and receive SMS messages, and a modified car horn to honk.
To detect impacts, there is a thread that measures when the user experiences very high G-forces in any direction (>10 Gs, ) and also monitors if the user is completely still (indicates that they may be unconscious).
Challenges we ran into
Communicating over SMS required us to learn about AT commands which are essentially an antiquated interface for server communication.
Finding a horn loud enough to be useful in a search and rescue situation meant we needed to branch out from traditional buzzers or speakers. After 3D printing a siren design found online, we realized a makeshift whistle would not be nearly loud enough, so we brainstormed to select a car horn - a very nontraditional component - as the main local notification device.
The accelerometer sometimes peaks at very high erroneous values. To avoid this setting off the impact detection, we limited the maximum jerk so if the acceleration value changes too much, it is considered erroneous and the previous data point is used for calculations.
Accomplishments that we're proud of
Making the GSM work was very difficult since there was no library to use so we had to write our own serial interface. Getting this to work was a huge victory for us.
What we learned
We learned how to parse NEMA sentences from GPS modules which contain a large amount of difficult-to-read information.
We also learned about programming systems as a team and getting separate subsystems to work together. Over the course of the hack, we realized it would make it much easier to collaborate if we wrote each of our subsystems in separate classes with simple functions to interact with each other. This meant that we had to use threading for continuous tasks like monitoring the accelerometer, which is something I did not have a lot of experience with.
What's next for High-impact Orientation Relocation Notification system
In the future instead of only detecting high G-forces, it might be more useful to collect data from normal activity and use a machine learning model to detect unusual behaviour, like falls. This could let us apply our device to more complicated scenarios, such as a skier getting stuck in a tree well or avalanche. Also, for use in more remote areas, integration with satellite networks rather than cellular would expand HORN’s safety capabilities.
Log in or sign up for Devpost to join the conversation.