Category Archives: Arduino


For week 2 of Understanding Networks, a newly created class that keeps shifting between abstraction and application, leaving me sadly uncertain as to whether I understand what Tom’s talking about at any given moment, our terrifying assignment was as follows:

Socket exercise: communicating in realtime. I will give you a game platform and the protocols to log in and communicate with it. Make a client to log in and play. Work in Processing, Flash, Arduino or whatever environment is comfortable to you. You will not play with your own client, but you’ll show someone else how to use it.

Continue reading Pongbox

Living in uninteresting times

don’t press the red button

This week’s assignment for Crafting with Data was

Use an Arduino to gather 500 samples of interesting data in two different conditions (1000 samples total). Post your data online so it can be downloaded.

Now, see, I did this assignment uncharacteristically promptly—days ago!—without having noticed the adjective interesting, so originally what I had was some profoundly dull numbers from a thermistor, measured (a) under my fluorescent proofreading lamp and (b) while I held the sensor between my fingers. You will thank me, therefore, for rereading the assignment, noting my error, and, at the last minute, using the Pong controller I made for Understanding Networks to gather some slightly less dull information from the x axis of an accelerometer: (a) walking on level floor, and (b) climbing up and down stairs.

Now, with charts!

accelerometer readings while walking on level floor

accelerometer readings while climbing stairs

The guts of my beautiful data collection device look like this:

Pong controller guts
(Click the photo for more details at Flickr.)

I used two Processing sketches—for the thermistor data, Rob’s code; for the accelerometer data, a quick-and-dirty mod of the almost wholly unoriginal code I used for the Understanding Networks assignment.

 Serial String Reader + Simple net Client
 Language: Processing
 Reads in a string of characters from a serial port until 
 it gets a linefeed (ASCII 10).  Then splits the string into 
 sections separated by commas. Then converts the sections to ints, 
 and prints them out.
 * Starts a network client that connects to a server on port 8080,
 * sends any keystrokes pressed.
 created 2 Jun 2005
 modified 6 Aug 2008
 by Tom Igoe
 modified 24 September 2009 by India Amos

import processing.serial.*;     // import the Processing serial library
import*;        // import the Processing networking library

Serial myPort;                  // The serial port

Client myClient;                   // instance of the net Client
String data;                       // string to hold incoming data
String ipAddress = "";    // address of the server
String myKey1;                   // the virtual keypress generated by the x-pin of the accelerometer
String myKey2;                   // the virtual keypress generated by the y-pin of the accelerometer
String myKey3;                   // the virtual keypress generated by the switch
String myKeyBuffer;              // all the virtual keys pressed by a single bleat from the Arduino 

float bgcolor;		        // Background color

