For halloween, each IDEO location held a one-hour pumpkin carving competition. I thought it would be interesting to see how much tech I could jam into a pumpkin within the time limit. Luckily, I had an old pneumatics kit under my desk and recently stumbled upon an incredibly simple way to get my iPhone to talk to Arduino. I was able to conceptualize, build, and program this wirelessly-controlled-pneumatic-eye-popping pumpkin in just over an hour, barely missing the deadline but experiencing how powerful these low fidelity prototyping tools could be.

Learn more after the jump…

There are a few ways to get an iPhone to talk to an Arduino, but none are as quick and simple as pairing up the mobile app TouchOSC (for Android and iOS) with Processing. The control system is practically plug and play and very minimal coding knowledge necessary to get up and running (so don’t be afraid if you’re new to the game).

This setup has been around for a few years but it hasn’t gained much traction for its potential value in low fidelity prototypes. The time investment is incredibly low compared to any other phone/Arduino strategies, serving as a great early filter for interaction concepts or realizing your wildest dreams of an iPhone controlled robo-pumpkin.

To make one thing clear: this prototyping method has a bit of  ‘smoke and mirrors’  in that the smartphone doesn’t directly communicate with the Arduino, but uses a computer as a receiver and translator between the two.  There are a few ways to take out the middleman but they take a bit more setup and a few more tools that would make the build lengthier.

TouchOSC is a great app for iPhone and Android that helps make this entire process incredibly easy on the interface side. The program allows you to build a basic interface via a desktop app  “TouchOSC Editor”. You can compile basic interaction objects (buttons, toggles, faders, etc…) onto an iPhone/iPod Touch/iPad screen which you can then easily transfer to any iOS device.

The custom TouchOSC interface creates “Open Sound Control” (OSC) signals sent via wifi that are received by an open Processing sketch on a computer. The Processing sketch then writes the signal to serial, which is transmitted wirelessly to the Arduino with a pair of Xbee Modules. The Arduino is hooked up to two air pistons powered by a bike pump and 2 liter bottle reservoir.

If any of these terms don’t make sense and/or you want to give it a shot yourself, there are a few great tutorials that go into more detail and make it easy to get started:

Sparkfun Tutorial for LED Control (doesn’t address Xbee)

MIT Robotics Class Tutorial with LED/Servo Control (with Xbee but with non-standard board)

***Note:  Neither the tutorials address an accessible Xbee setup. Here is what I used:

Arduino Uno,  Xbee Modules (x2), Xbee USB Dongle, and Xbee Arduino Shield

Check out Processing and Arduino Code I used in this project here

//-----------------------Start Arduino Code------------------------------

int message = 0; // This will hold one byte of the serial message 
int eyesPin = 9; // What pin are the eyes connected to?
int eyes_val = LOW; // eyes_val will be HIGH or LOW

void setup() 
{ 
Serial.begin(9600); //set serial to 9600 baud rate
}

void loop()
{ 
    if (Serial.available() > 0) 
    { // Check if there is a new message
        message = Serial.read(); // Put the serial input into the message

        if (message == 'R')
        { // If a capitol R is received... 
            eyes_val = HIGH; // Set eyes_val to HIGH and eyes are out
           }
        if (message == 'r')
        { // If a lowercase r is received...
            eyes_val = LOW; // Set eyes_val to LOW and eyes are in
        }
    } 
    digitalWrite(eyesPin, eyes_val); // Write digital value to eyes
}

//----------------------------end Arduino code--------------------------------

//----------------------------------start processing code------------------------------------ 

import oscP5.*; // Load OSC P5 library 
import netP5.*; // Load net P5 library 
import processing.serial.*; // Load serial library 

Serial arduinoPort; // Set arduinoPort as serial connection 
OscP5 oscP5; // Set oscP5 as OSC connection 

float eyes_val;

//--- Function: setup 
void setup() 
{ 

oscP5 = new OscP5(this,8000); // Start oscP5, listening for incoming messages at port 8000 
arduinoPort = new Serial(this, Serial.list()[0], 9600); // Set arduinoPort to 9600 baud 
} 

//--- Function: oscEventThis runs whenever there is a new OSC message 
void oscEvent(OscMessage theOscMessage) {
    { 
      String addr = theOscMessage.addrPattern();
    if(addr.equals("/1/push1")) {
    eyes_val = theOscMessage.get(0).floatValue();
    } 
    }
}


