Archive for October, 2007

Phys Comp Midterm NOTE

Posted in Physical Computing on October 22nd, 2007

I just checked my You tube links and realized, that for some reason or another, they were resized after I uploaded them. In the next few days I will convert my footage and re-upload.

Sorry about that.

I miss drawing….

Posted in Personal on October 22nd, 2007

well I do.

There was a time in life when I wouldn’t be caught without at least two sketchbooks in my bag, and I was pumping out some relatively beautiful things. Now, not so much….I’m not sure what happened. Maybe I got bored, or caught up in a style that was limited, I don’t know.

I’m excited by all of the new things I’m pursuing at ITP. I can make boxes laugh, and red orbs appear on screen…This is all well and good, I love what I’m learning, but I don’t want all these new things to ecllipse the artistics mediums that have become part of who I am over the years.

I miss my roots…I’m not sure if it’s school, or having finally escaped the world of commercial building, or just being surrounded by new people and new energy, but something is making me want to pick up a pen again in a big way. The only issue now is time, which I have none of…

In the next few days, after midterms are over, I think I will being a little experiment. I will attempt to draw everyday on the train to school and back, and posted what I’ve done here for all to see. I’m sure I’m rusty as all hell, and that I’ll forget some days, but I’m hoping maybe that I can put this blog to some use other then just documenting ITP work.

It would be cool to make it mine.

Cross your fingers for me.

Phys Comp Midterm 4

Posted in Physical Computing, Uncategorized on October 22nd, 2007

We have dancing pencils.

Yeah, thats right, dancing pencils.

Dave came up with the idea for pencils that did, well, something…

We got some Pager motors, attached them to the individual pencils, placed them in a pencil holder, rigged an IR range finder, and we were off….

p5220080.jpg

The pencils jostle around quite nicely, though make a huge racket in doing so. We will most likely have to soundproof the pencil case somehow.

Phys Comp Midterm 5 - User Testing

Posted in Physical Computing, Uncategorized on October 22nd, 2007

WHAT IS THIS?!? - First thing out of most peoples mouths when seeing our objects.

Book:
Very popular
Some problems still with random jumps over low limit??? Possible ghost-detector?
When done being taken off guard, people get VERY close - finale? more random?

Pencil:
People tried to borrow a pencil, wants to see
Noise at first too loud, people got angry — noise needed to be more buffered

Bag:
Chipmunk noises hilarious
“it’s like a humanoid, observation-oid kind of toy”
“are you doing that?”

Testing:

Whoa.
Scary
Cute

Walk past 3 feet, turn, frown, notice no more movements, leave (think they’re crazy)
Direction of sensor very important
Arrangement of pieces very important as well (thought of putting pencils, then bag, then book to gain attention, make come back to trigger smaller objects)
IR too small and inconsistent readings
Ultrasonic definitely needed
Place hand inside bag… look at video on computer
How to gain attention/break from daily routine…or do we? It’s nice that people can walk right by this without noticing at first, I feel like this subtlety is kind of nice. These objects shouldn’t be lound and overbearing.

People seem to like the subtle noises of the items themselves (the book makes a flapping sound, the bag squeaks, and the pencils make a racket). We were originally planning on hacking MP3 players to make these items laugh, though it seems now that this would take away from the overall effect of the installation. Also, when asked about the addition of LEDS in the objects themselves, several individuals asked “why would a book glow?”.

No LEDS. No sound. The objects themselves will seem even more real, and less novelty/hammy.

The best part of all this was that viewers, so used to the cutting edge technology and amazing electronic devices of ITP, seemed genuinely surprised by our relatively low-tech little display.

Wicked cool.

Phys Comp Midterm 3

Posted in Physical Computing on October 22nd, 2007

Baggie LIVES!!!
p5220086.jpg

Things are getting complicated…It is kind of amazing how hard it was to get this last object to work. The thing seemed simple: Stick a servo motor in a bag to make it open and close.

Yet…somehow….

First I built a base for the bag, also housing a motor, to give the thing two degrees of motion. I made the base out of plywood to securely anchor the first motor, and then hid the whole thing inside a cardboard box.
Next I built an internal frame for the bag itself out of matte board, to stiffen it up, and give a good surface for the servo to push and move.
A motor mount was built for the servo, and, also, holes had to be cut and alligned, allowing wires from the servo in the bag to pass unseen into the box below, where this item’s arduino and wiring would be housed.

