Adventures in Electrostatic

Archive for the 'Physical Computing' Category

Reporting for duty!

Published by Tom on March 13, 2008 under Physical Computing

It has been an interesting semester thus far with my pseudo product the “FireLight.” At first I thought it would be whiz-bang its done… but it turns out things take a long time when you are letting yourself be picky. I mean, I took two weeks to finally decide on a light source, that is unlike me; I usually just grab what is most cheap and available. This time, however, I wanted to be more professional and patient with my design process, and I have to say, I like it. Read more »

Light and veneers, but no computers.

Published by Tom on February 20, 2008 under Physical Computing

Its been nice the past two weeks fussing over such a deceptively simple thing: light. Which type of light should I use, halogen, LED, cold cathode, normal incandescent, fluorescent. How much do I need; and at what power? And to complicate matters I have to think about light in the context of exactly what I want to do; namely, glowing through wood. Its all very illusive and tricky. There aren’t any standards by which to judge lighting that are reliable; Read more »

fireLight?

Published by Tom on February 6, 2008 under Physical Computing

So I have this vision… a beautiful object that is little and wood, and it lights on fire; and with magic, it turns on and controls a larger light source. I also have this class, Physical Computing Studio, where you can pick a project to work on all semester. So I thought, great, seems like a match made in heaven: I get to create this image my mind cannot seem to let go of, and better yet, I have enough time to make it really well and put it in the hands of real users. All sounds good… and it is… theres just one small problem. I am not entirely sure what the ‘point’ of it is (the object). Read more »

Hello Studio!

Published by Tom on January 30, 2008 under Physical Computing

Nice to meet you.
Since we are going to be together for a semester, I should tell you a little about myself and what I plan on doing. For starters, the reason I am in pComp Studio is that I get to work on a project in my own way… specifically, seeing what its like to do the ‘distribution’ part of a project. Now I know thats not what ITP is known for… but I’ve had a lot of experience in what ITP is known for and I want to know what it feels like to really finish a project. So, thats where I’m going, and what’s gonna get me there is a really small project: using a flame to control a large light source. Read more »

morgen - The Socially Networked Alarm Clock

Published by Tom on December 17, 2007 under Networked Objects, Physical Computing

Morgen is based on the idea that while many people hate their alarm clocks, few hate their mothers. Morgen is an interface that uses the connections between people to make waking up a more dynamic and meaningful experience. Read more »

Networked Alarm p.2

Published by Tom on November 5, 2007 under Networked Objects, Physical Computing

Since our last installment of the Networked alarm, we’ve made a few changed and advancements. (Man that sounded very government scientificy) First, Kacie joined me to make this a group project, which is great. Along with her came a very important concept: social networking. We wanted to make the process of waking up a more meaningful/rewarding experience, and we figured involving your friends/family would do that.

At first, we wanted to have audio messages from your friends/family wake you up in the morning when you got up and turned off the alarm. That turned out to be impractical for the technology we are using. So we turned to written messages instead. In some ways, little text messages are more intimate and cute (especially with the little LCD screens we got). AND, with text messages we can easily connect the system to Facebook and other social-networking platforms.

So this is how there system works:
In the morning your alarm goes off. The alarm randomly picks one of the several nodes you have around your house, and tells it to start making noise. You wake up from the noise that the node is making, and get out of bed. Once up, you have to figure out which node is making noise. Once you figure it out, you walk over to the node and press it to stop its noise. If you woke up and got over to the node fast enough, you are lucky and a message is displayed. The message is from one of your friends or family on the Facebook. Each day, there is a blank on the ‘Networked Alarm Clock’s owner’s Facebook profile where one person can input a message. The next day, that message is delivered to you at the alarm node.

If you are slow getting out of bed and over to the node, the message is not displayed and you miss it… forever. There is no way to recover your lost messages, so its an incentive to get out of bed.

