This post will go into some of the reasoning and design choices that went into v1.0 of the KiT, which was designed Summer 2016.

Hardware

Microcontroller

With the means of communication, colored light, decided on, I had to figure out how to create a *useful* IoT device. Security isn't a huge deal because all that I'm communicating is a color (and this is currently just a prototype), but I prefer to have the option to use it in the future. I settled on the ESP8266 since it's simple, it offers WiFi for easy connection to WiFi networks, and I'd worked with it in the past. The exact board I chose was the Digistump Oak, because I had a few lying around from Kickstarter that I wanted to use and its connection with Particle.io should simplify the communication and programming parts of the board, allowing me to update all boards at once with new firmware if I made revisions. Power regulation was also taken care of by the Oak, so I only needed supply a MicroUSB cable to power the MCU, LEDs, and all peripherals.

LED

The LEDs are just generic common cathode RGB LEDs. I'm not going to get into driving an LED because that's been done to death, but in brief I used the PWM ("Analog output" in Arduino-speak) pins to drive a transistor that would drive each diode.

User Interface (Knobs & Buttons)

For user input I decided to use knobs. I considered a rotary encoder, but the hardware for that is a little more complicated, and I was going for SIMPLE. The other problem with most rotary encoders is a lack of a "start" position. This makes it harder to select a specific color by memory (which will likely happen as users become familiar with using KiT) because you can't turn the knob to where you expect it to be, as rotary encoders only give relative position, thus requiring the user to use visual feedback to select the desired color. So I decided to use a linear potentiometer (i.e. variable resistor) and an ADC to measure the knob position.

I need at least two knobs for user interaction. I was originally thinking three, one for each Red, Green, and Blue, but decided that was too complex and unintuitive. Instead, I'm planning to use the HSV color encoding (play around with it at Colorizer), and decode that into RGB values for the LED channels. The advantage of this is that there only needs to be one (maybe two) knobs to choose a color, because I will limit users to choosing either Hue or Saturation. If I limit users to just Hue, I might use the second knob to allow different pulsing patterns instead of just a solid color. Limiting the number of knobs is also beneficial to keeping the PCB small for cost and portability.

Sending a color will be implemented with a simple pushbutton. Because I was considering putting an enclosure around the KiT and the button needs to be press-able from outside, and I hadn't decided on a button, I left the switch as bare holes in the PCB to solder leads into later.

I designed the PCB in CircuitMaker to take advantage of their pre-built libraries and 3D mock-ups of the design.

Where's the Software?

Good question... unfortunately, when I started this summer of 2016, I got a little bit of work done on the software, but honestly didn't make much progress because I was fighting with setting up my Digistump Oak and trying to figure out how to write a driver for communicating with the off-chip ADC. Now the software should be easier (aka simpler) to write, and I'm going to write a new revision of the software from scratch, with better design. I'm considering adding in different blinking patterns to represent different people or just different emotions too (e.g. a "heartbeat" pulse, quick flashes to get attention, etc), which wasn't possible in the old version, so I'll just write it from scratch. I'll create a Github repo when I get my new hardware version sent out to PCB fab because of the longer lead time of that process.

In terms of software I'll be using, I'll probably be building this off the basic Arduino/ESP libraries for simplicity, with possibly FastLED thrown in to handle HSV to RGB color translation.