p5220083.jpg
(wiring inside the box, and the wooden frame that holds the servo to turn the bag)

Just when I thought the thing was completely, I realized a huge problem: The cardboard frame inside the bag was cutting into it. I reinforced all the seams of the bag with gaffers tape and then tried to reinsert the frame….No dice.
I then trimmed the frame, reinserted it, was ready to go when I realized that the bag was now too stiff to shut properly.

This was a total kick in the head. After some hours of staring at the damn thing, a walk across the block, and a mental breakdown, I realized that all we needed was a rubber band rig the close the bag after the servo forced it open. This took a couple of hours to rig.

p5220082.jpg
(the inside of the bag: Servo, rubber band return rig, and matte board frame)

Though this thing was a total pain in the ass to build (I originally thought it would take me about three hours. In the end it took over four days to get it right) it works wonderfully. There is footage of it operating below, though only the servo in the base was working when I took this. I will post a new shots as soon as I can take them.

Click to Watch

Phys Comp Midterm 2

Posted in Physical Computing, Uncategorized on October 22nd, 2007

Bookie lives.

Our first object is an old fake book I have, that was given to me by a dear dear friend (THANK YOU MS. KAWACHI!!!)

We outfitted the book with a servo motor, a ultrasonic range finder, an arduino, and a few LEDS.

soon we had this:

p5150061.jpg

Take a look at the link below to see our book in action.

Click Here

It’s kind of funny. People around us in the shop were working on incredibly involved things…yet, everyone came over to watch our new little creation flap about. This made me feel pretty justified in what we were doing. Soon we will have to come up with a way to hide the books interior…Also, I need to add some weight to the lid in order to help it shut quickly.

Phys Comp Midterm 1

Posted in Physical Computing, Uncategorized on October 22nd, 2007

(Over the course of our midterm project for p-comp, I’ve been jotting down notes and ideas in a sketchbook. As the project will be completed next week, I thought it would be a good idea to post some of what I’ve written).

INTIAL MIDTERM IDEA:

Bring a collection of inanimate, everyday objects to life. Objects will change and react to obervors and passersby via a bevy of sensors. Hopefully, the objects will react to a viewers prescence in such a way that is relatively easy to miss, therefore causing the viewer to do a double take upon noticing their intial movement or sounds.

HOW WE CAME TO THIS IDEA:
Dave, EJ, and I discussed what we wanted to do while sitting in front of Danny Rozins wooden mirror. While talking, we noticed how much fun people had with that peace. We decided that we wanted to build some sort of installation piece (rather then a product) that could cause a similar reaction. It was important to us that the piece not have any sort of physical interface, that simply passing by would trigger the objects and evoke a reaction. Most importantly, we wanted something capable of bringing a smile to peoples faces.

OUR ROLES:
We feel that this project will suit the three of us fairly well. Dave is undaunted by the thought of coding, which, quite frankly, scares the hell out of me. EJ is a wiring whiz (it’s sort of unreal how fast she can solder), and I’ll spearhead the building of the objects themselves. I’m looking forward to what we can learn from each other.

Serial Communication Lab ICM/PCOMP

Posted in Computational Media, Physical Computing on October 21st, 2007

WORLDS HAVE COLLIDED!!!

At long last, via the miracle of serial communication, ICM and PCOMP have collided in a rather wonderful way, via the miracle that is serial communication. What is serial communication, you ask? The official explanation sort of horrified me (picture screens of umlauts, quotation marks, and weird little indecipherable symbols, sort of like the nonsense Neo sees when looking at the matrix…I’m sure as hell no Neo), but I’m going to do my best to tell it how it is.

Serial communication is the method via which all of your external computer hardware devices (mouse, printer, scanner, etc) communicate with your actual computer. The device in question, and your computer transmit, tiny pulses of information back and forth to one another. Both devices are equipped with programs to translate these pulses into actual numerical or ASCII values, and then use these values to show you where your mouse pointer is on your screen, send in images from a camera, or do countless other handy things.

