<rss version="2.0">
	<channel>
		<title>AlexR's Physical Computing</title>
		<link>http://e-sa.org/itp/physcomp/</link>
		<description>Physical Computing</description>
		<language>en</language>
		<item>
			<pubDate>Fri, 07 Dec 2007 17:27 -0500</pubDate>
			<title>Final</title>
			<link>http://e-sa.org/data/view?fn=20071207_1197018996.txt</link>
			<guid>http://e-sa.org/data/view?fn=20071207_1197018996.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 11 to 13, Final<br />
<br />
<table width=630 cellspacing=2><tr><td><img width=320 height=240 src="http://e-sa.org/photos/2007/2007-12-01_09:37:04.jpg"></td><td><img width=320 height=240 src="http://e-sa.org/photos/2007/2007-12-05_23:50:38.jpg"></td></tr></table> <br />
emoto.photo is released in new glory!<br />
<br />
The Emoto.Photo is an evolution from the classic photo booth,<br />
incorporating user motion and physical interaction to create fun, quick,<br />
animated sequences of yourself that you can edit, play with, and send to<br />
your friends.<br />
<br />
Users interact with the Emoto.Photo by reacting to screen-based prompts<br />
and playing with a wireless RFID enabled stick. As the user is prompted<br />
(to jump, play air guitar, or kung-fu) random stills are taken, and then<br />
played back like a flip book style animated movie. Prompts are generated<br />
based on the level of user activity, making the Emoto.Photo genuinely<br />
interactive. The user can then edit the color, size and pixelation of<br />
the animation, which is stored online for later viewing.<br />
<br />
Check out Ramona's user document <a href=http://ramonapringle.com/emotomovie1online.mov>movie</a>!<br />
<br />
For our final Ramona, Syed and I prepared a new improved version of<br />
emoto.photo, our wand powered super active photo booth.<br />
<br />
- Wand Improvement<br />
<br />
First we switched from RF to Bluetooth.  It was great not grounding<br />
RX anymore (no inserting/removing cables on boot).  Data sent between<br />
the two devices was also more reliable.  I didn't notice any negative<br />
points.<br />
<br />
- Wand Body<br />
<br />
We prepared soft fabric, and wrapped the electronics at the end of the<br />
wand in it to keep it light and protected.  Next came bright green silk<br />
fabric I scrounged up in the garment district.  We covered the entire end<br />
of the wand, about a foot.  When we started working on the screen<br />
interface, we realized a foot, three inches in diameter, would make an<br />
unwieldy pointer.  So we covered the green fabric, except for the<br />
circular end, with black fabric.  Our pointer was good to go!  Later<br />
when Clay Shirky was using it, a prompted asked him to "kick it", which<br />
he did.  The wand kept working, and obviously users were no longer<br />
worried about fragile electronics!<br />
<br />
- Interactive Prompts<br />
<br />
To add an interactive element, we made the prompts interactive.  If you<br />
don't move at all, the prompts ask you to smile or wave instead of<br />
"shake your booty".  The prompts progress regardless of movement,<br />
instead of the first version which would grind to a standstill.  If you<br />
move a lot, the wand asks you to improvise a dance.  We added 9 levels<br />
of interactivity.  These levels are progressed through depending on how<br />
much you move the wand.  The interactive prompts were received well.<br />
We received comments that the prompts sometimes didn't correspond to the<br />
wand, for example "sing!", which caused confusion.<br />
<br />
- Post Processing<br />
<br />
Once all the photos are taken the user is able to modify the images by<br />
changing their color, pixelation or resizing.  The user uses the wand on<br />
the left to interface with the menu, and the modified movie is replayed<br />
on the right.  On the bottom left is an upload button, the middle resets<br />
your modifications, and the right restarts the program.  The post<br />
production added depth to the piece, and was also well received.  Once<br />
you've restarted, you use the wand to press a button in the middle of<br />
the screen to start again.  I removed the upload function temporarily,<br />
because processing was crashing.  I'm not sure what the problem was.<br />
<br />
As always, here is the <a href=http://e-sa.org/itp/physcomp/FinalProcessing.pde>code</a>.<br />
<br />
<table width=630 cellspacing=2><tr><td><img width=320 height=240 src="http://e-sa.org/photos/2007/2007-12-05_23:54:38.jpg"></td><td><img width=320 height=240 src="http://e-sa.org/photos/2007/2007-12-05_23:56:40.jpg"></td></tr></table> <br />
<br />
-- Fri, 07 Dec 2007 17:27 -0500 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Thu, 06 Dec 2007 22:59 -0500</pubDate>
			<title>Observations II</title>
			<link>http://e-sa.org/data/view?fn=20071206_1196995297.txt</link>
			<guid>http://e-sa.org/data/view?fn=20071206_1196995297.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Observations II<br />