In the last bit of the process, an email is sent to the person who wrote the message to you, telling them if you got the message or not, and when. If, on a day, no one leaves you a message, a default message is displayed which the owner sets. This could be a reminder or inspiration, whatever.

That is where we conceptually are.
Physically, we have work to do. This second week though, we have the wireless communication working, and the alarm clock hacked and accessible.

OH, and if you want to know more, see the pdf Presentation.

Reactive Spaces v1

Published by Tom on October 30, 2007 under The Softness of Things, Physical Computing

For Softness last week the topic was ergonomics. In my definition of ergonomics is probably wrong, but it all seems to be about the human body relating to things. How do we fit or interact with space. This all made me think of handles, mice (computer), gloves… all positive spaces, or spaces we wrap around. All of these didn’t really catch my interest… and maybe it was the architect in me, but I started thinking of the opposite: spaces that wrap around us. Like clothes that mold to your body or buildings that come to you. I think we are used to affecting small objects with our bodies, but what about big ones. What would it feel like to have a wall move around in response to you?I got lucky with timing because it just so happened to be motor week in pComp, so I figured I’d mix things up. What I envisioned was a hanging ceiling that would move and respond to you walking up to it and in it. The ceiling would move up to allow a little bubble of space for you to be in. Ideally, the ceiling would be a large area that many people could inhabit and interact in. A smooth, rich, surface would mold to your personal space. The people I talked to about this space/idea all really excited. There seems to be something in the largeness of the whole system… affecting a room, architecturally, with your presence.

Obviously, I could not complete a whole full scale ceiling in one week. So, I scaled back in a few ways: I changed the two-dimensional plane to a one-dimensional strip, and I made it physically smaller. It ended up being a little model where I could work out the mechanics and technical stuff, in preparation for a human-scale version. I learned a lot from this model. 1) DC motors are not way to go (too hard to accurately control), 2) IR sensors are a bit flaky and should be used with caution, and 3) A human-scale version of this project will be complex and expensive.

The basic system works like this: six panels of cardboard are connected together so they make a snake-like structure. At four different points, the structure is hung from strings which are connected to motorized rods. Below the panels are IR sensors which sense if something is under a specific panel or control point. When the IR sensor ’sees’ something, it tells that motor to pull the panel up. When it stops seeing it, it tells the motor to lower the panel. Simple. And because all the panels are connected, it makes one undulating surface. This prototype was somewhat of a failure, but I learned a lot of what not to do. So for next week I am going to make a second go at it. The topic will be space, so this project is well suited for it.

Networked Alarm p.1

Published by Tom on October 29, 2007 under Networked Objects, Physical Computing

I have a problem: I like to SNOOZE. I mean, it feels so good to go back to sleep after your alarm wakes you up, especially when its cold in the room, or you don’t really have to get up. I have tried many strategies to overcome this behavior: putting my alarm across the room, so I have to get up and hit snooze, giving myself a rule that I cannot wake up after 10am, jumping out of bed and yelling; but what usually happens is I don’t remember to use these tricks because I’m half asleep, or I get used to them and don’t ever remember walking across the room to hit the snooze button. I am sick of it. For my Networked Objects final project I am going to solve this one.

My plan is to make the alarm last long enough so that I actually wake up, and then hopefully make the more rational and reasonable decision to GET UP. This is how it will work: a little devise will sit next to my alarm, and three to four other devises will be placed throughout my apartment. When my alarm goes off in the morning, and I hit snnoze, the little devise sitting next to it, hears, and tells one of the other devises in the room to go off. So, I have to get up, find which one is going off, and hit it’s snooze button. Once I do that, it tells one of the other devises in the apartment to go off, so I have to find that one. This process continues until all alarms have been deactivated. Its like a like a little game. And because it is random which alarm goes off when, the game is always changing and I can’t learn it. I know it sounds drastic, but I’ve tried everything else (except having a regular sleep schedule I guess).

The great part about the system is that it is scalable. A user can add as many alarm nodes as they want, and the system automatically uses then. So if a person is really bad at waking up, they could have 10, or if a person just needs a little help, 2.

