Change Thing Door Thing See Thing

Top view of the inside of the assembly
Standard view of the assembly
Front view of the assembly
Actual hardware during testing

Inspiration

It all started when my roommate and I wanted a ring doorbell as a fun addition to our door. However, when we looked into it, the companies that run and hold the data for these smart home doorbells we discovered that they are notoriously bad about protecting user data, with some cases where they even deny a breach even happened even if many users report that random people were able to log into their ring account, and Amazon themselves saying it was just a backend issue, while at the same time introducing mandatory surveillance for law enforcement further disregarding consumer privacy. Something a user cannot control, stripping the user of more of their freedoms and trust with the products they buy. The idea that we can’t own our hardware and software is crazy especially with a device that deals with so much personal info. We wanted to create a device that you can trust, not because you trust the people who made it, but because you trust yourself. The inspiration for our name came from the simple concept that this isn’t a brand, not something to get hype around, it's simple, clean hardware, with simple understandable software, and a simple focused purpose. A product that doesn’t force you to use the cloud, isn’t expensive to repair, isn’t a product you just have, it’s a product you own.

What it does

Change Thing Door Thing See Thing could act as someone's main doorbell, and it would be an upgrade for most Americans. With live video and audio streaming to your mobile device or desktop and a wonderful-sounding chime, we have an amazing start to what can become an amazing doorbell. Just as important as what it does is what it doesn't do, we had more difficulties than we thought and were unable to implement event detection and saving because of a broken SD card reader on our chip which meant our Passive infrared sensor is useless, we intended for it to while drawing lower power than the camera detect infrared which would trigger the camera which would run on chip human detection which we also could not implement because to run an existing ML algorithm we would need the space from the SD card, and it is unrealistic to train our own model in a hackathon. Instead, we just have the camera recording when it is being viewed on mobile or desktop.

How we built it

For the hardware, we first found or created 3d models for each part we used, having to find models is easy until you realize that the ESP32 model you found online has its pins slightly misaligned or the scale is slightly off with what you can measure in person. Then we assembled all the parts in a skeleton form, no casing, just to estimate where we want all of the sensors, then by tracing the front face with all the sensors, we get an idea for how much clearance we need on all sides. After that it’s a matter of estimating how much space we need for wiring, where connections go, and how to make it look good. Beyond that testing hardware is hard since we couldn’t use breadboards easily with our parts. Each solder had to be a trade-off, do we want it longer to make it easier to test, or is it worth it to solder it close so that we don't have to re-solder the part. For the software, we began with understanding communication with the board and setting up the basic framework of a Tauri application, with android emulators for members who did not have android phones that they could build to. After which we set up the communication between our ESP32 and our phones making an HTTP request over the shared LAN. The next step was video streaming into the app after which we split up into working on UI and working on transferring audio which was considerably more difficult than video because the camera because video from the board's camera acted as a stream of JPEGs but audio could not be the same as it had to have larger packets and a smoother transition, low fps video is less obtrusive than choppy audio. After implementing streaming packets of audio we integrated the button and speaker to ensure we could also operate as a dumb doorbell.

Challenges we ran into

With the making capabilities at WPI only actualized through the numerous student-run clubs, operating solely out of the makerspace was impossible. Getting just about anything was a challenge, screws, transistors and a capacitor were all things we had to hunt around for praying people and places had not closed for the night. The biggest scare we encountered was when our camera stopped working. It was incredibly hot to the touch and would not respond to serial communication. With the camera being one of, if not the most important part of a smart doorbell we freaked out, we tried to find out if we could get another board after removing it and reinstalling it on our chip 5 times, and we even found a stranger who had the complete internals of a ring doorbell, who was happy to give it to us to see if we could salvage the camera off of it. Ultimately we discovered that the issue was from interactions between Mac devices and Arduino IDE causing us to pivot to PlatformIO. We faced lots of challenges but collaboration kept us going, which was easy because we have the entirety of outer cloud studio on our team.

Accomplishments that we're proud of

There were a lot of restrictions we had doing a hardware hack in such a short time, and it meant we had to be creative and correct the first time as much as possible. With two-hour lead times and the printers closing at 11 we knew precision in our first case CAD was absolutely critical, and one of our members delivered beautifully, ensuring measurements and tolerances were accurate in the CAD so well that all components fit in our small frame with no need for a second print.

What we learned

When dealing with hardware, it’s hard to keep scope within realistic bounds. Hardware just doesn’t move at the same speeds that software. It is important not to overestimate the amount of power of micro controllers, without the knowledge beforehand we didn’t know we needed parts like transistors, capacitors, and amps. It’s not the same as software where you can just install a new library. Hardware is consistent, but slow to iterate. Our team of four CS majors and one ECE major quickly became 3 people learning how to do hardware, one coder, and one CAD modeler. Also compared to running code on your machine, having to upload code to a micro controller is not just slow, but also finicky. Writing code and waiting one minute for your code to catastrophically break is a world ending experience.

What's next for Change Thing Door Thing See Thing?

Getting a new SD card reader module for the ESP32, this will allow us to implement the features that we really want/need, for example event based recordings, on device video storage, and being able to serve video from before a user hits the live button. Re-printing the casing with proper screw holes and better mounting hardware, all of that needs rigorous testing to get part sizes correct which can be a big issue when dealing with 3d printed hardware. Looking into ways to maintain weather protection while not compromising on repairability.