Voices of the 4.5 Million PComp Final

We began with a demonstration of the final build. We then discussed our process, reviewing the work we’d done since the final (presented here in the previous Playtesting & Prototyping post) and then summarizing our most recent work.  In the week between our continued playtesting & prototyping presentation and the final presentation, we did a lot, including a redesign.  After building the mechanism from chipboard, we thought we were ready to construct the final product from acrylic and put it on the plywood backing.  As an extra precaution, I created this  diagram specifying the placement of the parts on the backboard:

We knew we would have to adjust the placement of the counterweights, so we first assembled the arms using blue tape since the plasti-weld is quite permanent.  We measured and drilled holes in the backboard and slid everything into place.  Then we conducted a test — we held the funnel house in place and poured beans through it into the small arm.  The arm filled, tipped, and dumped the beans over the top of the second arm sending them flying everywhere except into the mouth of the second arm, where they should have gone.  We tried again, adjusting the counterweight on the first arm so that it would tip with fewer beans.  The result was better, but it didn’t work nearly as well as it had with the chipboard.  Why?  The best explanation we could come up with was that the chipboard was providing some necessary weight and friction that we weren’t getting with the acrylic.  (Unfortunately we have no photos or videos of this phase, but here is a montage of our process…)

After this fail, we decided it was time for a redesign.  We’d struggled with the challenge of aligning the two arms through four iterations and it was time to face the fact that we might never get this mechanism to work properly.  We went back to a design quite similar to our initial conception: an enclosed chute that moves the beans from the funnel house to the measuring cup receptacle.

Redesigning the mechanism meant we also had to rethink our circuit.  We had intended for the moving arm to connect two components, therefore acting as a switch.  With no moving parts this would no longer work.  If at all possible, we wanted to incorporate sensors that could be integrated using our existing code or something very close to it.  We settled on two flex sensors.  Although analog, we could map them to 0 or 1 in order to replicate the data sent from a digital sensor.  The enclosed chute had seams where the parts were fitted together and the flex sensor is thin enough to fit into that seam.  The result is that the sensors are barely visible, which is nice.

After making this design change, we were able to progress fairly smoothly.  We tested the enclosed chute with the funnel house and found that the beans moved quickly and easily from the funnel to the measuring cup.  Almost all of the beans made it into the end receptacle, a huge improvement over previous mechanisms.  We integrated the flex sensors into our circuit, measured the values, and mapped the data output to the 0 or 1 for Processing to read.  Then we brought the circuit together with the mechanism and got it functioning.

Once that was done, we were able to work on the presentation of the narrative.  With the redesigned chute, we had a nice open space on our backboard and we decided that would be a nice place to present the title, some data, and some contextual information.  We thought for a while about how to bring more context and data back into the project.  Initially, we’d based the project around state data, comparing foreclosure data in different states.  That aspect was lost when we moved to the cantilever arm construction.  We went back to the resources we’d initially collected and discovered that we had some nice points of comparison — peak monthly foreclosures, “normal” monthly foreclosures, recent (October 2012) data by state.  In keeping with the homey theme and aesthetic of the project, we decided to present this information in the form of recipes and wrote out a few recipe cards that users would be able to read and use as a guide for operating the project.  And we made the decision to put a “conversion chart” between the beans and the number of foreclosed homes in a picture frame.

One thing we didn’t have time to do was source better sound files and build out a more intimate listening experience.  Our conversations about this project with residents and classmates reinforced the fact that individual stories were the most engaging element of the project.  We’d tried to create an intimate experience, but we were asking people to listen from afar instead of leaning in and connecting with the storyteller.  It would have been nice to have a bank of speakers, each one of which played an individual story.  That way the user could pay close attention to one by leaning in close, or feel the gravity of the situation and become overwhelmed by standing back and hearing many voices at once.

Ideally, we would have had more time to think about and perfect the narrative aspect of the project.  We ended up spending too much time wrestling with the moving parts and the interpretation of the data and structure of the narrative suffered as a result.