//--- Function: pneumatic eyes on/off 
void draw() 
{ 
println(eyes_val);
if (eyes_val > 0.5) {
arduinoPort.write('R');//sends signal for eyes out
delay(200);
}
else {
  arduinoPort.write('r');//sends signal for eyes in
  
}

} 

//----------------------------------end processing code------------------------------------

At IDEO we are excited about “sketching in hardware” (super-fast rough interactive prototyping).  Here are some other related IDEO Labs posts:

Sketching In Hardware

Game On! A Workshop At  IIT

Quick-n-Dirty Multi-Touch: Flash API + Wiimote

Every fall the San Francisco chapter of AIGA, the professional association for design, hosts a gala to celebrate a community of over 1,600 students and professionals in the Bay Area under the umbrella of communication design, ranging from graphic design to interactive design and experience design. Each gala has a theme that is most evidently expressed through the auctioning of custom-designed objects by design firms and independents. This year’s event was a masquerade, and appropriately titled “Mask Appeal.”

IDEO was asked to participate again this year, so, of course, we took up the challenge. It didn’t take much convincing to recruit fellow communication designer Wilfred Castillo to help imagine what a contribution from IDEO could be. After a week of remotely brainstorming how to transform a $3 mask structure into something awesome, we finally landed on the concept of a wooden toy maze. It’s interactive, nostalgic and who didn’t love this game as a kid?

Click through for more photos and build details.

Once the decision was made, we consulted Nathan Whipple and Peter Bronk of the IDEO prototyping team in Palo Alto to see if it could be done in time for the event the following week. The minute the words “definitely feasible” were uttered, we sprinted through the weekend to design the layout of the maze structure and the graphics in Adobe Illustrator to move the rest of the production along. Anthem Printing in San Francisco had burned a silk screen for us by Monday morning, and the graphics were applied to the wood surface by nightfall.

Tuesday morning, the materials and source files were passed over to Nathan and Peter to begin figuring out how to best to build and assemble the mask. They mulled it over and came up with internal sleeves, to space the components. Peter machined the main mask housing out of RenShape®, and the internal spacers out of ABS plastic. After the parts were milled, they had to be finished with three layers of paint.

Between the graphics and the woodworking, it was a largely hands-on process that demanded a good deal of precision inherent in our craft. On Thursday November 10th, the day of the Gala, the product of this collaboration was finalized and ready for its big debut. Of course we all gave the game a quick play to break it in, but, after many failed attempts, it was time head to San Francisco to give it away to the highest bidder at the AIGA SF Gala.

(Mask contributions came in from designers from Dwell, ASTRO, Public, SMART, Apple, Landor Associates and many more awesome studios and independent creatives.)

We recently completed a prototype that called for expressive LED lighting.  The team wanted the device to have a personality; simply turning LEDs on or off wasn’t enough. We wanted LED’s to “wake up” slowly,  gently turn off, and “breathe” (continually fade brightness up and down) with variable rhythm. More importantly, these LED animations needed happen at the same time. This requires the LED software to “multitask.” I used Arduino because it reduces complexity and development time.

There is no native support for multitasking in Arduino, so I developed a custom solution. Each LED output would be updated in sequence every time around the “loop.”  For example, if there are three LEDs, LED1 updates, then LED2, then LED3. The software loops and the LEDs are updated again. Each time an LED is updated, the Arduino software calculates the LED output brightness based on the desired animation behavior.

A software LED description (C++ class) of LED behaviors and LED attributes called LEDController was created. Each real LED is represented in Arduino software as an LEDController software object. Every time an LED is updated, its LEDController object calculates its brightness, then sends the brightness value to the Arduino (PWM) output that drives the LED.

Not much later, a project came along requiring simultaneous animation of 36 LEDs. There aren’t 36 PWM outputs readily available on Arduino, so I used two LED driver ICs (LTC3220), each capable of driving 18 LEDs. An I2C interface was added to the LEDController class so instead of controlling an Arduino PWM output, the brightness value for each LED is sent on the I2C bus to its LED driver IC.

The multitasking approach developed for LEDs can be adapted for other kinds of output devices.  For example, the LEDController PWM output could be converted to a reference signal for motor position or velocity control. Imagine controlling a set of motors, or a combination of motors and LEDs. Any project needing to control multiple analog outputs could benefit from this class or adaptations of it.  IDEO’er Dave Vondle has verified this class works with the Arduino Mini shield he created.  This would be useful if you have a project that requires rechargeable batteries or high power outputs.

