The lab went pretty smoothly. Jenny had set everything up already, mostly. We both learned that there's such a thing as a unipolar motor that only goes in one direction (and doesn't go at all if the polarity is reversed) and we also learned that even a tiny motor can get going fast enough to make masking tape cut through paper.

Watch a movie of the motor in action!

The breadboard with the motor.

One half of the breadboard setup.

The other half of the breadboard.

Download the code

Low-bandwidth version.

Oren strumming the air guitar.

An image of the guitar with the breadboard. "No strings attached!" (A helluva lot of wires, tho').

For the MIDI lab, I decided to try out a beam-break detection system I had been wondering about for awhile. Creating an invisible "string" that could be "plucked" seemed to be a perfect applicaiton for MIDI.

The beam-break detection system is pretty simple: An infrared (IR) LED shines at an IR emitter/detector. If the IR LED isn't too far from the emitter/detector, you will pick up a signal. Indoor lighting gives off IR, too, so the values you get on the IR detector will vary depending on the lighting situation. To overcome this I created a "calibrate" routine where the PIC measures the initial value it reads off the IR detector and then compares subsequent readings against this "calibrated" value. If the new reading on the detector is off by a pre-determined amount (my "threshold variable"), we know the beam has been broken, and so we can do something (in this case, we send a MIDI note out).

A close-up of the IR emitter/detector

A close-up of the IR LED, which is situated facing the emitter/detector, about 6-8 inches away. You "strum" the guitar by interfering with the beam between this LED and the detector.

The reason I used an IR emitter/detector (note the emphasis) is that I wanted to be able to do some basic ranging. That is, I wanted to get more information about where the beam was broken, in addition to the fact that it was broken at all. When you break the beam with a finger, your finger reflects some of the IR from the emitter back to the detector (the emitter/detector combo is one unit, with both emitter and detector facing out. The IR LED is across from the emitter/detector module, about 6 inches away.). The idea (and this was born out when I looked at the data I was getting) is that there will be a range of values that the detector detects, going from low (finger breaks the beam far away from the emitter/detector) to high (finger breaks the beam right near the emitter/detector and a lot of IR light gets reflected off the finger into the detector), as well as the "calibrated" value (i.e., nothing breaking the beam).

In practice it worked out pretty well except for the fact that the range of values the detector read were not linear (they tend to be quite low for the furthest third of the length of the beam, and then jump up very quickly when you get less than a couple centimeters away). I don't think I got the correct code onto the PIC to translate those changing measurements into changing notes, though.

Here's a close-up of the breadboard, without the 20MHz clock.

I also drilled a hole in the guitar body and added a potentiometer with a knob on it (just like a real electric guitar). The values from the potentiometer are used to change the volume of the notes generated using the guitar.

You can download the PICBasic Pro Code (I commented it as well as I could).

One of the major problems I ran into was making sure that the PIC programmer was set for a high-speed oscillator (oscillator->HS). It was really frustrating before I realized I was forgetting to do that. Also, getting the hang of how to set up the hardware serial out (the HSEROUT command) was difficult.

I should point out that I didn't do this alone. Oren helped out a lot for the final stages, and Tikva helped me along when it was still an air harp. And Megan MacMurray gets special thanks for generously letting me use her 20MHz clock whenever I needed it.

Me jamming.

Me jamming harder.

There will be a movie coming soon (it's not the same without the audio).

Also, I'm planning on expanding the project to include a couple strings and Oren's suggestion which was to use photodetectors as "frets" to change chords. I am going to need to use lasers for the multiple strings (IR would diffuse and interfere with itself). I think I'll call it my Laser Air Guitar.

Zach and I have expanded our group to include Summer, who is going to be helping us with the aesthetic concerns, among other things.

We are planning on going through with a lot of the technical whiz-bangery that we weren't able to get to the first time around. Here's a list of a few itemized planned improvements:

• Make more robust connections for the CD jewel cases. Connection problems with the cases were the biggest problem we faced in the first incarnation. The CDs would only make intermittent contact and we would end up with the jukebox skipping tracks and not recognizing tracks.
• Make the jukebox have live updating. Before, it would only update after a song had finished playing. In the new version, it will know immediately when you insert or remove a track, and we will have the ability to use the jukebox to skip forward to the next track.
• Have the CD Jewel cases be digitally addressed. Currently we use unique, arbitrary resistors for each case. This limits the total number of CD Jewel Cases that we can create (and there's a little fuzziness with the analog readings sometimes). We plan to embed microprocessors in each CD case, with a unique ID number that is communicated serially to the microprocessor controlling the entire jukebox. This way we can have a nearly unlimited number of jewel cases.
• We will use tri-color LEDs to make an aesthetic, color-changing "glow" to the jukebox (like a real jukebox!).
• We're still not quite sure how to allow users to program their own cases, but we will most likely create a special program and special piece of hardware to allow them to do so.

There are a few more pie-in-the-sky improvements (wireless, anyone?) that are planned, that we hope to get to.

This method solves a few problems that I had been having earlier. Notably, I found that there began to be a significant lag when I had Applescript polling the PIC continuously. The program will run much faster this way, because Applescript really only does anything for the half-second or so after a track has finished playing. The downside to this scheme is that the computer doesn't really know the state of the CD tower until a track is finished playing. This means we're out of luck if we want the computer to be able to tell the tower to do something when a CD is inserted or removed. Zach and I plan to build in this functionality to the PIC, instead.

The main reason that our interactions with computers have been so stagnant is due to their design, and especially their raison d'etre. The focus when using a computer is the computer itself, whereas with other devices that use processors (i.e., a microwave), the interaction is focused on a specific activity for which that device is well-suited. As processing power continues to become cheaper, we will move toward "ubiquitous computing," an idea whereby processors will be embedded into everyday objects, which will allow our everyday objects to be "computers" in a limited sense. By giving small individual objects computer-like functionality, but within the scope for which that object is already well-suited, computing as we know it will recede so that the focus comes once again to the actions for which we use the ubiquitous computer-objects.

In the examples Dourish gives, I noticed a lot of ITP-like projects. For instance, one item is called "feather", and it floats a feather in a room whenever an action in another, far-away area, takes place. For instance, the feather might float in my room when my sister lays down on her bed in Minnesota, thus forming a new way of connecting with each other. Also, one project mentioned has a string connected to a motor that moves in proportion to the amount of traffic on the ethernet cable to which it is attached. This reminds me of my instructor's project that advanced the hands on a clock by the number of emails he had received since he last checked his email.

The Tangible Bits project at the MIT Media Lab caught my attention. The term refers to the transition from physical bits (i.e., atoms) to virtual bits, with a focus on the way virtual bits are superseding the need for physical bits. This is a fine idea, and I think that this sort of focus, when also taking into account the ubiquitous computing idea, can take us very far. By focusing on the actual physical objects necessary to do certain tasks, but imbuing them with digital properties, we can combine the best of both worlds.

The idea of multiple limited-ability compute-able objects that can interact and be used simultaneously also allows us to transcend the sequential order of interaction that computers have taught us. When using a computer, there is only one input source used at a time (occasionally we use both mouse and keyboard), and the idea is that one thing comes after the next. But when we employ the digitally-aware objects of a ubiquitous computing environment, interaction is more fluidly defined by a human's needs, rather than limited to sequential instruction to a central computer.

The idea, really, is that the idea of computing fades away and we are left with ideas that we have and tools (well-suited to their individual tasks) that we use to do them, taking advantage all the while of the benefits afforded us by virtual bits but never having to notice them as such.

Using two potentiometers to control X and Y movement, and a switch to act as the mouse's button, I was able to create my own mouse replacement. I connected it to Processing and was able to make a digital etch-a-sketch.

The picture below shows the controller. I just glued the X pot and the Y pot to a piece of wood to anchor them (otherwise you need to use two hands to control each pot: one to hold it steady, the other to twist the knob).

I made sure to connect the positive and ground terminals of the pot in the same order for each so that they would both increase resistance in the same direction. If I had wired them the other way, twisting left would decrease resistance on one pot but increase it on the other. If I had made this mistake I could have fixed it in the computer (changed one of the variables to be = MAXVALUE - value, for instance), but it's easier this way.

The switch is just a piece of cardboard with a wire in it that you press onto another bare wire that is wrapped around the wood. I had the etch-a-sketch in mind when I built this controller, and so the switch has a bit of a gummy feeling. I remember when I used to play with etch-a-sketches that erasing the image was always a little difficult. You had to shake it a lot, and sometimes your "etching" would only have faded instead of disappeared. So by making the switch a little clunky I kind of replicated the same clunky erase feeling.

I also attempted to replicate the unstable erasure via software. In my Processing applet, I made it so that the erase button only dims the onscreen etching. One needs to press it several times to get the image to disappear completely. See screenshot below:

Code

Yet, according to this reading, our capacity for processing information is only about 10-50 bits per second. That seems unbelievably low to me, considering all the sensory information we have access to. So how could it be true?

Well, the central idea is that we only really focus on one thing at a time, but our brains are so good at switching from thought to thought and input to input that we are able to scan through many different senses at once.

Another way we can get around this is that a lot of information gets processed subconsciously. Once we are so good at a certain task that it becomes automatic, like driving, we are able to subsume a great deal of sensory information subconsciously and not really process it, which frees the mind up for other tasks.

I know my own mind has a sort of "buffer" of information that it holds. When I am engrossed in a basketball game on TV, I have found myself literally unable to hear comments spoken to me. Not that tuning people out is anything extraordinary. The interesting thing about that is, as soon as the play is over (anywhere from a 2 or 3 to more than 10 seconds later), I then become conscious of the fact that someone did say something to me, but I truly had no recollection of actually hearing them speak. I need to ask the person to repeat their comment. I think it's amazing that I can know that someone said something to me but have 0 recollection of the actual act of them speaking to me.

I had a few spare moments in the lab, so I created an entirely new (but basically same-as-before) breadboard setup with the 10K resistor on the PIC's reset (upper left pin), power to the board and to the PIC, and the LED indicator light on the bottom. I figure it will be nice to be able to have two projects going at the same time, instead of having to pull all the attached wires each time my project changes. Plus, I think I'm a better solderer now, and I have hindsight on my side, so I was able to make a slightly cleaner board (the real improvement over the last one is in my serial connector. I did a much better job of soldering the header pins and laying it out this time).

The most difficult part of this lab was finding the servo motor. I trekked all around Chelsea trying to find a store that would sell it to me (there was talk about some store on 22nd street but I never found). I eventually had to go up to 30th street by 7th Av, a place called American Hobby Center, or something like that.

So what is a servo motor? Seattle Robotics has a good beginner's guide to the servo. Basically, it's a small motor that has a roughly 180-degree range of motion, and the shaft of the motor moves according to the time that a voltage is pulsed to it. It is connected to +5V and ground, and there is a control wire as well (this is the input to tell the servo how far to turn).

Luckily, there is a command in PicBasic Pro, PULSOUT that we can use to specify a length of time to send a signal to the motor. This is how we can specify how far the motor should turn. Sending a short pulse will cause the motor to reset back to its starting state.

One other neat thing I found out about from the Seattle Robotics link above is that servos move at a speed proportional to how far they have to go. This makes sense considering what I observed while using the little motor, but I didn't realize it before.

So what did I build? I came up with two ways to use the motor: manual and automatic. In manual mode, twisting a potentiometer varies the analog input to the PIC, which then translates this into a length of time to pulse the motor, with the result being that you twist the pot, and the motor twists along with you.

In automatic mode, the motor rotates until it hits a trip-switch that I built. When the switch is tripped, it resets and starts over. I think there's something really fascinating about watching the motor twist until it hits the wire and then abruptly resetting once it does. You can watch the movie below to see for yourself.

This first image is a close-up of the motor with the trip-switch. The trip-switch is just the yellow and white wires wrapped around each other. When the motor pushes the first wire, it touches the second and closes the switch.

This second picture is an overview of the entire board. It shows the switch in the upper right corner of the board and the yellow and red leds in the middle on the right side of the board. The yellow and red LEDs act as indicators of which state (automatic or manual) the board is operating in.

The LEDs also dim and glow according to the state of the stepper motor. This is done using PWM, or pulse-width modulation. The LEDs are PWM'd a certain length of time depending on the position of the motor's gear. Pulse-width modulation is when the PIC outputs a square wave voltage; the proportion of time the wave is HIGH and LOW (or ON and OFF) creates an average voltage. If the modulation is fast enough, the eye cannot see the individual on-off changes and perceives the LED as being dim (or bright). I was never able to keep the LEDs from flickering a bit. It was a trade-off between faster response of the stepper motor and smoother lighting of the LEDs.

The code.

During the first week, we gathered observations on an action that influenced a medium. This is what we found:

Action: Setting up and re-arranging a playlist using iTunes.
In a party setting, using iTunes to manipulated song playlists can be frustrating. iTunes expects only a single person to be creating and arranging playlists at any one time. Having multiple people trying to set up a playlist or just choose a song to play doesn't work very well when there is only one mouse. In addition, in a party situation a rather delicate device like the computer would be best kept out of sight (and spill-range).

The goal of the activity is to arrange the songs in a playlist in a desired order and have those songs play, in that order.

A person involved in this activity needs to be quite focused on the computer: They may have to use the keyboard to enter text to search on, and then they also must use fine motor controls to select the specific songs they want to play, and then either create a new playlist or drag them to a specific playlist. Next, they must order the playlist, and finally they need to click "play." The person doing the task typically needs to use both hands and must remain focused on the computer screen the whole time.

The only characteristics to take as given in this medium are the song files on the computer. Mouse- and keyboard-driven input are not the only means of sending information to a computer, and in order to find a tool that allows more expressive action in this medium, we expect to have to look to alternative forms of inputting song information to the computer.

Here is a video of a sample observation of someone attempting to create a playlist:

What's Ahead
As a first-draft idea, we plan to create a kind of a cartridge-based song selection system, using CDs as a visual/tactile metaphor for actual songs. A playlist can be arranged by arranging the order of the CD jewel cases in a standing CD rack.

The thesis of the first chapter could really be said to be, "Keep people in mind when you are designing something." I think part of the reason the principles laid out in DOET appeal to me so much is that a large part of my life philosophy is, simply, "Keep people in mind when you are doing something." I'm a very conscientious person. I develop feelings of discomfort when I realize I am hindering someone's ability to do something. This is pretty prominently pronounced while walking on the sidewalk: I am very aware of my surroundings and don't like to be in someone's way. I naturally gravitate to the side of the sidewalk when I am walking, and when I realize I need to stop and turn around, I will first slow down and then peel off the main foot-traffic flow. When I am having a conversation with someone, I find it difficult to concentrate if we are in a public thoroughfare and in the way, and I'll try to nonverbal influence the person I'm talking with to kind of scoot out of the flow.

So perhaps I'm especially inclined to be concerned about how an object's poor design would hinder someone's ability to operate it.

An example of an object the design of which I spend an inordinate amount of time thinking about is the cell phone. I have had two different models of cell phones myself, and used many others' phones, and I think they are truly ripe for design/experience improvement. For instance, my cell phone still doesn't display the time while I'm on a call. Since I have ditched a wristwatch for my cell phone's time display, I am basically unable to check the time while I'm talking to someone anymore.

On my most recent phone, I had to connect to the web in order to send or receive a text message. This is incredibly irksome, because it takes usually over a minute to connect to the web. And then, once I had connected to the web and navigated to my "messaging center," I was no longer able to access my phone's address book so I had to resort to writing down people's cell phone numbers on a piece of paper and then connecting to the messaging center, re-entering the phone number (the phone's input defaults to text input, too, so I had to change it back to number-only input), and then finally being able to send the text message. As a result, I almost never sent or read text messages. My new phone, thank goodness, has fixed this oversight.

Another, more subtle example, is the paltry "recent calls" list on the phone. It only holds 10 numbers at a time for each of missed calls, recent calls, and outgoing calls. I know that the phone's memory must be much larger than this, so why not have a larger list? This could be an option that is not readily available (having only 10 numbers at a time is usually sufficient for basic "recent calls" needs), but I for one would like to be able to go back to a day two months ago and see who I called, and who called me, if for no other reason than curiosity.

Again, I enjoyed reading what Norman had to say; his words resonate well with me, for I too am always finding "Norman doors" and other poorly-designed objects. I had long read the website of his colleague, Jakob Nielsen (useit.com), but hadn't yet heard any words from Mr. Norman. I'm glad I did.

This week I learned how to send serial signals out from the PIC to be read and understood by a computer. We used a PC program, Hyperterm, to view the serial data. Connecting reminded me of how I used to get on the internet back around '96: Specify the baud rate, the parity, stop bits, flow control, etc.

I figured out how to use a potentiometer wired in series with a 10K resistor to vary the voltage coming in to the PIC, and the resulting numbers that show up in Hyperterm range from 0 (when there are 0 volts, i.e., the potentiometer is at maximum resistance) to 1024 (because we specified that there would be that many steps between low and high).

In the course of trying to find something interesting to use this analog signal for, I thought about the different kind of input devices that were possible: there are force resistors, light-sensitive resistors, heat-sensitive resistors. We use single LEDs to indicate the presence or absence of a digital signal, so why not use one of the analog sensors mentioned above with an array of LEDs to indicate strength of the analog signal coming in? I decided to be fancy and try to create a crude remote control using an infrared sensor and infrared emitting LED.

I went down to Chinatown and found an electronics store where I bought an IR Photodiode, part number NTE3033, and an IR LED, part number NTE3017. I had a lot of headaches with these, mostly because I didn't have a clue how they should be properly powered and installed on the breadboard. I finally got a decent reading from the IR receiver when I wired it like a switch, from power to receiver to 10K-Ohm resistor to ground. But I never got the IR LED to work well. I wired it in series with a potentiometer so that I could vary the voltage on it (I wasn't sure if it uses the same amount of voltage as a normal LED), and I was only able to get big readings off my photodiode when I had the resistance on the pot turned down so low as to almost fry the board.

I had also been told that a digital camera will pick up IR, so that you can see an IR LED shining if you look through the camera's viewfinder. I could see no such thing on my poor IR LED.

Long story short, I plopped down a few more bucks at Radioshack for another IR-emitting LED, and all my problems were solved. On with the lab.

The first idea was, if I am going to make an infrared detecting system, I might as well just go ahead and make a full-blown remote control. I used a 9V battery and wired it together with a 5-volt regulator, a 220-Ohm resistor, the IR LED, and a push-button momentary switch. Here's the battery, wrapped in tape (to prevent its metal outside from creating shorts):

A close-up of the guts of the remote, before wrapping them all up in tape.

The final remote:

When the remote is clicked, you can see the infrared LED glow in the viewfiender of a digital camera:

Here is the original setup. The IR detector is the black blob on the right.

Here's how the board looked after I put the LED bar display in, trimmed all the wires, and bent the IR detector backwards so it would detect a signal coming from above.

This is the Radioshack IR Kit (emitter and detector) that saved me:

And, finally, a movie of the sucker in action, set to the Beastie Boys' "Remote Control" (turn your bass up):

And don't forget the code.

Our group chose to observe the actions of individuals at the Union Square Station subway stop in Manhattan. Metro stops in general are chaotic, busy places with a lot of mental stimulus. In the Union Square station, which has takes up nearly a full block of space underground, the situation is exacerbated by its immense size. There are overhead signs every 30 feet pointing the way to various tracks, there are hordes of people going in every possible direction, there are huge steel girders to avoid, there are subway maps on the walls, as well as other signs that sometimes are useful (e.g., posters informing about limited service on certain lines) and sometimes not very useful (e.g., advertisements, announcements of city events).

There are two major groups of subway riders: those who ride on a daily or near-daily basis (frequent riders) and those who are new to the station and unfamiliar with the navigation of it (tourists). For frequent riders, speed and efficiency are the priorities: They want to get to their ultimate destination with as few distractions as possible, and they want to avoid waiting (in lines, for trains, etc.). They want to know the answers to questions like the following:

• When is the next train?


• Is this the fastest route to my track?


• Do I need to speed up?


• Will the next train be express or local? If it's the local, is it faster to take it or to wait for the express?

• Is this the right track?


• Is this the way to my track?


• Which track should I take?


• Which exit do I take to get to the Tower Records (or Filene's Basement, etc.) aboveground?

Context-aware Trains
Several of the questions above are really directed at the trains themselves. If there were a way for the train to answer the question, "When will you arrive?" both tourist and frequent visitor would be helped. By using radio-frequency ID tags on the trains, coupled with receivers on the platforms, the trains will be able to know where they are, and the subway station will be able to know where trains are further up and down the tracks. This information could be presented in a variety of ways, including displaying a countdown timer in various places around the station (and also outside the station), making it available via SMS text messaging and also via the web.

Information Kiosks
A touchscreen kiosk (similar to the metrocard dispenser machines already installed) could be used to help the tourist and frequent visitor alike. The tourist could touch an area on a subway map of the city and have the machine tell it the best route to take to get to the destination. A frequent visitor could use the kiosk to find out how long it would take to get to an arbitrary location several train-switches away. The kiosk could also have information about the map of the subway station and it could be supported in part by advertising revenue from local stores, which would display (along with the weather information) on the display screen when it's not in use. The kiosk could also show aboveground images for each of the subway's exits, so that people exiting the subway won't arrive aboveground to find themselves across a busy street from their intended destination.

Aboveground Information
In addition to displaying train arrival times aboveground (so that a subway rider can know whether to hurry up or enjoy time outdoors a little longer), a status indicator could be used to inform the public when that entrance is closed or when a line's service has been discontinued.

Turnstiles
At busy times of the day, there is a mass exodus at certain exits of the station. These occur right after a train has arrived. If the trains were outfitted with the RFID tags described earlier, the station will know when a train has arrived. If the turnstiles could then be momentarily turned into one-way turnstiles (by keeping the bar from being able to move in a certain direction) and indicated as such using green or red lights, then the subway riders just entering the station would be able to get through the onrush of exiting people. The turnstiles could also be outfitted to pay attention to how many times they have been used in the past 10 seconds or so, and if they are unused for a specified period of time, they could be turned back into two-way turnstiles.

We also noticed that occasionally the metrocard needs to be swiped again, and the sound that accompanies the "swipe again" message on the display is the same sound that accompanies a successful swipe, leading to riders occasionally slamming into an immobile turnstile. The solution to this is simple: change the sounds so there is a negative feedback and a positive feedback sound.