In doing this lab, the tricky part was writing the code for both the Arduino and Processing that allowed the two programs to communicate seamlessly. Two pots and a button were wired to the Arduino, and their analog values were then translated into X and Y values that moves a ball on the applet produced by processing. My first attempt at serial communication, using a call and response binary method (code supplied by Tom) worked, but in a very strange fashion…Processing was receiving values from my Arduino, but not in a way that made sense (i.e. my virtual ball was floating around the screen with no particular rhyme or reason). I showed my problem to Matt Young, who graciously helped me fiddle with a few ints and values to get things up and running perfectly. It was a pretty cool moment when I was finally able to zoom the ball around on screen

This week, in ICM, our assignment was fairly similar to our original PCOMP lab. As I recently received a shipment from Sparkfun, I had some cool new toys to play with. After a little wiring, finagling, and dealing with a cranky Arduino, I was able to get an accelerometer working, along with a Thermistor. The processing code was fairly simple: temperature values from the thermistor were scaled to control both the opacity of the ball on screen; it’s color, and the color intensity of the background. The accelerometer provided both the x and y coordinates for the ball on screen, once the thermistor received a high enough value to make the ball appear on screen. The result, in short:

Blowing on the breadboard makes a blue dot appear, and grow in size and opacity. Waving the breadboard around like a madman makes this dot dance on screen. Fun for all.

(screen shots below)

reddot1.jpg

reddot2.jpg

reddot3.jpg

CODE

Arduino:

int firstSensor = 0; // first analog sensor
int secondSensor = 0; // second analog sensor
int thirdSensor = 0; // digital sensor
int inByte = 0; // incoming serial byte

void setup()
{
// start serial port at 9600 bps:
Serial.begin(9600);
pinMode(thirdSensor, INPUT);
}

void loop()
{
// if we get a valid byte, read analog ins:
if (Serial.available() > 0) { // do we have any data? this reads
//the length of the buffer
// get incoming byte:
inByte = Serial.read(); // if so, then get it!
// read first analog input, divide by 4 to make the range 0-255:
firstSensor = analogRead(0)/4;
// delay 10ms to let the ADC recover:
delay(10);
// read second analog input, divide by 4 to make the range 0-255:
secondSensor = analogRead(1)/4;
// read switch, multiply by 255
// so that you’re sending 0 or 255:
thirdSensor = 255 * digitalRead(2);
// send sensor values:
Serial.print(firstSensor, BYTE);
Serial.print(secondSensor, BYTE);
Serial.print(thirdSensor, BYTE);
}
}

Processing:

import processing.serial.*;

int bgcolor;
int fgcolor;
Serial port;
int[] serialInArray = new int[4];
int serialCount = 0;
int xpos; //values from accelerometer
int ypos;
int temp;
int tempVal; //value from thermistor
float randomVal;
boolean firstContact = false;

void setup() {
size(1000, 1000);
noStroke();

port = new Serial(this, Serial.list()[0], 9600);
port.write(65);
}

void draw() {
background(tempVal,0,0);
fill(0,0,tempVal,tempVal);
tempVal = (temp - 130)*10;
randomVal = random(1,3);
ellipse (xpos*15-500, ypos*15, temp + tempVal, tempVal*randomVal);
if (firstContact == false) {
delay(300);
port.write(65);
}
}

void serialEvent(Serial port) {
if (firstContact == false) {
firstContact = true;
}
serialInArray[serialCount] = port.read();
serialCount++;

// If we have 3 bytes:
if (serialCount > 2 ) {
xpos = serialInArray[0];
ypos = serialInArray[1];
temp = serialInArray[2];

println(xpos + “\t” + ypos + “\t” + temp + “\t” + tempVal);

port.write(65);
serialCount = 0;
println(xpos);
}
}

Servo Lab, from way back when…

Posted in Physical Computing on October 21st, 2007

First off, I have to apologize…I am so behind in my Pcomp lab entries, it’s sort of amazing. This entry is, oh, I don’t know, three weeks late?

So, without further adieu…

Servos!!!!

Now, as I’m sure you will notice in the entries above, I have become quite familiar with the servo, as they are pretty much the driving force behind my P-comp midterm project. The pictures below are from the week before I started trying to make books, bags, and pencils move, and the use of theses devices still seemed relatively straightforward….

Servos, for those of you not in the know, are the small electric motors that can often be found in RC models, robotics, as well as countless industrial applications. Servos, as I understand them, are controlled via pulse width modulation to accurately move them within a 180-degree range. I’m still a little unclear as to how, exactly, this is accomplished, but I’ll give you my version of the story: Inside the servo, a potentiometer is mechanically linked to it’s DC motor. This pot patiently waits for data pulses to come every 20 milliseconds, each pulse moving the motor incrementally, via internal gearing, until it completes its 180 turn. The servo then happily awaits orders to take the return trip back in the opposite direction.