Here is our final Arduino and Processing code, in a PDF: PComp_Final_ArduinoAndProcessingCode.

Physical Computing – Final Project – Playtesting & Prototyping

We received a lot of good feedback from our class on our final project concept presentation and adjusted our concept accordingly.  Some comments included:

  • Use short sound bites (a sentence or two) instead of a longer narrative story
  • Create a relationship between the speed at which someone pours the beans into the funnel and how quickly the stories come “pouring” out of the speaker.  A fast pour would trigger many stories (people talking over each other) and create a waterfall effect.
  • Incorporate moving parts between the funnel and the shoot.
  • Use a scoop to draw from a large container of beans instead of pre-portioned bags.
  • Make sure something happens right away to give users feedback.

This feedback got us talking about how to modify our project.  We all felt that the project should be built around the personal stories; the interface and any other auditory output should support the narratives.  Considering this, we redesigned the mechanism to incorporate two cantilevered arms, each of which will trigger a sound file to play when it moves.  The user will pour beans into a funnel which will deliver the beans into a receptacle at the end of one arm.  When the receptacle is full, the arm will tip, dumping the beans into a second receptacle at the end of a second arm and triggering a story.  Similarly, when the second receptacle is full, the arm will tip, dumping beans into a container and triggering a second story to play.  A second (or third, or fourth…) story will play even if the stories triggered prior haven’t ended, creating a waterfall of stories.  In order to help a user listen to one story all the way through, we will make sure the voices vary.  Perhaps a digram here would be helpful:

As you can see, we also decided to have the user draw from a large container of beans using a scoop instead of having portioned bags.  One drawback to this is that we loose the connection to state statistics.  We are still thinking about ways to bring this back in, as it was an important part of our initial concept. With this new design, we started to build prototypes.  Our first was a mockup made from cardboard, wooden dowels, plastic cups and used batteries as counterweights.  It’s not much to look at, but it helped us to realize some immediate issues.

  • We would need an established ratio between the small and large receptacles.
  • Alignment between the receptacles is crucial to successful operation.
  • Determining the weight and position of the counterbalance will take time and is important to do precisely.
  • We cannot rely on moving parts to trigger the sound files to play.  Instead of using an accelerometer to sense motion, for example, we decided to make a small part of the arm conductive and use it to complete a circuit.

 

 

The second version was made from corrugated plastic.  This material was easy to cut and assemble, but weighs next to nothing so it’s not a great substitute for acrylic, which we hope to use as the material for the final product.  In this version, we built the receptacle into the arm (instead of adhering something to it) and worked with the size and shape of the funnel (which will resemble an upside down house).  This version helped us to understand that the counterweight should also be built into the arm.

From here, we thought we had our design finalized and we went ahead and cut the cantilevered arms from acrylic.  We assembled two arms, filled the counterbalance compartments with beans, and affixed them to an MDF backboard.  We began to fill the first receptacle with scoops of beans, it started to lower, it started to pour the beans into the second arm.  We were hopeful!  Then, with the weight in the receptacle reduced, the counterbalance caused the arm to spring up, launching beans all over the room.  We’d accidentally built a bean catapult.  We understood immediately that the counterbalance needed to move with the arm in order to eliminate the forceful recoil.

So we built one more prototype, from laser cut chipboard (a horrible material to lasercut, by the way…).  We redesigned the arms so that the beans coming in would also act as the counterbalance and, as the arm tipped, the weight would be more evenly distributed and create a smooth tip down and back up.  This solution was inspired by hollow bamboo water fountains where the weight of the water tips the arms.

While we successfully got the first arm to tip, this prototype still needs improvement.  For our final design, we will need to make the following adjustments:

  • Make the second arm the same height as the first but twice the width (so that there’s still room for the beans to pour but doesn’t require 4 times as many beans to pour into the final receptacle).  In the above prototype, both the height and width of the second arm were twice as large as the small arm.
  • Use metal dowels (instead of wooden or acrylic) to support the weight of the arms.  Other materials won’t be able to support the weight, resulting in bending that tilts the arm in toward the backboard and creates friction.
  • Ditch the shoot at the end (between the second arm and the final receptacle).  It adds unnecessary height and doesn’t get us much in the way of sound or visuals.
  • Figure out how to ensure that the arm doesn’t hover between filling and tipping states.  This position will throw off the alignment with the funnel so no additional beans will make it into the receptacle.  (This is going to be difficult to manage.)
