Gian Pablo @ ITP

Two pieces that I worked on have made it into the ITP Winter Show! It is usually quite rare for works from introductory classes to make it in, but at the last minute they made it.

The two projects are "Action At A Distance" (wireless lamps), and "Turing Machine", with Ruth Sergel, an interactive documentary about the life of Alan Turing.

Of course, this means the semester isn't quite over, as both projects need last minute tweaks.

Do check out the show in person, if you can come, and if not, enjoy browsing the project database.

Posted by Gian Pablo at 09:47 AM | Permalink | Comments (2) | TrackBacks (0)

Here is my final project for Comm Lab: a panoramic view of the street where I live.

Click on the image for the full resolution version (big!)

Read after the link for more info on how I put it together.

Here is how I built the panorama:

I used a very wide-angle lens (12mm focal length) on a Nikon D50, and took pictures from across the street, at measured intervals. I used a bubble level on the camera to keep it approximately straight, though this didn't work 100%.

I then brought the pictures into Photoshop one at a time, and used the PTLens plugin to compensate for the effects of lens distortion. (Curved lines that should be straight). However, there was still a massive perspective effect. Click here for one of the source images.

I used the Photoshop Lens Distortion Correction tool to compensate for this, appearing to tilt the buildings forward. Here is an example after doing this.

I then had to assemble all the images into a single document. I imported each photo into a separate layer in photoshop, and then stretched/shrank it so that it matched the previous photograph. Of course, the perspectives are quite different, so this was often quite difficult.

The current version was exported at this point. I am still working on adding an adjustment layer to each photo, this will let me fine-tune the border between adjacent photos by having a smooth blend.

Posted by Gian Pablo at 06:53 PM | Permalink | Comments (0) | TrackBacks (0)

Working with Ruth Sergel on this project, an interactive documentary about Alan Turing built using the Processing programming environment.

Alan Turing was one of the pioneers of computer science, hence using a computer program to tell his (tragic) story is particularly appropriate. However, writing a computer program to tell story is quite awkward, compared to editing a video or using an authoring environment, so it makes sense to make the most of the limitations.

Therefore, the project makes ample reference to concepts of code and encryption, the underlying algorithms are a simple Turing Machine, and even the source code is displayed and used to share facts about Turing.

The physical interface, which Ruth is working on, uses a partially dismantled typewriter. The idea is to provide something of the look and feel of the Enigma encryption machines, whose codes were cracked by Turing.

Read past the link for more info on implementation...

This was a complicated project!

Processing is not really suited for interactive storytelling, with distinct "scenes". We ended up controlling program flow with a main case-switch, keeping track of which scene is active in a single variable.

Most of the debugging effort went into two areas:

1) The Sonia sound libraries
2) Dealing with the effects of interrupt-driven background routines

The Sonia libraries eventually turned out to be quite easy to work with, but there were a couple of major trouble areas. One is that you cannot create any of the Sonia classes until the Sonia library is actually started. It's not enough to load the library, the library has to actually be running for you to create audio classes. The error message returned is something really weird about file names. The second area of trouble was with playing multiple consecutive sounds, ie. stopping the currently playing sound before playing the next. This required very elaborate tracking of play states, in order to recall which is currently playing in order to stop it.

The second trouble area was that we were using movie playback and video capture routines, both of which rely on a background event handler. However, some of the major flow control variables were affected by these, which meant that the program could change states unexpectedly. It was very difficult to trace this back to the continuing execution of the background routines.

The short-term solution was to make sure that any background routines were stopped when not needed. The longer term solution is to ensure that all the major flow-control events happen in the main loop, not in background routines.

I suspect the program could be simplified further by making better use of object-oriented programming.

Posted by Gian Pablo at 04:45 PM | Permalink | Comments (1) | TrackBacks (0)

"Action at a Distance" is my final project for the Physical Computing class.

It consists of four separate lamps, lit with multicolor LEDs, that display the same pattern of lights in response to gestures, no matter how widely separated. (Well, within radio range).

What do I like about the project?

* Gesture control of the lamps is fun, especially since the response is immediate.
* The instant synchronization of the lamps, all separated, is attractive and engaging.
* It's attractive - I would not mind having it in my house. (This was actually a primary design goal)

Click on the thumbnails below to see pictures of the lamps on display:

Read past the link for more detailed information, including links to related posts:

The project was inspired by my midterm project, a gesture sensitive lamp for attracting attention in restaurants. I realized that project was more interesting for the interaction, than for the practical application.

I defined the project as a cluster of intelligent lamps, where the big step forward would be using radios to synchronize the lamps.

In order to drive the multicolor LEDs without using all the outputs on the microcontroller, I used AD5206 digital potentiometers.

