The first assignments for Zachary Eveland’s Wearables Studio class were as follows:

Assignment: Make a wearable
Come to class next week with a working wearable device or garment. This assignment is just a sketch to get the juices flowing – whatever you make should function, but rough edges are fine.

There are no restrictions on the type of wearable, but it should relate to your semester-long project. Use this as an opportunity to experiment with new materials or techniques. If you haven’t built a soft circuit before, this might be a good time to do so.

Assignment: List your project concept(s)
During next week’s class, we will discuss and finalize everyone’s concept for semester-long projects. If you have more than one project in mind, write them all down.

Immediately after the first class, I went to the NYU computer store and picked up a new LilyPad, in case my project would require one—I definitely don’t want to have to unstitch that fucking glove until I’m sure we’re done with it. Then, all week, I was pondering what I could make. An apron with timers on it? A doodad in my handbag that would turn my living room light on and off? I don’t know; I suck at ideas.

I also suck at not procrastinating, so on the morning of class I ended up doing the quickest thing I could think of: taking apart my brand-new TV-B-Gone (which I bought readymade, not as a kit, because I know I can’t solder that kind of fiddly thing to save my life), mounting it on the back of a felt flower (formerly a barrette that came in a Sampler box), and hooking the whole thing onto a big safety pin so I could attach it to my sweater.

Such craftsmanship!

The point of this object is that the off-the-shelf TV-B-Gone comes in a rather menacing-looking black plastic case, and holding such a thing up to point it at a TV would be conspicuous and would probably get you accused of being a terrorist. The happy felty flower pin, on the other hand, is extremely stealthy: because the center LED emits IR, it doesn’t visibly light up when the button (located immediately under the LED, and clickable through the felt) is pressed. There’s a red indicator light that blinks when the IR beam is active, but it’s hidden behind the flower petals and so only visible to the wearer (except, maybe, in a dark room—but everyone will be looking at the TV, of course, not at your goofy brooch). It’s kind of inspired by the TV-B-Gone hoodie by Becky Stern, but my problem with that idea is that you have to be wearing your hoodie all the time. I like hoodies plenty, but I would never wear the same one every day, which means I probably wouldn’t have it when I needed it. A pin, on the other hand, could be attached to a hat, coat, or handbag that’s worn every day.

For the second assignment, I scribbled down notes about two ideas:

Party Dress

polka dots or other pattern elements have RGB LEDs on them, so that

• dress can change color to
  • match rest of outfit
  • indicate motion–e.g., red if the wearer becomes horizontal
• lights pulse when
  • your cell phone is ringing
  • someone stands close to you
  • nobody stands close to you

Memo jacket / scarf / pin

• records snippets of audio, e.g., notes to self
• transmits recordings wirelessly to computer, where assistant can transcribe or otherwise file them
• last recording can be played back
• camera can take a snapshot whenever she puts something away that she’s afraid she might lose
• emits a sound when the calendar on computer says has an appointment coming up
• has a display that can show messages/reminders
• can transmit an emergency call to her computer

The Party Dress idea came from a conversation I had with the magnificent Erin McKean of, among other things, A Dress a Day. The Memo Jacket idea is for my mom, who’s convinced that she has Alzheimer’s Disease. I don’t know how to implement either of these ideas, but the Party Dress is much closer to my field of nonexpertise, since I’ve already worked with IR sensors and LEDs. How one connects that many LEDs, I have only the vaguest idea; and how one gets one’s cell phone to talk to them? Well, surely somebody else can figure this out for me.

In class, then, we did an brilliant thing: Zachary had us each explain our project ideas to another person (or, well, it was supposed to be two other people, but I was paired up with Lara, who’s all about wearables, and we ended up just talking with each other), and then that person explained the project to the class. So we got to hash out our ideas a bit in a low-stress interaction, and then we got to hear what parts of our description were most memorable and comprehensible.

Above is the PowerPoint slideshow that Diego made for our in-class presentation. There is also copious supporting material at the following locations:

• Photos, with lots of chatty comments
  
• Videos, interspersed with kittenage
• Arduino code
• Processing code
  • colors_highlight_new_swatch – this is the color palette module. It reads a text file containing all the colors in the appropriate Krylon spraypaint line and outputs them as a grid of colored squares. The active swatch and rolled-over ones are highlighted with colored borders. It’s glitchy, as you can see if you look in the upper left corner, but basically it works.
  • spraycans – I would like to make my own set of brushes, based on Diego’s, that are all the same style but in different sizes. These would then be mapped to the number of fingers being held up, with more fingers triggering a bigger spray cone. This would make it easier for users to get predictable, slightly repeatable results. Toward that end, I made a spraycan object whose spray cone, label number (for the size), and can color (for the paint) are variable. Epileptics should probably not view this sketch.
  • Main application – The “final” in “final_application_4″ refers to the this being our final project for the semester, not to the code itself actually being final. For, verily, it is not. This is the wrapper into which all the other modules will eventually be rolled. It’s a whole lot of nested if statements and functions. This program doesn’t run unless the glove is plugged in; I should fix that, to make it easier to check code while programming.

