Category: Physical Computing

WWMD (What Would Moses Do) – Final Documentation

WWMD allows a user to control a wall of water with the wave of their hand. I built this project along with Mark Breneman for our ITP Intro to Physical Computing final project.

Water control comes from a Kinect tracking hand movement, communicating the data to Processing, which then sends it to an Arduino controlling a stepper motor. The motor turns gears on a tube of water which has holes drilled on one side. The wall of water is open when the holes face down and closed when the holes are above the water level.

Continue reading

ITP – PComp – H-Bridge lab

For the “Get Creative” section of this lab, reference my Final Project. I will be spinning a motor to move paddles and control water. Changes in x position will move the paddles and water, creating or narrowing a gap in a wall of water.

ITP – ICM & PComp Final Project Concept

I have found an inspiring project that I’d like to tackle as a combined final project for both my Intro to Computational Media and Intro to Physical Computing class. It is a device that uses an Arduino and Processing to draw images on a wall.

It seems like these types of devices have been around since the mid 2000s, but only recently adapted to the Arduino by people like Der Kritzler and Drawbot.

Der Kritzler was designed to draw on glass

This drawing of Abraham Lincoln was done by Drawbot

So building another version of these items will certainly not be groundbreaking technology. The hardware set-up seems manageable for a beginner like me.

Nonetheless it will certainly be a helpful learning experience for me since I am rather inexperienced in the physical computing realm.

But I am also intrigued by the possibilities to add on to the concept once I get the basic foundation built. First, I would like to offer it up for use by the ITP community in a common area on the floor if possible. It could allow students to showcase their talent or to make announcements about upcoming events. It would be great to have a system of archiving what is produced and posting it online, or simply hooking up a camera for live viewing of the pen drawing. It could draw weekly, daily or hourly. Perhaps I could generate an online queue that would allow people to submit their work and have it draw when it is available or at a certain date & time. Perhaps the pen could also write comments from the community about the generated art. Perhaps the generated art could be on a whiteboard but the comments could be printed out on paper below. Perhaps there could be a way to integrate the feed with the laser cutter, silk screen or Makerbot 3D printer. Perhaps I can create a dock that can hold different colors or types of pens and cycle through them as needed in the drawing, escaping a mono-color approach.

Also, it would be good to explore a range of image processing options for translating a photo or SVG image into a drawing. Der Kritzler writes left to right, one line at a time. Others like SpritesMods version seem to draw with an assortment of up/down/left/right movements.

With my recently completed media controller project, we rushed to get all the pieces together in time for the deadline. I am hoping with this project that I can get the general outline of the device working a good week or two before the deadline so that I can spend more of my attention on these other style/output issues. This, along with the image submission/queueing, could help refine the product and make it more accessible for the user. I believe there is considerable value in these tweaks.

ITP – Physical Computing – Interactivity Observation

For my Physical Computing class, we’ve been asked to observe a piece of public interactive technology. I watched people at my subway stop buy MetroCards and enter the subway.

Starting with the cards, I have always found it odd that NY went with a system of cheap cards that require swiping. A much better system adopted by countless other cities use RFID cards, which require you to just tap or hold the card at the turnstile. NY’s system inevitably ends up with people having to swipe many times (at faster or slower speeds) or replace cards as the magnetic strip on the back wears out. Most tourists seem to have trouble getting the swiping thing down. There are no instructions and only limited feedback (“Swipe again” or “Swipe again at this terminal”). If the speed of their swipe is the problem, the system should alert them to that.

Observing people enter the subways in the morning around 8am on a weekday, I was surprised by how almost everyone was able to get through with one swipe (more than 90% of the people). The people I watched who did not get it in the first swipe were most likely to require three or more swipes (over 70% of the multiple swipers). I think the fact that it was rush hour meant that most riders I observed were not tourists, but rather people on their way to work. I am sure the rates are much worse in places like Times Square during the middle of the day.

Had NY adopted an RFID card system, most New Yorkers would require less time interacting with the MetroCard self-help terminals. They could add a bigger balance to their card since they would feel less secure that they would lose it (since they would not need to take it out of their wallet or purse to enter the subway) or that the card would wear out (flimsy, free cards tend to do that).

Nonetheless, the MetroCard terminals are generally well designed. Multiple language options are a plus for this city. Multiple payment options are also a plus, although the cash system is quite slow. The machines are very picky about the bills, so it takes some time to pay this way. The majority of the people I observed were using cards (debit or credit) to pay. I think this option alone greatly reduces the amount of time required between starting and getting a card. Once again, most commuters in a hurry seemed to be able to navigate the system quite quickly (in under a minute).

ITP – PhysComp – Stupid Pet Trick

As with my fellow first-years at ITP, I have been working on my Stupid Pet Trick assignment for the Intro to Physical Computing class. The assignment proved to be much more of a challenge than I expected. I think in large part this came from the project I chose to pursue, which required much more building and much less coding than I expected and actually wanted.

My goal was to produce a product that had a scale with a Big Mac on one side and a piece of fruit on the other. It would be like having a devil on one shoulder and and an angel on the other. Depending on what the person picked, the scale would tip and trigger one of two buttons. Behind the scale is a black board with a head-sized mirror. When the person makes his choice, one button can trigger a set of horns or a halo.

Continue reading

ITP / PComp Week 2 – Fantasy Device

The device I would love to have is based on my experience as a diabetic. I would love to have a data aggregation device to easily collect my daily readings. This device would work with all brands/manufacturers and all types of medical devices. It would not require me to log into a computer, would not ask for passwords and not serve any other purpose other than collecting and transmitting data.

Continue reading