Radio communications was handled with Zigbee radios from Maxtream. There were some challenges involved in using them, but with Rob Faludi's invaluable help, I was able to get everything running well.

A key part of the project was defining a simple protocol for lamp communications. Since I had not finalized my design for the interactions, the protocol is more general than it needs to be. In the end, I only used the commands related to lighting lamps, signalling that a lamp has turned on (and needs to be synchronized) and for reporting status.

Physical construction was straighforward. I used white foamcore in the interests of time, though in future I will rebuild the lamps with plexiglass. The most time-consuming part of assembly was building the wiring harnesses for the sensors and the LEDs, which involved a lot of delicate soldering work. The end result looks OK, and setting up the LEDs to reflect against a white background gives a nice diffuse effect.

As of this writing, the lamps have been functioning continuously for over 24 hours, so the code seems reliable. I notice occasional glitches probably due to the loss of data sent over wireless.

Future plans for the lamps:

* Rebuild in plexiglass
* Adaptive behaviour to lack of activity
* Better display routine
* More complete implementation of gesture processing

Posted by Gian Pablo at 11:58 AM | Permalink | Comments (1) | TrackBacks (0)

All four lamps are finished, and working!

Gestures in front of any lamp affect all the lamps. The lamps all show the same display, but it depends on which lamp generated the triggering event.

For those of you new to the project: the concept is "action at a distance", the lamps all react in unison regardless of distance (well, within a few hundred meters). Technically, quite complex: uses AD5206 digipots, Zigbee radios and Arduino minis, all held together with some elaborate software.

I am quite pleased with how it works, but can already think of a few improvements:

* Full state machine implementation
* Individual addressability
* Better discovery routine
* Time out routine
* Fading between LED settings

More info after the link...

Here is a picture of the electronics.

From top to bottom, two AD5206 digital potentiometers, the Arduino microcontroller, and the Zigbee radio. At the very bottom the 5V regulator for the Arduino and the 3.3V regulator for the Zigbee.

The casing is a pencil box from the Container Store on 18th and 6th.

Posted by Gian Pablo at 10:30 PM | Permalink | Comments (0) | TrackBacks (0)

Another lamp built - two to go!

Today's lessons:

* Important: a Zigbee needs to hear a "wakeup" character (any character) to start sending. So before doing anything else, send it something, like a carriage return, or an "X".
* Also important: when putting the Zigbee into command mode, instead of setting the guard time to 1000 msec exactly, make it 1100 msec, before sending the "+++" command. 1000 msec is too exact, and sometimes does not trigger correctly.
* When two Zigbee radios try to talk at once, neither one is heard.
* Power matters. Voltage, amperage, etc. need to be taken into account.
* If it isn't broken...

Posted by Gian Pablo at 08:26 PM | Permalink | Comments (0) | TrackBacks (0)

For my final project, I am using the Zigbee radios all in broadcast mode, ie. all of them are transmitting to destination FFFF, so that all the radios in the network can listen at once.

This is useful for debugging (I can "listen" using a Zigbee and a laptop) and for simplifying the code.

However, it creates a problem: whenever the lamps receive a message, they send out an acknowledgement and a status report. If this report contains the letter "L", then the other Zigbees interpret it as a command, and send out their status reports.

So every command leads to a flurry of radio communications, and I guess some messages are lost or delayed.

Easy to fix, by forcing the lamps to ignore any line that doesn't start with an "L", but nevertheless something to keep in mind.

Posted by Gian Pablo at 09:14 AM | Permalink | Comments (0) | TrackBacks (0)

Some progress: I have completed physical assembly of the first lamp, and learned a lot in the process.

The lamp is shown below, with the LEDs lit in red, yellow, green and white.

Read past the link for more thoughts and observations.

Based on experience with the midterm project, I ran a power and ground "bus" the vertical length of the lamp, for the sensors and the LEDs to tap into. This will make things a lot simpler when actually wiring.

However - this means you have to be careful when making some of the cable joints (twisting wires together and soldering), since the LED pins are quite close together, and short easily. This is turning out to be a major problem for me, and manifests as sudden, erratic flickering of the LEDs.

I have also found that the extra resistance of the wires (and possibly the crappy solder splices) changes the behavior of the AD5206 digipot. The LEDs are dimmer, and respond differently to variable voltage. There seems to be a big "step" in their response curve, after which they become much dimmer suddenly.

I have also noticed that when there is a short in any of the LEDs, the behavior of the of the other leads connected to the digipots becomes quite strange.

Todd pointed out that since I am using the 50k ohm part, this is to be expected. At full brightness, it will perform like the 10k ohm part, but at half brightness, the greatly increased resistance will make them much dimmer. I will have to compensate in software for this, and but will end up with fewer usable brightness values.

Posted by Gian Pablo at 05:54 PM | Permalink | Comments (0) | TrackBacks (0)