learning the ropes

things I made at ITP and after: sketches, prototypes, and other documentation

Monday, October 16, 2006

(notes from Lisa)
Making a really robust flex sensor and a package to contain it.
The task at hand is how to house the sensors so that the “tail” will
be protected, and still function.
We start using a perf board, then put heat shrink tubing on the
sensors in order to that the contacts were secured.

We are looking to cut a hole out of the lucite blocks.
The idea is to make a channel through it to protect the top of the
sensor from being stamped and stepped and stomped on.
So we attach the female header to the perf. board, and solder it on.

I don’t like that I can’t make a clean square cut with the dremmel
tool on the lucite-housing.

posted by Michael at 10:53 pm  

Tuesday, October 3, 2006

Midterm Project – Phase 1

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.

posted by Michael at 9:46 pm  

Wednesday, September 27, 2006

Observation Assignment – Part 2

The Interaction:
The driver for Community Lines operates the controls in the cockpit of the Gate 51 minibus.

The Gate 51 Bus which I ride to the Port Authority Bus Terminal

Physical Orientation:
The driver is seated

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:
minibus observation

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

posted by Michael at 12:54 am  

Monday, September 25, 2006

Lab 2 – Analog Inputs (part 2)

When considering what to do for the creative part of my Physical Computing lab, I initially thought of some sort of mood-proclaiming piece of clothing.

Instead of using a flex or pressure sensor to light up the LEDs on a “luv-o-meter,” I wanted to prototype a display for a t-shirt that could display a short and partially encrypted message about the wearer’s stress level. I remember seeing a persistence of vision project on one of my first trips to ITP (perhaps it was the winter show?) and thought I might be able to make a single column of LEDs light up and scroll the message past.

Using only a slightly modified version of the circuit from my game of catch, I set about drafting some code to drive a vertical array of 5 LEDs.


posted by Michael at 11:12 pm  

Monday, September 25, 2006

Lab 2 – Analog Inputs (part 1)

LAB 3 - Pulse Width Modulation

In addition to the adjustable LED level suggested in the lab notes, I decided to program the Arduino board to gradually fade the LED level down from the level set by the potentiometer. Last week when I was working on my game of catch I wanted to have the first LED gently fade in and out during the “wind-up” phase of the throw. This week, I figured out how to do it.


posted by Michael at 10:56 pm  

Thursday, September 21, 2006

Observation Assignment 1

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.

posted by Michael at 9:25 pm  

Monday, September 18, 2006

Catch is Done for Now

I finished the first version of my catch game.

The schematic is pretty basic…
catch schematic.jpg

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


posted by Michael at 10:24 pm  

Sunday, September 17, 2006

Working on Catch

the whole layout

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.

t-salvaged switch

posted by Michael at 9:07 pm  
« Previous Page

Powered by WordPress