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.

The week 6 lab is an introduction to DC motors and transistors.  Our midterm project will incorporate a motor, so this lab (as well as week 7) will help us determine which type of motor to use and how to set up our circuit.

First, we set up the circuit with a potentiometer, a transistor, a small DC motor, and an additional power supply for the motor.  You can control both the direction and the speed of a DC motor.  Direction is controlled by which lead is connected to power — to reverse the direction, just reverse the polarity.  Speed is controlled by voltage — to achieve a slower speed, reduce the voltage, for a faster speed, increase the voltage.  In this lab, we will use the potentiometer to control the speed of the DC motor.

Here are a couple pictures of the circuit setup:

Because the DC motor receives power from a separate power supply that is greater than the 5v supplied by the Arduino, it’s necessary to include a transistor which acts like a switch.  The transistor has three legs: the base (which is connected to the Arduino output), the collector (connected to the high-current load), and the emitter (connected to ground).  One final component is a diode on the connector leg.  When the DC motor stops spinning, some current will come back in the reverse direction of the current flow.  The diode prevents this back voltage from reaching (and harming) the transistor.

Now that the circuit is complete, we write some code for the Arduino (no Processing in this lab) to move the motor.  The first program makes the motor spin, pause, repeat.  Here’s a video: DCMotor_StartAndStop_Wk6Lab_121105

The second program uses the potentiometer to control the speed of the motor.  Here’s a video of that:DCMotor_PotControls_LabWk6

This little DC motor spins surprisingly fast.  I had attached a little paper flag to better visualize the movement and it flew off immediately.  I had to replace it with a piece of very sticky tape.

The week 5 lab for Physical Computing was on serial duplex, an expansion of last week’s lab on serial communication.  This lab took me a long time to complete, I think because of the amount of code there was to understand and replicate.

In this lab, we set up a circuit with two analog inputs and one digital input.  I used a FSR, a photocell, and a button.  The first step was to simply send and read the data in the serial monitor.  We programmed the Arduino to send the data from one sensor in many different formats — including raw binary, ASCII encoded binary, ASCII encoded decimal, hexadecimal, and octal.  Here is a picture of my circuit setup and a screenshot of the serial monitor:

Circuit Setup for Week 5 Lab – Serial Duplex

Data in Many Formats

The next step in the lab was to put together the code to send the values of all three inputs instead of just one and figure out which value corresponds to which sensor.  This lab covers both the punctuation method and the call-and-response (handshake) method.

Punctuation Method: The first part uses the punctuation method which means that each set of data (in this case, one reading from each of three sensors) ends with a specific type of punctuation to indicate that’s the end, this data set is now complete. We wrote the Arduino code that reads the value from each sensor, prints the sensor value, then prints a comma after the first two sensor readings.  For the final sensor, we use Serial.println instead of Serial.print so that we get a carriage return and a linefeed at the end.  The result is three numbers separated by commas on each line and we know that the first value corresponds to the analog sensor in A0 (the photocell), the second value corresponds to the analog sensor in A1 (the FSR), and the third value corresponds to the switch.  Next we had to write the Processing code to receive and read the values.  (Eventually, we’ll use this information to draw a ball and make it move!)

Similar to the first serial communication lab, we have to import Processing’s serial library at the top of the code and make a global variable which will hold the serial port (in my case this is always 4).  We add a new line of code in setup: myPort.bufferUntil(‘\n’);  This line says wait to call serialEvent until the ASCII newline byte comes into the serial buffer.  ’\n’ means “newline” and the ASCII value for that is 10.  We get “newline” after the third sensor value has been read (that’s why we used Serial.println) so what this means is that the bytes will be read into the buffer until a linefeed is sent, then serial.Event will be called.

In serial.Event the sensor readings come in and are put in a string, then the string is split at the commas and the values are converted to integers.  Then we use a for loop to print out the sensor number and corresponding value.  Here’s a screenshot of Processing receiving the information from the sensors:

Processing Reads the Sensors!

What’s exciting is that now we have a bunch of integers that we can use to make something — like a ball that moves around.  To do this, we created some variables (xpos and ypos) and then assigned the sensor values to them.  (There’s a video at the end of this post.)

