While visiting Québec, Canada, I saw this fantastic installation in Montmorency Park: a field of fiber optic flowers. This project was done to honor the 150th anniversary of the Québec Convention. The field was comprised of over 15,000 flowers which gradually changed color over time. The slight variations of the timing and color of each flower made this installation even more fascinating to watch.
The construction of the flowers was relatively simple. Each flower was composed of a fiber optic cable running through some clear plastic tubing with a translucent plastic bulb on top.
The real magic came from the illuminated cable inside of the flowers. The fiber optic cable gave each blub a pleasant glow while the glowing cable running through the clear tubing created the subtle illusion of a stem.
It was possible to trace the fiber optic cables back to the light sources. As the sources were covered, it was hard to tell exactly what was powering them. The sources were running some sort of synchronized lighting program so that the large garden would simultaneously change color.
Although each flower was all slightly different, they all came together to make one beautiful glowing blanket covering the entire park. This has definitely inspired me to try to make some of my own fiber optic works of art.
On a whim I decided to add LED lighting to my desk hutch. I already had a reel of LED strips but nothing to control them. As I wanted to build a controller that afternoon, I constructed it from parts which could be purchased locally. The controller I made has an on/off switch and two knobs: one to control the brightness and the other to control the color of the lights. Here is how I built it!
The first step is to make holes in the project box. I did this with my trusty Dremel. Drill five holes: two for the potentiometers, one for the power switch, one for the power jack and a one for where the LED strip wires will enter the project box. Once the box is drilled out, place the power switch, potentiometers and power jack into the project box. Solder the power wires to the components.
Next, I assembled the LED strips. If you are adding connectors to the LED strips, solder those on to the strips. If you’re connecting multiple strips, be sure that you bundle the wires together properly. I’ve found that using colored wire or marking wires with different colors of tape makes it easier to keep everything straight.
Next, solder the potentiometers and LED strips. Mark the data lines for the LED strip and the potentiometers so you know which wire corresponds to a given component. It makes coding the microcontroller easier.
Next, solder the microcontroller. Keep track of the pins and their corresponding data lines. When soldering the potentiomenter to the microcontroller, make sure to connect the potentiometer data wire to pins that can support the analogRead function. These pins generally begin with the letter ‘A’.
Now it’s time to program the microcontroller. The simple code can be found here. Update the code to reflect the length of your LED strip and the pins that correspond to your components. Be sure to test everything!
Once you’ve verified that everything works, tape up any solder joints so that there are no shorts. Close up the box and you’re done!
I recently taught myself how to knit. I was interested in the mechanics of knitting, especially how it’s possible to weave string into cloth with just a few simple tools and techniques. It was also appealing because it’s something that can be done in small sessions rather than requiring long spans of continuous attention. Furthermore, knitting is a skill that allows you to make really cool things.
Knitting during a flight delay
To get started, I picked up an awesome introductory knitting book, Stitch N’ Bitch. The friendly folks at Knitty City also helped me pick up some needles (size 10) and yarn that were suitable for a beginner.
My first project was this simple ribbed scarf. Admittedly, it took me a long time to figure out the purl stitch, but I finally had some success with the English method of knitting. At the beginning, I made some mistakes and had trouble getting the yarn tension right which resulted in some oddities in the knitted fabric. By the end of the scarf, however, the stitches were even and consistent, resulting in a cool stretchable ribbed pattern.
For my second project, I wanted to try something a little harder. I made the Official Kittyville hat. I used a cheap wool yarn so it wouldn’t be an expensive mess if I screwed the whole thing up. This required needles that were smaller (size 7) than the ones I used for my first project. The hat also involved some new techniques, such as knitting in the round, decreasing size, using double-ended needles, and picking up stitches in the middle of the fabric. Overall, the stitches were still slightly too tight, but the end result came out well. It’s definitely something I will wear when it gets a little colder.
I’ve added lots of knitting project ideas to my ever-growing project list. I want to try combining conductive yarn and Fair Isle knitting to make functional and attractive knit circuits. Of course, there are lots of great non-technical projects in there too, like these Dalek mitts.
Knitting on a train
And, by the way, did you know that knitting is good for your health? Sources say that it is an excellent stress reliever and could possibly have the same effect as meditation. I’ve definitely found myself getting lost in the motions of moving the needles.
I took the Super Mario Clouds class this weekend at NYC Resistor. It was taught by Jonathan Dahan and David Huerta. The goal of the class was to recreate Cory Arcangel’s Super Mario Clouds project. This involved hacking a Super Mario Brothers cartridge to show just the clouds. Here is a video of his finished project:
The first step was to take apart a Super Mario Brothers cartridge. Interestingly enough, the actual board inside was much smaller than the cartridge. The game was divided into two chips: character/sprite data on the left chip and program data on the right chip. Since we were going to use the existing Super Mario sprite data, we only needed to remove the program chip. After carefully desoldering the program chip, we replaced it with a socket and a 27C256 EEPROM.
Next, We talked about how a Nintendo worked. There were some very helpful explanations in the Nerdy Nights Tutorials. The Nintendo uses a custom 6502 processor which has the audio processing built in to the chip. There is a separate picture processing unit used to display graphics. The program ROM is limited to a mere 32 KB, so Nintendo had to do some clever graphics manipulation in order to create a rather seamless side-scrolling experience.
The next step was to download Cory Arcangel’s Super Mario Clouds code. There was quite a bit of software setup required to run and compile the code from scratch. As a word of warning: some of these tools work best in Windows. As I am a Mac user, I used a Windows virtual machine on VirtualBox. To run the code, we used the FCEUX Nintendo emulator. Here is a screenshot of the original code as rendered by the emulator:
But what if we wanted to modify the code? The original Super Mario Clouds code was written in nbasic. To create a new binary, we first had to compile the code with nbasic and then convert it to 6502 assembly with nesasm. Those tools can be found here. Finally, an NES splitter is needed to split the resulting .nes file into .chr and .prg files (for the respective character and program chips).
Once we had the .prg file, it was time to burn our programs to the chip. This was done using an EEPROM programmer. We simply selected the chip type, uploaded our binary and let the programmer software do the rest.
After uploading our programs to the cartridge, it was time for the moment of truth. We plugged our cartridges into an old Nintendo and hoped for the best. Fortunately, most of the cartridges worked on the first try!
This project was a great way to spend an afternoon with my head in the (Super Mario) clouds. Now I really want to create my own Super Mario piece. I never thought I would be so excited to write assembly code…
Today I upgraded my Adafruit Ice Tube clock with a GPS module. The clock is beautiful but I found myself frustrated by having to continually update the time as the clock would slowly get out of sync. Fortunately, there is a handy guide on how to add a GPS module to the clock so that it can readjust the time based on GPS. It only took a few minutes to do the entire upgrade.
For the GPS module, you can use any 5 volt GPS module with 4800 baud TTL NMEA output. I chose the Parallax PMB-648 as it is relatively low cost and fits the specification perfectly. Once you have the GPS, it’s merely a question of disassembling the clock and soldering the GPS to the clock.
The next step is to reprogram the clock with the new firmware. You will need a 6 pin AVR programmer for this. I used Adafruit’s USBtinyISP AVR programmer. Make sure you have AVRDUDE set up correctly. With the correct environment, it is simply an issue of pushing the new firmware that supports GPS timekeeping.
And that’s it. Just reassemble the clock and case and you are done. It was really cool to turn the clock back on and have it automatically adjust to the correct time. Now I don’t have to keep resetting the clock 🙂
This was one of my first Arduino projects. After some near misses with bicyclists while running at night, I decided to get some lights so people could see me in the dark. But why stop at boring plain lights? Wouldn’t it be cool if they could respond to my heart rate?
I looked at a number of existing heart rate sensors for Arduino, but most were optical and could not get accurate readings while I was running since they were constantly being jarred. Since I run with a Garmin GPS watch and heart rate monitor, I tried to hack into the information being sent between the heart rate monitor and the Garmin watch.
Reading a bit more about the technology, I learned that Garmin used the ANT protocol for communication between the watch and heart rate band. The good news was that SparkFun made an ANT transceiver breakout board. The bad news was that the board was discontinued and I could only get my hands on one board. I decided to move forward with this board for prototyping knowing that I would need to come up with a different solution when I made the final project.
The first step was to get the Garmin heart rate monitor and an Arduino communicating with each other. The ANT protocol documents are pretty thorough and they make great bedtime reading. Fortunately for those of us who are impatient, this thread on the SparkFun forums has sample code that already implements the protocol for the Garmin heart rate monitor.
Now that I had the pulse rate information, it was time to add lights. I am a huge fan of Adafruit’s LED strips. These strips have weatherproofing so it would be possible to run outside in the rain. I trimmed the strips to the length of my arms and sealed the ends.
I added seven different light modes which increased in speed with the heart rate: rainbow, raindrop, range pulse, color shot, twinkle, circulatory and Cylon. Most of these modes are self-explanatory. The range pulse mode faded the strips in time with the pulse and also chose the color based on the current pulse rate (blue being low pulse, red being high). Here you can see a quick demo of the seven modes:
I then began building the final version. For this, I chose to use a Teensy 2.0 because of its low price and small size. I also had to revisit the ANT transceiver. Searching around, I found this ANTAP281M5IB module with an on-board antenna. After some very delicate wiring and soldering, this proved to be a direct replacement for the SparkFun board.
Once everything was working, it was time to put this into a portable package for running. The main concern was power. After a bit of research, I found these Energizer power packs that I could plug directly into the Teensy. The one amp power pack would power both LED strips for about an hour. After verifying that everything still worked, I placed the assembled project into a small project box.
The last issue was how to attach the LED strips to my arms. I thought about embedding them into a jacket by sewing them in, but I decided against that as it would be a pain to clean. Finally, I just glued some cable clips to the back of the LED strips and used velcro straps to adjust them for the right fit.
And after all that we were ready to go! My first real-world test was the Midnight Run in Central Park on New Years Eve 2013.
I haven’t posted in a few months because most of my time has been consumed with work and school. With respect to school, I have been taking Statistical Natural Language Processing at New York University. As my final project for this class, I have been working on something which I have been curious about for quite some time – probabilistic postal address elementalization.
What exactly does “postal address elementalization” mean? This is the process of breaking a postal address into tokens and classifying the function of each token, such as house number, street suffix or zip code. For my experiment, I created twelve distinct classes: five for administrative areas (country, state, county, city and neighborhood), one for postal codes and six for street address components (house number, prefix, pre-directional, base street name, post-directional and suffix). An example of an elementalized address is below:
Although this seems like a straightforward problem, it is complicated by the fact that many countries have different languages and address formats. For example, in Ghana and Cameroon, there is no standard postal code system. In the Netherlands and Ireland, there is no province or state in the address. In some countries, such as France and Mexico, the postal code is placed before the city whereas other countries place it after the city. Furthermore, known names of terms in specific classes can overlap, so disambiguating streets can be tricky, like Avenue N in Brooklyn (“N” could be a post-directional or street name) or N Broadway in St. Louis (“St.” could be a suffix or part of a city name).
Traditionally, address elementalization has been implemented by building rule-based systems to handle each individual address format. This makes the process of building international address parsers very time consuming as one would need to implement a new rule-based parser for every single country. By building a statistical model to do this, implementing a new international format is as simple as training the model with a new data set.
Some interesting characteristics of postal addresses are that they have a grammar (as defined by the address format) and the elements are contextually dependent. These traits make the problem well-suited for natural language processing. There are natural language processing techniques that are used for similar purposes, namely part-of-speech taggers which are used to classify the parts of speech in a sentence.
For my final project, I looked at four different techniques of statistical part-of-speech tagging and applied them to the problem of postal address elementalization. The code is here.
The first strategy was a Hidden Markov model (HMM) tagger. HMMs are statistical models that can be used to find the most likely sequence of states for an input. This is done by using transition probabilities (the probability of a specific state given the previous state) and emission probabilities (the probability of the proposed state given the current input token). These probabilities are learned by observing a training set. The model then tries to classify the input left to right, calculating the probability of a proposed state as the product of the transmission probability, emission probability, and maximum probability from the previous state. The model tries different state combinations over the input and returns the sequence of possible states with the highest overall probability. A variation of this is the trigram HMM tagger, which uses the two previous probabilities to calculate the transition probability.
The second strategy was a Maximum-Entropy Markov model (MEMM) tagger. MEMMs are similar to HMMs in that they try to find the sequence of states that has the maximum total probability for an input. However, instead of just using observed counts for the transition and emission probabilities, we train a maximum-entropy distribution to calculate the probabilities. The main advantage of doing this is that we can have custom features factor into the probability, such as the current token length or whether the token contains a number. This allows for greater flexibility in tuning the tagger, but it makes the overall classification time slower.
The third strategy was a Transformation-Based Learning (TBL) tagger, also known as a Brill tagger. The TBL tagger generates rules based on observations in training. These rules indicate observed conditions on when a tag should be swapped with a different tag. During classification, initial tags are assigned to the terms based on the observed probability. The tagger iterates through the rules which were learned in training, swapping tags as necessary, until there are no more rules to be applied or a given score threshold is met.
The fourth strategy was a Conditional Random Field (CRF) tagger. CRFs implement a number of feature functions which take the proposed states and the input observation and return some value between 0 and 1. These features, like the features in MEMMs, can be just about anything, such as whether the current token is capitalized or whether it ends in -ed. Each of these feature functions has a different weight based on observations in training. The score for a sequence of states is calculated by summing the feature functions for every word over all words and then normalizing. Just like HMMs and MEMMs, we find the sequence that maximizes the overall probability.
From my initial work, I found that the Maximum-Entropy Markov model and the Conditional Random Field taggers consistently had the highest overall accuracy of the group. Both consistently had accuracies over 98%, even on partial addresses. For full format American addresses, these taggers had an accuracy around 99.7%. If I had to choose between them, I would go with the Conditional Random Field tagger as it was considerably faster in tagging the addresses.
I didn’t have enough time to finish everything that I wanted to implement, so this is still a work in progress. I still want to implement some smoothing techniques for unknown states, such as Katz backoff and Kneser-Ney interpolation. There are also a few more part-of-speech tagging techniques I would like to experiment with. I guess that old adage is true in this case – time flies when you are having fun… 🙂
Today I took the Making Things Move With Arduino class taught by Ranjit Bhatnagar at NYC Resistor. I was particularly excited for this class as all of my Arduino projects have been rather stationary. This class was a great overview of some different ways to add motion to your Arduino project. It featured the Adafruit motor party pack.
We had five separate gizmos to play with: one DC motor, one stepper motor, two sizes of servos and one solenoid.
Left to right: small servo, large servo, solenoid, DC motor, stepper motor
We also assembled the Adafruit motor shield which simplifies using multiple motors with an Arduino. There was a lot of soldering to do up front but it was worth it! Once everything was assembled, we got to play with all of the different types of motors. We even got to keep the motors so the fun could go on all night long!
What was my favorite part of the class? THE MOTOR PARTY!!! WOOOOH!!!
The first step is to remove the infrared (IR) filter from the camera. I broke my first camera attempting to do this. I was far more careful with my second one and successfully removed the filter. The little blue chip is the IR filter:
This is how the photos look with the IR filter removed:
Kitty is not impressed.
After successfully removing the filter, the next step was to build an IR LED array to be used as a light for the camera. With a little bit of help, I was able to laser cut a perfect array of holes for the LEDs. Following the instructions, I assembled the LED array and turned it on, only to be disappointed by an incredibly dim light.
What went wrong? Here’s the point where I confess that I am relatively new to electronics, and so there are certain lessons that are yet to be learned. I wired the LEDs incorrectly. I got a second batch and wired them together.
And still the array was too dim. It was time to really understand how the circuit of the array worked. There was something more at play here. I found a really cool LED array calculator online that helped me get to the bottom of my problem. I had to examine the LEDs more closely. The instructions use infrared LEDs from Radio Shack, which have a 940 nm wavelength, a 100 mA forward current and a 1.28 volt forward voltage. My first two attempts used LEDs that had a forward voltage of 1.5 volts, which meant that the LEDs were not getting enough power. I ordered a new set of IR LEDs with a lower forward voltage of 1.2 volts and assembled the array for the third time.
The third attempt was better. With the new array, I was able to capture photos in the dark!
I did a little test to get a feel for how well the camera worked. First, I set up a small scene to photograph. I was interested to see how the camera could capture color and detail. Here is the control photo, taken with my normal camera:
First, I took a photo with the lights on. The room was somewhat dark, so the photo did not come out very clear:
Next, I took a photo with the lights off, about one foot away from the objects. The detail was still somewhat clear, although differentiating colors was not really possible.
The second photo was taken from two feet away. At this point, some objects are no longer visible.
The final photo was taken from three feet away. The objects are almost imperceptible at this point.
Although it was fun to build this, it isn’t very practical for real-world use. The major problem seems to be the power, as the 9 volt battery drains very quickly and is not strong enough to power many high-power infrared LEDs. If I go back to this project, the first step would be to build an array with a larger power supply and brighter LEDs. In the interim, I will just have to be content with taking nighttime pictures of things up close.
Recently, I’ve been spending a bit of time with Fritzing. It’s a piece of software that allows you to document prototypes, design circuits and manufacture PCBs. So far, I have only used the breadboard view to generate wiring diagrams for my Arduino and Sensors class, but I am still very impressed.
One of the circuits in my class involves wiring an accelerometer and a switch to an Arduino. Here was my attempt to photograph the circuit:
From the photograph, it’s not very clear on how to wire the accelerometer. There are too many wires in the photograph and it’s not easy to see where each wire terminates. Of course, I could try to recreate this circuit using wires with less slack, but there is a simpler solution – use Fritzing! The image generated by Fritzing makes it much easier to understand how the accelerometer is wired:
It’s fast and simple to generate the wiring diagrams. Fritzing has a bunch of predefined components (such as breadboards, switches, resistors and Arduinos) that you can drag and drop together. There’s also a great snap-to-grid functionality that ensures that components are connected. Fritzing allows you to import component libraries from other vendors so that you can prototype with correct representations of the components. For example, the accelerometer object comes from the Adafruit Fritzing library.
I’m really glad to see that there are excellent open-source tools available for this kind of thing. It makes sharing knowledge much easier. I’m already impressed by the breadboarding functionality, so I am looking forward to tinkering with the schematic and PCB views!