So here is the final frame, but we will be testing and calibrating with a sheet of MDF before drilling into the back board.

 

 

 

US Housing Foreclosure Soundulization

A sound visualization (soundulization) of the foreclosure crisis that has gripped the US since January 2007.  According to the foreclosure data firm RealtyTrac, from January 2007 through September 2012, about 4.5 million housing units have been foreclosed.

Although the crisis affects all of us, perhaps the impact has not been as direct for some people. This project aims to tell the story of crisis by providing context to the big abstract number of home foreclosures and bring a personal-level of understanding via stories told by homeowners who have been affected.

One inspiration for this project was a Planet Money/Weekend Edition story which used the sound of candy corn to represent monetary sums explaining the income gap.  This project will use dried beans to represent number of foreclosures.  The interface will be a few bags of beans on a table, each labeled with the name of a state (we will start small with three representative states).  The bags are opaque so that the user can’t see what’s inside.  The user picks up a bag and pours the contents into a funnel, the beans trickle out of the funnel, down a track, and into a large clear container.  As the beans are poured into the funnel and make their way down the track, they produce a “plinking” noise which soundulizes the quantity of foreclosures.  As users pick up more bags of beans and pour them into the funnel, the glass container begins to fill until it eventually represents the total number of foreclosures since the housing bubble burst.  The clear container will be marked with numbers (.5 million, 1 million, 1.5 million, etc) like a measuring cup and possibly also years/quarters or historical events so that it’s clear what’s being measured and by what units.

In addition to the sound of the beans, we’d like to incorporate personal stories from homeowners.  We plan to use photocells under each bag and inside the funnel.  When the photocell under the bag is exposed to light, and when light is removed from the one in the funnel, a story from a homeowner in that state will begin to play.  These personal narratives will provide additional context to what happened in each state.

Initial Diagram:

Initial Budget :

 

Item Quantity Unit Cost Total Cost
1/4″x2′x1′ clear plexi sheet for funnel and pathway 2 $14.00 $28.00
1/2×2′x4′ plywood for table 1 $9.00 $9.00
5lb dried beans 1 $10 $10
Photosensors 4 $0.00 own already
Speakers 2 $0.00 borrow from ER
Misc Hardware tbd tbd $20.00
Breadboard 1 $0.00 own already
Arduino Uno 1 $0.00 own already
Laptop 1 $0.00 own already
Total $67.00

Video Documentation Responsive Window Shade

Presentation PDF

Final Arduino Code for Processing Simulation

/*Intro to PComp Mid-term Fall 2012
Liz Khoo, Natalie Tschechaniuk, Katie Adee
-----Responsive Moire Window Shade-----
Parts:
 - 18"x18" frame with dowels
 - 6-position rotary switch
 - Parallax PIR motion sensor
 - Unipolar step motor
 - Arduino UNO
 - Breadboard
 */
#include
const int switchPin1 = 2;
 const int switchPin2 = 3;
 const int switchPin3 = 4;
 const int switchPin4 = 5;
 const int switchPin5 = 6;
 const int switchPin6 = 7;
const int stepsPerRevolution = 100; //motor is Mabuchi # PF35T-48L4 w/3.6 degree steps
 Stepper myStepper(stepsPerRevolution, 8,9,10,11);
 int stepCount = 0;
int switch1Value = 0;
 int switch2Value = 0;
 int switch3Value = 0;
 int switch4Value = 0;
 int switch5Value = 0;
 int switch6Value = 0;
int pirPin = 12;
 int pirState = LOW;
 //int pirVal = 0;