<br />
What is the difference between reactive vs. interactive devices?<br />
Usman Haque asks this excellent question in terms of <a href=http://www.haque.co.uk/papers/ArchInterSys.pdf>architecture</a>.<br />
Tom Igoe refers to it as rich interaction.  If you wave at a wall, and<br />
lights turn off corresponding to the path of your arm, I would call the<br />
piece reactive.  When I think of Plaplax's piece Shadow, where cones<br />
which have been touched change animations on screen, I think of it as<br />
reactive.  However, the piece has a rich, pleasing aesthetic which<br />
brings it into the realm of art.<br />
<br />
When dialog begins between the user and the device, I imagine it being<br />
interactive.  The prompts which we developed for emoto.photo are<br />
interactive.  Depending on the amount of user motion, the prompts change<br />
correspondingly.  Don't move at all, and it asks you to make faces and<br />
tries to get you to move more.  Move a lot and it makes you work out!  A<br />
major lesson learned: always keep beauty and interactivity in mind when<br />
designing.<br />
<br />
-- Thu, 06 Dec 2007 22:59 -0500 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Wed, 14 Nov 2007 01:21 -0500</pubDate>
			<title>Final Preparation</title>
			<link>http://e-sa.org/data/view?fn=20071114_1195020875.txt</link>
			<guid>http://e-sa.org/data/view?fn=20071114_1195020875.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 10, Final Preparation<br />
<br />
Work on the new version of emoto photo continues.  First off we switched<br />
the RF to Bluetooth.  That was fairly straight forward.  RX and TX<br />
cables running from the bluetooth chip to arduino should be switched; RX<br />
-> TX, TX -> RX.  Then use the AT commands as per Sparkfun's page to get<br />
it up and running.  Once the baud rate is set as you want it, your off<br />
to the races!  <br />
<br />
Our problem with bluetooth wasn't technical, but space.  The card is<br />
quite long and sticks out the side which makes it easy to whack and<br />
break.  I made a header so it can lay flat, but I need to redo this so<br />
it lays flat parallel to the board.  Next, we wrapped the wand end in<br />
cushion and purchased some very green fabric.  We are working on blob<br />
detection, but the fabric may generate too many shades.  We will<br />
continue to iron these details out, then get to modifying the code.<br />
<br />
-- Wed, 14 Nov 2007 01:21 -0500 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Mon, 05 Nov 2007 23:33 -0500</pubDate>
			<title>Schedule for Final</title>
			<link>http://e-sa.org/data/view?fn=20071105_1194323498.txt</link>
			<guid>http://e-sa.org/data/view?fn=20071105_1194323498.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 9, Schedule for Final<br />
<br />
Our work toward emoto.photo v2 continues!  First we will rebuild the<br />
wand itself, and jump into post production.  Users will be able to<br />
modify the content they filmed by shaking the wand during playback.<br />
Part of this may be tracking the wand in video and using that as new<br />
input, or possibly modifying the blob of the wand itself.  The wand will<br />
become indestructible (knock on wood), opening for freer play.<br />
<br />
Nov 7 - Nov 14 :<br />
rebuild the wand<br />
code post production effects<br />
<br />
Nov 14 - Nov 20 :<br />
Color tracking/prompts<br />
establish phases (photo taking, post) & "experience as a whole"<br />
proposal for winter show<br />
<br />
Nov 20-27: Thanksgiving week<br />
<br />
Nov 26-28: User testing<br />
<br />
Nov 28: Present user testing<br />
<br />
Nov 28 - Dec 5:<br />
Sound - effects & playlist<br />
Idle Mode<br />
<br />
Dec 5: Presentation<br />
<br />
-- Mon, 05 Nov 2007 23:33 -0500 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Wed, 24 Oct 2007 01:13 -0400</pubDate>
			<title>Midterm</title>
			<link>http://e-sa.org/data/view?fn=20071024_1193200535.txt</link>
			<guid>http://e-sa.org/data/view?fn=20071024_1193200535.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 7, Midterm<br />
<br />
<a href=/itp/physcomp/emoto.photo.diagram.jpg><img width=712 height=400 border=0 src=/itp/physcomp/emoto.photo.diagram.jpg></a><br />
<br />
Team: Ramona, Alex and Syed<br />
<br />
Thanks to Ramona for the great explanatory image.<br />
<br />
Functionally, our project was ready a week ago.  Tom offered two great<br />
suggestions: 1) show the image as it taken to the user, and 2) allow the<br />
users to download the sequence rather than worry about postproduction.<br />
So, that's what we tackled!  We didn't add a skin for the wand, or get<br />
into postproduction, but that may be for the final.<br />
<br />
We needed to redo the prompt timing, so first off we rewrote the<br />
processing code.  Next we added a few prompts, adjusted the number of<br />
photos taken and timing, and finally started showing a photo to the user<br />
each iteration.  We also wanted to give the experience a "game feel".<br />
This meant no reloading Processing each time you play.  More<br />
importantly, Ramona made up an excellent howto explanatory image for<br />
users, and an amazing introduction movie.  I added three states to the<br />
code: init, running, and playback.  To move from init to running (where<br />
photos are taken) and playback to init one wiggles the controller<br />
intensely.<br />
<br />
Handling this intensive wiggling, for which I wanted a defined motion,<br />
was a pain.  First I tried modifying the wand's code to add a forth<br />
value which signifies sequential change in the x-axis.  No problem.<br />
Thing was, sometimes the RF receiver dropped the incoming data, meaning<br />
you missed the queue, inconveniencing the user to wiggle again.  After a<br />
few hours of work, I just moved the code into processing, making it<br />
time based.  If I were to redo it, I would probably use bluetooth, or a<br />
protocol which allows two way communication to verify data integrity.<br />
<br />
Ramona user tested again on Sunday which helped us fine tune.  Finally<br />
on Tuesday we wrote the code to upload users movies to a website.  We<br />
call a script from Java which archives the images and then scp's the file<br />
to a remote server.  Next a command is run on that server to combine the<br />
jpeg images into an mpeg movie.  We used a great program called ffmpeg.<br />
We ended using it on the server side as it was easier to install than<br />
compiling ffmpeg locally.  The URL is displayed during playback.<br />
We specifically left out an index page for users privacy.<br />
<br />
<a href="/itp/physcomp/MidTermProcessing.pde">processing code</a><br />
<a href="/itp/physcomp/MidTermAccelCode.pde">wand (transmitter) code</a><br />
<a href="/itp/physcomp/MidTermAccelRecv.pde">receiver code</a><br />
<a href="/itp/physcomp/uploademoto.sh">upload emoto to remote server</a><br />
<a href="/itp/physcomp/midterm/genmovie.sh">generate movie from emoto</a><br />
<br />
-- Wed, 24 Oct 2007 01:15 -0400 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Wed, 24 Oct 2007 00:57 -0400</pubDate>
			<title>DC Motor Control</title>
			<link>http://e-sa.org/data/view?fn=20071024_1193198902.txt</link>
			<guid>http://e-sa.org/data/view?fn=20071024_1193198902.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 7, Lab: DC Motor Control<br />