Call-and-Response Method: Next, we modified the code (both Arduino and Processing) so that Processing has to request new data when it’s done reading the data it has.  For Arduino, we added a method called establishContact() which sends out a message until it gets a byte of data.  Here’s a screenshot of the serial monitor after adjusting the code — it prints out “hello” until you type something into the box and hit “send”, at which point the sensor values are returned:

Hello!

In Processing, we create a new global variable called firstContact.  This determines whether or not Arduino has sent anything.  Processing will listen until it gets something from Arduino.  Once firstContact becomes true, then Processing will split the string at the commas and convert them to integers (just like in the punctuation method) and then print the sensor numbers and values.  After this unit of data has been parsed, we tell processing to write to the serial port which sends a request back to the microcontroller asking for more data.  And, again, we can use this information to make a ball and move it around.  This is a quicktime video of me controlling the ball with the photocell, FSR, and button.  The movement is erratic to say the least.  SerialDuplex_Wk5Lab_SensorsControlBall_121026

The results of using the punctuation method and the call-and-response method are the same in this lab — the format of the printed values and the movement of the ball look the same.  Although the code is complex, and I can’t say that I completely and fully understand it entirely, conceptually, I like the call-and-response method better.  Since the two devices are in communication with each other, it makes sense for this to go in both directions.  And it seems cleaner to send data one unit at a time when the receiving program is ready rather than just sending information continually and hoping that the receiving program can keep up.

This week for our Physical Computing midterm we had to do some playtesting of the concept.  We collected materials on Thursday and were really excited about a six position switch that we bought.  We are hoping that this switch will allow the user to control five or six different states of the kinetic window screen: 1) closed (static), 2) slow motion, 3) faster motion, 4) open (static), 5) “automatic” / responsive mode – connect to a distance sensor (or photocell for playtesting), possible position 6) medium speed.

We started by working on the Processing and Arduino code that would control the movement of two patterns and we setup the circuit using a couple of buttons.  Pressing one button triggers quick motion, pressing the second triggers slow motion.  We got this working successfully and planned to elaborate on this setup–to bring in the switch and a photocell–but Hurricane Sandy prevented us from reaching the floor (where our new materials are stored) on Sunday.  We will have to resume this test early this week, as it’s essential for us to properly figure out the circuit before moving forward with the project.

Liz was able to have her boyfriend test a basic setup based on our aforementioned work.  She brought in a potentiometer to the circuit and adjusted the function of the buttons — one button stops the motion, the other starts the motion, and the potentiometer controls the speed.  Here’s a video of that test:  P Comp Midterm Playtest

While this is a good start, we need to expand on the testing and build out the complete circuit.  Also, we’d like to determine which type of motor we’ll use.  We were able to borrow a stepper motor for our testing, and this week’s lab and lessons are about DC motors, so we should be well positioned to make this decision shortly.

We’ve started to work on our Physical Computing midterm and will be discussing the concept in class today, Monday, October 22.  Katie, Liz and I are working together on a kinetic window screen.  Our inspiration came from a few sources.  First, we liked the idea of trying to create something which is both aesthetically pleasing and functional.  The screen creates privacy and allows light in but also creates patterns as the movement and light levels vary.  Second, we were interested in playing around with a moire effect and thinking about how to create such effects using overlapping patterns.    Third, we wanted the cutout patterns to reflect patterns in nature, for example: pebbles, cut fruit, cellular structures.  Because moire has its origins in textiles, we originally thought we would use fabric for the screens.  As our conversations about the project progressed, we began to consider using high quality paper instead of fabric.  This is primarily an economic consideration, but has a couple additional advantages over fabric: it’s easier to use with the laser cutter and, because it’s less expensive, we can test out multiple patterns before deciding on the final one.

Here’s a short description:

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.

And here’s a labeled diagram:

Diagram for our Physical Computing midterm project.

And a preliminary list of materials:

There are a few patterns we’re considering.  Next week, during the playtesting phase of the project, we’ll experiment with different patterns and determine which one(s) we’ll use.  Some look more promising than others, but animating them in processing will give us a better idea of how they’ll look when built out.  Katie generated these patterns using using rvb and Rhino.

Possible patterns for the paper loop.

