Electronic Holiday Cards

As the holidays approached last year, I pondered what I should prepare as gifts for friends and family. I always stress out about choosing presents because I want to make sure that I give something that's useful and/or long-lasting while accurately reflecting the relationship between me and the receiver. Cards with hand-written notes are highly valued in my social circle, but I want to give more than just piece of paper. Being an electronics enthusiast, I like to have circuits in my cards, but the ones sold in stores are almost universally annoying and bad. Thus began my quest to design and make my own electronic holiday cards.

   My high-level goals at the outset were to create an electronic card that is highly interactive, can be programmed, and shows off my nerdy side. Store-bought cards usually just play a single audio clip when you open them, but I wanted to add a wider range of sounds and more ways to trigger them. Different types of effects other than audio would be cool as well; I've never seen a card with lights, for instance. Making the card re-programmable would serve two main purposes: enabling software fixes and upgrades after construction, and introducing people to the idea of modifying and extending their gift. Few of my family members know any code, but I like to press the topic in hopes they'll come to learn and enjoy it in time. In addition to being able to program it, adding operating notes and source code listings directly to the card would help encourage them to learn more. It's also a expression of my character that's visible on the card's exterior.

   The design is an electronic keyboard with four keys that can only play one note at a time. Each key represents one bit in an LSB-first four-bit number that selects a note out of a single-octave scale ranging from A3 to A4 in half-step increments. For example, pressing just K0 (the leftmost key) plays A3. Pressing K0 and K1 together plays B3 flat. This scheme leaves a few key combinations left over, so I plan to use those as triggers for additional sequences or modes in the future.
   The materials are a mix of corrugated cardboard, cardstock, and glue. The cardboard makes for a much chunkier card than I had intended, but it actually feels nice and solid in the hands. The keys are implemented by partially cutting tabs into one side of the cardboard so they would fold down while remaining attached to the rest of the body. Underneath are rubber dome buttons that give the keys lots of travel and don't produce unwanted clicking noises. Paired with each key is a colored LED that lights when the key is pressed. The LEDs are Adafruit Sequins that have large solder pads and built-in current-limiting resistors. These make assembly much easier. Both the LEDs and keys are wired with slices of old IDE hard drive cables that thread through the cardboard up to the controller at the top half of the card. The controller is an ATMEGA328P in a 28-pin DIP package. At first, I thought that package would be too physically large, but it actually just fits within a cutout in the cardboard. Plus, I've only ever soldered through-hole parts before, so it improved ease of assembly. In addition to the buttons and LEDs, the controller is connected to the speaker driver, programming port and battery. The driver is another Adafruit product based on the PAM8302 that has adjustable volume and a shutdown pin. It drives an 8 ohm 0.25 watt speaker with a diameter of 1.5" that fits nicely next to the controller at the top of the card. The programming port at the top is connected directly to the VCC, RESET, MISO, MOSI, SCK, and GND pins on the controller. The programming protocol is specified in application note AVR910, and it works perfectly with the USBTinyISP programmer I have in my toolbox. Adjacent to the port is the battery holder and a switch to direct power from either the port or the battery. The battery holder opens at the edge of the card and accepts CR2032 coin cell batteries.

   I was careful to plan ahead and worked for several weeks before the big holiday party where I would give out the cards, but I still completely blew the deadline and didn't get the first set of five cards out until after New Years. Despite that disappointment, this was one of the most fun and satisfying projects that I had ever worked on. On their own, the electronics, software, and mechanics are very simple, but bringing them all together was both challenging and rewarding. When people did finally receive their cards, they genuinely enjoyed them. All of the cards worked well even after some use, though failures did include paper partially detaching from the cardboard and thin speaker wires breaking off of the driver.

   With this year's holidays coming up, I definitely want to change things to make the cards easier to manufacture. The point to point wiring in the current version consumes requires several hours of soldering, cutting, and stripping for a single card. Therefore, I want to finally learn PCB design so that I can simply wire pairs of boards together and sandwich them between paper and/or cardboard. In addition, I want to add many more features to the software (available here) like pre-programmed music sequences and a Simon-like game. Some fancy pop-outs that add additional dimensions when the card is opened would be cool too.

Middle School Robotics Classes with Johnny-Five

Last summer, I was offered the opportunity to hold robotics classes at a nearby middle school. I jumped at the chance because it would allow me to have complete control over the curriculum. I had already spent several years helping with a high shool's FIRST Robotics Competition (FRC) team, but I was starting to feel constrained by the rules and expectations of the games. This time, there would be no need to balance the students' fun and education with success at regional competitions.
   Not to say that there weren't downsides. While at least one other mentor was present to help the students, none of them had any previous experience with robotics. Classes were held in a normal middle school classroom with no access to any tools or parts. The school provided computers to all students, but they were locked-down Chromebooks that I couldn't install any additional software on.
   These conditions led us to use the Sparkfun Inventors Kit 4.0 as a base for the hardware. It's relatively affordable and comes with all the parts needed to assemble a simple driving chassis. The electronics include the RedBoard, which is Sparkfun's Arduino Uno clone, and a handful of sensors, LEDs, buttons, and switches. A nice printed manual with step-by-step instructions and lots of illustrations is also provided. We rarely used it in our classes, but it did provide inspiration and guidance when planning the projects. The only flaw was the flaky ultrasonic rangefinders, but those have since been upgraded in the new 4.1 version of the kit.
   Most of the students had already been introduced to Javascript programming in previous classes, so we wanted to keep using the language to program the RedBoard. The Johnny-Five Node.js library was the obvious solution for us due to its compatibility with a large range of peripherals and excellent documentation. There is also a convenient Chrome app that packages the library with a simple UI. We used this app all through the first round of classes, but frequent bugs and inability to save code to the filesystem drove me to adopt a different approach. I got out a stack of old laptops that I had accumulated over the years and installed Linux and Johnny-Five on them. Students would use the built-in text editor (either mousepad or gedit) to write code, save them to files on the desktop, and drag the files to a special icon that would invoke Johnny-Five to connect to the Arduino and run the program.

   After assembling the parts and software, the next big challenge was to think of an fun projects for the students. Middle school kids lose interest a lot faster than the high schoolers I was used to, especially after a long 6-hour day of classes. I initially started each class with a short slideshow on the technology relevant to the following project, but this failed to make much of an impression. Later, I began class with the first part of the project, and after their interested was piqued by the new sensor  or actuator, I would follow up with an explanation about it that would be needed to finish the rest.

   The projects increased in complexity until the students could assemble a driving robot that used an ultrasonic rangefinder to navigate. For the first course, the robot was supposed to follow a hand that was placed in front of it. This turned out to be a exciting way to physically interact with the robot and learn how to build up complex logic in Javascript. The fun and challenge both increased in the second course. The robot hardware ended up mostly identical, but the assigned task was to navigate through a simple walled course. Teams were encouraged to finish the course in the least amount of time. The sense of competition infused much more energy and focus into the students than ever before. I am still reluctant to admit it, but the prospect of winning or being the best is a crucial motivator for many people.

   Although it was hard work, I thoroughly enjoyed running my first robotics classes. My fellow mentors were extremely helpful and encouraging; the lessons wouldn't have been nearly as effective without their assistance. Though the students were sometimes hard to control, they were truly inspiring with the energy that they brought to the class. Some even engineered novel solutions that I had never considered and asked thought-provoking questions that led me down rabbit holes I wouldn't have otherwise explored. In all seriousness, I'm hopeful that this experience will encourage them to use technology to improve the future.