<br />
<table width=630 cellspacing=2><tr><td><img width=320 height=240 src="http://e-sa.org/photos/2007/2007-10-22_06:21:30.jpg"></td><td><img width=320 height=240 src="http://e-sa.org/photos/2007/2007-10-22_07:37:52.jpg"></td></tr></table> <br />
<br />
In preparation for the DC motor lab I decied to build one of the<br />
protoshield's sold for the arduino.  There isn't any documentation on<br />
Sparkfun's site about assembling it, and while fairly straight forward,<br />
I found this <a href="http://www.atomicsalad.com/archive/2007/03/11/tutorial_sparkfun_protoshield_assembly_use.php">great tutorial</a>. It took me about 2 hours to put together.  <br />
What's a good way to cut that female header?  Drove me nuts.  Was it<br />
worth the time?  Yes, having the breadboard and arduino in that little<br />
unit is sweet.<br />
<br />
Protoshield aside, this week's lab was about working with a DC motor.<br />
It took awhile of looking at Tom's diagram, but eventually I wired<br />
things up.  Looking at the <a href="http://focus.ti.com/docs/prod/folders/print/sn754410.html#technicaldocuments">tech specs</a> for the SN754410 helped.<br />
The chip is surprisingly easy to use once you get the hang of wiring<br />
it up.  Vcc1 goes to 5V to power the chip, Vcc2 is to power the motor.<br />
<br />
I connected a POT to control the speed of the motor which worked fine.<br />
I had to turn the dial around to get it up to 5V before the motor<br />
started turning.  Below is my code, based off of Tom's:<br />
<br />
<p class=codefoo><br />
int switchPin = 2;	// switch input<br />
int motor1Pin = 3;	// H-bridge leg 1 <br />
int motor2Pin = 4;	// H-bridge leg 2 <br />
int speedPin = 9;	// H-bridge enable pin <br />
int ledPin = 13;	//LED <br />
int potPin = 0;		// Analog input pin for the pot<br />
int potValue = 0;	// value read from the pot<br />
<br />
void setup() {<br />
	// set the switch as an input:<br />
	pinMode(switchPin, INPUT); <br />
<br />
	// set all the other pins you're using as outputs:<br />
	pinMode(motor1Pin, OUTPUT); <br />
	pinMode(motor2Pin, OUTPUT); <br />
	pinMode(speedPin, OUTPUT);<br />
	pinMode(ledPin, OUTPUT);<br />
<br />
	// set speedPin high so that motor can turn on:<br />
	digitalWrite(speedPin, HIGH); <br />
<br />
	Serial.begin(9600); <br />
<br />
		// blink the LED 3 times. This should happen only once.<br />
	// if you see the LED blink three times, it means that the module<br />
	// reset itself,. probably because the motor caused a brownout<br />
	// or a short.<br />
	blink(ledPin, 3, 100);<br />
}<br />
<br />
void loop() {<br />
	potValue = analogRead(potPin); // read the pot value<br />
	analogWrite(speedPin, potValue/4);<br />
	Serial.println(potValue);		<br />
<br />
	if (digitalRead(switchPin) == HIGH) {<br />
		digitalWrite(motor1Pin, LOW);<br />
		digitalWrite(motor2Pin, HIGH);<br />
	} <br />
	else {<br />
		digitalWrite(motor1Pin, HIGH);<br />
		digitalWrite(motor2Pin, LOW);<br />
	}<br />
	delay(10);<br />
}<br />
<br />
// blinks an LED<br />
void blink(int whatPin, int howManyTimes, int milliSecs) {<br />
	int i = 0;<br />
	for ( i = 0; i < howManyTimes; i++) {<br />
		digitalWrite(whatPin, HIGH);<br />
		delay(milliSecs/2);<br />
		digitalWrite(whatPin, LOW);<br />
		delay(milliSecs/2);<br />
	}<br />
}<br />
</p><br />
<br />
-- Wed, 24 Oct 2007 00:57 -0400 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Mon, 15 Oct 2007 21:39 -0400</pubDate>
			<title>RF Fun</title>
			<link>http://e-sa.org/data/view?fn=20071015_1192497552.txt</link>
			<guid>http://e-sa.org/data/view?fn=20071015_1192497552.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
