Difficult Conversations: PComp Final Project Concept


One of the foundational metaphors of interaction design is Chris Crawford’s description of good conversation, from The Art of Interaction Design (I discussed this book in a previous post).  When I began to consider what I wanted to do for my final project for Physical Computing, I asked myself, “What is the conversation I most want to have right now?”  The response? A difficult one.

Continue reading Difficult Conversations: PComp Final Project Concept

PImage & Pixels: Image Processing


Week 7 of Introduction to Computational Media was devoted to image processing.  We focused in on the unit of the pixel, and considered the way in which the screen is a collection of integer and color values for each individual pixel, and using various methods we can operate on a single one or groups of them.

For our assignment, we were given the open-ended task of creating a Processing Sketch that experiments with manipulation of pixels via images (whether static, moving, or captured from a live camera).  I chose to see if I could play with the metaphor of mixing pixels to explore the relationship of my own portrait to that of Bret Harte, a figure from the history of my hometown (Eureka, CA, for the non-family out there reading this).

Continue reading PImage & Pixels: Image Processing

Stormchestra: PComp Midterm, Part 2

 photoOur working prototype, as of a few days ago.

In my last post I outlined the details of the Physical Computing Midterm project Rebecca and I have been working on.  We started by exploring the properties of three sensors: a piezo, a basic electret (from Radioshack), and a more complex electret (from Adafruit).

all 3 sensors

We found the first two sensors gave readings that were more erratic than we were prepared to deal with for this current task, so we proceeded with the Adafruit component. Rebecca began to look at ways to get smooth, workable values .

Continue reading Stormchestra: PComp Midterm, Part 2

A Tempest: Our PComp Midterm, Part 1


Adafruit Electret Mic.

Rebecca and I have been thinking about breath.  We decided that we wanted our midterm project for Physical Computing at ITP, which needed to involve Serial Communication, to use a sensor that would transduce breath into electrical information.

Our first test, upon recommendation, was to use a Piezo component.


We found that it did transmit serial data that could be read by Processing, but the data was erratic, the user experience was annoying (you have to put your mouth right up to the hole in the Piezo), and there was a lot of unwanted noise created by the body of the component.

Continue reading A Tempest: Our PComp Midterm, Part 1

Rockslide with Particles, Phase 2

Intro to Computational Media – Week 6
“Rockslide with Particles, Phase 2”


//Main Code

// ArrayList<RockSystem> rs;

RockSystem rs; //Delcare new RubbleSystem object

void setup() {
size(640, 450);
// rs = new ArrayList<RockSystem>();

rs = new RockSystem();

void draw() {

// Draws a mountain in the background
vertex(30, 275);
vertex(120, 150);
vertex(300, 88);
vertex(460, 130);
vertex(580, 300);

// for (RockSystem r: rs) {
// rs.bouncing();
// }


void mousePressed() { //Starts rocks falling, including exploders
// for (int i=0; i < 100; i++) {
// RockSystem r = rs.get(i);

Visit my GitHub for the rest of the code, including all the classes.

Two-Way (Duplex) Serial Communication, Part 2


In the first part of this lab for Week 5 of Physical Computing at ITP, we looked at the Punctuation method for ordering data in serial communications.  Now we’ll look at the Call-and-Response or Handshake Method.


This method works on the principal of sending the data separately, as opposed to an ongoing list that’s formatted for clarity (Punctuation method).  Each time the Arduino program wants to receive the data, it makes a new request.

We establish this system of requests by updating the Arduino code with a function called  “establishContact()”:

void establishContact() {
 while (Serial.available() <= 0) {
      Serial.println("hello");   // send a starting message
We modify the “loop()” phase of the program using an “if { ” statement to instruct it to look for incoming serial data, and retrain the rest of the Arduino sketch from the Punctuation method.
We now update the Processing code in a similar way (instructing the code to consider each new chunk of incoming data), except here we use a boolean (true/false) variable to manage the interpretation of the sensor readings.  The two images below show the full code:
Week4Lab2ProcessingHandshake Week4Lab2ProcessingHandshake3

The final result, in this case, is the same interaction of the physical interface on the breadboard and the ellipse on the screen.   By adjusting the analog sensors, or depressing the switch, will manipulate the circle within the Processing sketch.


There are, however, advantages and disadvantages to using either the Punctuation or Call-and-Response/Handshake method.  See the lab text for more details.

Two-Way (Duplex) Serial Communication, Part 1


In the first lab for Week 5 of Physical Computing at ITP, we looked at basic Serial Communication between our microcontroller and a computer.  In this second lab, we’ll be using multiple inputs on the Arduino (one digital, two analog) to output data onto software, starting with the Arduino IDE Serial Monitor and leading up to Processing.


Using the “Serial.println” command in the Arduino code, the output to the Serial Monitor default to an ASCII value between 0-255.


Now we add commands into the code that print the values in ASCII and a few other formats so we can see them side-by-side: the raw binary value, then the ASCII-encoded binary value, then the ASCII-encoded Decimal, Hexadecimal, and Octal values.  While these are not all commonly used in Physical Computing, familiarity with the relationships between them will be helpful in a range of applications.


Next we send the readings from all three sensors to the monitor.  The goal here is to be able to take those readings and utilize them within software.  The first hurdle we encounter is that the data comes in a string that doesn’t convey which sensor corresponds to which value.






There are two methods of ordering this data.  The first is the Punctuation  method.



Adding a command that includes a carriage return, causing a new line to be printed at the beginning of each cycle, will clarify that the first value is always the first sensor.


We refine the code by specifying each pin/sensor that will pass data serially.



We can proceed at this point to using Processing.  We write code that attaches an ellipse in the Processing sketch to the values coming from the sensors on the breadboard.


Adjusting the analog sensors, or depressing the switch, will manipulate the circle within the Processing sketch.


In Part 2 we’ll look at how the same result can be achieved with another method for organizing the data, called the Call-and-Response or Handshake method.

Beginning Serial Communications



Beginning with a simple potentiometer on the breadboard, code is set in Arduino to write to the serial port.


This is the beginning of serial communications, but at this point the data is unintelligible, because it’s coming in ASCII characters.


To see the data differently, the program Cool Term can be used.  Here it shows the ASCII representation:


And here it shows what’s coming from the potentiometer in HEX:


Click here for video of the variation in the readings.

Next I used the Serial.write command to send data to Processing.


The code maps the data visually, as you can see in the video below.

In the second lab for Week 5, we’ll consider multiple sources of data to be communicated serially.