void setup() {
pinMode(switchPin1, INPUT);
 pinMode(switchPin2, INPUT);
 pinMode(switchPin3, INPUT);
 pinMode(switchPin4, INPUT);
 pinMode(switchPin5, INPUT);
 pinMode(switchPin6, INPUT);
 pinMode(pirPin, INPUT);
Serial.begin(9600);
 establishContact();
 }
void loop(){
//ON--slow 1 step/ 3 sec
 if (switch2Value == 1){
 myStepper.step(1);
 //Serial.print("step count: ");
 //Serial.println(stepCount);
 stepCount++;
 delay(3000);
 }
//ON--medium 1 step/ 1 sec
 if (switch3Value == 1){
 myStepper.step(1);
 //Serial.print("step count: ");
 //Serial.println(stepCount);
 stepCount++;
 delay(1000);
 }
//ON--motion responsive/high 1 step/half sec
 pirState = digitalRead(pirPin);
if (switch4Value == 1 && pirState == HIGH){
 myStepper.step(1);
 // Serial.print("step count: ");
 // Serial.print(stepCount);
 //Serial.print(", pirVal: ");
 //Serial.println(pirVal);
 stepCount++;
 // delay(500);
 }
switch1Value = digitalRead(switchPin1); //OFF--aligned open
 // Serial.print("Position 1: ");
 Serial.print(switch1Value);
 Serial.print(",");
switch2Value = digitalRead(switchPin2); //ON--slow 1 step/ 3 sec
 // Serial.print("Position 2: ");
 Serial.print(switch2Value);
 Serial.print(",");
switch3Value = digitalRead(switchPin3); //ON--medium 1 step/ 1 sec
 // Serial.print("Position 3: ");
 Serial.print(switch3Value);
 Serial.print(",");
switch4Value = digitalRead(switchPin4); //ON--motion responsive/high 1 step/half sec
 // Serial.print("Position 4: ");
 Serial.print(switch4Value);
 Serial.print(",");
Serial.print(map(pirState,LOW,HIGH,0,1));
 Serial.print(",");
switch5Value = digitalRead(switchPin5); //OFF--aligned closed
 // Serial.print("Position 5: ");
 Serial.print(switch5Value);
Serial.println();
 }
void establishContact() {
 while (Serial.available()  Serial.println("hello"); // send a starting message
 delay(300);
 }
 }

Final Processing Code for Screen Simulation

import processing.serial.*;
 PImage pattern1;
Serial myPort;
float switch1, switch2, switch3, switch4, switch5, pirVal;
 boolean firstContact = false;
 int ypos = 0;
void setup() {
 size(1000, 1000);
String portName = Serial.list()[4];
 myPort = new Serial(this, portName, 9600);
 myPort.bufferUntil('\n');
pattern1= loadImage("http://itp.katieadee.com/pcomp/PF.png");
 }
void draw() {
 background(255);
image(pattern1, 0, ypos-1060);
 image(pattern1, 0, -ypos);
if (ypos >= 530) {
 ypos = 0;
 }
 }
void serialEvent(Serial myPort) {
String myString = myPort.readStringUntil('\n');
 if (myString != null) {
 myString = trim(myString);
// if you haven't heard from the microncontroller yet, listen:
 if (firstContact == false) {
 if (myString.equals("hello")) {
 myPort.clear(); // clear the serial port buffer
 firstContact = true; // you've had first contact from the microcontroller
 myPort.write('A'); // ask for more
 }
 }
 else {
int switches[] = int(split(myString, ','));
 for (int sensorNum = 0; sensorNum < switches.length; sensorNum++) { print("Sensor " + sensorNum + ": " + switches[sensorNum] + "\t"); } println(); if (switches.length > 1) {
//open
 if (switches[0] == 1) {
 if(ypos!=0){
 ypos+=1;
 }
 if (ypos >= 530) {
 ypos = 0;
 }
 }
//slow
 else if (switches[1] == 1) {
 ypos += 1;
 }
 //fast
 else if (switches[2] == 1) {
 ypos += 2;
 }
//use motion sensor
 else if (switches[3] == 1&&switches[4] == 1 ) {
 ypos += 3;
 }
//close
 else if (switches[5] == 1) {
 if(ypos!=265){
 ypos+=1;
 }
 if (ypos >= 530) {
 ypos = 0;
 }
 }
 }
// when you've parsed the data you have, ask for more:
 myPort.write("A");
 }
 }
 }