RF Fun<br />
<br />
For our midterm, part of the project is to build a wand which will serve<br />
as an interface for manipulating a series of photos.  The wand itself<br />
needs to be wireless, so users don't feel restricted in their use of the<br />
wand.  We don't want people getting tangled up, or lassoing others up.<br />
The accelerometer can take some punishment, so I'd like people to swing<br />
with gusto.<br />
<br />
For the project we are using Sparkfun's <a href="http://www.sparkfun.com/commerce/product_info.php?products_id=7815">RF Link - 4800bps - 434MHz</a>.<br />
This RF link is also sold at the NYU Computer Store.<br />
<br />
First of all, the <a href="http://www.sparkfun.com/datasheets/RF/KLP_Walkthrough.pdf">KLP Walkthrough Tutorial</a> was very helpful.  <br />
The first two RF link's I bought were bad, I don't know why.  I don't<br />
*think* I did anything to toast them.  Tom was kind enough to lend me<br />
his so I could continue working.<br />
<br />
TX (transmitting) code:<br />
<p class='codefoo'><br />
byte counter;<br />
<br />
void setup()<br />
{<br />
	// 4800 baud model, but use 2400<br />
	Serial.begin(2400);<br />
	counter = 0;<br />
}<br />
<br />
void loop()<br />
{<br />
	Serial.print(counter, BYTE);<br />
	counter++;<br />
	//delay(1); <br />
}<br />
</p><br />
<br />
RX (receiving) code:<br />
<p class='codefoo'><br />
int incomingByte = 0;<br />
<br />
void setup()<br />
{<br />
	Serial.begin(2400);<br />
}<br />
<br />
void loop()<br />
{<br />
	if (Serial.available() > 0) {<br />
		incomingByte = Serial.read();<br />
		Serial.println(incomingByte, DEC);<br />
	}<br />
	//Serial.println("I am having fun");<br />
}<br />
</p><br />
A few lessons I learned:<br />
<br />
1. Despite being good for up to 4800 bps, using 2400 bps with no delay<br />
seemed to be the most reliable.  <br />
<br />
2. When loading code to the receiver module, make sure the wire to RX is<br />
DISCONNECTED, otherwise the arduino gets confused (RX is shared with<br />
USB, so the arduino can't differentiate between incoming RF data and the<br />
computer data).<br />
<br />
3. When printing out values to the computer, the serial to USB<br />
conversion seems slower than the rate of incoming data, causing the RX<br />
buffer to overflow...  basically, all the incoming data wasn't being<br />
printed, it looked like 0, 200, 240, 5, 10 - just bits and pieces.  The<br />
code below adds the values up to make sure the data being received is<br />
consistent.<br />
<br />
4. Range: 3-4 meters, by powering from the arduino and using an antenna.<br />
<br />
RX code with consistency check:<br />
<p class='codefoo'><br />
int incomingByte = 0;<br />
int c = 0;<br />
int total=0;<br />
<br />
void setup()<br />
{<br />
	Serial.begin(2400);<br />
}<br />
<br />
void loop()<br />
{<br />
	if (Serial.available() > 0) {<br />
		incomingByte = Serial.read();<br />
		Serial.println(incomingByte, DEC);<br />
		c++;<br />
		total += incomingByte;<br />
		if (c == 256) {<br />
			Serial.print(total, DEC);<br />
			Serial.print(" ");<br />
			Serial.println("loop");<br />
			c = 0;<br />
			total = 0;<br />
		}<br />
	}<br />
	incomingByte = 0;<br />
  //Serial.println("I am having fun");<br />
}<br />
</p><br />
The next step was to battery power the wand.  Just adding a battery (9V)<br />
to the arduino didn't seem to work.  The power LED came on, but no data<br />
was being transmitted.  After a bit of experimenting, I realized<br />
plugging the USB cable in after the arduino boots jumpstarts data<br />
transmittal.  Why?  Turns out with the Arduino NG (rev. c) you need to<br />
keep RX from floating.  Do this by adding a 10k resistor from RX to<br />
ground.  In my case, this didn't interfere with the reprogramming of the<br />
device.  Refer to this page for <a href="http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1176690710/0#0">more info</a>.<br />
<br />
<table width=630 cellspacing=2><tr><td><img width=320 height=240 src="http://e-sa.org/photos/2007/2007-10-09_04:54:04.jpg"></td><td><img width=320 height=240 src="http://e-sa.org/photos/2007/2007-10-09_07:26:58.jpg"></td></tr><tr><td><img width=320 height=240 src="http://e-sa.org/photos/2007/2007-10-16_20:44:48.jpg"></td><td><img width=320 height=240 src="http://e-sa.org/photos/2007/2007-10-16_20:45:30.jpg"></td></tr></table> <br />
<br />
-- Mon, 15 Oct 2007 21:39 -0400 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Thu, 11 Oct 2007 10:28 -0400</pubDate>
			<title>Week 5, Lab: Serial</title>
			<link>http://e-sa.org/data/view?fn=20071011_1192111657.txt</link>
			<guid>http://e-sa.org/data/view?fn=20071011_1192111657.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 5, Lab: Serial<br />
