Not Quite a Meditation Device

So I’m stressed. Really really stressed. Schoolwork, work-work and all the noise of life.

After our Synthesis session on Friday, I began trying to devise my next little project for Physical Computing, and I realized that what I really want is a machine that will help me calm down. Remembering that meditation devices were among Tom Igoe’s greatest physical computing hits, I set about imagining what meditation device I would make for myself. I didn’t want it to measure something invasive like breath or sweat; I wanted it to be something a person could interact with voluntarily that would soothe through the interaction.

I thought about the stress relief balls that used to be on everyone’s office desk, and started thinking about using one to control a visual program. My thought was that I might squeeze a ball (which intrinsically feels good and relieves some stress) to drive a calming visualization.

But what aspect of the squeeze and what aspect of the visualization? It occurred to me that one of the things that helps me to calm down is deliberate, repetitive motion. I decided that the program would have the user set a rhythm (or rather, a time interval), then place a cue for the smoothest, most regular interpretation of that directly in the middle of the user’s field of vision. The goal would be to squeeze smoothly and make the cue disappear by matching one’s own actions to the computer’s ideal.

(And let me say here that I should have talked this out to myself – any place where there are words like “goal” and “ideal” is a terrible place to begin thinking about mindfulness… but I digress.)

I considered using a Hall Effect Sensor on one side of the ball and a magnet on the other to measure the “squeezedness” of the ball, but Tinkersphere was out of analog Hall sensors, and I realized an FSR taped to the surface might do the trick just fine, with maybe even more flexibility in terms of ball choice. I then went to the 99-cent store and bought a selection of squeezy balls. After a market survey of one potential user (my girlfriend), I decided that the “Guardians of the Galaxy” ball was best for size, firmness and overall feel.

I mounted the FSR to the outside with tape, wrote a program for the Arduino to gather pressure data, then wrote a program in P5 to pull that data and analyze the pressure of the squeeze and the period of fluctuation. It then calculated the average time between peaks, and set that as its “ideal” rhythm.

The program works with the user by coloring the background to match the squeeze – white for no pressure, black for max pressure. It then projects the “ideal” pressure at any given moment in a sort of sphere-like object in the center of the screen.

And I tried using it and realized that I had created the exact opposite effect from what I had intended. Far from it being easy to set my own rhythm to the computer’s, it was intensely difficult – I had made for myself a demanding and unsatisfiable taskmaster.

But at the same time, it was an oddly compelling interaction. I discarded it after the first evening as digital fascism (or something very like it) and then returned to try it again the next evening, just for the hell of it. Miraculously it was much easier, and still much more engaging than two shades of gray on a computer screen ought to be.

The problem, though, is the falsehood of the central premise, namely that there’s something to be gained by syncing one’s own motions to a computer’s suggestions. The thoughts I have (and they are many) center around two lines of inquiry. First, it would be much more interesting to use the same program to have two users sync their motions to each other, remotely – a weird wordless way for two friends or separated lovers to connect, or two strangers to meet.

The other is that it’s a great definable but essentially unpredictable input – the user has full control but not necessarily much understanding of that control. It would be fascinating to drive an animation based on parameters (pressure, period, regularity) supplied somewhat thoughtlessly by one (or, better, two) users, where nothing was clarified (i.e. “by doing thing X to the ball, thing Y will happen on screen) except through iteration.

Thoughts, thoughts… more to say coming soon!

Comments are closed.