I expect to continue to use and adapt LEDController, and I hope you find a use for it as well.  If you do, please post it in the comments and show off what you made!

The LEDController Class: Overview

The LEDController class can drive LEDs using Arduino PWM outputs, or using an external I2C LED driver IC.  Use of the I2C interface allows large numbers of LEDs to be driven simultaneously.

Each LED is represented in application code as an LEDController object. LEDController attributes are used to customize LED animations. Every time the Arduino loop function executes, all LEDController objects are updated.

The Class

LED Actions

The following actions (animations) are enumerated and used to seed the action attribute.
The action attribute represents the type of animation. (See LEDController.h and LEDControllerSource.pde for details.) In this document, attribute names are indicated by italics.

TURN_HIGH –Immediately sets the associated LED brightness to the value of the analogHighValue attribute.

TURN_MID –Immediately sets the associated LED brightness to the value of the analogMidValue attribute.

TURN_LOW – Immediately sets the associated LED brightness to the value of the analogLowValue attribute.

TURN_OFF – Immediately sets the associated LED brightness to 0.

BLINK – The associated LED will blink between the analogHighValue and the analogLowValue.  The analogHighValue will last for blinkTimeHigh milliseconds. The analogLowValue will last for blinkTimeLow milliseconds.

RAMP_HIGH – The associated LED will increase its brightness from its present value by rampUpValue steps every rampUpDelay msec until the brightness reaches the analogHighValue. Remember to initialize the low brightness by using one of the TURN actions (e.g. TURN_LOW) first if necessary.

RAMP_LOW – The associated LED will decrease its brightness from its present value by rampDownValue steps every rampDownDelay msec until the brightness reaches the analogLowValue. Remember to initialize the low brightness by using one of the TURN actions (e.g. TURN_HIGH) first if necessary.

RAMP_CONT_HIGH_LOW – The associated LED will ramp its brightness between the analogHighValue and the analogLowValue. The ramp up rate is created by the combination of rampUpDelay and rampUpValue and will ramp up until the analogHighValue is reached.
The ramp down rate of is created by the combination of rampDownDelay and rampDownValue and will ramp down until the analogLowValue is reached. Triangle and sawtooth waveforms can be created.

RAMP_CONT_HIGH_MID – Similar to RAMP_CONT_HIGH_LOW. The associated LED will ramp its brightness between the analogHighValue and the analogMidValue. The ramp up rate is created by the combination of rampUpDelay and rampUpValue and will ramp up until the analogHighValue is reached.  The ramp down rate of is created by the combination of rampDownDelay and rampDownValue and will ramp down until the analogMidValue is reached. Triangle and sawtooth waveforms can be created.

LED Attributes

update – true if the action is to be updated when takeAction() is called, false otherwise.

action – The enumerated value that references the LED action/animation.

analogHighValue – The signal intensity of the highest brightness to be used. The range is 0 to 255.

analogMidValue – The signal intensity of a middle of range brightness to be used. The range is 0 to 255.

analogLowValue – The signal intensity of the lowest brightness to be used. The range is 0 to 255.

analogValue – The present analog value.

rampUpValue – The number of analog steps to increase at each LED update time.

rampDownValue – The number of analog steps to decrease at each LED update time.

rampUpDelay – The number of milliseconds between LED updates for ramping up.

rampDownDelay – The number of milliseconds between LED updates for ramping down.

i2CAddress – The I2C address of the LED driver IC.

ledAddress – The LED address within the LED driver IC.

ioPin – The Arduino pin number associated with the LED to be driven by PWM.

blinkState – High when the blink value is analogHighValue, low when the blink state is analogLowValue.

blinkTimeHigh – The number of milliseconds the LED is at analogHighValue when the action is BLINK.

blinkTimeLow – The number of milliseconds the LED is at analogLowValue when the action is BLINK.

previousTime – The time value returned by the millis() function at the last update.

usingPWM – True if using the PWM outputs, false if using I2C.

takeAction()
A takeAction() function for each LED object is added to the application loop() function. The takeAction function checks to see if the associated LED is to be updated based on the LED attributes and if applicable, the amount of time since the last update. Each LED is independently checked for updating each time the loop() function executes. Thus, each LED waveform is checked for updating at a minimum rate equal to the time required to execute the loop() function.
(See the “Sample Application Code” below.)

Constructor
The LEDController constructor is used to initialize LED object attributes. There are separate constructors for PWM and I2C objects. (See LEDController.h for details.)

LEDController objects are typically created as global objects in the main application file.

