Special thanks to Caleb Clark, Anh Nyugen, and Rucyl Mills for their awesome work in filming the Secret Tree.
March 24th, 2007. New York City.
Episode 4: 4 minutes
Wherein we take at Michael, Aichen and Sun's Physical Computing project "Secret Tree.
They have more episodes at http://techtrek.tv
Ai-Chen and I did a bit of rewiring on the Secret Tree circuit board. One of the problems we had last week was that all of the ground wires for the LEDs on the trees were connected to two PCB terminals. I didn't purchase enough terminal at RadioShack so that every pair could have a ground of its own. This not only made things messy, but it also made the connections suspect.
The other major discovery I made which explained much of the circuit's random (unintended) behavior was that the two AD5206 chips interfered with one another. I plugged a single LED into each of the twelve outputs (across the two chips) and found that a simple test program didn't operate properly when both chips were running. As soon as I disconnected the three data lines (CLK, SDI, and CS) from the second chip, the first chip would work properly. I wondered if there might be some sort of "floating" condition when the two chips were used together. Since CLK and SDI were shared, I hypothesized that CS was likely the culprate. To test this, I added 10K pull-down resistors on the chip selects of both chips. It worked! The test program dimmed the lights in the proper sequence rather than skipping around randomly on the third and fourth outputs.
- Continued construction using the perfboard/shrink tubing sensor package and finished two shoe prototypes
- User Test - Patricia (using foamboard prototype + Korg synth module)
- Felt that more sensitivity was needed. She found it difficult to trigger the samples without stomping really hard
- Didn't like bass drum on the heel; felt it would be more natural on the front
- Cannot tell where the sensor is -- perception is that it is close to the center of the shoe
- Feels the system is more responsive with the 10k resistor than with the 2k
- Could play either sitting or standing
- Would like to play along with some other music
Lisa, Hatti, and I are in the planning (some might say "requirements gathering") stage of our Physical Computing midterm project.
We have been brainstorming and brainstorming more, but haven't committed to an idea yet.
The Interaction:
The driver for Community Lines operates the controls in the cockpit of the Gate 51 minibus.
Setting:
The Gate 51 Bus which I ride to the Port Authority Bus Terminal
Physical Orientation:
The driver is seated
Background:
Each minibus has a personality of its own. The whole fleet of them is a motley crew -- inside and out. I do not know who decorates these vehicles (whether the driver or a separate interior designer). They are not as colorful as I have heard their counterparts in India are, but nevertheless each seems optimized for the comfort and personality of the driver.
My Assumptions:
I assumed (and hoped) that the bus driver would pay attention to the road and traffic rather adjusting the many controls within his reach.
Quick Sketch of the Interaction Area:
- The areas of greatest activity were the steering wheel and the passenger door handle.
- While driving in New Jersey prior to entering the Lincoln Tunnel, the driver rested his right hand on the passenger door handle. He frequently opened and closed the door to allow passengers to enter and exit the bus. His right hand remained on the steering wheel except when he was counting money.
- A metal plate above the passenger door handle prevented it from opening unexpectedly. This locking mechanism required the driver to bend his hand forward so he could release the catch with his thumb before opening the door by swinging his arm out away from his body and towards the passenger door. This motion was very fluid.
- As riders exited the bus, the driver collected their money and inserted it into the slot between the air conditioning vent and the vent's trim ring. To secure the dollar bills there, he pushed in the right side of the vent so it squashed the money against the trim ring. This is an innovation I had not seen on other bus trips.
- I could not perceive that the driver payed any attention to the engine monitor. He neither looked at it nor pressed any of the buttons on it. I had wondered on an earlier trip what the device was and spent most of the ride trying to figure out the pattern of the numbers on its display. Neither the engine monitor nor the lighting control panel appeared to be part of the original equipment of the minibus. Both appeared to have been bolted onto the dashboard after the vehicle had been purchased.
- Unlike other buses I have ridden, this one did not contain a radio. The trip was quite quiet except for the occassional bleep from the driver's cell phone. I believe he stored his cell phone somewhere along the door to his right. After we exited the Lincoln Tunnel in Manhattan, he picked up the phone after it bleeped at him.
- Having read CH 1 of the Design of Everyday Things (Norman), I was mindful of the design of the climate controls in the minibus. Even from a distance, it was clear where the controls were set: the knob was molded in the shape of a pointer which indicated the current setting.
I tried my first series of observations during my morning commute to ITP on September 14. After our discussion of the observation assignment in class on 9/20, I discovered I had been going about the observations incorrectly. The focus was supposed to be observation -- not interpretations.
Here is what I saw during my observations
- 2 iPods
- 1 mobile device user browsing emails
- one tablet PC user (me) observing others
- EZ pass readers wirelessly collecting tolls from cars, trucks, buses going into the Lincoln tunnel -- this is transparent technology
- GPS system in a Lexus SUV
- cell phones on the bus (making calls, playing games)
- many cell phone users in cars holding their phones and talking
- Toll-taker at the Lincoln Tunnel toll plaza grooving to his iPod
Once in Manhattan and on the A train, I encountered many more iPods and other personal audio devices: almost half of the riders were wearing earbuds of some sort.
It seemed that everyone was isolated from everyone else.
One lady who boarded the train after me thumbed her Blackberry nervously for about 3 minutes.
... and in fact it should be noted that I found a soldering problem on the little board I salvaged. Apparently when I rewired it, I knocked one of the circuit traces loose, which prevented the upper right switch from working. This caused me much consternation while trying to develop the catching algorithm. Thankfully Serial.println helped me figure things out.
I modified my program to use the upper left switch for both throwing and catching. Maybe it's not so interactive anymore, but it's done and I have other things like Spatial Design homework to do.
If you like to read source code, you can do so in the full entry.
I'm working on a game of catch as my first self-chosen project in Physical Computing.
The idea is simple: two players throw a ball (represented by moving LED) back and forth. The thrower controls the speed by the amount of time he takes to release SW 1 after pressing it. To catch the ball, the second player, must press his button exactly when the ball reaches him.
The implementation is not as simple: it appears that I may need to draw a state diagram. The schematic isn't complex, but I have a feeling that the code will be.
For now, I will keep my goals simple.
1. Test out a throwing algorithm (done). I've already made the "ball" move and at varying speeds
2. Make SW1 trigger the throwing algorithm
3. Work out a catching algorithm
In order to get my salvaged switches working, I visually inspected the circuit traces and then poked around measuring continuity until I found the pairs that matched.