So then . . . The other day I was talking about the glove project with my friend Rose, and I rhetorically asked what the hell this kind of low-fi, large-format drawing setup would be good for. Rose’s answer was immediate: graffiti.

Duh.

So then, what we need is just a limited palette of Krylon spray paints, and a couple of brush types—say, a fat marker and three sizes of spray patterns. And then, when I asked my perpetual question of “What are the other fingers doing?,” Diego had this brilliant idea: the number of fingers you’re using determines the brush size. Index finger for the marker; index and middle for a small spray nozzle; index, middle, and ring for a medium spray; and all four fingers for the biggest spray—what you’d use to fill. That’s a pretty intuitive mapping. We wouldn’t need to track motion on all the fingers, just whether they’re flexed or not. And we could use an accelerometer to register wrist tilts, somewhat like the Rock ‘n’ Scroll, to cycle through the color palette.

The thumb would remain an on/off switch.

We could have different backgrounds to paint on, like brick walls, subway cars, trucks.

Bitchen.

This idea is, in fact, so cool that it has already been done.

Developing . . .

Photo: ASBO by rubberdreamfeet / David Hayward. Some rights reserved.

Ever since we started putting the actual glove together, I’ve been thinking about how the software side of this project should take into account what I expect to be a pretty low-resolution input system. When I was making a drawing interface for what was purely an ICM project, I was assuming an average level of mouse dexterity. The stroke-width picker that I made last Wednesday, for instance, is obviously too small to be operated with our crude pointer.

So what kind of interface would work?

I did some Googling around, to get ideas of what kind of controls can be operated with little dexterity. In particular, I looked for things you can do while wearing mittens, since I figure that that’s approximately the level of control our hypothetical user will have. Some findings:

Some military radios are touted as being usable even while wearing Arctic mittens: “The desired frequency is set by four knobs on the side of the radio which can be operated even while the operator is wearing Arctic mittens, or in the dark by counting clicks from the end-stops” (”Clansman PRC-349 / RT-349 VHF Transceiver,” Armyradio.com). Its that idea of click feedback that I find interesting. If you’re choosing from a limited set of options—say, brush sizes— on a very small display, it’s not too annoying to cycle through them one at a time to get to what you want. This is the way my cell phone, toaster, and camera menus work. And they all provide beeps or clicks for feedback. What kind of feedback will we give to let our user know what’s going on?

Other physical controls that can be operated while wearing mittens include a camera’s zoom ring and aperture and shutter speed dials (Matthew G. Monroe, “How to Shoot in Freezing Temperatures and Keep Your Hands Toasty Warm,” digital-photography-school.com); Velcro closure tabs on outerwear; and KEYnetic’s rock ‘n’ scroll cell phone interface (via LyteByte).

On the screen side of things, some relevant input methods include Morse code and onscreen keyboards. Again, I like the simplicity of tapping, though I can also see uses for a matrix of a few very large buttons.

Obviously, with two weeks to go, I don’t have time to really get into learning interface design for this project, but I think where I’m going is toward a system that has a drawing mode and a tool selection mode. When you’re drawing, there’s nothing else onscreen except maybe one or two tools or hints—how to turn the drawing line off, how to activate the control menu. You can’t select these controls onscreen, because how would you do so without drawing a line all the way to the button? And whatever gesture you use to activate the menu must be able to be done without moving the drawing pointer.

The Rock ‘n’ Scroll model is pretty good for us within one mode or another, but you have to be able to switch between the two without moving your drawing pointer. So that would involve . . . the thumb? It’s possible, though not necessarily easy, to move your thumb without moving the rest of your hand. So maybe as long as your thumb is tucked in, the pen is on, and if you stick it out, the pen is off.

Once we’ve got a way to separate the two modes, I was thinking the control screen would be super-simple, with only one control editable at a time. So, something like this:

Photo: Elephant Painting by Venson Kuchipudi. Some rights reserved.

I finally managed to be in the same place at the same time as Diego, so we were able to make a work plan, go buy some supplies, and put together our first prototype of what now seems to be The Drawing Glove.

