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

My PilotWiings: Reality project’s interface is complete. It displays the wiimote orientation and control settings for the PalmZ. Flight commands will be transmitted via serial communication to an Arduino microcontroller that will interpret the controls and translate them to the 17 bit IR messages that the PalmZ expects. It will then broadcast the commands via an array of IR LEDs, allowing the PalmZ to be flown via wiimote!

Blip.TV Link

I used to read Melissa Havergal’s other socialite blog before she had to shut it down, but now she has a new one.  Kinda fun.

http://sociallifeny.blogspot.com/

MoMa currently has a great design+tech exhibit going on called Design and the Elastic Mind. There are a vast array of projects on display covering subjects such as sustainable practices, sustainable energy, nanotechnology, data visualization, and physical computing.

Of course, you can always come to the NYU Interactive Telecommunications Program’s (ITP) 2008 Spring Show to get a dose of other design+tech projects ! You may even find a project of mine at the show…

On Aspen Mountain, there area a number of “shrines” dedicated to fallen musicians…Elvis Presley, Jerry Garcia, John Denver, and even Liberachi. (view a panorama here.) The shrines are not well known or clearly marked. Usually a local has to show you the location, unless you sumble upon one while skiing through the trees. The shrines consist of memorabilia to the musician as well as a quiet place to sit and contemplate the musician’s life. The Jerry Garcia shrine is one of my favorite places to take a break on the mountain, and I always wanted to leave something behind. Instead of leaving a photo, ticket stub, or some other type of physical object, I decided that I would leave the actual MUSIC. Thus, the jerryPlayer was born!

jerryPlayer is a crank-powered audio amplifier. The original intention was to include a 1.5V mp3 player as well to create a self-sustained solution, but I had many problems hacking an existing MP3 player to work, which I’ll discussin a moment. The player is powered by a hand-cranked dynamo that can generate a max 12V at 500mA (short circuit current). The energy is stored in a 1F 11V capacitor. Here’s the energy data:

Measured Open Circuit Voltage (V): 12V
Measured Short Circuit Current (mA): 500mA
Target Capacitor Capacitance: 1F
Target Capacitor Charged Voltage (V): 11V
Target Capacitor Total Energy (Joules): 72J
Time to Charge (seconds): 63 seconds
Observed Power (Watts): 1.142W

The dynamo was taken from a LED bicycle light and hacked for my purposes. The unit came with a small power conditioning board that included a bridge rectifier chip (to allow the crank to be turned in either direction) as well as a capacitor to smooth the current. This was then connected to an LM386 amplifier, which needs a minimum of 6V. This amplifier is a simple one, but provides a good amount of power for the few feet of space I want to fill. The output will eventually be connected to a waterproof speaker to sit outside the housing, but for now it’s conneced to a 3″ speaker. When fully charged, the amplifier provides a decent audio signal for about three and a half minutes until it cuts out. This is actually better than I expected, and will provide a nice “snippet” of music for the shrine…encouraging people to hear a small portion and then move on. (I don’t want people to necessarily hang out for an extended period…although they could keep the player going with a few turns of the crank every few seconds.)

The amplifier’s input was connected to an iPod Shuffle to provide audio for the presentation, but I intend to use the the capacitor to power a 1.5V or 3.3V mp3 player in the final version. This will presumably reduce the amount of playback time, but from my tests it should only reduce it by a minute or so. I rendered four Coby 128mb mp3 players I bought at a Super Value store inoperable in my tests. They worked for a short while, but eventually died. I think this may be due to excessive current, although they are extremely low quality players and could just be very touchy about the condition of the power they are given. (I was using an LM317 variable voltage regulator, which supposedly provides relatively “dirty” current.) They would not have been a good solution anyway because their interaction requires that a user hold down a play button to power the device, and then hit the play button again to start playing. This could have been achieved though an external momentary switch, but I would prefer the player to begin playing when it is powered, so I will probably be using the Sakura DIY mp3 player for the final product.

For our “sensor” assignment, we were required to either record sensor readings to a web-based database or we could read information from a web service and represent it in a physical computing object. My partner Estee Wah and I decided to do the latter by grabbing traffic “incident” information for NYC and representing the current status in a unique way. We made a poster that depicts a road running to the horizon, with a cityscape in the distance.

Each of the four road lines are three dimensional translucent paper with a white LED behind them. The LEDs are then flashed in sequence to simulate movement (via an Arduino). As the number of traffic incidents increases, the delay between the LEDs flashing increases, slowing the perceived movement…as if one is in slow traffic.

Roady is programmed by grabbing a single <incident> tag from a PHP script that gathers XML traffic data via a customized RSS fee from Yahoo. Each <litem> node that Yahoo returns is one incident, so we simply count the number of items to get our traffic scaling factor.

Our first XPort assignment was to create a physical client for a networked Pong game. Anything would work as long as you could make the virtual paddle move left and right. My idea was to use a urinal, to allow players to urinate on two sensors to move left or right. (Yes it’s been done before.) I found a kids “training” urinal, which made for an easy-to–hack controller. My original intention was to use force-sensitive resistors (FSR’s) to trigger left/right movement, and they worked well in testing. However, I was unable to complete a working controller. Here’s what I learned:

• FSR’s are extremely fragile (I broke four and ran out of replacements)
• You can’t use the terminal “screen” command to listen in on serial communication between an Arduino and an XPort. If you do, the commands will never be received by the XPort!
• Vinyl tape stuck to plastic is not particularly watertight.