<br />
<img width=320 height=240 src="http://e-sa.org/photos/2007/2007-10-06_13:23:48.jpg"><br />
<br />
In the serial lab we connect a sensor to the arduino, which transmits<br />
data back to the computer via USB, which processing then reads and<br />
processes.  For the sensor I used a 3-axis accelerometer, the same which<br />
we will be using for our midterm (I am working with Ramona and Syed).<br />
It was no problem connecting the accelerometer to the breadboard and<br />
reading in values.<br />
<br />
Next I attached the arduino and breadboard to a dowel, hoping to get a<br />
wand effect, something easy for people to swing and play with.  I<br />
composed the arduino code to monitor the values of the accelerometer,<br />
taking the difference of the three axis' over 100 milliseconds, in 10<br />
millisecond cycles.  If the difference exceeded a predefined value, this<br />
was considered movement in that axis and a 1 is sent, otherwise 0 is<br />
sent to the serial port.<br />
<br />
The format for sending data is:<br />
XYZ255XYZ255XYZ255<br />
The 255 denotes markers, so processing knows which of the three bytes is<br />
X, Y, and Z respectively.  X, Y, and Z are 0 or 1, 0 meaning no<br />
movement, 1 movement in that axis.<br />
<br />
Processing then reads these values, and as the want is swung pictures or<br />
taken, or a dialog on screen advances.<br />
<br />
ADD PHOTOS<br />
<br />
Here is the code used with the accelerometer.<br />
<br />
<p class='codefoo'><br />
/* <br />
 * MidTerm code for Accelerometer based wand<br />
 * by Alexander Reeder<br />
 * Oct 9, 2007<br />
 */<br />
<br />
// THRESH represents the threshold's for change<br />
#define X 0<br />
#define XTHRESH 35<br />
#define Y 1<br />
#define YTHRESH 25<br />
#define Z 2<br />
#define ZTHRESH 35<br />
<br />
// for ADC we delay(10)<br />
// CYCLE denotes how many of these cycles<br />
// we wait before comparing differences<br />
#define CYCLE 10<br />
<br />
int sensor[3];		// array to hold the sensor values<br />
int lastsensor[3];	// last sensor value<br />
int c = 0;		// counter<br />
int tmp = 0;		// temporary variable for caculations<br />
int diff[3];		// cumulative differences between sensor and <br />
			// lastsensor, refreshed each cycle or on change<br />
<br />
void setup() {<br />
	// initialize the serial port:<br />
	Serial.begin(9600); <br />
}<br />
<br />
void loop() {<br />
	// read in analog values, of which there are three: X, Y and Z<br />
	for (int i = 0; i < 3; i++) {<br />
		sensor[i] = analogRead(i)/4;<br />
		// if the value is 255, truncate it so we can use 255<br />
		// as a unique value to punctuate the sentence:<br />
		if (sensor[i] == 255) {<br />
			sensor[i] = 254; <br />
		}<br />
		//DEBUGGING<br />
		//Serial.print(sensor[i], BYTE);<br />
		//Serial.print(sensor[i], DEC);<br />
		//Serial.print(" ");<br />
	}<br />
	//DEBUGGING<br />
	//Serial.print(255, BYTE);<br />
	//Serial.println("");<br />
	<br />
	// if we have done one cycle, reset the difference array and counter<br />
	if (c == CYCLE) {<br />
		for (int i = 0; i < 3; i++) {<br />
			diff[i] = 0;<br />
			lastsensor[i] = sensor[i];<br />
		}<br />
		c = 0;<br />
	} else {<br />
		// otherwise, add up the difference between sensor and last sensor<br />
		for (int i = 0; i < 3; i++) {<br />
			tmp = lastsensor[i] - sensor[i];<br />
			// make sure the value is positive<br />
			if (tmp < 0) <br />
				tmp = tmp*-1;<br />
			diff[i] = diff[i] + tmp;<br />
			lastsensor[i] = sensor[i];<br />
			//DEBUGGING<br />
			//Serial.print(diff[i], DEC);<br />
			//Serial.print(" ");<br />
		}<br />
		<br />
		// X-axis change, 1 on change 0 on none<br />
		if (diff[X] > XTHRESH) {<br />
			Serial.print(1, BYTE);<br />
			diff[X] = 0;<br />
		} else <br />
			Serial.print(0, BYTE);<br />
		<br />
		// Y-axis change<br />
		if (diff[Y] > YTHRESH) {<br />
			Serial.print(1, BYTE);<br />
			diff[Y] = 0;<br />
		} <br />
		else<br />
			Serial.print(0, BYTE);<br />
			<br />
		// Z-axis change<br />
		if (diff[Z] > ZTHRESH) {<br />
			Serial.print(1, BYTE);<br />
			diff[Z] = 0;<br />
		 } <br />
		 else<br />
			 Serial.print(0, BYTE);<br />
		 <br />
		// end of data string<br />
		Serial.print(255, BYTE);<br />
	}<br />
	c++;<br />
	delay(10);<br />
}<br />
</p><br />
<br />
At first, I was unsure about the range of values an accelerometer would <br />
provide.  I wrote a little code to measure the range of values.<br />
<br />
<p class='codefoo'><br />
/* <br />
 * Using an accelerometer,<br />
 * determine the range of its values over a period of time<br />
 * by Alexander Reeder	<br />
 * Oct 5, 2007<br />
 */<br />
