The Touchstone is a device by John Finley, Angela Huang and Jeff Kirsch that allows users to exchange a touch at a distance. In its current iteration, it uses light to communicate touch across a room. In further iterations, the Touchstone will use an internet relay to allow a pair of devices to communicate from anywhere in the world. The story of its development to date follows.

Origins and Ideation

In brainstorming projects for the final, we began by identifying a number of broad themes of interest, including:

• Action at a distance
• Visualizing the invisible
• Multiple small parts acting as one
• Bringing the distant closer
• Ambient communication

From there, we brainstormed a variety of projects that touched on one or more of these points. One in particular emerged as interesting to the entire group, and seemingly plausible within the timeframe of the project.

Whether just across town, or somewhere on the other side of the world, everyone in the studio has someone they care about deeply but see considerably less than they’d like. A number of mechanisms exist for sending composed messages to these people, in phone calls, emails, IMs, text messages, etc. But what about simply communicating a “Thinking about you,” without the added overhead of words? The deceptively simple way a touch communicates that sentiment was the genesis of our Distant Touch concept, which evolved into the Touchstone.

Original Concept

As originally conceived, the Touchstone system would consist of a pair of desktop devices. When touched, the local device would sense the heat from the user’s hand and send a signal to its distant partner, causing the remote device to heat up. The more a Touchstone was touched, the hotter the remote device would become, to a maximum heat. Touchstones would “cool” much faster than they’d heat, which meant that communication of a touch was asynchronous; a remote stone would be hot to the touch if its partner was touched recently, or frequently. On Rob’s advice, we attempted to consider a bit more of the complexity of relationships, allowing the Touchstone to become actively cold if neglected.

There were a number of points we found compelling in this original conception. The idea of translating the heat of a touch into an electronic signal, and then back to heat on the other side seemed a novel analog to the translation of voice, images and text that we’re already quite familiar with. Additionally, the fact that the device responds to touch, and its output (heat) can only be sensed through touching meant there’d be no way to determine the state of the “conversation” without effecting it.

From a technical perspective, we quickly realized that attempting to sense the heat of a touch in a device that heats up would likely lead to a variety of headaches in the form of feedback loops, we decided to instead use a capacitive sensor as a digital touch trigger, simply counting the length of a touch, and incrementing the programatic “heat” accordingly.

We also realized that getting a Peltier Junction in our hands and working would be difficult for the first iteration, and instead simulated heat through an LED that went from blue (cold) to red (hot.)

Differentiation of Labor

In order to best use each person’s skills, we decided to split out the various tasks involved in developing the prototype. Angela, with her background in Industrial Design, dove into formal studies for the shape of the device, and essential element in building something that afforded touching and could present a “neutral” posture from which to express presence or absence. Finley, one of two people in our class who could properly be called programmers, concentrated on the software while I worked in tandem building out the hardware. In reality, we both moved between both of these roles, troubleshooting each other’s code and wiring at three in the morning. As much as possible, we were all involved in the bigger picture interaction questions, and I took something of a role of keeping an eye on where the various pieces of the project were and creating informal landmarks for development.

First Iteration and Feedback

The first iteration of the Touchstone brought together a number of in-progress bits to give the class a general idea of where the project was going. It incorporated a blue to red heat-simulating LED, in addition to capacitive proximity sensor, all hidden under a hollow styrofoam orb. As there was only one device, we rigged the prototype to “heat” itself up, so that when touched, it actually displayed the state of the imaginary remote stone. The untouched device sat on the table glowing blue; when touched the color would become increasingly red, until a point where the orb glowed purely red. When the touching hand was removed, the device would slowly “cool” back to blue.

We gained some useful insight from this simple demonstration. First, we learned that although we intended the LEDs to serve only as a stand-in for heat, the class found the lights to be very compelling. Second, when we explained that the response they saw was in fact that of the remote device, our classmates raised their concern about the lack of a local verification of interaction, and indication of the state of the remote device. We took both of these into consideration as we moved forward with prototype.

Faking It (Second Iteration)

From the beginning, we realized that we wouldn’t really know much about how the interaction worked until people tried it, so we set about trying to make as “real” of a prototype as we could as quickly as possible. Unfortunately, technical progress came slower than we’d hoped, and by the second demonstration, we’d just barely gotten two Touchstone mockups to communicate over a wired serial connection. Rob encouraged us to consider building a simple man-behind-the-curtain prototype to allow people to better experience and respond to a demonstrated interaction. We quickly decided to fork the development once again, with Angela continuing work on the form of the device and Finley taking on primary responsibility for the software and hardware of what would become the eventual for-presentation prototype, while I quickly built and coded a potentiometer-controlled, two-LED interaction model.

The man-behind-the-curtain Touchstone

The benefits were immediate and obvious. Before even getting the device into classmate’s hands, seeing the “remote” and “local” heat indicator lights both fully “hot” suggested the need for a special state when both devices were touched simultaneously; I quickly added a “heartbeat” pulse on both devices to indicate as much. This, in turn, helped us realize that the interaction was not so much about heating or cooling the Touchstone over the longterm, but instead about a synchronous communication of presence. Heartbeat state enabled, we let people play with it.