Changing LED Attributes
The attributes of an LEDController object may be changed in the application code when it is desired to change the associated LED behavior. For example, an LEDController object named ledREDController can have its analogHighValue changed to 200 by coding:

ledREDController.analogHighValue = 200;

PWM Interface
To use the PWM interface for a given LED, set usingPWM to true, and set ioPin to the PWM pin number connected to the LED.

I2C Interface
The I2C interface that presently uses the Linear Technology LTC3220 LED driver IC as an I2C example.  ( See the LTC3220 data sheet for I2C implementation details. ) The adaptation of the LEDController class to other I2C based LED driver ICs is left to the developer.

Creating complex animations
Complex animations may be created by sequencing LED object actions within the application code, typically via a time triggered state machine. For example, the application can ramp an LED to a specific brightness, wait for a period of time, then ramp it down.

Sample Application Code using PWM outputs

(Download the complete RGB_LED_Tester source code.)

#include "LEDController.h"

// Constructors:
// LEDController(int i2cAddress, int ledAddress ,[optional arguments...])
// for Linear Tech I2C LED driver
// or
// LEDController(int ioPin ,[optional arguments...]) for direct PWM on the Arduino
// optional arguments are:
//  boolean updateIn, int actionIn, int analogHighValueIn, int analogMidValueIn,
//  int analogLowValueIn, int analogValueIn, int rampUpValueIn, int rampDownValueIn,

// int rampUpDelayIn,
//  int rampDownDelayIn, int chaseDelayIn, int chaseNumberOnIn,
//  boolean blinkStateIn, int blinkTimeHighIn, int blinkTimeLowIn,

// unsigned long previousTimeIn,
//  int dwellLowTime, int dwellHighTime);

boolean buttonWasUp=true;

LEDController ledREDController(6);
LEDController ledGREENController(5);
LEDController ledBLUEController(3);

//State machine states
enum{
STATE_0 = 0,
STATE_1 = 1
};

int testState=STATE_0;
unsigned long stateStart
unsigned long stateEnd;

void setup(){
pinMode(3, OUTPUT);
pinMode(5, OUTPUT);
pinMode(6, OUTPUT);
stateEnd = 0;

ledREDController.action = BLINK;
ledGREENController.action = RAMP_CONT_HIGH_LOW;
ledBLUEController.action = RAMP_CONT_HIGH_MID;
}

void loop(){

// Application code goes here
switch(testState){

case STATE_0:

if(millis() > stateEnd){
stateStart = millis();
stateEnd = stateStart +1500;
testState = STATE_1;
ledBLUEController.action = RAMP_HIGH;
ledBLUEController.rampUpValue=4;
}

break;

case STATE_1:

if(millis() > stateEnd){
stateStart = millis();
stateEnd = stateStart + 1500;
testState = STATE_0;
ledBLUEController.action = RAMP_LOW;
ledBLUEController.rampDownValue=4;
}

break;
}

// Update the LEDs

ledREDController.takeAction();
ledGREENController.takeAction();
ledBLUEController.takeAction();
} // end of loop

I taught a workshop with Anijo Mathew in October at the Illinois Institute of Technology on prototyping in electronics or “sketching in hardware.”  The class was a variation on a concept created by IDEO’s Haiyan Zhang called “Game On!”  The idea is to demonstrate how fast the participants can move from concept to interactive prototype.  It’s incredible what people with little to no previous experience can achieve in the span of a few hours.  We constrain the workshop to the creation of a game because it allows people to be silly, excited and not over complicate the challenge.

Sketching in Hardware

Sketching is a tool for conveying and capturing the right level of information as quickly as possible. When designing for interactive systems there is often value to bringing sketching off of the notepad and realizing the interaction in technology. In this workshop you will be introduced to a set of tools (in this case, Arduino + Flash/Actionscript) and will break into teams to create a game that incorporates a variety of physical interactions.

In the workshop, we had a bunch of electronic sensors that were plugged into a prototyping board called Arduino.  The Arduino was plugged into the computer with a USB cable that allows the sensors to control a game on the screen.  We started the day getting Arduino working with Adobe Flash on everyone’s computer.  After everyone got it working we split into groups and started brainstorming ideas for games.  The teams spent the last 4 hours cutting, gluing, wiring, drawing, learning and coding to end the day with working, playable games.  Check out the games they made and some technical details after the jump.

The Games:

Lion Vs. Pig:

This game uses Arduino connected to potentiometers, distance sensors and an arcade button.  The pig tries to eat the lettuce, and the Lion tries to eat the pig.  The pig can hide from the Lion behind the barn.  The position of the animals is controlled with the distance sensors and sliders, while the lettuce is randomly placed with the arcade button.

Singing Glass:

This uses a rotary touch strip to control the pitch that the wine glass makes.  When the pitch is high enough for a period of time, the glass breaks.

Kick the Cat:

This game uses Arduino connected to a flex sensor taped to a force sensor.  The player bends the end of the flexible sensor assembly backwards like a catapult to determine the angle and squeezes to control the power.  When he/she releases, the shoe kicks the cat.  The objective is to get the cat into the trash can.  The force sensor/flex sensor control was really fun, unfortunately I didn’t get a photo of it.  You can see the control on the bottom left of the video.

Soccer Shoot Out:

Source: thenewidiom.com

This game uses a three axis accelerometer (like the Wii) taped to the player’s shoe.  the movement of the player’s kick controls whether the ball will go into the goal or not.

Check out what the students had to say on their blog at The New Idiom.

The Details:

We had a bunch of sensors to choose from and each team of 3 had an Arduino Board.  We loaded some software called Firmata onto the Arduino boards that allowed us to do all the programming within Flash.  The Flash library for communicating with Firmata on Arduino is called as3glue.  We took the “simpleIO” example from as3glue and used that as a starting point.  The last piece of software is Serproxy (downloaded from Arduino site), which passes the messages from the USB connection into Flash.

As the teams were coding I would ask if they got stuck on anything and would make examples to help them out.  I posted all of my materials including the examples here.  I borrowed a bunch of office supplies from IDEO to use as props, but the props work much better when I have brought a bin of old junky toys, pipe cleaners, foam, clay, etc.

Sensor list for Sparkfun: (in order of importance)

IR Distance Sensors, Jumper Wires

Rotary Potentometers, Knobs

Slide Potentiometers, Sliders

Arcade buttons (Blue, Green, Pink, Yellow)

Light Sensors:

Flex sensors

Accelerometers

50 cm touch strips

Rotary touch strips

Wii Nunchucks, Wii Nunchuck Adapters:

Force Sensors

Capacitive Touch Sensors

Motion Sensors

Color Sensors

To begin with, we took Alex’s official IDEO portrait and Photoshopped out everything but his hair, converted to vector art, and made an inkjet print on transparency.  (Careful if you’re using your office’s laser printer — if you use the wrong transparency film, it’ll melt and ruin the printer!)  Print another one, proportionally smaller, for the viewfinder.

Tape the transparency to one of the plastic frames that comes with the Diana.  We used double-sided tape.  Since  the image projected from the lens gets flipped, your transparency will need to be upside down and reversed.

Then tape a piece of vellum or tracing paper on top of the transparency.  This is just temporary, so tape it lightly with something you can remove easily.  The vellum will act like the ground glass in a large-format view camera, showing the image that will project from the lens onto the film.

Pop the frame into the camera.  Remember it needs to be upside down and reversed.  At the last minute, we added the IDEO logo.  It’s backwards here though, as we discovered after shooting the first photo.  Don’t forget the vellum — it’s missing here.

It’s possible to just slide the smaller transparency in front of the viewfinder, between the clear plastic and the teal plastic body — no adhesive is necessary.  You might want to wear gloves, so you don’t get fingerprints on the transparency.

To calibrate our new creation, we put the camera on a tripod.  When you remove the back cover of the Diana, you lose the tripod mount, so we fabricated a mount with a clamp zip-tied to an L-bracket and bolted to the tripod head with a 1/4-20 nut.

Note the tape measure on the floor:  we wanted the subject’s head framed as big as possible in the photo, so we had Lindsay stand at the 36 inch mark (the minimum focus distance of the Diana lens).

Switch the camera to the “B” (bulb) setting and tape the shutter button down to keep it open.  You’ll see your subject projected onto the vellum.  It helps if there’s a lot of light on your subject and dark behind your camera.  Now compare the size and position of your viewfinder view (how you’ll frame your photos) and the film view (what will actually be captured).  Note that since you’re not framing through the lens like an SLR,  there’ll be a parallax discrepancy.  For the final prototype, we reprinted Alex’s hair bigger and shifted its position on the transparency to better match Lindsay’s head.  We also reprinted the viewfinder hair to match the film view.