<br />
int sensor[3];		// array to hold the sensor values<br />
int high[3], low[3];	// high and low values<br />
long lastPulse = 0;<br />
int refreshTime = 2000;	// period of monitoring<br />
<br />
void setup() {<br />
	// initialize the serial port:<br />
	Serial.begin(9600); <br />
<br />
	// setup<br />
	for (int i = 0; i < 3; i++) {<br />
		high[i] = analogRead(i)/4;<br />
		low[i] = high[i];<br />
	}<br />
	delay(10);<br />
}<br />
<br />
void loop() {<br />
	for (int i = 0; i < 3; i++) {<br />
		sensor[i] = analogRead(i)/4;<br />
		if (sensor[i] == 255) {<br />
			sensor[i] = 254; <br />
		}<br />
		if (high[i] < sensor[i])<br />
			high[i] = sensor[i];<br />
		if (low[i] > sensor[i])<br />
			low[i] = sensor[i];<br />
		//Serial.print(sensor[i], DEC);<br />
		//Serial.print(sensor[i], BYTE);<br />
		//Serial.print(" ");<br />
	}<br />
	//Serial.print(255, BYTE);<br />
	//Serial.println("");<br />
	delay(10);<br />
	if (millis() - lastPulse >= refreshTime) {<br />
		Serial.println("");<br />
		Serial.print(high[0], DEC);<br />
		Serial.print(" ");<br />
		Serial.print(high[1], DEC);<br />
		Serial.print(" ");<br />
		Serial.print(high[2], DEC);<br />
		Serial.println("");<br />
		Serial.print(low[0], DEC);<br />
		Serial.print(" ");<br />
		Serial.print(low[1], DEC);<br />
		Serial.print(" ");<br />
		Serial.println(low[2], DEC);<br />
		Serial.println("Set down, resetting!");<br />
		delay(2000);<br />
		for (int i = 0; i < 3; i++) {<br />
			high[i] = analogRead(i)/4;<br />
			low[i] = high[i];<br />
		}<br />
		delay(10);<br />
		lastPulse = millis();<br />
		Serial.println("Move it!");<br />
	}<br />
}<br />
</p><br />
<br />
<img width=240 height=320 src="http://e-sa.org/photos/2007/2007-10-08_09:13:18.jpg"> <br />
<img width=320 height=240 src="http://e-sa.org/photos/2007/2007-10-06_13:59:42.jpg"> <br />
<br />
-- Thu, 11 Oct 2007 10:28 -0400 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Wed, 03 Oct 2007 07:11 -0400</pubDate>
			<title>Week 4, Midterm Project Proposal (Ramona, Syed and Alex)</title>
			<link>http://e-sa.org/data/view?fn=20071003_1191409805.txt</link>
			<guid>http://e-sa.org/data/view?fn=20071003_1191409805.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 4, Midterm Project Proposal (Ramona, Syed & Alex)<br />
<br />
This project will be comprised of video/digital images and physical<br />
input, combined to create animated sequences of the participant.<br />
<br />
The setup:<br />
A screen (plasma or computer) with a camera on top.  The participant<br />
will be prompted to stand in one spot ("X") and follow directions<br />
telling them to look straight ahead, turn left, look down, smile, etc.<br />
The images (still or video, depending on technology and how project<br />
manifests) will become the library of images used in the physical<br />
computing experience.<br />
<br />
The logic is that creating things is fun, and it's even more fun when<br />
you get to watch yourself. It's easy to follow simple prompts, which<br />
will be displayed on the screen either as text, or as images/clips to<br />
respond to, and then those shots will be combined into different<br />
sequences to form animations.<br />
<br />
The element of physical computing is a ball, which will have a 3-axis<br />
accelerometer inside, and use zigbee wireless transmition to<br />
communicate with the processing applet (image library/code), each<br />
associated with an image from the library (ex. Sensor 2 = frown,<br />
sensor 14= look up) so that as the player plays with the ball, an<br />
animated sequence is crated. The sequence will be a series of images,<br />
one after another with straight cuts, which depending on their<br />
sequence/order express diffferent emotions/feelings/themes.<br />
<br />
A few conceptual images:<br />
<br />
<img src="/itp/physcomp/midterm_1.jpg"><br />
<img src="/itp/physcomp/midterm_2.jpg"><br />
<br />
An elaboration of this idea is to involve short video clips, that<br />
include both dialog snippets and slightly longer responses to on<br />
screen stimuli. Then, not only based on switch contact, but also<br />
based on the motion/speed/direction of turning the ball, a sequence<br />
will appear that is preset as "sad" (a slow turn) or "happy" (a fast<br />
turn), with a continuum in between correlation speed of movement to<br />
the content that is produced.<br />
<br />
User-centered, user-generated content<br />
<br />
-- Wed, 03 Oct 2007 07:11 -0400 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Mon, 01 Oct 2007 17:54 -0400</pubDate>
			<title>Week 4, Lab, Servo</title>
			<link>http://e-sa.org/data/view?fn=20071001_1191275120.txt</link>
			<guid>http://e-sa.org/data/view?fn=20071001_1191275120.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 4, Lab: Servo<br />