Two-color Touchstone interaction test from Jeff Kirsch on Vimeo.

Again, a number of insights immediately came of the first hands-on tests. Parts of the interaction seemed natural enough, but it was unclear what each light indicated without being able to see what was (or wasn’t) happening with the other device. Additionally, having multiple colors plus a “pulse” seemed too much for a device as simple as this. Blue didn’t map to “cold” or “neglected” as well as red mapped to “hot” or “maintained,” and the range of purples in between didn’t seem to map to anything at all. We’d been sticking too closely to our simulation of hot and cold, and realized that “off” served better than blue to indicate that the devices weren’t touched, allowing the increasingly bright red light paired with the heartbeat pulse to communicate more clearly. We also played with some labeling for the local and remote indicators on the stone.

Our success in this was confirmed when testers started to respond, unprompted, with realization and delight at the appearance of the heartbeat pulse, even in our obvious curtain-less test.

One-color Touchstone interaction test from Jeff Kirsch on Vimeo.

Somewhere in the midst of these various discoveries, we were able to get wireless communication working, and to pull elements of code from the interaction prototype into the actual device prototype. A video of the first successful test (where we somewhat confusingly use a blue LED to indicate the remote side) follows:

Two color touchstone communication test from Jeff Kirsch on Vimeo.

Technical Decisions

With our final presentation quickly approaching, we realized some decisions had to made as to which features and functionality would make it into the final prototype. We’d done some testing with a Peltier Junction, but the difficulties of thermodynamics, paired with the success of our LED-based mock-ups led us to drop the heat angle without much remorse. We’d also been hoping to make all the electronics for the final product fit within the shell of the Touchstone itself (by this time, beautifully rendered in acrylic by Angela) but realized after a short feasibility meeting that the benefits of spending the required time and energy to attempt that goal would be much less than spending that time ensuring that we had two identical, reliably communicating Touchstones exhibiting the desired interaction model. A similar calculation caused us to, with somewhat more remorse, abandon our attempts as making the capacitive sensing work (replacing it instead with a force sensor, which left the interaction identical from the user’s perspective) and of making it possible for the devices to communicate at a range beyond what could be achieved with the xBee radios (a more problematic concession, and one we plan to address in future iterations.)

Final Prototype

For our final presentation, we built two electronically and programmatically identical devices, each with a pair of red LEDs, a force sensor and an xBee radio to communicate with their partner device.

Programmatically, the stones still use a “heating” metaphor. Each time through the code, we check for any pressure on the device. If pressure is sensed, we increment a counter by one (to a maximum of 255), and transmit the value of that counter over the radio, while simultaneously lighting the local LED with a corresponding value. If no pressure is sensed, we decrement the counter and do the same, down to a level of zero.

On the receiving end, each stone simply reads its serial port, and sets a “remote heat” variable to the received value. The remote LED lights accordingly. If no good value is received, the variable remains at the last good value. This bare-bones approach (we’d initially attempted to transmit a single character to indicate touch, and to have each stone increment or decrement the remote value internally) not only greatly simplified our code, but made the system appear much smoother and more reliable to the user.

Physically, we used Angela’s finished acrylic model, as well as a foam form model. We put LEDs in each and force sensors on the bottoms, and set them up on a piece of cloth, running the umbilical cable hidden underneath to and under-table box with the rest of the hardware. The two Touchstones were set up on opposite sides of the room.

The setup worked convincingly enough to spark a critique about the nature of the interaction, rather than the fidelity of the prototype, and by that measure it was certainly a success.

A video of the final prototype, showing one side of the interaction:

Touchstone Demonstration from Jeff Kirsch on Vimeo.

Attempted Revisions

Prior to the final class meeting, we attempted three different additions to the prototype. At the suggestion of one of our guest reviewers to make the Touchstones more responsive physically, Angela incorporated memory foam into a second acrylic model. Finley and I worked to get an ideally more reliable capacitive sensor back into the equation, but quickly realized that we were once again going down the wrong path by trying to develop a makeshift solution for something that could be easily achieved with the right components, and that made little obvious difference to the user in the long run.

We did, however, make a serious attempt at adding a second level of interaction, namely, the ability to squeeze the Touchstone and have that physically manifest itself (through a concentrated vibration) on the remote device. While ultimately unsuccessful, we got far enough to know what needed to be accomplished to implement that new functionality, changing the “heat” values imperceptibly from 0-255 to 0-254, and using a value of 255 to indicate that the remote device was being squeezed. This would then cause a small vibrator motor (embedded in the memory foam) to vibrate.

Next Steps

We all learned a lot from working on the Touchstone, and by the end of class found ourselves every bit (if not more) interested in the project as we were at the beginning. We’re planning to continue development as time allows, concentrating on a few important areas.

First, we plan to find a way to make the device work from different locations. This is an essential part of the interaction that fundamentally changes the way the Touchstone is perceived, and potentially, the viability of the solutions we’ve out in place thus far. Part of this is making it capable of connecting to the internet, and another (I’m convinced) is getting it into a condensed, stable package. Neither is trivial, but they both should be well within our abilities.

Second, we’d like to continue refining the form. At present, there’s something unresolved about the texture of the device, and we need to determine if the addition of memory foam hurts that or helps. There’s also a difference of opinions about the organic shape of the device, whether it’s too much or not enough.