void setup() {
  // establish the background and foreground:
  size(200, 200);      

  // Connect to server on port 8080
  myClient = new Client(this, ipAddress, 8080);

  // List all the available serial ports

  // I know that the first port in the serial list on my mac
  // is always my  Arduino module, so I open Serial.list()[0].
  // Change the 0 to the appropriate number of the serial port
  // that your microcontroller is attached to.
  myPort = new Serial(this, Serial.list()[0], 9600);

  // read bytes into a buffer until you get a linefeed (ASCII 10):

void draw() {

// serialEvent  method is run automatically by the Processing applet
// whenever the buffer reaches the  byte value set in the bufferUntil() 
// method in the setup():

void serialEvent(Serial myPort) { 
  // read the serial buffer:
  String myString = myPort.readStringUntil('\n');
  // if you got any bytes other than the linefeed:
  if (myString != null) {

    myString = trim(myString);

    // split the string at the commas
    // and convert the sections into integers:
    int sensors[] = int(split(myString, '\t'));

    // print out the values you got:
    for (int sensorNum = 0; sensorNum < sensors.length; sensorNum++) {
      print("Sensor " + sensorNum + ": " + sensors[sensorNum] + "\t"); 
    // add a linefeed after all the sensor values are printed:

    // Convert integers into behavior.
    // A change of +/-50 on sensor 1 means a roll forward (down) or backward (up), respectively. Flat is 520.
    // A change of +/-50 on sensor 2 means a tilt coounter-clockwise or clockwise, respectively. Flat is 505.


    if (sensors[0] > 570) // rolling forward, so paddle down
      myKey1 = "d";

    if (sensors[0] < 470) // rolling backward, so paddle up
      myKey1 = "u";

    if (sensors[1] > 555) // rolling counter-clockwise, so paddle left
      myKey2 = "l";

    if (sensors[1] < 455) // rolling clockwise, so paddle right
      myKey2 = "r";

    if (sensors[3] > 0 ) // button pressed
      myKey3 = "x";

    myKeyBuffer = myKey1+myKey2+myKey3;

    // If there's incoming data from the client:

    if (myClient.available() > 0) { 
      // get the data:
      data = myClient.readString(); 

    if (myKeyBuffer != null) {
      // send out anything that's typed:
 if (keyPressed) {
   // send out anything that's typed:



Baby steps

grid of 61 colored squares

This is the second smidgen of the code for our final project. It pulls RGB values and color names from a tab-delimited text file (which is, itself, based on the actual Krylon color options) and outputs this grid of swatches. The swatches don’t do anything yet—just drawing them took me, like, two days, thank you very much, and that was with some very helpful help from Shawn. Partly this is because I apparently can’t keep in my head for more than thirty seconds how arrays and objects work, and partly it’s because I just. can’t. focus. And partly it’s because I apparently have no idea what the fuck I’m doing.

I’m beginning to really like Diego’s Plan B, as proposed over the weekend:

Fake our own deaths.

Continue reading Baby steps

MC Squared

MC Squared documentation thumbnails

Get it now! Detailed, full-color documentation of the famed MC Squared midterm project!

MC_Squared(fin).pdf (14.68 MB; sorry, it contains a couple of embedded videos)

We gave our presentation today, the thing mostly worked, and it wasn’t too embarrassing. And, unlike some people in the class, my group actually got two or three hours of precious, golden sleep the night—well, morning—before. (We closed down the floor at about 3:30 a.m., but a few of our classmates relocated to the library or some such place to keep working. Everybody seemed pretty crispy by 9:30 this morning.)

PhysComp, week 6: Bride of Serial Out

This week’s lab was mostly uneventful, although it took me something like six hours to do—I started after our CommLab make-up class ended, around 4 pm, and stayed until nine or ten.

First I thought I’d use one of these nifty sensors I got from SparkFun,

PComp lab, week 5: Serial Out

but then I realized I have no idea how you’re supposed to hook them up. Stick the pins straight into the breadboard? Solder wires on? How long should the wires be? So instead I used the stupid knob again, plus one of the IRs I bought for our midterm project.

The thrill of the knob has totally worn off. Then I saw Jorge soldering wires to an ultrasonic range finder just like the one I have, and I thought maybe it was a good time to try out my own. Ha! Thus began one of my more frustrating soldering bouts so far.

Helping hands

It must have taken me forty-five minutes to solder three freaking wires onto this cookie . . . and then it took me another hour to realize that the reason it wasn’t working was that I’d soldered the yellow wire to the wrong hole. And then I couldn’t get it unsoldered to save my life, so I just attached a fourth wire.

Finally I got them all hooked up:

1 digital + 2 analog

And then, there was serial output:

Et cetera.

After all that hair-pulling, the ultrasonic sensor was giving me really erratic readings (then again, so was the push-button switch: its value didn't change when I pushed the button, but it did when I touched the button). So I switched to two IR sensors, since I had so many lying around.

Then I got to the part about the handshake. Handshaking? Was not happening for me. I think it may have had something to do with this:

PhysComp homework, week 6: serial out 2: 15 PhysComp homework, week 6: serial out 2: 16

The Processing application was looking for the word "hello," but the Arduino didn't seem to be able to say the word without stuttering horribly. I tried for more than an hour, I think, to get them to talk to each other, but finally I had to just give up.

PhysComp midterm project, week 2: Rough prototype

A semi-working prototype!

Part 2 in the saga that began last week.

After spending about an hour playing with the Minim library in Processing, I went into the lab to see if I could get it to work with actual input from our IR sensors. This was basically a repeat of this week’s homework, which I’d done, for once, before the morning it was due, so the wiring part was uncharacteristically easy. I need to get some header pins, though; the stranded wire on the IR sensors is a pain to plug into a breadboard.

So our project—which I realize I didn’t explain last week—is going to be a cubeoid musical (or, at least, noisy) instrument with an infrared sensor set into each side, mounted corner-up (as demonstrated by Diego) on a camera tripod. One or more players can then use their hands or other body parts or utensils or pets to trigger different sounds from each side. We were thinking that for Phase One, i.e., this week, we’d have the sounds be synthesized tones, and that for Phase Two, the final version, we’d make it play various different loops.

It turned out, however, that it’s far easier—for me, at least—to get Minim to play loops than to synthesize sounds. And there are a lot of free sound clips out there in the world. I got mine from This pre-prototype, therefore, has only two sensors, both of which trigger audio loops. It also has the beginnings of a lame-ass bouncing ball animation, but it doesn’t do what I want it to do, mostly because the signal’s changing too rapidly. Graphics were a tentative feature for Phase Two, so I’m not going to fuss with that part any more this week.

Here’s some crappy video of Filippo (left) and Diego (right) making the sensors generate noise. You can barely hear it, unfortunately—listen for the annoying rapid clicking sound, which I think is the hi-hat sound.

The beauty part? This doubles as my ICM homework.

Here’s the Arduino code:

/* Reads data from two analog sensors (IR sensors, in this specific example)
and outputs the values in a format that can be easily parsed in Processing.

int ledPin = 7;
int irSensor0 = 0;
int irSensor1 = 1;
int sensorValue = 0;

void setup()
// Flash the LED three times to announce the start of program.
pinMode( 7, OUTPUT );
digitalWrite( 7, LOW );
delay( 300 );
digitalWrite( 7, HIGH );
delay( 300 );
digitalWrite( 7, LOW );
delay( 300 );
digitalWrite( 7, HIGH );
delay( 300 );
digitalWrite( 7, LOW );
delay( 300 );
digitalWrite( 7, HIGH );
delay( 300 );
digitalWrite( 7, LOW );

// Start serial port at 9600 bps:
Serial.begin( 9600 );

void loop()
if (Serial.available() > 0)
// Read the first (0) sensor:
sensorValue = analogRead( irSensor1 );

// print the results:
Serial.print( sensorValue, DEC );
Serial.print( "\t" );

// read the second (1) sensor:
sensorValue = analogRead( irSensor0 );
// print the results:
Serial.println( sensorValue, DEC );

// Follow the last sensor value with a println() so that
// each set of four readings prints on a line by itself:
Serial.println( sensorValue, DEC );
// delay ( 100 );

And here’s the Processing code, where most of the excitement takes place.