<br />
Here is the ITP intro physcomp <a href="http://itp.nyu.edu/physcomp/Labs/Servo">link</a> for the lab.<br />
<br />
Connecting the servo to the arduino and getting it to spin was no<br />
problem.  All I needed to do was solder a header to connect the servo<br />
motor cable to the breadboard.  Thanks Tom for the reference code!  My<br />
motor had a smaller range, closer to 1000 - 2200.<br />
<br />
<table width=768><tr><td><br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-30_00:31:24.jpg"> <img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-30_00:32:54.jpg"><br />
</td></tr></table><br />
<br />
For the analog output, I decided to combine the lab with my Spatial<br />
Design <a href="http://e-sa.org/data/view?fn=20071001_1191277275.txt">project</a> (please see the link for prototype details).  <br />
I designed and built a simple mobile to emulate the motion of a person<br />
bowing.  Being a mobile, one would think the object flows smoothly and<br />
elegantly with a light breeze.  This mobile is static, normally<br />
restrained in position (and perhaps should be called a sculpture and not<br />
a mobile as such).  <br />
<br />
I decided to take the idea of a mobile and invert it; rather than wind<br />
blowing and moving the mobile, active interaction would be the trigger.<br />
Only when one blows on the mobile is it actually released.  Bowing<br />
itself represents social restraint, only after expected protocol between<br />
parties is fulfilled does communication flow freely - if even then.<br />
<br />
I used a flex sensor to control the movement of the servo.  I attached a<br />
circular dongle to the top of the flex sensor, the idea being when one<br />
blowed on its surface the motor would move, moving the mobile.  It sort<br />
of worked, although you had to blow really hard to make the motor move.<br />
Attaching the flex sensor was also difficult.  In the end, I think I<br />
should have used another sensor.<br />
<br />
<embed src="http://e-sa.org/itp/physcomp/week4_servo.mov" width="320" height="240" autoplay="false" loop="false" controller="true" pluginspage="http://www.apple.com/quicktime/"></embed><br />
<br />
<table width=768><tr><td><br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-10-03_09:59:52.jpg"> <img height=240 width=320 src="http://e-sa.org/photos/2007/2007-10-03_10:01:42.jpg"><br />
</td></tr></table><br />
<br />
Here is the my <a href="/itp/physcomp/flexservo.c">code</a>.<br />
<br />
-- Mon, 01 Oct 2007 17:54 -0400 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Wed, 16 Sep 2007 10:06 -0400</pubDate>
			<title>Week 3, Lab, Analog In</title>
			<link>http://e-sa.org/data/view?fn=20070925_1190746272.txt</link>
			<guid>http://e-sa.org/data/view?fn=20070925_1190746272.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 3, Lab: Analog In<br />
<br />
Here is the ITP intro physcomp <a href="http://itp.nyu.edu/physcomp/Labs/AnalogIn">link</a> for the lab.<br />
<br />
Step 1.<br />
<br />
First I connected the breadboard to the Arduino.<br />
<br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-16_06:56:40.jpg"> <br />
<br />
Step 2.<br />
<br />
Next I connected a potentiometer, as per the lab instructions.  As you<br />
turn the potentiometer up and down the green LED's intensity changes<br />
accordingly.  <br />
<br />
<table width=768><tr><td><br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-16_08:31:02.jpg"> <img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-16_08:32:28.jpg"> <br />
</td></tr></table><br />
<br />
Step 3. <br />
<br />
Next I connected a variable resistor.  I used a flex sensor and<br />
programmed the arduino to send the reading from the sensor back to the<br />
terminal so I could monitor change.  What I noticed about the flex<br />
sensor I was using was that it registered bending in only one<br />
direction.  I made a mental note to be careful how I integrate the flex<br />
sensor into future projects.<br />
<br />
<table width=768><tr><td valign=top><br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-16_09:45:00.jpg"></td></tr><tr><td><img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-16_09:45:20.jpg"> <br />
</td></tr></table><br />
<br />
Step 4.<br />
<br />
Have fun!  For the final step in this lab we were suppose to create a<br />
luv-o-meter.  My luv-o-meter works for guys only.  It is a modified pair<br />
of pants which was a flex sensor along the zipper line.  When you first<br />
put the pair of pants on, in an unaroused state, you press a button<br />
which takes the initial flex reading.  After an, um, change, a red LED<br />
blinks on and off to indicate a high reading on the meter.  <br />
<br />
The main problem with this project, as with the the chimes, was securing<br />
the arduino in an ungangly fashion.  Next, there was the obviously<br />
problem that the luv-o-meter registers a high reading whenever you stand<br />
up.<br />
<br />
<a href="http://e-sa.org/itp/physcomp">Up</a><br />
<br />
-- Tue, 25 Sep 2007 14:51 -0400 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Wed, 16 Sep 2007 10:06 -0400</pubDate>
			<title>Week 2, Observation</title>
			<link>http://e-sa.org/data/view?fn=20070919_1190210302.txt</link>
			<guid>http://e-sa.org/data/view?fn=20070919_1190210302.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 2, Observation<br />
<br />
Street corner.  Early evening.  The street lights glare into my eyes as<br />
I inspect my surroundings.  I focus on a man.  His body is gyrating to<br />
an unheard tempo.  He grasps in each hand pole like objects, standing on<br />
a pedestal.  Left, right, left, right he glides, no forward motion.  His<br />
hand moves to touch a panel in front of him.  There are many buttons on<br />
this panel, too many to ascertain what his press could be effecting.  He<br />
presses the same button again and again in a hurried fashion.<br />
Finishing, he grabs for the pole, missing the first attempt, almost<br />
losing his balance.  The gyrating continues.<br />
<br />
<a href="http://e-sa.org/itp/physcomp">Up</a><br />
<br />
-- Wed, 16 Sep 2007 10:06 -0400 <br />
			]]></description>
		</item>
		<item>
			<pubDate>Wed, 16 Sep 2007 08:28 -0400</pubDate>
			<title>Week 2, Lab, Digital In and Out</title>
			<link>http://e-sa.org/data/view?fn=20070919_1190201524.txt</link>
			<guid>http://e-sa.org/data/view?fn=20070919_1190201524.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 2, Lab: Digital In and Out<br />