If you want to know more about the technical aspects of how the system would work, you can refer the the System Diagram.

Midterm

Published by Tom on October 23, 2007 under Physical Computing

I’m tired of tweezers. Mostly because I have been tying little knots in conductive thread and soldering way to small LEDs. Why? you ask, to make a physical away message. What? is that you ask, you can refer to the PDF or SITE linked at the bottom, but basically, its a way to let the people around you (especially at ITP) that you are either ‘available’ or ‘occupied.’ This is accomplished through a necklace with a user control and LEDs. I worked in a group on this one, Jen Grier and Heather Rasley, and we decided we wanted to make a pretty and elegant object… that worked… so thats hard, esp when it has to be soft, and portable, and robust.

Technically, the Physical Away Message, or PAM, is not complex, two or three simple switches that control an analog circuit; but fabrication wise, it was a difficult little project. We ended up making five prototypes, each approached a little differently, using everything from surface mounted LEDs, lace, two types of conductive thread, latex tubing, zippers, snaps, magnets, tape, wire, batteries (coin and AA), metal jewelry cases, etc… Needless to say we learned a lot about fabrication, specifically small fabrication.

Although our PAM was a daunting and, by the end, aggravating process of: design, prototype, test, re-design, prototype, test, again and again; it was great being able to have multiple revisions of a project. Usually at ITP we have one go at something and are always let saying: “if I could do that again I would…,” but with this midterm we got to try it again.

Working in a group was also helpful, especially near the end when we started multi-threading the project (each making our own prototype). Actually, the team work aspect was really enlightening. I have worked in team many times, but usually with team work the problem is complex and big, so many people can work on it at once. But with our PAM, it was small, so really only one person could work on it at a time, not efficient. Next time, when faced with such a situation, I will try to design the production part to be more multi-threaded.

Overall I am satisfied with this project. I am glad its over though, the world of wearable electronics is tricky.

Links:

Midterm Presentation (PDF)

Midterm Presentation (Website)

Team:

Jen Grier

Heather Rasley

Flag Waver

Published by Tom on October 8, 2007 under Networked Objects, Physical Computing

Wowy wow wow that was tricky!
I just finished my fist excursion into networking… a place I have never really been before. So for Networked Objects, we are using a little devise called the Xport. It converts serial data to the ethernet protocal (what the internet speaks), what that means is: I can now make my pComp projects (sensors, microcontrollers, LEDs, etc) talk to to the internet. Which is good because the internet has a lot to say and many people are listening. This all probably sounds complicated and scary… and it is. Mostly, I think, because there is so much going on I cannot control. In typical pComp projects you can touch the wires, program the chip…. debug all that stuff. But when you start playing around on networks, you often cannot change anything (its in other people’s control) and its invisible-that makes debugging really hard.

BUT, I prevailed, and it wasn’t that bad. I mean, it took a looooong time to get everything running right, but it was a great process.
So this is what I made: I made a little flag connected to a servo motor that waves every time someone posts a comment to THIS blog entry. So if you post a comment to this entry, the flag will wave at my desk… happy. It is a simple concept, but a nice one. Something physical happens in my world when you do something physical in yours-even if you are in Texas, China, or where ever. The execution however is not simple. Heres a summary: Arduino microcontroller tells Xport “go check if anyone has posted a new comment,” Xport says “ok” and connects to the ITP server. Once the server is connected, the Xport gets a message saying “hey, your connected,” it then passes it on the Arduino who says, “ok, go get a php file on that server,” the Xport does so and comes back with how many posts are on the entry. The Arduino then decides if there has been a new post, if there has, it tells the servo motor “wave that flag”… and the servo does, and I smile. If there is not a new post, the Arduino says “oh, well lets wait a couple seconds and try again”. And that goes on forever until I unplug everything.Lots of bits to get broken in there, but it all works!So thats about it, if you want to make me smile, post a comment.