As the motor in the servo itself is controlled via a pot, these devices are ideal transducers, easily converting input from analog sensors into controlled motion. Below you’ll see some still pictures of a servo controlled via an Ultrasonic range finder. The LED in the servo was placed there to indicate the motion generated by the motor itself.

p5080059.jpg

p5080060.jpg

Big Buck Hunter Quantifications/Further Observations:

Posted in Physical Computing on October 21st, 2007

Continued my Big Buck Hunter Research quite some time ago, wrote this, and completely forgot to post. My apologies.

Big Buck Hunter

Big Buck Hunter Quantifications/Further Observations:

In order to quantify the game a bit, I myself played a few rounds of the game, and watched five separate groups of people play.

Game play steps/observations about those steps:

1) Insert cash (any amount)

Money goes in, fun comes out.

2) Once money is in, press big orange or green button

3) Select game (1 or 2 player), Trek (3 shooting scenarios plus one Bonus) or Trip (9 shooting scenarios plus four bonus rounds). Select animal to hunt, choice of deer, antelope, moose, ram, and elk.

4) Insert more cash if necessary (a Trip is $1.00 per player, a Trek is $2.50).

5) Select a weapon, either green or orange gun.

6) Stand approximately four feet from the machine (nowhere on the machine itself is a proper standing position given).

7) Begin game play. (No instructions are given, other then “Pump to reload” and “Don’t shoot the does”. Absolutely no information about scoring is presented.

8) If a player shoots a doe, their turn is ended abruptly, though they are allowed to keep points earned from any buckshot before their mistake.

9) The player has the opportunity to shoot three buck. The amount of doe on the screen varies from scene to scene.

10) An average turn (if no does are shot) lasts approximately 30 seconds. After the actual virtual shooting takes place, scores are displayed. Each buck shot is assigned a point value, seemingly based on its “weight” as well as its “rack” (the number of tips it has on it’s antlers), and the “distance” and which it was killed (how far away it was in the virtual space presented, not the shooters distance from the machine). Supposedly, accuracy is also counts, but in a rather confusing manner that has very little effect on the players final score.

11) After a player has completed his/her/their turn, the rifle is passed to the next person up. If four people are playing (the games maximum) the wait between turns can be up to 2-3 minutes. During this time the other players often cajole or bother the one that is shooting, drink their beer, or get more beer to drink. Often those players that approach the bar for a refill end up missing their turn, or will have someone take it for them.

12) On an average turn, most players make between 10-15 shots, though this number greatly depends on their skill level or personal method of game play. Some players will make only 3-5 shots per game, depending on their accuracy. Others will make 20+, depending upon a volley of virtual bullets to slay their virtual quarry.

13) If a player is having a hard time, the machine will offer tips and suggestions, such as “aim for the vitals” via graphics in between turns, or a voice (mentioned in my previous observation entry).

14) Most complete games seem to take between 4-5 minutes per trip, and around 5-8 minutes per trip, and 15-20 minutes per trek (with four players).

So what is it about this game? It seems to me that the most attractive aspects of this game are:

1) Kitsch. This is a hunting game that shows up, as far as I know, in urban bars. Men, women, Veggies, Vegans, and meat lovers alike can plug away at virtual animals, no harm, and no foul. As violent as hunting in reality actually is, this game is free of blood, guts, or gore…just an occasional hill Billie asking the player if “you gots enough room in yer fridge for all that meat”. It seems as though some play seriously, and others for novelty, but in the games I’ve watched no one has ever flat-out refused to play, and almost all seem to have had a good time doing so.

The Interface.

2) The Interface. The two gun system is incredibly simple, and easy to learn. I was lucky enough to watch someone play for the first time during my first round of observations. She mastered the interface with in the first round of play.

3) It’s social. I have never, ever witnessed anyone playing this game alone. The short breaks allow for rounds of friendly ball breaking, friendly interaction, and cavorting.

4) Guaranteed game play. This is a big one. No matter how much you suck, or how good a player you are, once your money is in the Big Buck Hunter machine, you are guaranteed a relatively good amount of playtime.