<br />
Here is the ITP intro physcomp <a href="http://itp.nyu.edu/physcomp/Labs/DigitalInOut">link</a> for the lab.<br />
<br />
Step 1.<br />
<br />
First I connected the breadboard to the Arduino.<br />
<br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-16_06:56:40.jpg"> <br />
<br />
Step 2.<br />
<br />
Next I connected a switch, as per the lab instructions.  When the switch<br />
is pressed the red LED switches on, green turning off.  Otherwise the<br />
green LED is always on.<br />
<br />
<table width=768><tr><td><br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-16_07:27:38.jpg"> <img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-16_07:28:14.jpg"> <br />
</td></tr></table><br />
<br />
Step 3. <br />
<br />
Time to have some fun!  I decided to continue work on a project I<br />
started in The Softness of Things.  I had made wind chimes from copper<br />
pipe, so I decided to turn the chimes into a switch.  By rigging wires<br />
from the individual pipes to digital in, the LED's to digital out, I<br />
strove to express the sound of the chimes in light.<br />
<br />
The contact between the pipes, despite the pipes being quite large, was<br />
much better than I thought.  I didn't measure amperage, but I'm bit<br />
worried that I was using a decent amount of power to generate a<br />
potential across the pipes.  I programmed the Arduino to light the LEDs<br />
on contact between the pipes, which resulted in short bursts of<br />
responsive light.  The sound of the chimes was not affected by the<br />
wiring.<br />
<br />
The most difficult part of the project was finding a place to put the<br />
Arduino and breadboard.  I hadn't build a resting place for it on top of<br />
the chimes, but it is definitely something I will need to do if I want<br />
to make the project viable.  Also, the wiring was a mess.  I added +5V<br />
to the center chime, and the rest were grounded, acting as switches to<br />
individual digital in.  These wires, with the LED's made a complete<br />
mess.  I need to redesign all the wiring, which will not be easy, to<br />
make the chimes look decent.<br />
<br />
<table width=768><tr><td valign=top><br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-16_10:40:08.jpg"></td></tr><tr><td><img height=320 width=240 src="http://e-sa.org/photos/2007/2007-09-18_12:02:48.jpg"> <br />
</td></tr></table><br />
<br />
<a href="http://e-sa.org/itp/physcomp">Up</a><br />
<br />
-- Wed, 19 Sep 2007 08:28 -0400<br />
			]]></description>
		</item>
		<item>
			<pubDate>Sun, 09 Sep 2007 21:26 -0400 </pubDate>
			<title>Week 1, Lab, Electronics</title>
			<link>http://e-sa.org/data/view?fn=20070909_1189387432.txt</link>
			<guid>http://e-sa.org/data/view?fn=20070909_1189387432.txt</guid>
			<description><![CDATA[

Introduction to Physical Computing<br />
Week 1, Lab: Electronics<br />
<br />
Here is the ITP intro physcomp <a href="http://itp.nyu.edu/physcomp/Labs/Electronics">link</a> for the lab.<br />
<br />
Step 1.<br />
<br />
The lab writeup doesn't say much about the LM7805 voltage regulator.  <br />
I recommend checking out the <a href="http://www.national.com/mpf/LM/LM78M05.html">datasheet</a>. <br />
<br />
I think National's site is pretty easy to understand, and they'll send<br />
you free samples if you ask.  You'll want to put 12V (your power source)<br />
on the "IN" side, and the "OUT" will output 5V.<br />
<br />
<table width=768><tr><td><br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-09_10:40:48.jpg"> <img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-09_11:29:06.jpg"><br />
</td></tr></table><br />
<br />
Step 2.<br />
<br />
220 Ohms, think Red.  And red.<br />
<br />
<table width=768><tr><td><br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-09_11:50:16.jpg"> <img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-09_11:51:08.jpg"><br />
</td></tr></table><br />
<br />
Step 3.<br />
<br />
The voltage is equally dispersed between the two LED's (~2.5V).<br />
5/3 volts (1.6V) isn't enough to power 3 LED's, so if you inserted a third none<br />
of them would light.  And the world would be dark.<br />
<br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-09_12:25:06.jpg"><br />
<br />
Step 4. <br />
<br />
When I measured the amperage, I read 60 mA.  I assume that this is<br />
because it was the amperage across all three LED's in the parallel<br />
circuit, which works out to 20 mA per LED (much more reasonable).  I<br />
returned to a single LED (w/resistor) and read the amperage which was<br />
~20 mA.<br />
<br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-09_12:35:24.jpg"><br />
<br />
Step 5.<br />
<br />
I love things that turn.<br />
<br />
<table width=768><tr><td><br />
<img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-09_13:03:20.jpg"> <img height=240 width=320 src="http://e-sa.org/photos/2007/2007-09-09_13:11:32.jpg"><br />
</td></tr></table><br />
<br />
<a href="http://e-sa.org/itp/physcomp">Up</a><br />
<br />
-- Sun, 09 Sep 2007 21:26 -0400 <br />
			]]></description>
		</item>
	</channel>
</rss>
