A slideshow of our presentation can be found on Slidshare.

On Monday, December 10 Katie, Liz and I presented our final Physical Computing project in class.  We started with a demonstration:

Then we 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, Katie created this great and exact diagram specifying the placement of the parts on the backboard:

PComp Final Project – Diagram for Placing Components on 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!)

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.

Final Rebuild – Refiguring the Components into an Enclosed Chute.

Redesigned Chute with Funnel House and Measuring Cup

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.

Conversion Chart and Data Recipes

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.

More pictures of the final build below.  And here is our final Arduino and Processing code, in a PDF: PComp_Final_ArduinoAndProcessingCode.

Final Project – Housing Crisis Sound Visualization

Funnel inside an upside down house

Measuring Cup Receptacle

The final project process was an intense learning experience.  Some things I’ll be keeping in mind going forward:

• Understand exactly what the problem is and carefully evaluate the best way to solve it.  In our case, there were two points at which we should have considered abandoning the moving arm mechanism: after unintentionally building a catapult and after building the chipboard model which only worked moderately well.  A redesign at either of those points wouldn’t have had such an impact on the time available to build out the narrative.
• Make sure to keep the centerpiece of your project in the center.  We allowed ourselves to push the narrative elements to the side because without a working mechanism and circuit, there would be no vehicle for the narratives.  The end result was a working mechanism that didn’t carry much weight.
• Think through feedback and ask questions. We heard a lot of helpful things from our classmates, but we didn’t ask about the best way to implement those suggestions.

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:

Physical Computing – Final Project Diagram – Version 2

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.

Physical Computing Final Project – Cardboard Mockup

Physical Computing Final Project – Cardboard Mockup

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.

Physical Computing Final – Corrugated Plastic Prototype

Physical Computing Final – Corrugated Plastic Funnel

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 springback.

Physical Computing Final – Acrylic “Final”. It looks so nice but it’s just a catapult!

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.)

Right after completing the midterm project for Physical Computing, we moved into work on our final.  Katie Adee, Liz Khoo and I decided to continue working together.

We decided to create a 3D data visualization of the housing crisis in the U.S.  In addition to using physical elements, we want to make sound a significant part of the experience.  For that reason, we’ve dubbed the project a sound visualization, or “soundualization”.  Here’s a description:

A sound visualization (soundualization) 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.

And here’s an initial diagram:

Physical Computing – Initial Diagram of Final Project

And, of course, what concept and diagram would be complete without a budget:

Our Physical Computing midterm project was due on Monday, November 12.  Here’s a PDF of Physical Computing midterm presentation (this document contains diagrams and code in addition to the photos and videos in this post).  We worked tirelessly in the weeks leading up to the due date to perfect our build, the circuit, and our backup plan.  Before I go any further, here’s a demo of the working project:

Katie built the wooden frame with one side not permanently joined so that we could insert the shade and make adjustments easily.  This design worked really well.

We conducted a lot of test cuts on the mylar using the vinyl cutter.  This process not only informed the settings of the machine but also helped us to determine which pattern we wanted to use for the final shade.  The ideal pattern allows and blocks roughly equal amounts of light, uses pointy shapes instead of rounded shapes, and has significant repetition.  Based on this, we picked a pattern and began the long process of cutting.  Here’s some documentation of that process.  As you can see, the best we could get the vinyl cutter to do still wasn’t good enough; Liz and I had to manually remove many of the cutout pieces.

Before assembling the final product, we had to test the assembly.  Using an extra piece of mylar, we tried different dowels, different adhesives (for traction) and lubricants (for smooth motion), and methods for connecting the ends of the mylar.  The most significant discovery was that we needed to use aluminum dowels rather than wooden ones, which were slightly warped.

As we were working on the build, we were also perfecting our circuit.  The six-position switch was more difficult to use than anticipated.  But with a little help from the residents, we got it figured out.  Turns out we just needed a little continuity test to get the pin situation straightened out.  Our motor also gave us some problems.  With help from Scott, we learned that the particular motor we had was wired a bit oddly.  Thankfully, he loaned us a different stepper motor which we were able to integrate into our circuit.  Here’s a digram of our completed circuit (Fritzing didn’t have some of the components, so the final diagram is a little wonky looking…):

Most of the circuit for our Physical Computing midterm, including a stepper motor and a motion sensor (the six-position switch has yet to be incorporated).

Midterm Wiring Diagram (some parts aren’t represented well with icons)

We built a housing for our circuit both to hide the electrical components and to provide information about the different settings.  The icons represent five settings: the shade can be fully opened or fully closed, move slowly or quickly, or sense motion.

Then… we brought it all together!  Putting the shade into the frame took patience and precision, and there were times when the motor just didn’t want to turn that dowel, but we were very happy when it worked (video at the top, image below).

Responsive Window Shade (video at the top of this post).

One of the ideas behind this project was that as varying amounts and types of light came through the window shade, the pattern/movement of the pattern would create pleasing shadows.  Here’s a simulation of the shadows:

Because the shade didn’t work consistently, we also built a backup using Processing.  In this video, you can see that the interface simply controls a Processing sketch that’s been loaded with an image of the pattern.

The midterm was an informative process.  Instead of trying to coherently assemble the things I learned into a paragraph, I’ll simply list a few of the top picks here:

• Iteration is key.  Ideally we would have built a prototype before building our, um, final prototype.  This would have helped us pinpoint the weaknesses in the design earlier on.
• Projects that require extreme precision can be difficult to pull off successfully.  I didn’t fully realize the precision necessary to bring this together flawlessly.  The mylar had to fit inside the frame exactly with the edges hiding within the frame but not actually touching it; the dowel had to turn with as little friction as possible where it connected to the frame but friction was necessary to rotate the mylar; the surface tension of the cut mylar had to be equal across all areas for a perfectly smooth rotation.
• A Plan B is essential.  Without our backup Processing sketch, this project would not have been as successful.  I was glad we’d worked out a mockup of the project which demonstrated success with our circuit and code, even if our build wasn’t exactly perfect.