IDEA Hacks, billed as “California’s largest college hardware-focused hackathon”, took place at UCLA over 36 hours of the MLK weekend. The theme was home automation.


The Team

I showed up with no team, no project idea, and negligible electronics experience. 36 hours later, I left with a team, a working prototype, and a tiny bit of electronics experience. Pretty good deal, eh?

My role: mechanical design and 3D printing

  • Sang
  • Alex
  • Cole
  • Cathy


It’s easy to purchase reusable batteries, use them, and then get too lazy to actually charge them. Wouldn’t it be useful if a device existed to decrease the effort involved in recharging batteries? Of course, there’s always the option of purchasing one of those giant boards with slots for 8, 10, 20 AAA batteries. But what’s the fun in that?

Enter the automatic battery charger, aka the “Bougie Battery Box”*. Featuring enough space for more than 10 AAA batteries, just throw your AAA batteries into the hopper, where they’ll be automatically fed through a charger. After a few hours, they’ll be deposited into the reservoir, fully charged!

*We didn’t have a formal name for the product, but I’ll refer to it as the BBB throughout.

Final product

Design and testing

Battery holder

One of the challenges we had was limited hardware—we only had one continuous rotation servo. As a result, we decided to dedicate that servo to cycling the batteries. We first started with a single “hinge”, which turned at most 180 degrees to accept batteries from the hopper and deposit them in the reservoir.

First iteration. Note the recessed back panel.

However, there were some electrical challenges: because the servo didn’t have an internal encoder (what?) it had a tendency to drift when time was used to turn it back and forth. As a result, we transitioned to a “water wheel” design, which only required the servo to turn in a single direction, and for 1/3 a turn at a time.

Later iteration. The frame was printed in separate sheets, and screwed together using #2-28 machine screws.


Since we were on campus, on the second day, my team and I decided to go back to the dorms to bring my 3D printer to the hackathon. Once it arrived, it never stopped printing—it ran for 24 hours straight! Because we had constant access to a 3D printer, we were less worried about making mistakes, and tried different printing orientations to try a balance of speed and print direction strength—literal rapid prototyping!

3D printer
Baby’s first hackathon, basking in the sunset.

I maximized print layer height (0.3 mm), and used a speed of 60 mm/s, corresponding to best practices for coarse or draft quality prints. However, when running a gcode file for a neighboring team, I saw that they were printing closer to 80 mm/s, and neither bed adhesion nor print quality were issues! I still have a lot to learn about my printer, including testing the upper limits of its print speed.

In order to make sure the batteries reached the charger and didn’t get stuck in the hopper, I designed the hopper to be comprised of two slopes. That way, even if the batteries hit the first slope vertically, they would bounce and roll flat down the second slope. Luckily, I didn’t have to reorient the batteries, because the charger could detect polarity and work in either direction. This setup worked (see gif), but the batteries could get stuck in the corners; I could have included fillets (with radii not equal to battery radii) to increase instability at the corners.

Battery falling

Electrical overview

Since I didn’t work on designing the electronics (besides a brief stint attempting to program an LCD), this is what I understood the electrical functionality to be.

Battery voltage may be detected by measuring the voltage relative to the Teensy’s voltage.

The electronic guts of the battery box. The two white wires on the side of the box detect voltage and charge the battery, but since that functionality was inconsistent, the two wires sticking up are used to detect voltage.

When a full battery charge is detected, the servo turns, depositing the battery into the reservoir and allowing the next battery to fall.

Front view of the battery box. Our singular servo is on the left. Black plastic on black jacket does not make a good fashion combination.

Battery charging turned out to be a nontrivial exercise, so we were advised by mentors to build all the hardware/software besides the actual charger. Towards the end, Alex and Sang built a “naive” charger that fed the battery a small (~60mA) current, with a temperature sensor to shut off the process if things got too hot.


Like any good prototype, our charger decided to give up when we were actually doing a demo for the judges. A wire came loose on the perfboard, resulting in the waterwheel not triggering when a fully charged battery was placed between the wires. The judging presentation could have been worse, but with three sleep deprived engineering students, we didn’t have much success in convincing our judges that our project was something they would want to purchase.


What we did well

  • For a team that never worked together, communication was surprisingly smooth. (Being constantly within 10 feet of each other helped as well). However, we naturally checked in with each other every few hours, and contributed ideas to each others’ subsystems.
  • Integration went surprisingly well. Thanks to our communication, we were generally aware of what each of us were doing at any given point in time. Hardware-wise, we also had the advantage of a standard AAA battery form factor.
  • We were also able to choose a relatively simple idea and work on it to completion. There’s still some aspects on our project we can expand on, though:
    • Charging arbitrarily sized batteries—everything from 9V rectangular batteries to AA or coin cell come in rechargeable varieties
    • Sorting batteries after they’re charged (or “rejecting” them)
    • Application to “battery share”: Uber for batteries! (That probably exists already, though!)

What we did poorly

I’m not sure how the standard of a “poor job” gets applied to a hackathon, since all we’re trying to do is to finish the project, but here’s some things we could improve on for the next hackathon:

  • Device idea: Battery chargers already exist, and rechargeable batteries seem like a niche product (only useful in high-throughput battery situations, like for photographers). We could have chosen an idea that is more universal, or market it during our presentation to apply to more people.
  • Speaking up: I didn’t realize until halfway through the second day of the hackathon that none of the team members knew each other! Had I understood this earlier, maybe I would have been more willing to express my opinions when we were deciding what to build during the hackathon.
  • Sleep is important! Most of the teams that did well weren’t hammering away at their projects throughout the night; rather, they would go back to their apartments around 2 or 3 am, rest, then come back early the next day.

Sleep is important!


Judging is not just based on the functionality of the device at the end of the hackathon, but also on the project’s overall vision and its potential.

One of our concerns we had when prototyping was lack of materials (e.g., higher torque motors) to create something to scale. However, the winning teams made the most of the parts given (e.g., a closet with origami outfits, or a stove represented by an LED).

I can’t wait to go to another hackathon! In some sense, hackathons are like instant gratification—no need for laborious design, analysis, and testing—just build it! I enjoyed the feeling of only having our project to focus on this weekend, and not being distracted by academic obligations.

Possible future projects in the vein of home automation

  • Laundry sorting/folding machine, with capability of turning clothing inside out
  • People with unconventional homes (e.g., tiny houses, truckers)
  • 3D printer for hackathons: portable, fast-printing, direct drive printer (preferrably cheap)
    • Is there actually a need for this, though?