Well, actually, first, we were able to sit there scratching our heads over how to connect a flex sensor. I’ve had one of those things for months and never used it, because I could never figure out how it should be connected. So I looked online and found . . . lots of other glove projects using flex sensors. That’s okay, though—“This one is different—because it’s us.” I also found some inspirational photos of flex sensor connections.

People had warned us that these sensors break easily, and I’d read that they only last for a limited number of bends. I knew there was no way I could solder wires to one these without wrecking the whole damn thing, so I thought that for quick-and-dirty prototyping purposes, maybe I could just hold them together with electrical tape.

Yeah. Meanwhile, Sofia wandered over to ask what we were working on. She, too, was making a glove, and I took the opportunity to ask her how the hell she was attaching her flex sensors to wires. The answer: wire wrap. Okay, that makes sense. She also kindly revealed the location of the specific Radio Shack where she’d managed to find a wire-wrapping tool, but it turned out they had them (albeit somewhat hidden) at the store closest to school. So Diego went out and got us some enamel-coated magnet wire and a wrapping tool.

Man, I am never soldering anything, ever again. Wire wrapping is the way to go.

Diego had attached the flex sensor and LED to his original, flat prototype using Velcro, and we decided to stick with this approach (so to speak) for the glove version. So I borrowed a needle from Thomas and spent a ridiculously long time sewing tiny squares of black Velcro onto a black glove using black thread, in the inky darkness that is the central work area at ITP. The following photo is enhanced for your viewing ease; in reality, I could not at all see what the fuck I was doing:

Finally the wires were all wrapped, the Velcro was all attached, the alligator clips were clipped (yes, the wires we laboriously wrapped were too short; and your point is . . . ?), and we had a thing to test.

Hey! It lights up!

It even stays lit when you put it on! And the flex sensor turns the LED on and off!

As the video shows, we soon ran into some technical difficulties. I ended up tailor-tacking the sensor and all the wires down, so that they’d stop pulling out of place. But it kind of works! Amazing!

Onward. Next, we get to try to attach the remaining four sensors and LEDs. And we’ll probably want to eliminate some of those noisy wires, since flex sensors really don’t like them.

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.)

Diego and/or Filippo cut all the squares out of black foamcore and set two of the infrared sensors into the sides. Then, when I rolled in after dinner, I taped the pieces together into a flat pattern and made velcro hinges to pull it together into a box:

And then—my crowning achievement of the day—I devised a neat little latch for it.

While Diego and Filippo were figuring out more deluxe ways to use Minim than what I had hashed together the day before, I set about making my breadboard setup a little more robust, so that it could stand being sloshed around a bit in the box. Because the wires that came with the IR sensors are multistranded and very fine, they’re difficult to poke into the holes in a breadboard, and then they don’t want to stay in once they’re there. So it seemed to me that they ought to be soldered to header pins, as shown in the soldering lab.

This is, of course, much more difficult than it looks—for me, at least. I present to you what I believe to be my ugliest soldering job yet:

Hideous. Pathetic. Heartbreaking.

But soldered they were, and they were, in fact, slightly easier to plug into the breadboard. Once I, you know, straightened the pins out with pliers.

How are you supposed to do this? Is there some trick to soldering multistrand wire to a header pin? Was I just doing it all wrong, wrong, wrong? Is it a mess because (a) I can’t see in the shitty light of the lab, and (b) I can’t hold my hands steady? I hate this. Help!

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

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.

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:

And then, there was serial output:

• “Now you get a range of garbage characters.”
• “List all the available serial ports.”
• // 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:
println();

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:

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.

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 CanadianMusicArtists.com. 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.

I was trying to figure out the math to make part of the graph show up as brown—i.e., earth—and then scatter flowers on top, but something wasn’t working out and I was running late, so I gave up.

Anyway, here are the progress shots:

Setup:

Pot hooked up:

Blinking LED:

I also shot a fascinating movie of the program loading on the Arduino and starting up—you know, flickering yellow light, then blinking LED; hot stuff:

Final code on Arduino:

int potPin = 0;
int potValue = 0;
int ledPin = 2;

void setup()
{
// flash LED three times to announce start of program
pinMode( 2, OUTPUT );
digitalWrite( 2, LOW );
delay( 500 );
digitalWrite( 2, HIGH );
delay( 500 );
digitalWrite( 2, LOW );
delay( 500 );
digitalWrite( 2, HIGH );
delay( 500 );
digitalWrite( 2, LOW );
delay( 500 );
digitalWrite( 2, HIGH );
delay( 500 );
digitalWrite( 2, LOW );
delay( 500 );
digitalWrite( 2, HIGH );

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

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


Final Processing applet