The lost labs…

For completeness’s sake (and continuity’s loss), here are some bits from labs I didn’t document:

Early days -  analogue to analogue input (potentiometer controls LED):

Experimenting with servos – this was actually part of an abandoned midterm idea (the printer foosball notion, perhaps it’ll still be realized one day), but it’s more entertaining than my lab. A servo responding to colour tracking:

What came next..

The rest of the acupuncture project was documented at zangfu.wordpress.com, but I wanted to use this blog to discuss some of the technical issues in further detail.

Basically, we wanted to create a system where an ‘ordinary’ acupuncture needle could trigger a switch – we needed something that would be soft and reusable. Thomas Gerhardt was working on something similar – a felt resistor – and suggested using steel wool. This proved fruitful – we eventually constructed a series of ‘cartridges’ containing two bundles of steel wool, separated by a layer of rubber. The one bundle was hooked up to power, the other to ground, and when the needle penetrated both, the circuit was completed.

A problem: steel wool ignites when you put 5 volts or higher near it, so we had to restrict our power input to 3v (easily done with the Arduino Diecimila, where you can set output to 3v, but we stuck a regulator on the board too, for peace of mind).

A bigger problem: the needle sometimes takes bits of steel wool with it when we’re poking around, creating a situation where the two wool bits are permanently connected. After trying extra layers of glue, packing the steel wool in latex, we eventually came upon the most effective (and seemingly most obvious) solution – adding extra rubber. As of writing, this works. Some pics:

And here’s our initial ‘aha’ moment with the steel wool (sorry for the lousy lighting):




AP: themes, designs

Aram brought his acupuncture doll to the floor on Thursday, which opened up some new ideas – one of the things that Aram had expressed earlier was the visual connection between the multiple ‘nodes’ on the doll (connected by colour-coded lines) and the NYC subway map. This seemed an apt metaphor for the acupuncture process – the subway lines as veins or energy ‘meridians’, the flow of people through the city like a bloodstream. Acupuncture, as Aram explained, is about balance – in a simplified way, it’s about locating ‘congested’ areas on the body, places where there is an uneven distribution of resources. In this way, it’s a lot like a microcosm of a public transport system.

We’ve got our reservations about the correlation between the two systems coming off as a little too ‘cute’, but for now, it still seems like a potentially rich relationship to explore.

Acupuncture: research phase.

My first feelings about the interface for my idea were that it might begin as a kind of ‘game’, involving people applying ‘needles’ to some kind of doll or model to manipulate ‘flows of energy’, however I might choose to represent those.

I presented a vague sketch of my idea in Physical Computing class, and some new stuff emerged: Tom suggested that the project might have a valuable educational capacity (an aspect I hadn’t fully considered before), and some other people in the class suggested the the ‘model’ should be a 1:1, full-scale representation of a human form (I’d been thinking of it as a lot smaller). Tom also talked about the reality quotient – how far you can push ‘realism’ before it becomes creepy/undesirable/ultimately unrealistic. The trick, it seems, is to find a model for reality that exactly meets your needs, neither failing nor exceeding them.

The most important thing to come out of the class was a suggestion by Alex that I talk to Aram, who he said had some detailed knowledge and experience of acupuncture. Aram is in my ICM class (which is, in this case helpfully, just after my P-Comp class), and so I grabbed him seconds after it ended and asked if he’d being willing to share some of his knowledge with me sometime. What followed was many hours of conversation (and, in my case, education), after which Aram decided to leave his current Physical Computing group and, to my great joy, join the acupuncture project.

Though bursting with multiple ideas, we agreed on a couple of things: we didn’t want to create a strictly educational, entirely reverential expression of acupuncture – we both were more interested in using the model of acupuncture to express something more personal and maybe more emotionally charged than just an interactive ‘how it works’ piece – we felt strongly that the project shouldn’t be didactic in any way. Additionally, while not wanting to do away with all educational qualities of the work, we quickly realized that a full scale model wouldn’t serve any of our purposes – the actual acupuncture process is so complex and nuanced that the amount of knowledge we’d be able to express on a full body model would be necessarily limited. Better, we felt, to ‘accurately’ communicate one central part of acupuncture than attempt the capture everything about it (and, in doing so, risk misrepresentation).

Final project: Acupuncture Interface, first thoughts

Around the beginning of this year, I went to an acupuncturist. It’s not the kind of thing I usually do – those who know me best will attest to my general skepticism regarding…well, everything really. So entering into ‘alternative’ therapy, handing my body over to a person and a process that I knew so little about, was simultaneously thrilling, mystifying, amusing, and a little scary.

I had a few acupuncture sessions, and I stopped my treatment without really making a decision to – after missing one appointment, my lack of time and money (as I was preparing to move to NYC) suddenly seemed very apparent. I wasn’t quite sure if the acupuncture was helping what I was wanting it to help (while I’m in confessional mode: some stomach problems, a too-often runny nose, general unwellness), but I did feel great afterwards: I was exceptionally relaxed and calm for the rest of the day, at least. And during the procedure my mind felt clear and focused – which finally brings me to the beginnings of this project. What struck me most, while lying on my back staring at the ceiling, was just how abstract, almost metaphorical the whole process was – I hadn’t been given (or really been expecting) a full explanation of what was happening to me and how it was going to work. In fact, I couldn’t even really tilt my head comfortably enough to see the size of the needles I was being poked with. My body image (both internal and external) was pretty much the product of my mind, with the odd physical sensation (pulsing, tingling) acting as a sort of clue. I wanted, someday, to visually articulate what I felt was happening to me, and explore the disconnect (or connect!) between, I suppose, the knowable and the unknowable.