If you’ve done everything correctly, the images should match up in the viewfinder and on your vellum “ground glass.”  If so, remove the vellum before loading the camera with film.  We used the Lomography Instant back for the Diana, but this should work for 120 roll film, too.  The Instant back yields Polaroid-like mini-prints, which we wanted for the Alex’s going-away party.

OK, now you’re ready to rock.  Stand about 3 feet away from your subject and snap away.  Given the low-quality lens on the Diana, and our plan to shoot indoors, we found that the flash helped out a lot.

Some of the greatest hits from the party.  Note Alex in the top photo, wearing his own hair.  It takes a bit of practice (and luck) to get the hair in the right place.

Special thanks to Lindsay Wai for construction and testing help and Michelle Moy for vector art and printing expertise.

The cave (or iCube, as we’re told they would prefer we call it) is comprised of three white walls and a floor, all about 10′ x 10′ in size. Onto each surface is projected a high-resolution, stereoscopic image. A viewer stands in the room wearing polarized 3D glasses — like you might use in a 3D movie — with small markers that stick out a bit from the frames.

The markers are illuminated by IR LED floodlights located on the perimeter of the room, and IR-sensitive cameras use those positions to determine the precise location of each eye within the room. From those positions, stereo images for each projector are calculated and rendered on the fly, and the result is absolutely amazing.

We had heard about this technology before, but seeing is believing. Of course to get the real experience you need to physically be in the space, but you might enjoy living vicariously through David’s experience (click here to see the vid in HD instead):

WATG’s incredible hotel and resort work provide a superb example of the power of this tool. Why not let a client walk through their new resort before ground has even been broken? Take them into one of these and they’ll never settle for blueprints and a miniature model again.

Part of what makes this experience so wonderful is the lack of heavy, complicated headgear. The viewer is free to walk around, and the environment responds to their every move. There’s no training required or cumbersome technology to stand in the way of the content. But the effect doesn’t come cheap: you’ll need over half a million dollars and a lot of space to pull this off.

Now, how can we do something similar for pennies on the dollar?

(OK, maybe that’s still taking our word for it, but, well, you know). The Party App is our Toy Lab‘s first foray into fun, playful iPhone apps, and as such we thought we’d share the experiment with Labs readers. The app is a mere $0.99 at the iTunes or App store: click here to learn more.

If you download the app and try it out (say, at a New Year’s Eve party), let us know what you think by leaving a comment…

Thanks, and see you in 2009!

How’d he do it?  Florian’s thoughtful song is deceptively simple: a tiny music box is attached to the stem of his bike.

A microphone is carefully attached beneath it, placed to allow just enough ambient noise while getting clean sound from the music box. The box’s crank is connected by a makeshift belt which is connected at the other end to his front hub.

Once in place, it’s up to Florian to modulate the pace of the song by controlling his own speed. We think the result speaks for itself.

Happy holidays from IDEO Labs — We’ll see you in the new year!

In fact, with eight worldwide locations, six time zones, and roughly fifty people involved, IDEO’s Global Chain Reaction looked more like a blueprint for possible points of failure than a functioning Rube Goldberg machine designed to run sequentially across three continents.

Even Jon Kaplan, the IDEO veteran behind the effort, had moments of doubt. But more than that, he had moments of disbelief: How could someone actually come up with that!? How could someone actually engineer a pole-dancing doll to spin around in silver garland, knock down a Phillippe Starck juicer, trigger a Gaussian gun, and topple a Tickle-Me Elmo, plastic eyes first, onto a computer mouse that then prints a document in Shanghai? All told, there were about ten other machine-based vignettes that lasted almost 20 minutes and spanned day and night, thanks to the fifteen-hour time difference between offices.

Unlike many Rube Goldberg machines, the goal wasn’t to turn on the lights or pour a glass of milk. Instead, Jon wanted to get people psyched about IDEO’s engineering capabilities and to broadcast the distributed contraption live for all to see. Of course, getting a hot dog in the Chicago office to dial a cell phone in Palo Alto for the sole purpose of pumping helium into a bucket of soap and water for a three-foot cylinder of bubbles did plenty to get people excited. When the Chicago team added flames to the mix, Jon didn’t flinch.

“I sent out rules and people either ignored them or followed them. The sense of humor part was great. Munich emailed early on and said, These rules are there for breaking, right?”

The San Francisco office waits patiently for the New York office to knock on their door

The New York office logs on

Elmo in Palo Alto sends a print to Shanghai

Munich maps out their multi-floor Rube Goldberg

The Boston team gets their machine ready amongst scenes of local history