Safe Sip

Inspiration

We've all heard horror stories of spiked drinks, especially at college parties. One of our group members is from Los Angeles, where some bars are utilizing drink lids that flash red when moved as a safeguard against tampering. But we realized that it would be beneficial for event organizers, such as the risk manager at a fraternity or the bartender on duty, to also be notified of drink-tampering activity.

What it does

Safe Sip is both a hardware device and a mobile app. The mobile app registers the event attendees' names, phone numbers, and optional emergency contact information. The hardware device is a drink lid that can be set to an "armed" state. If the drink lid is moved while armed, the owner of the lid (an event organizer) and the event attendee registered to the lid would both be notified of potential drink tampering via a text message and flashing LED lights on the lid's body.

How we built it

In hardware, we used micro-controllers, a radio chip, and an accelerometer for the internal electronics. The accelerometer was our motion detector, and the radio chip was how we sent signals to the app's SQL database.

We used .NET Maui, a cross-platform development framework for the front end of the app, and Microsoft Azure for the backend.

Challenges we ran into

Hardware

-The radio chip's firmware was very difficult to work with. We spent over 6 hours just on this.

-3D printing the lid's casing under time pressure was difficult. We barely had enough time to get all of our prints done!

-We had limited resources. The hackathon didn't supply any hardware components, so we could only use what we already had on hand. Besides the chip, we also had issues sourcing a power supply and sub-optimal micro-controllers.

Software Frontend

-Debugging required a lot of coordination; we only had one phone to test the app on and we needed NFC tags to access certain pages

-Daniel was learning a new framework on the fly and had to set up half of his development environment from scratch

Software Backend

-Texting was a bit of a problem. I first thought to simply send texts as an email through the Google SMTP servers, but quickly found out that it had a few flaws. I moved to the Vonage API and it seemed to work well. I implemented the entire API, however, after multiple failed messaging attempts I realized that Vonage would only allow me to text phone numbers that are "verified" and thus render the device useless to any new customers. In the end, I found Twilio and used their platform to create a phone number and messaging service that worked very well.

-Accessing SQL can be a pain. At the start of our project, I was setting up a SQL server on Azure and wanted to access it from my laptop to edit. I tried connecting to it many times and it repeatedly failed with a generic error. I ended up going against standard practice to open the server to all incoming traffic from all IP addresses, but it was to no avail as I found that I still could not access the server. A few hours later and I eventually found that WPI masks our IP addresses on campus WIFI and that I would have to use a VPN to actually connect to the machine. A couple of clicks and a VPN later, I was editing the SQL server with ease.

General

-We overscored and ran out of time for many of the features we wanted.

-We were all exhausted due to the time crunch.

-We had a late start because we took so long to come up with a solid idea.

Accomplishments that we're proud of

We're proud of the quality of the work we did given the time constraints, team size, and limited hardware selection. We had one person for the front end, one person for the back end, and one person for hardware, and we utilized our talent spread well. Building and connecting a mobile app, a SQL database, and an IoT device in such a short time frame was very difficult and required long hours. We're also proud of coming up with an idea that we see as actionable and practical in our local community. WPI is a campus with a lot of parties and a strong Greek life presence.

What we learned

1) Don't settle. We had lots of ideas but as a group, we kept going until we had something that felt beneficial for all stakeholders, would give everyone on the team an opportunity to show their expertise, and be practical in the real world. Knowing that everyone had a role and that our project was actionable in the real world made staying motivated much easier.

2) Diversity is a strength. Having people with different backgrounds helped at every point of the development process, from brainstorming to hardware assembly to app development. Our hardware guy would ask the two software people for help scouring documentation on firmware, and we needed people with different skillets and resources to cover each other's weaknesses. We all surprised each other at varying points in the development process.

3) Teamwork averages to fairness but work is skewed moment-to-moment. Everyone took turns being the focus of attention. When we struggled with our radio chip, all hands were on deck to puzzle out the firmware. When we were prototyping the app, we had most of our resources on mobile development. And everyone needed breaks at different times. We all had different body clocks in processing the long hours and that would cause large time blocks where only two people were working. It's important for everyone to act in good faith and pick up the slack when needed.

4) Communication, communication, communication. Our team came in as good friends before the hackathon so our communication and teamwork were smooth. But when communication did break down it tanked our productivity. There was a long stretch in the middle of the hackathon where we were all separated and not messaging each other, and that caused a big productivity loss and unnecessary stress.