It resurfaced as a concept for both an ICM and physical computing project a couple weeks ago, at the intersection of numerous ideas. In my “Mapping Narratives” class, I’ve been thinking a lot about some kind of data visualization – or map – of bodily image or process. This begun as an ICM midterm looking at ‘phrenology’ – the pseudo-science that posits the brain as a collection of localized regions – but now I see the opportunity to collect all these threads into one project, involving acupuncture.

Idea!

Have also been thinking the last couple weeks about the ultimate version of our foosball game – eventually, I’d like to see it control an actual table, with actual foosmen. Since we’ve been relatively successful so far in our protoype efforts, we might have more time to focus on this aspect (which we’d decided to leave for a future iteration). I’d been having a hard time thinking about how we might control the lateral movement bar (some kind of gear system? pulleys?) until last night, when I hit upon the idea of using a modifier printer interface (which is already adept at speedy back-n-forth motion). Now investigating getting hold of an old, fairly robust dot matrix printer, and seeing what can be done with it (have already been directed towards the Dot Matrix Printer Symphony).

Documentation of lateral movement via distance sensor

Sandra shot this video, documenting our trials with the distance sensor.

Midterm, part 2.

After working out just how we wanted people to interact with ‘football’ (ie. standing or sitting, how many feet could be used in the game, what kind of motions felt intuitive, which ones made you lose balance or control), we began looking at our tech possibilities. Of the knowledge and sensors we had available, we decided to try some options that seemed achievable – using motion-tracking to control the ‘kick’ aspect, and either a set of switches, a kind of ‘rolling pin’ or distance-sending for the lateral movement.

Since I’d had some experience with motion-tracking, using Max/MSP and Director, I decided to discover how it worked using Processing. Tom has significant Java experience (which would be very helpful with game development), but hadn’t used Processing before (though it’s built on Java), so he begun investigating how it worked.

Sandra had purchased and user her distance sensor for one of the labs, so she started testing with it.

I discovered that tracking an average location of movement proved quite successful in imaging a kick movement, though didn’t allow for fine control, since as soon as ceased moving, it would cease detecting. I now want to combine this approach with colour tracking, and see if I can produce more subtle and tweak-able range of values. We also decided as a group to add some physical requirements to our interaction, to get more stable results from our computing components. It seems now that participants will strap a coloured velcro band to their foot/shoe before playing. The viability of this has yet to be user-tested.

Sandra and I worked on a simple Processing application that fed in values from the sensor, and it turns out that the distance sensor has wider range of ‘width’ detection than expected (ie. it not only senses how far away your foot is from the sensor, but it allows for a decent amount of ‘back and forth’ movement within that). Sandra, I think, is going to now focus on the housing necessary for the camera and distance sensor, both of which seem to be viable options.

Tom is continuing to work on Processing and the game development, though has contributed to the colour-tracking research, suggesting the velcro strips.

MidTerm Beginnings

Our team (myself, Thomas Chan and Sandra Davila) originally had rather divergent ideas for our midterm, that, it seems clear only now, have all informed ad contributed to our choice of project. Thomas was interested in some kind of gestural tracking device (such as a replacing the mouse with some kind of physical hand-and-finger controlled interface), Sanda was thinking about something that would control people’s movement through subway stations, primarily via the feet. All I knew was that, since I’d been using the “Pong” model for my lab experiments, I would enjoy developing some kind of game interface.

We settled, apparently arbitrarily, on a kind of foosball controller – we happened to be sitting by the table when discussing our ideas, and it eventually encroached on the creative process. Tom and I both had a propensity for foosball, and Sandra, though not an avid player, enjoyed the idea.

Initially, we wanted to replicate the foosball interface (ie. an up-and-down movable rod with a left-to-right turnable knob) as a videogame controller, and allow this to communicate with an online, screen-based foosball game.

After investigating some of the potential technological solutions (a rotary encoder, a sliding potentiometer), we soon realized that our biggest challenge was going to be preserving the feel of actual foosball in the compromised context of the game controller. Our difficulties here forced us to more directly confront our creative goal, and we agreed that, instead of reproducing an already-understood interface and sending it online, we wanted to confront the actual method of interaction. Earlier, I’d jokingly come up with the idea of foot-controlled foosball (ie. ‘football’ ), and this was revisited when rethinking our project. We all liked that this would allow us to mount a larger critique of how interactions are translated through different mediums, from an actual foot and body-controlled soccer game, to a hand-controlled bar game, back to a foot-controlled digital game.

PotPong Touch

Updated PotPong to take two analog inputs – one from the potentiometer, the other from a touch sensor (which would default to a setting of ‘255′ when not in use, and needed some software constraints to be fully usable). Additionally, the Processing code would write back to Arduino – an LED light would go on or off depending on which side was ‘winning’.