Process

Interactive Floor Projection

For our final project for Physical Computing, Yin Ho and I created an interactive floor projection that seeks to activate everyday space by playing with perception.

To do this, we combined a Processing sketch of shifting floorboards with camera tracking to identify a person’s location on the sketch. This was a departure from our initial inclination to build a series of pressure sensors to lay on the floor in a grid pattern. Camera tracking allows us to project directly onto the surface of whatever space we’re working in and removes the limitations of resolution inherent in discrete sensor values.

Computer vision, as we came to realize, is quite a broad field of study and getting an accurate reading of a figure moving across an animation proved rather difficult. We considered motion tracking, color tracking, and infrared tracking before finally settling on a form of brightness tracking that was, in the end, jittery and not very accurate. So our presentation consisted of two iterations of the project: the first, pictured above, which is controlled manually with a mouse, and another that incorporates a webcam and our first attempt at computer vision.

I hope to explore this area of research further in order to develop an interactive experience suitable for deployment in public space.

Animated Space

For our third and final project in Physical Computing, my partner and I are developing a functional scale model of a floor system for video projection. The idea is relatively straightforward: using homemade pressure sensors to detect when and where someone is standing in a room, a video animation appears on/around that space.

The resolution of our floor will be 5 x 4—twenty squares within which the animation will occur. Instead of purchasing twenty force sensitive resistors, we’re building switches with wire mesh and foam. The wires are attached to separate sheets of aluminum mesh and spaced apart by 1/8″ strips of foam. With pressure applied, the two sheets come in contact, completing the circuit.

Working at a scale 1/4th actual size, each tile will measure 4.5″ x 4.5″ for a total floor size of 7.5′ x 6′.

New York Sound Controller

The second of three projects that occupy the semester in Physical Computing, New York Sound Controller: Quartet for Accelerometer Pods was an attempt to conduct the sounds of an urban environment. Our desire was to give the performer control over the volume of different field recordings sampled from around Manhattan by maneuvering discrete metal pods.

We traveled around the city, gathering sounds as they met us—train traffic, pedestrians, water, Grand Central Station, ATM buttons, construction. Many of these form the backdrop of our daily commute. Using a shotgun microphone, we sought to isolate disparate elements of urban cacophony in order to designate each to an accelerometer pod. Afterward, field recordings were combed through and pared down to twelve of the most interesting samples.

The project was then broken up into three stages of development: sound editing, programming, and pod construction. We drilled holes in a set of spice tins suitable for the pod housing. Code was worked out in Arduino for the motion of the pods and in Processing to control sound with the help of the Minim library. Wires in an ethernet cable connected an Arduino Mega to the accelerometer boards. We also formed small pucks out of blue foam for the accelerometers to rest in inside the pods.

While our project was functional and had some of the qualities we had envisioned in the early stages, the accelerometers proved difficult to draw consistent readings from. As such, the motion of raising the volume and lowering it was much more jerky than we wanted. Additionally, the LEDs were intended to brighten and dim in accordance with volume levels and, due to time constraints, we fell back on a less functional blinking pattern. I’m ambivalent about the future of this project in its current form. Still, there was a lot we learned along the way and potential to revisit the concept.

Full Height Turnstile: Some Observations

Entering the 8th St–New York University subway station just south of Astor Place on Broadway, commuters must pass through a full height turnstile in order to reach the platform. The process involves, first, swiping your MetroCard through the card reader, situated to a person’s right, approximately three feet from the ground. The gate will then give you a high pitched tone and, if your card is read correctly and you have sufficient fare, a green light indicating that it’s OK to proceed through the turnstile. The interior metal spokes can then be pushed to rotate 120°, allowing one person through at a time.

I wanted to observe how people interact with this gate as it’s one I use on a regular basis and the experience varies. Obviously, one advantage to the system is that it allows for more points of entry into a station without requiring station attendants to watch for turnstile jumpers (although, pairs do occasionally squeeze through the full height turnstile together). So I spent some time watching people move through the turnstile, noting the rate of success and any recurring issues that arose. I was surprised to find that roughly nine out of ten people move through the gate in one sequence of motion. That feels like a better success rate than my own. Only one person was wrongly turned away by a turnstile rotation that ended before enough clearance was established to pass through. The rest either needed to swipe their MetroCard again, or the card was expired or had insufficient fare.

Easily the most common problem was the system’s way of communicating whether or not the card swipe is approved. There are two reasons for this, related to the system’s two forms of feedback: a tone and a green, backlit sign. The first is that, even with careful listening, it’s very difficult to distinguish between the tone of an accepted swipe and that of a rejected one. Both are exactly the same pitch and seem to be differentiated only by how many times the beep repeats—a subtlety completely obscured by the reverb of the space. Thus, the beep serves only to confirm that the card has been swiped, nothing more. You’d think that, at least for those who aren’t blind, this would be compensated for by the green “Go” sign that lights up when your card swipe is validated. I find, though, that its position is a bit too far forward in the motion of moving through the gate. As a result, people are often beyond the sign by the time they realize they need to swipe their card again, requiring them to walk back two or three steps and try again. This is how backups tend to occur at the entrance.

I would propose establishing two distinct pitches and shifting the placement of the “Go” light. This would allow for clearer interaction and speed the flow of commuter traffic through the turnstile. Ideally, the whole system would be unnecessary because people would simply pay trustworthily. It would be interesting, though, to study how many do if the gate were scaled down.

Tone Output

Connected to a speaker, Arduino puts out a weak audio signal unless you use a wave shield or run the audio off your computer. We’re doing the latter through Processing’s Minim library for a media controller group project. I’m interested in the potential of bringing multiple small speakers into an installation environment. Check out Peter Vogel’s work as one example.