
Electronics / Product Design / IoT / Sensor Integration
Soda Can Prevention Device
2025 • Functional Product Prototype
This project was a smart locking soda-can case designed to make soda drinking less automatic. The device uses sensors, a servo lock, OLED feedback, sound detection, weight tracking, and two ESP32s to slow the user down, track usage, and force a small moment of reflection before getting the drink.
Status
Functional Prototype
Controllers
2 ESP32s
Sensors
Touch / Weight / Sound
Role
Design / Code / Integration
Demo / Media
The media shows the project from CAD to physical prototype: enclosure design, sensor layout, wiring, locking mechanism, and the final assembled product.

Final Product Prototype
The final yellow enclosure brought the touch sensor, OLED display, microphone, locking mechanism, and can holder into one physical product-style prototype.

Servo Locking Mechanism
The servo acted as the physical lock. The latch geometry made the case harder to force open while the countdown sequence was active.

Electronics Wiring Layout
The full system required a dense wiring layout connecting the ESP32, OLED, touch sensor, microphone, load cell amplifier, servo, and power source.
Project Motivation
The idea was to build a product that could make someone more aware of how often they drink soda. Instead of making a normal container, we wanted the case to interrupt the habit. The user has to wait, stay calm, and put the can back before the system stops bothering them.
I do not see this as a perfect consumer product or medical solution. It is more of a behavior-aware prototype: a physical system that uses friction, feedback, and tracking to make an automatic action feel less automatic.

System Architecture
The system starts when the user touches the sensor. From there, the device begins a countdown, checks for loud tampering through the microphone, displays messages on the OLED, unlocks the lid through a servo, and uses the load cell to measure how much was consumed once the can is returned.
The project used two ESP32s. The first ESP32 handled the main sensors and actuators inside the case. The second ESP32 stored and displayed usage data like pickups, grams consumed, cans finished, and daily, weekly, and lifetime totals.

Design + Manufacturing
The enclosure had to do a lot at once. It needed to hold the can, house the electronics, support the load cell, expose the OLED and sensors, and create a locking geometry that the servo could actually control. Madeline created the initial design direction, and I pushed a lot of the later redesigns because I had the printer and could keep testing fit after fit.
A lot of the work came down to small physical details: making snug interfaces, leaving space for wires, adjusting the lock geometry, and making sure the printed parts could actually assemble around real components instead of just looking good in CAD.

CAD Iteration
The CAD went through multiple versions as the project became more real. The early can-holder shape was simple, but once the electronics, load cell, and locking mechanism were added, the geometry needed more structure. The latch and hinge area became one of the most important regions because it decided whether the lock would feel real or flimsy.


Mechanical Locking Mechanism
The servo was the physical lock. Once the waiting period ended, the servo moved the latch and allowed the user to access the can. The point was not just to move a part; the geometry had to make the case feel locked while still being simple enough to print, assemble, and debug.
This was one of the areas where the product became more mechanical than just electronic. The sensor logic only mattered if the lock actually controlled access to the drink.

Electronics + Sensor Integration
The electronics were the densest part of the build. The main ESP32 had to connect to the touch sensor, microphone, OLED, HX711/load cell, speaker, servo control, voltage pins, and power rails. There were enough wires that the internal packaging became its own engineering problem.
My workflow was to add one component at a time. I would test a sensor by itself, debug it, confirm the code worked, then integrate the next component. That kept the project manageable instead of turning the whole system into one giant mystery.

Weight Tracking
The load cell was the foundation of the tracking system. When the user started the sequence, the device recorded the starting weight of the can. After the user returned the can, it measured the ending weight and estimated how much liquid was consumed.
This turned the prototype from a simple lockbox into something that could actually measure behavior. Instead of only blocking access, the device could report pickups, grams consumed, cans finished, and usage over time.

ESP32 Communication + Data Logging
The second ESP32 gave the project a cleaner way to separate real-time control from stored user data. The main ESP32 handled the sensors and actuators, while the second ESP32 received usage information through ESP-NOW and tracked daily, weekly, and lifetime values.
The goal was to show the user more than just a warning. The system could tell them how often they picked up the can, how much they drank, and how their behavior changed across longer periods of time.

Debugging + Iteration
This project was pretty straightforward in the sense that I knew how to attack it: isolate one sensor, make it work, then add the next piece. But the full integration was still a hassle. The device had a lot of pins, power connections, wires, sensors, and actuators all competing for space inside one printed enclosure.
The main lesson was that working code is not the same thing as a finished product. Once everything had to fit physically, wire routing, internal clearance, mounting points, and the order of assembly became just as important as the code itself.

Technical Highlights
Built a smart locking soda-can case that used sensors, user feedback, and data logging to slow down impulsive soda drinking.
Integrated a TTP223B touch sensor, 1kg load cell with HX711 amplifier, MAX4466 microphone sensor, OLED display, speaker, and servo locking mechanism.
Used two ESP32 microcontrollers: one as the main controller inside the case and another for logging daily, weekly, and lifetime drinking data.
Used ESP-NOW communication so the device could separate real-time control from longer-term usage tracking.
Designed and redesigned the 3D-printed enclosure, latch area, can holder, internal sensor mounts, and wiring space around real hardware constraints.
Built the system one sensor at a time, testing each part before integrating it into the full product-style prototype.
Tools / Hardware / Software
Main software environment: Thonny IDE with ESP32-based control and communication logic.
Mission Log
This project came from an intro mechanical engineering electronics class where the goal was to make some kind of product using the electronics we learned. Honestly, I did not feel like the class itself taught me that much because I had already built projects like Bonnie and the phone gimbal, but this project still gave me a reason to work with new sensors and package everything into a product-style prototype.
The concept was a soda can prevention device: a smart case that makes the user wait before accessing a drink, tracks how much they consume, and gives feedback if they try to rush the process. It used a touch sensor to start the sequence, a microphone to detect loud tampering, a servo to unlock the case, an OLED to display messages, a speaker to annoy the user when they broke the rules, and a load cell to measure how much liquid was consumed.
My friend Madeline made the initial design direction and concept structure for the box, but I ended up taking over a lot of the later physical redesign because I had the printer and could keep iterating. I made detailed changes so the parts fit more snugly, adjusted interfaces between printed pieces, and worked through the practical problems that only show up once the hardware has to live inside the model.
The way I built the electronics was one piece at a time. I tested a sensor, debugged it, confirmed that the code worked, and then added the next part. That process made the system manageable even when the wiring became crowded. By the end, the project had a lot going on: two ESP32s, communication between them, sensors, actuators, power rails, a servo lock, tracking logic, and a physical case that had to hold it all together.
The final prototype worked smoothly. It was not a polished consumer product, but it proved the idea. We were able to bring a product from concept, to CAD, to printed parts, to wiring, to code, to a functioning prototype in a reasonable amount of time. For me, this project showed that I could integrate a lot of separate components into one system and still keep the final product understandable.
Final Result
The final device worked as a complete sensor-based product prototype. It could detect user input, begin a timed access sequence, respond to noise, unlock with a servo, measure can weight, track consumption, and display user feedback. The system had no major hiccups by the end and proved that the concept could be built as a real physical device.

What I’d Improve
The biggest improvement would be the internal electronics packaging. A custom PCB or cleaner wiring harness would make the system sleeker, more reliable, easier to assemble, and more realistic as a consumer-facing product.
I would also redesign the internal dimensions. The prototype ended up fitting mini cans comfortably, but regular cans were too tight. A future version would have better can clearance, cleaner mounting points, and a more intentional layout for wiring, batteries, sensors, and maintenance access.
