During the day, universities around the world feature the brightest minds, most challenging ideas, and greatest opportunities to grow as both a person and an intellectual. At night, however, such campuses can feel nearly foreign or frightening as the streets lack the normal bustle of students and the light grows dim. Universities attempt to alleviate students' anxiety and worries of safety by offering a variety of services; at Cal, we have our system of Night Safety Shuttles and BearWalk staff that accompany students. Yet, these services tend to have extraordinary wait times, sometimes exceeding two hours. Enter GetHome.

What it does

GetHome connects verified students with one another such that no user has to walk home alone. By utilizing the pathing and geolocation of Google Maps, as well as the information gathering and communication offered by Cisco Meraki and Spark respectively, GetHome quickly pairs two users headed in a similar direction and provides a path such that they both get to their desired location with a minimal amount of safety risk. In addition, GetHome uses Cisco applications for data analysis and tracking to virtually accompany pairs as they make their way home: access points can ensure that users are on the correct path, and a chat-bot can double-check users have successfully gotten home.

How we built it

As a webapp, we utilized HTML5 and CSS3 to create a clean and precise landing page, with one redirect included for when a user lines up in queue. The basis of our working code is Javascript, which we used to interface with the various APIs allowing for accurate tracking and pathing of paired users. Using Google Graphs and Maps, we generated formulas to calculate and accurately map distances between all users as well as the distances between their respective destinations, while simultaneously displaying such information in easy-to-read graphical elements. A combined integration of Cisco Spark and Cisco Meraki, done via creation of Spark bots and information gathering with AWS Lambda, generates the heatmap for users to find their partner as well as open an avenue of communication between the two. Obscured from the user, we also rely on Meraki's Real Time Location Services (RTLS) to track whether individuals are following the anticipated path home; deviations are viewed as hazardous and can be handled by our companion-bot, which checks in with users to see if they're okay.

Challenges we ran into

Utilizing the REST API efficiently was difficult, seeing as how none of our team members had previous experience working with HTTP POST requests. In addition, working with the servers provided for accessing real-time data of our immediate location proved difficult, as some connection errors and faulty permissions prevented us from dedicating our full effort towards completely understanding the use cases of the functions and services provided alongside the data.

Accomplishments that we're proud of

As a team, we are proud of creating our first ever Spark bot and formulating conclusions based on real-time data via Meraki's Dashboard. Meshing together multiple APIs can become messy at times, so we are extremely proud of our clean implementations that serve to precisely and efficiently merge the varied applications we delved into.

What we learned

Throughout this hacking process, we learned a great deal about how to work with Node-RED for Cisco Meraki and Spark queries, as well as how to integrate such applications with services like AWS Lambda to properly retrieve points of interest, such as MAC addresses for tracking. The less-experienced of our team also learned how to utilize APIs in a very general sense within HTML and Javascript; as a whole, we built upon past experiences to further increase our efficiency and teamwork in regards to formulating ideas and bringing them to manifestation through research and dedicated work.

What's next for GetHome

Meraki's ability to precisely locate devices through triangulation by access points as well as the flexibility of heatmaps allows for the possibility of creating paths that avoid high-risk areas; this would be a further step in preventative safety, reaching beyond what our application currently utilizes Meraki's location services for. Combined, having Meraki anticipate the next access point the user should be pinged at as well as formulating the path so it is not only the shortest path, but also the safest, would be extremely beneficial for GetHome and its users.

Built With

Share this project: