Friday, April 20, 2007

Lab 7: MIDI




MIDI lab took me about an hour but was pretty fun once I had it all running. Ben Yee motivated me to get'er done by supplying a pre-sodered MIDI connector cable.

Lab 6: Controlling Motors




Ahh, monster trucks. That takes me back. For this lab, Paul and I scrapped together some scraps, tossed in a motor and made our truck drive forward AND reverse! Actually it didn't go hardly anywhere as we used duck tape as the belt between motor and wheel axle. But on the bright side of things we did get the motor going in two directions so a small victory.

Wednesday, April 18, 2007

Final Project Prototyping

http://itp.nyu.edu/~bmy1/video/wing1.MOV

The idea for the final project is to have a bird-esque thing of wings that hang by a stiff rod from the ceiling. the wings are on a hinge and dangle on the sides. Underneath the bird will be a fan that, once triggered, will spin to send an air current upward creating lift underneath the wings causing them to rise and fall to simulate the bird flapping its wings in flight.

Thursday, March 1, 2007

Lab 5: Processing



Yo! So this lab had more stumbles than most simply because I had to figure out how to make my computer cooperate between arduino, breadboard, processing, etc. and there was a big problem with my serial permissions. But Todd H. helped us through, and by us I mean Paul, Lucia, and I. Having prior experience with processing, once we got everything up and running I was able to mess around with the program and get a pretty cool etch-a-sketch type thing going. Paul had knobs to use so it worked much better on his than mine which was using flex sensors. Lucia added a twist to the program also and we ended up with these great dots that you can draw with. On to the midterm which is going to be difficult to say the least.

Wednesday, February 21, 2007

Lab 4: Motors


Due to exhaustion from travels (or waiting to travel thanks to JetBlue), I'm only doing the basic lab to get a motor working this week. This is exciting in the sense that it's all coming together: the computer programing, the wiring, the sensors, and now a motor. I'm ready -- or once I'm fully rested -- to really get my hands dirty and wrap my mind around the arduino language to see what i can really make a sensor and motor do. But I'll save that for next week. For now, I give you a flex sensor turning a servo motor.

Wednesday, February 14, 2007

Lab 3: LEDs and Flex Sensor



success! getting the feel this sort of stuff. i have some videos that demonstrate the flex sensor working, but not knowing how to upload those I'm just going to talk about it: currently I have three LEDs hooked up with a flex sensor. I borrowed a program from the original lab and made some basic alteration to accompany additional LEDs, and presto: I can bend the flex sensor and all three LEDs dim or brighten based on if you bend the sensor or not.

Monday, February 12, 2007

Continuing My Observation

What details do you notice that you previously overlooked?
The quality of the audio on such systems is usually so poor that people simply pass on the ability to talk to the visitor and simply buzz the stranger in, which sort of undercuts the purpose of the system to begin with in terms of security. While many upperclass people can afford doormen, there should be a better system that eliminates the need for a human and I know it can be done cheaply.

What parts of the transaction seem fluid or effortless?
Opening the door. And that's about it.

What parts seem to take the most effort? What parts seem the most awkward or strained?
Everything else. For the visitor: finding the interface, learning the interface, learning how to respond to the audio, opening the door before the buzzer expires. For the occupant: listening to the visitor, trying to explain to the visitor what to do, giving enough time to allow the visitor to open the door during the buzz.

Saturday, February 10, 2007

Part Two of Observation Assignment

For the second stage of this exercise, pick the interaction you found the most interesting and observe and describe it in depth.

What is the setting? An apartment where there is a buzzer to unlock the front door of the building, plus an intercom.

What is the physical orientation of the person (sitting, standing, etc)? One person is standing at the entrance of the building, usually in a small interior foyer, waiting for the door to be unlocked (aka: to be buzzed in). The other person is standing inside the apartment at the buzzer.

What does the person physically do in the course of the interaction? The person who enters the building must first locate the interface and then figure out which buzzer corresponds to the correct apartment he or she is visiting. The person then presses the buzzer for several seconds as to make sure the person in the apartment hears the buzz (but not too long as to annoy the occupant). The occupant then must rush to their buzzer, and either press the talk button or simply unlock the entrance through the buzzer. If the person presses the talk button, then the other person waiting to be let in must listen (not easy to do) and respond by simply talking or locating a talk button (this always seems awkward). finally, the occupant now buzzes to let their friend in and holds down the button for several seconds to give their friend time to grab the door knob and open the door. Often this routine fails and the person must again buzz the occupant to let them know that they failed to open the door in time.


How many steps does it take? At least 2 or 3 steps on the part of each participant (the occupant and the visitor) assuming everything works as planned.

How many times is the person listening to the device? again, 3 or 3 times each IF everything works as planned... and often it does not.

How many times is the device "listening" to the person? It's not, it's simply a gateway for two people to interact.

What's the balance of that time? 30 seconds to a minute... assuming the people have interacted with the interface before, otherwise this could take minutes.
Thinking about the physical interaction between people and machine that I witness everyday, I have to say the first one that comes to mind is neither something I witness nor does it involve a person. It involves a dog, specifically the one next door in the adjacent apartment, and a mechanism his owner has to calm his barking. I live on the first floor of an apartment building and when someone enters generally this dog from next door (speak of the devil, he's barking now) likes to bark to "greet" the person entering. Well, I suppose at some point in time the owner realized this barking could go on for too long and installed some sort of device that buzzes (perhaps shocks the dog) from inside the apartment. Soon after the first bark, you hear the buzz. It doesn't seem to work very well (the dog is currently still barking about a minute into the buzz). But what is interesting to me about this interaction is that someone has spent time designing a machine that is meant to alter the behavior of an animal by delivering negative feedback, aka punishment. Through this supposed conditioning a "reverse" interaction is occuring: the machine (technically) insititues the interaction, and the animal responds. I wish I could see it work.

Wednesday, February 7, 2007

Lab 2: First Arduino Program


Another lab, another stumble, another fix, and presto: an LED lights via an arduino. This time the problem came from me thinking the LED could light just by having a current run through the arduino without having into install a program. A friend set me straight and once I loaded the program everything worked. Although I should admit that I had ground and power backwards briefly forgetting the importance ofthe red and blue band that run down the sides of the breadboard. I'm learning.

Wednesday, January 31, 2007

With a potentiometer:


Potentiometer turned so that the LED is dimmed:

Pics From First Lab

With a switch:


Better angle:

Wednesday, January 24, 2007

Lab One: Electronics

It took a second effort and renewed electronics self-esteem, but I got an LED to light. I probably spent four hours+ working on this lab before giving up and realizing I needed to remove myself from the project for a few days and then comingback to it ith a fresh mind. This strategy worked. Within two minutes of returning, I realized my mistake in the circutry and fixed the issue... and ta da: a bright white LED working as it should. The mistake was in having the LED itself faced in the wrong direction on the breadboard. I read up on LEDs and realized this could possibly be the problem, but I tried so many different LEDs when I was using trial-by-eror to fix my circut, I can't believe every LED I put in I put in the same direction. Now I know why one end of the LED is longer than the other. Initially I was worried that I had botched the sodering of my DC power supply, but the readings I got off the multimeter suggested all was working with the supply as it should with a healthy 12volts coming into the breaboard. I played with the resistor and regulator ad learned a lot about them in this process, including the realization that my resistor was the wrong kind.

The next step will now be adding a switch and then a variable voltage with a Potentiometer. I'll report soon how it goes and hopefully have a picture or two.