Both these things will help us in the key determinations we need to make about the fundamental interaction. Ultimately, is it successful? Does it compellingly provide a new means of communicating presence and care at a distance? Does it appropriately allow for the opposite to be communicated? Must it? In the end, the only way to tell is to get the devices out in the world, in the hands of users, and observe the results.

Code, as used in the final demo is below:

/*
_____ _ _
|_ _|__ _ _ ___| |__ ___| |_ ___ _ __ ___
| |/ _ \| | | |/ __| '_ \/ __| __/ _ \| '_ \ / _ \
| | (_) | |_| | (__| | | \__ \ || (_) | | | | __/
|_|\___/ \__,_|\___|_| |_|___/\__\___/|_| |_|\___|

// Hearbeat simulation animiation.
// From full brightness go down slightly,
// then up and then down for a while.
// Inspired by elCalvoMike.
void heartPulse(){
for (i = 255; i > 100; i--){
analogWrite(remoteLED,i);
analogWrite(localLED,i);
delay(((60000/rate)*.1)/255);
}
for(i = 100; i < 255; i++) {
analogWrite(remoteLED,i);
analogWrite(localLED,i);
delay(((60000/rate)*.2)/255);
}
for (i = 255; i > 100; i--){
analogWrite(remoteLED,i);
analogWrite(localLED,i);
delay(((60000/rate)*.1)/255);
}
for(i = 100; i < 255; i++) {
analogWrite(remoteLED,i);
analogWrite(localLED,i);
delay(((60000/rate)*.6)/255);
}
}


Prep work

All told, the most challenging part of the lab may have been simply getting the radio into the circuit.

Fully soldered XBee breakout board.

Because the XBee uses closely-spaced pins, it can’t fit directly into the breadboard. Sparkfun sells a great breakout board to deal with just this issue, but it comes without headers and requires a lot of tiny joins. 40 in all. It’s actually not a bad way to hone those soldering skills.

Wiring

From there, hooking up the breakout boards is simply a matter of connecting VCC to 3.3v power (the XBees can’t work at 5v, and will fry at 7,) and ground, as well as DOUT to the Arduino Rx pin, and DIN to the Arduino Tx pin. This actually caused a bit of confusion in the studio, as In and Out are obviously device-relative and labeling isn’t standard.

Beyond that, hooking up the button and buzzer, or in our case, an LED, was a straightforward operation.

Programming the radios, and a cautionary tale of XBee + Arduino

The XBee radios are programable through standard AT commands. While experimenting with the radios prior to the lab, we’d attempted to use “screen” on the command line, which is something less than a pleasure. Funnel.cc’s XBeeConfigTerminal makes everything much, much easier, and we were rapidly able to pair the radios that way.

At this point, you’d think we’d be ready to drop the example code into Arduino and upload it to the board, but there’s a slight and important caveat. Because there is only one channel of serial communication on the Arduino, it’s essential that the Rx pin be unplugged from the radio, or any other potential input, prior to attempting to upload code. Otherwise, the board will enter a mode where it’s ready to be programmed, but be confused as to the source of that information. This causes the board to become out of sync with the IDE, and requires a bit of unplugging and re-plugging to get things sorted out. If you’re able to remember this, however, the whole operation goes fairly smoothly.

Simple and feedback doorbells

While the simple doorbell just triggers an alert on the board, the second bit of code sends a confirmation back, and lights an LED on the sending board. By unplugging the Rx and Tx pins, we’re able to show that the feedback really does come from the remote unit.

A demo of the operating (silent) feedback doorbell is below.

Wireless Lab Video from Jeff Kirsch on Vimeo.

Final thoughts

This simple exercise gave us most of the tools we needed to move forward with wireless communication on the Touchstone. While two boards communicating back and forth while running identical code is more difficult to achieve than a pair of boards with different code, the same fundamental lessons (especially unplugging the radios before upload) apply.

Full lab info available here.

The project Evinn Quinn, Stephanie Aaron and I decided to take on for our midterm was a system for indicating to cell-phone talkers when they’re speaking too loudly for the context they’re in, a product we call SAVI, or Smart Audio Volume Indicator

Problem Realization

In our project development conversations, we came upon the problem of people speaking at contextually inappropriate volume levels in public spaces. Be it the bus, the elevator or the bank line, we could all recall instances of this happening.

In most cases, these people were on cell phones, and while some may simply not have cared who else they might be bothering, we came to believe most were simply unaware of the volume at which they were speaking.

In our anecdotal observations, we’ve seen that this can lead to embarrassing leaks of private information, and uncomfortable social situations for all involved. Potentially, these situations can escalate to confrontation or violence. In short, it seemed an issue worthy of addressing.

Solution Formulation

Honing in on the frequency with which manifestations of the problem involved cell phones, we decided to pursue a cell phone-specific solution. Equipped with a microphone and a variety of potential outputs, it seemed the perfect platform. As we’re not cell-phone developers, however, we decided to prototype the behavior by building our own device.

We recognized the basic components of a solution were these: We’d need to measure the volume of the ambient noise in a space, measure the volume of the phone user’s speech, compare these values (with some sort of allowance for speaking over background noise,) and provide feedback to the speaker if a certain difference was exceeded.

We considered a variety of possible outputs, from a tapping on the shoulder to a whisper in the ear which got progressively louder as the transgression persisted to some form of vibration. To begin, however, we decided to tackle the input and signal comparison problems.

First Iteration

For the first iteration, we decided to table to output discussion, and concentrate on dealing with inputs and programatic comparison of levels. While we were able to find schematics for a microphone and amplifier circuit, and get ahold of the various parts needed to assemble it, we found the range of values we were able to pick up was too small to even be sure the input was working correctly. Not wanting to waste time, we decided to fake the inputs as well, and deal primarily with the programming and behavioral logic of detection and alerts.

First Iteration

Along those lines, we built a prototype consisting of two potentiometers (one to set the “background” volume, and another the volume of the phone user’s voice) and an LED hooked up to an analog pin as our output (we knew from the beginning that we’d want the output, whatever it would be, to scale with the intensity or persistence of the loud talking.

We fairly quickly arrived at a simple bit of code to compare the two inputs, with a defined “alert delta” required to trigger an alert. Over this threshold, the LED lit in realtime to a brightness determined by the difference between the speech volume and the background volume. Code follows:


//Define fixed items
#define ledPin 9 // LED connected to digital pin 9
#define Mic1 0 // Mic (pot) for background volume connected to analog pin 0
#define Mic2 1 // Mic (pot) for speech volume connected to analog pin 1
#define alertDelta 100 // Minimum difference between background volume and speech volume required to trigger alert

void clearRoutine() {
analogWrite(ledPin, LOW);
}


Response and Feedback

Faking both inputs and outputs, it was impossible to really test the device in use. We faked up a little enclosure, however, and did a man-behind-the-curtain demo for the class, which was enough to see the potential and get some feedback.

On the input side, we clearly needed a microphone to work, and we determined that the speech one was the most important. The background mic could be faked a little longer. As for output, a number of suggestions came up, but Russ said something particularly intriguing about the essential nature of having the output map immediately and directly to the speech input itself. As we’d identified vibration as a candidate for that output, it was even more important that we find a way to differentiate that feedback from any of the other ways a phone might vibrate.

Both these things in mind, we moved ahead to the next revision.

Second Iteration

The second iteration began to reveal some of the things you can only tell by building and testing. We managed to wrangle microphone input into a range we were comfortable with, and added a vibrator motor as an output.

The first thing we realized we’d have to adjust was the analog output to the motor. Under a certain level, it simply wasn’t enough to start the vibrator motor moving, so we needed to account for that in the code.

The next big discovery was that we simply couldn’t get the microphone input to predictably trigger the alert. In the midst of yelling, it would stop, and it would trigger in the midst of normal speech. We even switched back to the LED as an output to make sure the motor wasn’t part of the problem. We soon realized the problem: speech is never at a continuous volume, the ups and downs are what enable our sounds to be shaped into words. Depending on where we “sampled” the “waveform,” we might hit a peak in regular speech, or a trough in loud speech. Instead, we’d need to look at, and respond to the envelope of the speech, not an individual sample. This meant building an average, and after a little searching we found a jumping-off point for writing code to do just that.

We were able to establish a flexible array, and respond to a rolling average of the speech volume. This smoothed out the bumps, and with some trial and error we were able to get output that wasn’t jumping all over, but was obviously and immediately related to the speech input. It was immediate enough that those who tried it knew inherently what was happening.

Tweaks and Presentation

The day before our presentation in class, new, better microphones with integrated amplifiers arrived, and we quickly integrated them into the project. This did not resolve a major remaining issue, however: every time an alert was triggered, a feedback loop began that all but ensured the device wouldn’t come back from the alert state.

With Rob’s help, we went through our code, and couldn’t find anything that would cause such an issue. All other possibilities excluded, we came to the conclusion that having the motor on the same power bus as the rest of the circuit was, when activated, causing a voltage drop large enough to frustrate the readings from the microphone. As a solution, we separated the power supply to the motor, which seemed to solve the problem.

Finally, to improve the artifact for presentation, we moved the components that didn’t absolutely need to be in the handset itself to an outboard breadboard connected with a ribbon “bus”. Additionally, we created a cleaner enclosure for the whole thing.

Presentation Mockup with outboard parts

Everything held together for the in-house demo, and though the background volume level was still “faked” with a potentiometer and the motor vibration wasn’t as consistent or smooth as it might have been (or was in earlier testing) the concept still exhibited merit and seemed like something that could be successful (if potentially difficult to find a market for) if developed to its natural conclusion.

Code, as used in the final demo it below:

//Define fixed items
#define motorPin 9 // Vibrator motor connected to digital pin 9
#define Mic1 0 // Mic (pot) for background volume connected to analog pin 0
#define Mic2 1 // Mic for speech volume connected to analog pin 1
#define alertDelta 5 // Minimum difference between background volume and speech volume required to trigger alert

readings[index] = speechVolume;
// add the reading to the total:
total= total + readings[index];
// advance to the next position in the array:
index = index + 1;
// if we're at the end of the array...
if (index >= numReadings) {
// ...wrap around to the beginning:
index = 0;
}
// calculate the average:
average = total / numReadings;
}


A quick video of SAVI in action:

SAVI in Use from Jeff Kirsch on Vimeo.

Part I: Drawing and Animation

The first part of the lab was pretty basic drawing and animation. Lessons in changing shape, color and positioning come together in later examples when we build a simple character out of multiple shapes and the animate it programatically. Anticipating the need for a robot in later examples, I created my character in a function from the start. Not too much to remark on here, so I’ll just link to the examples.

Shape
Swatches
Character
Animation

Part II: Duplicating Examples

Part two was significantly more challenging. We were asked to match four examples of increasing difficulty.

Square Lights

The first example has four squares in a larger square. The square under the mouse is white, white the other three squares are black. I accomplished this by drawing four black squares, and then checking the current mouse position and redrawing a white square on top. Looking back at my code after having completed the who lab, it obvious that this could be accomplished much more efficiently. Maybe I’ll return to it if I get a moment.

Color Swapper

In Color Swapper, we have a red rectangle and a blue rectangle. The red rectangle slowly becomes more and more blue as the blue rectangle becomes increasingly red, and vice versa. The end effect makes it appear that the colors are shifting from side to side.

Programmatically, that’s not too far off, and my solution has a “primary” variable as the red value for one rectangle and the blue for the other. The other color value is set by a “secondary” variable whose value is 255 minus the value of the primary. I add another variable to keep track of the direction we’re currently going in, and then decrement or increment the primary value accordingly. Color Swapper

Racetrack

The Racetrack program produces a box that runs around the edge of a box. This actually struck me as one of the most straightforward of the set. I draw a box, and keep track of the direction in which it is moving, starting with it moving to the right. When I hit the edge of the frame, I change to moving it down, and so on. No collision detection here, I just use the “width” and “height” methods to determine to determine where to change direction. This allows the frame to be resized and the animation to continue functioning. Once again, this could be cleaned up, but in the interest of keeping moving, I left well enough alone on this one. Racetrack

Bounce

To my mind, this was by far the hardest example to approach, but eventually one of the simplest to implement. The example shows a box that begins at the top of the frame, and drops as if pulled by gravity toward the bottom. It bounces back up but, having lost some energy, does not return to its original height. After many bounces, it settles on the bottom of the frame.

I enlisted the help of my seriously math-y wife on this one, and between the two of us we managed to overthink the thing through several greatly overcomplicated versions, never getting it quite right. We set the box to change direction at a “top” and then lowered the “top” on each bounce. This made the box appear to “bounce” between two surfaces. We then tried to ease the top bounce… It was never quite right.

After a break, I decided to readdress the problem in a more realistic manner. I set out thinking I’d have to start from scratch, but we actually had created most of the necessary constructs already. I had a variable for velocity, set to 0 at the beginning of the program. I had a variable (held constant, actually) for acceleration, which set the box in motion to begin with. I had a test to tell if the box was at the bottom of the frame, and was able to change its direction. The only missing component was loss of velocity, which was easily implemented through a poorly-named “drag” constant. I added a quick line to decrement the velocity by that constant on each bounce, and the rest took care of itself. Bounce

Part III: Snowman Scene and Sharing Functions

Having made it through the previous examples, the snowman scene was a nice break. This exercise is basically about abstracting code into functions, calling those functions with arguments, and sharing functions. As a general rule, I attempt to split things into functions, so this wasn’t anything too new.

A couple issues did arise, most notably that the scale() method effected not only size, but positioning. I worked around it for my custom function by internally adjusting the passed X and Y values, and simply adapted the stated X and Y values for my drawn snowmen.

To make things a little more interesting, I made the robot have flashing eyes (timed to alternate each second, by test if a given second was even or odd) and added Clint Beharry’s “Snow” function.

Snowman
My Function
Shared Function

Lab instructions available here.

Simple Serial Output

First, we wire up a simple potentiometer to an analog input, and pass the readings to Serial.print and from there, the computer.

In the serial monitor, the values are interpreted as ASCII characters. I had some fun trying to hit the “carriage return” character to break the flow of input up.

This code makes it all work:


int analogPin = 0;
int analogValue = 0;

void loop()
{
// read analog input, divide by 4 to make the range 0-255:
analogValue = analogRead(analogPin);
analogValue = analogValue / 4;
Serial.print(analogValue, BYTE);
// pause for 10 milliseconds:
delay(10);
}


Simple Serial Output

With a little more code in Processing, we’re able to visualize the serial input. Somewhere along the line, I developed the strange habit of choosing the “cu” interface for the Arduino instead of “tty”, so I had to make the appropriate change to the code. Otherwise, everything went smoothly. Code follows:


/*
Sensor Graphing Sketch

// at the edge of the screen, go back to the beginning:
if (graphXPos >= width) {
graphXPos = 0;
// clear the screen:
background(48,31,65);
}
else {
// increment the horizontal position for the next reading:
graphXPos++;
}
}


And that’s about that. Full lab info available here.

Basic speed control

Basic motor setup

The wiring for simple pulse-width modulated control of a motor is pretty basic, though a few additional precautions are necessary. First, rather than connecting directly to an Arduino analog output, we use that output to control a (TIP 120) transistor, allowing more voltage to go to the motor than the Arduino can handle. For the small motor in this example, 5v is more than enough. In addition, a diode is needed to prevent blowback from the motor. The “diodes” in our kit don’t seem to be directional, but using an LED instead seemed to make things work nicely.

As in so many other labs, a potentiometer provides analog input.

The following code is loaded to the Arduino:

int motorPin = 9; // motor connected to digital pin 9
int analogPin = 0; // potentiometer connected to analog pin 0
int val = 0; // variable to store the read value

void loop()
{
val = analogRead(analogPin); // read the input pin
analogWrite(motorPin, val / 4); // analogRead values go from 0 to 1023, analogWrite values from 0 to 255
}


And the results:

Basic Motor Speed Control from Jeff Kirsch on Vimeo.

Controlling direction

Controlling the direction of a motor is as simple as changing the direction of current. That, however, is easier said than done. Basically, you need a set of electronically controlled relays to force current across the motor in one direction, or the other.

Luckily, such a setup exists, in one package. This H-Bridge chip actually allows directional control of two motors. In our setup, a switch is used as a digital input for the Arduino; this is then translated into output to two legs of the H-bridge, causing current to the motor to reverse direction. The wiring is pretty straightforward once you see what’s going on; the results are below.

Directional motor control

Directional Motor from Jeff Kirsch on Vimeo.

Code follows:


const int switchPin = 2; // switch input
const int motor1Pin = 3; // H-bridge leg 1 (pin 3, 1A)
const int motor2Pin = 7; // H-bridge leg 2 (pin 7, 2A)
const int enablePin = 9; // H-bridge enable pin
const int ledPin = 13; // LED

Lab instructions available here.

Controlling a servo

The first project involves a simple servo motor, connected to power, ground and an Arduino PWM pin (digital 9, in this case), and a potentiometer, connected to power, ground, and an Arduino analog input pin.

The code below is loaded on the Arduino. It reads and scales input from the potentiometer, and uses those values to control servo position through the servo library.


// Controlling a servo position using a potentiometer (variable resistor)
// by Michal Rinott

#include <Servo.h>

void loop()
{
val = analogRead(potpin); // reads the value of the potentiometer (value between 0 and 1023)
val = map(val, 0, 1023, 0, 179); // scale it to use it with the servo (value between 0 and 179)
myservo.write(val); // sets the servo position according to the scaled value
delay(15); // waits for the servo to get there
}


The results can be seen below:

Servo (Full Range) from Jeff Kirsch on Vimeo.

By changing the mapping from this:


val = map(val, 0, 1023, 0, 179); // scale it to use it with the servo (value between 0 and 179)


to this:


val = map(val, 0, 1023, 0, 90); // scale it to use it with the servo (value between 0 and 90)


we’re able to make the full range of the potentiometer only control movement between 0 and 90 degrees, as shown in this second video.

Servo (Partial Range) from Jeff Kirsch on Vimeo.

Controlling a speaker

Using another library, the Tone library, we’re able to easily produce audio from a speaker connected to one of the Arduino’s digital output pins. Analog input is provided by the same potentiometer as before. The code and results are below.


#include <Tone.h>
Tone mytone; // declare a tone name

void setup() {
// initialize the tone
mytone.begin(8);
}

void loop() {
// read the analog input
int inVar = analogRead(0);
// map the input to a frequency range between 200 and 2000 Hz
int note = map(inVar, 0, 1023, 200, 2000);
// play the note
mytone.play(note);
}


Arduino Synth from Jeff Kirsch on Vimeo.

Create something unique

At first, I wasn’t sure where to go with this part of the assignment; just a bit of a brain freeze moment. I decided to use a flex sensor in a voltage divider circuit as an input, put wasn’t sure what I could do with it that wouldn’t be boring.

Then, all it once, it dawned on me. I’d construct a simple tone-matching game.

Tone Game Tour from Jeff Kirsch on Vimeo.

I hooked a second speaker up to the Arduino and wired in the flex sensor, plus a simple momentary push-button switch. The script below does all the work, producing a randomly-generated pitch from one speaker, while controlling the pitch of another tone based on the input from the flex sensor. A simple boolean test determines if the note controlled by the flex sensor is within +/- 5 Hz of the target note, and if so plays a little “success” progression and selects a new target pitch.


#include <Tone.h>
//defines "BUTTON" as "13"
#define BUTTON 13
Tone mytone; // declare a tone name
Tone mytone2; // declare a second tone name
//create integer variable "randTone" to hold random tone values and initilize to 440 Hz
int randTone = 440;

void setup() {
// initialize the tone controlled by the flex sensor
mytone.begin(8);
//initialize the randomly generated "target" tone
mytone2.begin(7);
//begin serial connection for debugging
Serial.begin(9600);
//set BUTTON as an input
pinMode(BUTTON, INPUT); // and BUTTON is an input

//This function runs when the input note is close enough to match the target note. It plays a quick melody based on the target note, then calls generateRandTone() to produce a new target note for the next round.
void successRoutine() {
mytone.play(randTone);
mytone2.play(randTone);
delay(500);
mytone.play(randTone / 2);
mytone2.play(randTone / 2);
delay(1000);
mytone.play(randTone);
mytone2.play(randTone);
delay(1000);
mytone.play(randTone * 2);
mytone2.play(randTone * 2);
delay(1000);
mytone.play(randTone);
mytone2.play(randTone);
delay(1500);
generateRandTone();
}


A video of the game in action: (Warning, the audio is very, very annoying.)

Tone Game Demo from Jeff Kirsch on Vimeo.

Full instructions for the lab available here.

Using a simple variable resistor

The basic setup involves a potentiometer, which serves as a voltage divider without any additional components. The center pole of the potentiometer is run to analog input pin 3 on the Arduino, while the other poles run to power and ground. An LED (with a 330 Ohm resistor) is attached to digital pin 9 and ground to serve as our output.

The following code is loaded to the Arduino:

int ledPin = 9; // LED connected to digital pin 9
int analogPin = 3; // potentiometer connected to analog pin 3
int val = 0; // variable to store the read value

void setup()
{
pinMode(ledPin, OUTPUT); // sets the pin as output
}

void loop()
{
val = analogRead(analogPin); // read the input pin
analogWrite(ledPin, val / 4); // analogRead values go from 0 to 1023, analogWrite values from 0 to 255
}


The Arduino reads the voltage coming off of the potentiometer (reading 1023 for 5v, and 0 for 0 volts) and divides it by 4 to get an 8-bit value for pulse-width modulated output to the LED.

Adjusting LED brightness with Arduino from Jeff Kirsch on Vimeo.

The code also prints the values coming off pin 3 to the serial monitor:

Serial output of potentiometer readings from Jeff Kirsch on Vimeo.

Sensing temperature

The next step is replacing the potentiometer with another form of variable resistor (and an appropriate fixed resistor to complete the voltage divider). I chose a thermistor, and started with a 10k fixed resistor.

Squeezing with my fingers, I was only able to raise the temperature a few degrees, but there was clearly a change in voltages. The voltage drop across the thermistor read between 4.45 volts when “resting” and 4.38 volts when held, with appropriate changes in voltage measured across the fixed resistor.

Switching to a 1k fixed resistor gave a more even division of voltage at ambient temperatures, with the thermistor ranging between 2.45v baseline and 2.14v when held, with the fixed resistor taking on the balance of 5 volts in each case. Serial output reflected this with reads in the 500+ range.

Invent something

For the last part of the lab, we’re asked to make something with an analog input.

A raid of another institution’s computer store brought a very interesting component to my attention, the Sparkfun ADXL335 Triple Axis Accelerometer. Some quick research revealed that this breakout board outputs voltage between 0 and 5 volts from each of 3 pins depending on its orientation. That meant that I’d need three analog outputs as well. But what has three components with values between 0 and 255? Why, the RGB color space, of course. Luckily, the computer store also carried a diffused Triple Output RGB LED.

To start with, however, I simply soldered a header onto the accelerometer, hooked it up to the Arduino (with the help of this tutorial), and watched the values roll into the serial monitor.

ADXL335 Accelerometer soldered to a 6-pin header.

I then tweaked the code to map the input to three channels of PWM output and hooked up a few LEDs for a quick test.

Accelerometer-controlled LEDs from Jeff Kirsch on Vimeo.

With that all working, and having gotten past some common cathode confusion, I wired up the RGD LED, tweaked the code, and gave it a try.

Arduino + Accelerometer + RGB LED from Jeff Kirsch on Vimeo.

And there you have it… real-time color mixing based on orientation. My lovely fiancee Cara assisted with the demo.

In my excitement, I left the outputs connected to the closest pins of the LED, so in this video, the color channels don’t map to the axes in the correct order. In the code included below, X is blue, Y is red and Z is green.

/*
Created September 27 2009 by Jeff Kirsch

}


Thanks to Eric for his help in getting the input reading and output writing into a nice reusable function.

Lab instructions available here.

Soldering the power jack

Reverse of the 7805 5v DC regulator

With power flowing to the rails on either side of the breadboard, we’re able to use the multimeter to confirm a reading of 5.01v.

Next, we use a momentary switch, LED and a 330 ohm resistor to build a circuit.

A simple circuit

The voltage as measured at various points on the circuit is as follows:

• Across switch (open): 3.41v
• Across switch (closed): 0v
• Across LED (open): 0v
• Across LED (closed): 2.02v
• Across resistor (open): 0v
• Across resistor (closed): 1.91v

This makes sense. When the switch is open, no power flows to the LED or resistor. When the switch is closed, power flows to those components, and voltage drops across each. The closed switch provides no resistance, so there is no voltage drop across it.

The next circuit is simply two LEDs in series. Voltage drop across various components is as follows:

• + to LED1+: 0v
• LED1+ to LED1-: 2.69v
• LED2+ to LED2-: 2.40v
• LED1+ to LED2-: 5.01v

As the two LEDs provide adequate resistance (5.01v drop across the circuit), there’s no need for any additional components.

It really did read 5.01v when I pressed the shutter

The next step is to create a parallel circuit. For this, we’ll use three LEDs, and bring the resistor back in. Since the LEDs are in parallel, the voltage drop over each is the same (3.68v). Measuring current with the multimeter in series, we get a reading of 8.3 mA.

LEDs in parallel

Finally, we solder leads onto a 10k potentiometer, and connect that to a single LED and a 330 ohm resistor. Adjusting the resistance increases or decreases the voltage going into the circuit.

Varying resistance in a circuit from Jeff Kirsch on Vimeo.

The voltage ranges from 0v to 3.8v. The LED doesn’t come on at all until the voltage hits 1.72v, and gradually brightens until “snapping” to full brightness at 3.69v.

And that’s about it. Full procedure is available here.

The idea for this project stems from some thinking I was doing about how we, as humans, communicate. Despite cellphones, text messaging, email, teleconferencing and the like, there’s clearly a tremendous amount of value to physical contact, in all its forms, with other human beings. This is true not just socially but commercially, as evidenced by the continued need for business travel. Nothing closes a deal quite like a handshake. And nothing starts one quite like a handshake, either.

A handshake in itself can tell you a lot about a person. For me, an awkward one isn’t usually a deal-breaker, but it definitely does effect my impression of what comes next.

That initial handshake is usually followed by an exchange of ideas and information, to put it about as dryly as possible. If any of it seems to be leading anywhere, there’s usually a swapping of information about how to get in touch in the future. Maybe a business card, maybe a phone number on a napkin.

For an increasingly large number of people, the contact information they collect is stored digitally, but it’s rarely gathered this way, despite various attempts to make it catch on.

I’d propose that there are a number of reasons for this. First, most solutions are fairly clunky, require both parties to own the same hardware and software, and simply don’t provide any real compelling advantage over more traditional methods. Second, there’s a physicality inherent in the handshake and the card-pass that has some real value. (Admittedly, the latest generation of smart phones provides some examples of attempts to add physicality back into the equation, but they suffer from many of the same downsides as earlier efforts.)

What I’m envisioning is a digital exchange of data that happens silently in the background of a handshake. RFID-enabled rings transmit a unique wearer identifiers to each other. This exchange is only triggered when the rings are in close proximity. Contact information, including location and time of first meeting, is instantly sent to each party’s address book of choice. If this isn’t a first meeting, information is updated and appended as needed.

Now, there are obviously quite a few leaps being taken here, but hey, that’s the point of the assignment. To make this work, and avoid the problems of the earlier digital solutions plus a boatload of new ones, I’m assuming a few things are true. A non-exhaustive list follows.

• Battery life is not an issue
• There are well developed, open standards for RFID
• Various manufacturers use these standards
• There are well developed, open standards for storing and transmitting contact information
• Security considerations have been considered
• Internet access is ubiquitous

With such a system in place, business cards could become a thing of the past, as a seamless transmission of information directly to the place it was needed would occur as easily as humans have greeted each other for centuries. The information transmitted could also be context-specific, eg. when you’re out at a bar, your personal information might be favored over your work number and website.

It isn’t very much of a leap to consider a possible ecology of these sorts of devices, transmitting different information to each other based on the pairings. A ring in proximity to another device embedded in the back of a shirt might transmit data commiserate with a hug. A locket worn around the neck would likely share even more personal information. In this way, the different levels of digital data that each person maintains are mapped to our physical interactions with others in the real world.

I’m not saying this is something anyone would ever buy, or even want, but again, that’s not the point of the assignment. We’ve simply been asked to consider the ways that physical computing could effect our lives and interactions, and I’m perpetually fascinated with the space where the digital world and the physical world interact.

For the purposes of my in-class presentation, I’ve put together a much lower-tech prototype to mock up the interaction. I wouldn’t want all that soldering to go to waste.

Basically, I use an aluminum foil ring and bracelet to close a circuit and tell the Arduino to run a simple function. This function makes some fake “progress” lights turn on, and then sends hard-coded “contact” information to a console on a computer screen. It’s not much, but it helps illustrate the concept and allows me to show off my foil-jewelry making skills.

Imagined Physical Computing demo from Jeff Kirsch on Vimeo.

The basic setup is shown below, sans all-important human participants. I’ll get a circuit diagram up as soon as I get a chance.

Quickly prototyped board for use in class

The code running on the Arduino, tweaked almost beyond recognition, but based on a simple example from Getting Started with Arduino is below. It’s scarcely as clean, efficient or well-commented as it should be, but it works for a quick-and-dirty demo.

#define DEL 100
#define LED1 10
#define LED2 11
#define LED3 12
#define LED4 13
// the pin for the LED
#define BUTTON 7
#define BUTTON2 8
int val = 0;
int val2 = 0;

void setup() {
pinMode(LED1, OUTPUT); // tell Arduino LED1 is an output
pinMode(LED2, OUTPUT); // tell Arduino LED2 is an output
pinMode(LED3, OUTPUT); // tell Arduino LED3 is an output
pinMode(LED4, OUTPUT); // tell Arduino LED4 is an output
pinMode(BUTTON, INPUT); // and BUTTON is an input
pinMode(BUTTON2, INPUT); // and BUTTON is an input
Serial.begin(9600); // set up Serial library at 9600 bps
}

void myResetFunction() {
delay(1000);
digitalWrite(LED1, LOW);
digitalWrite(LED2, LOW);
digitalWrite(LED3, LOW);
digitalWrite(LED4, LOW);
}