This week in Physical Computing the lab was about serial communication (specifically, serial output).  This is the big time–we’re learning how to get two electronic devices (yeah, like the computer and the Arduino) to talk to each other.  In this lab, we sent data from the potentiometer to the computer and graphed the output.  The result was that, when you adjusted the potentiometer, a graph in a Processing sketch changed accordingly.

First, I set up the circuit connecting the potentiometer to analog pin A0.  Then, I programmed the Arduino to read the analog sensor and print the results to the serial monitor.  This instruction was pretty familiar but then came a twist — to use Serial.write() instead of Serial.println(), which will send the sensor value serially.  The result is that instead of seeing numerical values in the serial monitor (like we have in the past) we see a bunch of characters that make no sense at all.  As I continued through the lab, I learned that these are ASCII characters.  Serial.write() sends out the sensor reading value as a binary and then the serial monitor receives this information in bytes and displays the ASCII character which corresponds to that byte.  OK, so, why?  Well, the computers talk to each other in bits and bytes, so the sensor reading needs to be sent in bytes in order for the computer to know how to read them.  It’s important to remember that both electronic devices need to be in agreement about the voltage, data rate, and order of interpretation of bits in order for communication to work.

The next part of the lab was to download and install CoolTerm, which allows you to see both the ASCII characters and the hexadecimal values.  Here’s a screenshot of my CoolTerm window:

Now we are going to graph the sensor values.  I wrote the sketch in Processing that will read the sensor values according to the instructions in the lab, making sure to include the Processing Serial Library.  The Arduino is sending data to the computer and this graph visualizes the sensor output.  Mine doesn’t look exactly like the image in the lab — instead of making peaks it sort of hits a plateau at the top, but I think it’s working properly.  Here’s a short screen capture video of my graph: Lab_Wk4_SerialCommunication_GraphOfOutput

This week for physical computing we had to complete two labs.  One using the servo motor (analog out) and the second involving tone output.

In the first lab, we set up the breadboard with a force sensing resistor and a servo motor and programmed the Arduino to map the FSR input to the servo’s 180 degree output.  Here’s a video of my working setup: ServoLabVideo  (You can see that as I apply more pressure to the FSR, the arm of the servo rotates more.)  This lab is my first exposure to controlling motion and using the servo motor is really cool.  Up until this point, I’ve been mostly making LEDs turn on and off, which is pretty satisfying, but having the ability to make things move is going to be great.

In the second lab, we set up the breadboard with a little speaker and two photocells then programmed the Arduino to play a tone that varied in frequency with the analog input.  As you move your hand over the photocells and adjust the amount of light that hits the cells, the frequency of the tone changes.  The volume of the tone output is very low (I used the speaker in the kit) and nearly impossible to capture using the camera on my phone, so here’s a picture of the working setup (no video).

The input from two photocells adjusts the frequency of the tone output.

The second part of the tone output lab was to use the same setup to play a tune.  This was accomplished by including a file called pitches.h and then putting the notes we want in the tune in an array variable.  This was all totally new to me so I had to use the code provided in the lab.  Even though I didn’t write this code myself, this part of the lab was really instructive.  Up until this point, I hadn’t realized the extent to which the output can be controlled by the code that you write.  The analog input labs last week started this thinking (making the LEDs toggle, for example) and I guess conceptually this should be obvious (you write the instructions and, if everything goes well, the circuit you build follows those instructions), but for whatever reason this little tune really brought it home.

This lab had a third section where we built a little musical instrument using three sensors as keys on a keyboard.  Again, we included the pitches.h file but this time used an if statement to control which sensor played which note.  The result was that you could play three different notes, each corresponding to one sensor.  This part of the lab was an excellent extension of the tune portion.  By working through this section, I was able to see the value of interaction.  Telling the circuit to play a tune is really fun for me, but might not be so interesting to anyone else.  Here’s a picture of the final setup.

Each sensor controls the output of one note.

So, three pretty big revelations in one week of labs: 1) motion is something that can be controlled, 2) you can tell your circuit what to do, and 3) you can even make those orders interactive (if you setup your circuit with interaction in mind).  Now to come up with a way to combine these ideas into a creative project…