!blog - corey menscher

My entry in the 2008 ITP Spring Show is titled The Naked Pixel. It is a ColorKinetics iColor Tile that displays individual pixels of a nude photograph of Marilyn Monroe sequentially over time. Using a light sensor, the piece detects when the lights go out and further “undresses” each pixel’s color into its binary value by displaying a sequence of ones and zeroes. The intention is to convert a still image into an animated sequence of pixels. This changes our perception of the image by limiting the stream of optical information from a parallel format (all pixels at once) to a serial format (each pixel individually). Our visual system is incapable of parsing this information, which fundamentally changes the character of the image. Our experience of the still image becomes entirely new, even though the content of the image remains.

For more information, check out my Naked Pixel page.

During the Winter Show, instead of printing cards for my project I offered to send people SMS messages with information about it.  It was a manual process, though, requiring me to send the message template from my phone.  For the Spring Show, however, I’ve created a slightly better service that everyone can use.

The service is simple.  It pulls the project information from the ITP Project Database via an RSS feed and returns a text message with the project title, associated student names, and the project’s link.  The information is automatically shortened by limiting the title to 30 characters, replacing full names with first initial+last name, and using http://is.gd to make a small URl.  Additionally, a user can pass her email address, and an HTML e-mail is sent with a lot more information.  It’s built upon the ITPedia service from which I host the ITP directory search I released earlier in the year.  A user simply texts the projectID to the Textmarks service (41411) like this:

itpedia spring08 XXXX [email@address.com]

(Remember, the email address is only required if they want to get an email back.)

For example, you can retrieve information about my project by texting “itpedia spring08 1988″ or “itpedia spring08 1988 your_email@address.com” to 41411.  To get YOUR project ID, simply login to the Projects Database (https://itp.nyu.edu/projects/) and select the desired project from the left.  You’ll see your project page, but more importantly, you’ll find the project ID in the URL after “project_id=”.  For example, my project page is “https://itp.nyu.edu/projects/projectinfo.php?project_id=1988″, so my project ID is “1988″.

If anyone in the show wants to use the service, all you have to do is instruct people to send the text. That way they can tag your project for later, and you won’t have to worry about printing up a bunch of cards.

Pilotwiings: Reality is my final project for Networked Objects. The goal of the project is to provide an alternate control mechanism for flying an indoor remote-controlled airplane using the accelerometers and buttons of a Wii remote. The wiimote connects to a computer over bluetooth, and its accelerometer values and buttons presses are captured by a custom Processing application (using the WRJ4P5 library) . This application then sends a series of digits as an encapsulated message to an Arduino over USB. The Arduino parses the message and flashes a series of IR emitters to control the plane.

Throttle is controlled by tilting the wiimote up and down, and turning is accomplished by rotating it let and right. Additionally, the wiimote button “A” cuts the throttle off, while the trigger button “B” bring the throttle to full. (To see a video of the UI of the Processing app in action, see my previous post.

The largest challenge by far has been hacking the Palm Z’s infrared control protocol. The Palm Z controller emits a series of pulsed IR light to communicate with the plane. By researching and talking to other R/C hackers, I determined that the Palm Z uses a 17-bit “message” comprised of the following:

Message Format: SS ChCh ThThTh RuRuRu TrTr ChkChkChkChk St

SS = Start Bit

Ch = Channel declaration

Th = Throttle value (0 - 15)

Ru = Rudder value = (0 - 7)

Tr = Rudder trim value

Chk = Checksum

St = Stop Bit
Example:

“SS001110000001110” = Channel A, Full Throttle, No Rudder/Trim

There are three “channels” defined by a 175, 130, 100ms delay between each “message”. However, I was unable to determine the exact timing for each bit value. For example, the developer I spoke to claimed that a “true” bit was represented by the IR emitter being on for 7ms and off 6ms, and a “false” bit was represented by the IR emitter being on for 13ms and off for 11ms. However, when I attempted to measure the values myself, I found this to definitely not be the case. Unfortunately, when I used an oscilloscope I was unable to determine the exact timings myself (they tended to vary across messages), so I will need to do more research to get it to work. This may include contacting the manufacturer.

I ran into issues getting the Arudino to flash the IR emitter with the proper timings.  I would often find that the IR emitters would either flash too quickly or slowly for the desired bit.  This may be alleviated by optimizing the code.

HelioHopper is a small helicopter whose short “hopping” style of flight is powered by solar energy.  It was developed with Oscar Torres, Theresa Ling, Drew Burrows, and myself.

HelioHopper’s goal is to educate an audience of the abundance of ambient solar energy in our environment. Multiple HelioHoppers, made of flexible solar panels, small batteries, and counter-rotating blades, are scattered in a field. As sunlight falls upon their solar panels they gather enough energy to take a short flight, emulating grasshoppers. The frequency of hops is directly proportional to the amount of sunlight available to the HelioHoppers…providing a physical representation of available ambient energy. Seeing multiple HelioHoppers jumping randomly as their energy requirement is met will hopefully inspire viewers to consider the availability of solar energy, as well as the futility of creating energy-harvesting objects that serve no other purpose.

Once the energy is depleted, the HelioHopper’s solar panels begin to harvest ambient solar energy to allow further flight. We wanted to demonstrate the abundance of energy available, as well as the concept of “The Paradox of Efficiency”. This paradox states that as we increase our energy efficiency…in this case harnessing the available solar energy…we find more uses for the energy, which negates any savings. HelioHoppers were created by the mere fact that we CAN harness the solar energy andimplement existing parts (batteries, plastic, motors) in a way not previously executed.

The frequency of hops can also be related to the amount of solar energy available. Similar to cricket chirp frequency being related to the temperature outdoors (http://www.loc.gov/rr/scitech/mysteries/cricket.html), the HelioHoppers will take flight as sunlight intensifies.

We used a small remote-controlled indoor toy helicopter as a platform for developing HelioHopper.

We created our own circuit for harvesting solar energy and storing it in a small lithium-polymer battery, with the intention of releasing enough energy to propel the HelioHopper into the air so it can fly a short distance. The solar energy is collected by 4 5.5V flexible solar panels, which are quite light. To release the energy, our original intention was to base the circuit on a 1381 Miller Solar Engine based (using 1381N 3.7V voltage trigger), but there were a number of unforseen problems.

The biggest problem with using this circuit was that we used a small 3.7V 20mAh (20C) LiPoly battery. Due to the nature of lithium polymer batteries, they can not (or rather should not) be discharged more than 1v or so. This meant that we needed the circuit to come on at 3.7V, but turn off again around 2.7V. The circuit we attempted to use, however, wanted to drain the battery completely because it was designed for capacitor energy storage. We attempted to circumvent this problem by using an additional 1381L 3.4V voltage trigger, but we later found out that the 1381 voltage triggers actually flip on when ANY voltage above their threshold is provided. We thought the trigger would only work within its 3.0V to 3.3V range, but we were wrong. This led to us moving to a 555N timer IC. The 1381N was used to trigger the 555 timer, which was configured to turn on a transistor for a 10 second period, giving us a 10 second flight. This is theoretically better for the battery as well, as the 10 second duration kept battery discharge well within it’s 1V range.

Unfortunately, the 3906 transistor we used to turn on the motors was not capable of driving them with enough current. It tops out at around 200ma and we needed more like 600ma for sustained flight. This was solved by using a TIP120 transistor, which can pull over 1A. The TIP120, however, is a very large component with a metal heatsink. Having to use it immediately killed the possibility that our prototype would fly with the circuit onboard.