Super Mario Clouds

Super Mario CloudsI 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.

Disassembled SMBNext, 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.

IMG_9491The 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:

clouds-3But 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.

ProgrammerAfter 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!

Nintendo hackThis 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…

GPS Clock Upgrade

Ice Tube ClockToday 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.

Clock and GPSFor 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.

Solder TimeThe 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.

IMG_9030And 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 :)

Pulse Jacket

led_image_2 01This 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.

Microcontroller with ANT breakout boardNow 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.

Microcontroller with lightsI 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.

IMG_8863 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.

IMG_8862The 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.

Assembling the arm supportsAssembled JacketAnd 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.

New Years Eve - 2013New Years Eve - 2013And now I can easily be seen in the dark!

Probabilistic Postal Address Elementalization

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:

address_elementalizationAlthough 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…  :)

Arduino and Motion

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.

Motors
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!

Arduino and Motors

What was my favorite part of the class? THE MOTOR PARTY!!! WOOOOH!!!

Miscellany by Miria Grunick