Frame Construction – Responsive Window Shade

Frame joins and no glue make for quick disassembly.

I made the frame a few weeks back. Which definitely saved some time during the crunch.

While we were deciding on a final pattern. Natalie did some material/settings tests with the vinyl cutter, so we would not waste time or materials later on.

We tested both thin and thick mylar

Thin mylar ripped when the settings for the blade were to high or fast

Finally, Natalie found the best settings for the thin mylar

After finding ideal settings, we tested a portion of the final pattern at different scales.

It took a few hours to cut the final screen.

It took quite a bit of time to remove the mylar from the contact paper, and make sure all cutouts were removed without ripping.

Play Test

For our PComp midterm project–a moving window shade–we developed a Processing sketch that would mimic the movement of the real window shade.

This play test includes two buttons and a potentiometer. The sticky note just indicates where the buttons and potentiometer are. The note did not say what the buttons and dial did.

The user’s inclination was the push the buttons many times. After a few seconds, he figured out that the first button stopped motion; the dial controlled speed, and the second button moved the shade at that set speed.

When prompted to set the shade to “open” all the way without moving, there was difficulty controlling the potentiometer so that it was exactly closed.


Also, built 18″x18″ frame for shade. Used frame joints & no glue so that we can easily assemble and disassemble as we test. (Will bring to studio once the train situation is less hectic).

Midterm Project Description

Katie Adee, Liz Khoo, Natalie Tschechaniuk

Create a paper window screen that is kinetic and responds to user input.  A loop of paper, the length of which is equal to the height of a window, is fitted around two dowels, one at the top of the loop and the other at the bottom.  The dowels are set within the window frame.  The paper has a cutout pattern which allows light to come through.  The pattern is repeated so that the front and back of the paper loop can be aligned exactly (the negative spaces match up to allow a maximum amount of light to shine through) or not aligned at all (the negative space matches with positive space to block light).  When moving between those settings, the cutout patterns merge and depart from one another, creating new patterns on the screen and on the floor/wall from the sunlight.

The user can adjust the setting of the screen (light, privacy, in between, in motion) using a potentiometer or switch.  Another thought is that a motion sensor/ photo sensor enables the screen to respond to the user’s approach or presence of sunlight — it will begin to move when a person is nearby, for example.

Things we hope to discover from our playtesting:

  • Positioning of motor in relation to the dowel and the paper loop
  • Positioning of photosensor/ motion sensor
  • Most desirable patterns

Goals of the pattern:

  • makes interesting/beautiful patterns on floor/wall when light shines from behind (i.e. comes in the window);
  • makes interesting/beautiful pattern when in motion (not dizzying)
  • allow light in when pattern is aligned exactly;
  • create privacy when patterned is not at all aligned;

Initial Bill of Materials

Item Quantity Purpose Cost Supplier
dowels/wooden rods 2 secure both ends of patterned loop $3-$8 each Home Depot 
roll of paper/ mylar roll we need to get enough for multiple tests primary component of project $65 (we probably don’t need to buy a whole roll, need to investigate further) Pearl Paint 
DC motor – with speed control and continuous rotation 1 control motion direction and speed based on voltage/input $10 Use the motor from our kit for testing,
buy a different one if necessary
rubber/grippy material for end of each dowel 4 pieces (maybe 1-2″ wide, length the same as the dowel diameter) wrap each end of the dowel to better grip the paper as it rolls $10 canal rubber
motion sensor 1 sense proximity of person or presence of sunlight – initiate motion $1 Adafruit 
window frame 1 hold the dowels and the paper roll free Katie’s scrap wood
potentiometer 1 allow user to manually adjust the paper roll/ 5 thresholds to read for 5 possible states $1 Adafruit