The Water Clock
CPSC 581 Fall 2021 - Project 3
CPSC 581 Fall 2021 - Project 3
Created By: Abraham Beauferris, Marcello Di Benedetto, Christopher Rodriguez, Rory Skipper
This project seeks to create a physical prototype that solves an everyday problem. The problem we chose to focus on was the common issue of dehydration during long work days. As computer science students, we spend a lot of time at our desks in front of screens, and while trying to meet deadlines and becoming immersed in daily tasks, it can be difficult to remember something as simple as drinking a glass of water. This behaviour can lead to dehydration, and uncomfortable headaches.
As an answer to this, we created a novel device capable of reminding a user to drink a glass of water at set intervals throughout the day. The user can fill their glass, place it on the device’s scale, and after a time interval, will receive an auditory notification from the device, reminding them to take a break and drink a glass of water. When the alarm does sound, the only way to dismiss it is to drink the glass of water and place the cup back on the scale, verifying that the user actually drank the water. The user can repeat this timer indefinitely, by placing another filled glass on the scale. This device will also track the user’s daily water intake, and display it on a screen.
We used a collaborative take on the 10 + 10 ideation method for this project to decide on a final design with useful and intuitive features and use cases.
Intial ideation sketches for a physical prototype to "solve an everyday problem" with an Arduino.
This design describes a physical prototype that acts as an alarm that indicates when your dog wants to leave the house. It would presumably work with a proximity sensor or camera, but we ultimately deemed it would be difficult to realize a prototype that worked consistently.
This design describes a physical prototype that acts as a callback for when you are at a dog park with your pet. It would work with a battery powered vibration motor attached to a dog collar as well as a secondary device the owner would carry to gauge distance from the dog. We ultimately decided an implementation would be difficult to realize due to technical constraints and difficulty of testing the prototype.
This design describes a physical prototype that acts as a drink delivery system, first pouring a drink then using an array of Toio robots to deliver the drink to the user. While our ideation process used this prototype as a jumping off point for our final design, we ultimately decided this implementation was not novel enough.
This design describes a physical prototype that waters a plant according to a preset schedule, dispensing water into a plant pot. Again, while our ideation process used this prototype as a jumping off point for our final design, we ultimately decided this implementation was not novel enough.
This design describes a physical prototype that sets an alarm upon someone entering a room. We ultimately decided a proximity-sensor-based alarm was a little too simple to adequately storyboard and develop intrigue.
This design describes a physical prototype of a motorized back scratcher that is mounted to the wall. Similar to the previous concept, we ultimately decided this idea was lacking in complexity.
This design describes an alarm system that upon ringing, activates several Toio robots to push useful objects within reach on your nightstand. While the design was functional and relevant to the project’s goals, we ultimately decided it would be difficult to implement consistently and wasn’t particularly intriguing within the scope of the target audience.
This design describes a physical prototype of a motorized Tower Pros mounted to a table to act as a wrist massager. Similar to the back scratcher concept, we ultimately decided this idea was lacking in complexity.
This design describes a “stovetop timer” which would use a motor attached to a pulley attached to a stovetop knob set up with a timer. When the timer is set and activated, the motor would engage, pulling on the pulley which would rotate the knob. This could be used as a timer. We ultimately abandoned this idea due to safety concerns regarding the idea.
Finally, this design describes an alarm clock that helps those who have trouble obeying their alarms and getting out of bed. To disarm the alarm, the user must drink a glass of water and place it back onto a weight sensor. This action necessitates sitting up straight, and hydrating oneself, a good start to the day. This idea ultimately developed into our final design, due to its engaging concept, usefulness as an everyday device, and novelty.
Moving forward from the ideation phase, our group chose to iterate on concept #10, “The Water Clock”. We landed on this concept as this device aims to solve a well defined problem that is especially relevant to our position as computer science students. This relatively simple design would provide a great benefit to the user, while also allowing us to become more acquainted with managing several devices concurrently with an Arduino.
The following are some details and variations of our chosen concept, the “The Water Clock"
This design variation entails a motor pushing the cup of water onto the user if they do not wake up upon the alarm sounding. While an effective negative reinforcement, we ultimately found this design a little too cruel, in opposition to the engaging user experience we were trying to achieve.
This detailed sketch shows the screen displaying a countdown until the next drink. This was implemented in the final design as it proved to be much more relevant user feedback as opposed to just displaying the time of day.
This iteration seeked to refine the design of the system, integrating each input and output device together into a single module. We felt that this design enhanced the aesthetic appeal greatly and ultimately factored into our final design.
This detail outlines the device’s ability to “remember” the weight of an empty cup of water so as to identify if the cup is removed or filled, along with exactly how much liquid is within the apparatus. This was implemented in the final design, as the scale is “zeroed” upon startup.
For this iteration, we further refined the ideas necessary for the functioning of the physical prototype. In this case, we thought that the design would need to detect the state of the water in the glass being drunk by the user. Since it would be easy to exploit the system if the cup was simply being removed counting as a pass state, one of our group members suggested zeroing the scale with the glass being empty, thus using that specific weight only as the recognized success state. This was a useful idea and ultimately ended up in our final design.
This variation describes a visual indicator to display the amount of water left in the glass. While novel, we ultimately felt this idea didn’t aid the core functionality of the prototype in a practical sense, as we could just use a translucent cup as a way to offer the same information.
This variation describes using a small robot, such as a Toio, to notify the user to drink upon the time limit finishing. While the alarm functionality was useful and was implemented into the final design, we found the use of a Toio superfluous to the practical usability of our design.
This design describes a similar prototype with a different use case; in this case, as a snack timer that allows a user to space healthy snacks out within set intervals. While useful, without the use of a cup, we would have to use an empty scale as the success state. Unfortunately, this would be easier to abuse as the user could simply place the object off the scale without eating it.
This design would push the water towards the user when they need to drink as an invitation of sorts. We ultimately decided the concept did not aid the core functionality of the prototype enough to justify its implementation.
This design would display the time along with the alarm. As this feature is not integral to the operation of the device, we felt that it did not provide enough relevant information for the use case of a periodic “drink water!” notification. For this reason, this variation was not pursued further.
The final design uses an Arduino, scale, LCD screen with alarm and timer encased in a box. We took many useful aspects from various points in our sketching and ideation process, such as the enclosed design, countdown timer, daily intake display, and an empty glass being used as a check for successful consumption of the water.
The user can fill their glass, place it on the device’s scale, and after a 20 minute interval (would be around an hour in a real world application or set by the user), would remind them to take a break and drink a glass of water. When the alarm does sound, the only way to dismiss it is to drink the glass of water and place the cup back on the scale, verifying that the user actually drank the water. The user can repeat this timer indefinitely, by placing another filled glass on the scale. This device will also track the user’s daily water intake, and display it on a screen. This system can be used with all kinds of cups and glasses also being usable with a water bottle allowing the user to do multiple alarms without getting up.
This project was implemented using an Arduino Uno, HX711 and load cell, DS3231 real time clock, Nokia 5110 LCD, and a simple speaker. The frame for the scale was 3D printed and we used a cardboard box to hide all wires and boards that did not need to be exposed to increase the aesthetic appeal and simplicity of the visual design. The microcontroller was programmed using the Arduino IDE and utilizes external libraries for the various components including HX711_ADC, LCD5110_Graph and RTClib.
My personal contribution to this project was the configuration and procurement of the hardware resources, integration of libraries for the hardware, along with participating in pair programming for the program logic. All group members contributed to the ideation and refinment process of the 10+10 design process.