Joan Dress Update

Hey guys,

I have updated my Joan Dress blog, and have reached the end of phase 1 of the development process. Check it out!

Actions, Events, and Filtering

I wrote a program in processing that reacts to how vigorously you shake an accelerometer.

The arduino communicates the sensor's readings through a serial connection to processing. I used a smoothing function, in my arduino code, to get clean values from the accelerometer, which tends to give very eradict readings otherwise.

calm
Originally uploaded by 0x000000.

When you first open up the processing app, it is a calm, blue day.

planting
Originally uploaded by 0x000000.

If you make it so that the sensor's readings match up on the x- and y-axis, you plant flowers on the screen.

blowing
Originally uploaded by 0x000000.

Slightly shaking it causes the blooms to blow...

storm
Originally uploaded by 0x000000.

Quickly shaking it causes a rain storm (and all the flowers blow away)


Leaving the sensor alone for 10 seconds let's the storm go away, returning you to a clear day.

Download Processing and Arduino code

language objects

The Inkas may have used clusters of strings and knots (called khipu) as their way of recording language, while most other cultures of the world have used written records of ink on paper. This suggestion is described in 1491: New Revelations of the Americas Before Columbus by Charles C. Mann, Appendix B.

Honestly, I have never stopped to think about representing language in terms of objects versus written symbols, but the concept of creating a physical system for recording thoughts is actually quite inspiring. It reminds me of the way genes are encoded in long strands of DNA, although this system sounds like it has many more base elements to it. These elements include the kind of material used, the way the strings were spun, and the direction of the knots attached to all the other strings in the khipu. There were also, apparently, 24 different string colors.

It makes me think that it might be interesting to create a kind of khipu myself. The Inka's khipu sound fairly complex however; each khipu which has been found encoded one of 1,536 possible "distinct information units"!

Our clothes have a fingerprint

I read this fascinating article the other week on how a robber was nabbed based on a unique pattern of wrinkles found down the side of his blue jeans, as seen on the bank's surveillance tape. The puckers and creases along the side-seam of his pants were a result of how his body moved within the denim fabric, thus creating a kind of barcode, or fingerprint, which was used as indisputable evidence in a court of law.

This made me think about all the ways in which we leave our own marks on our habitats. I love thinking about how our environments, including of course, our own bodies, act as a record of our lives. The kinds of activities we engage in, the way we move, these are all silently recorded, day by day. Just looking at my office chair, it's evident that i like to sit on my heels while in it; the fabric is stressed and slightly pushed downwards from the center of the seat.

This also made me think about the notion of 'memory'. It's not an original musing perhaps, but i still find memory fascinating. Life may seem to exist right here right NOW in our field of vision, but the past feels very material nonetheless, thanks to not only records of experiences and thoughts stored in our minds, but also to physical records we may have; gifts, letters, scars, the way the soles of our shoes are worn down in the same place on every pair.

hmm.. fascinating indeed...

American Museum of Natural History

My Sensor Workshop class went by the American Museum of Natural History last week, and got to take a look at their newest permanent exhibit, the Hall of Human Origins. We also got a special behind-the-scenes peek at the workshops where they construct the dioramas on display in the museum.

I was particularly interested in seeing this exhibit, since my old academic roots lie in human evolution and primate sociobiology. Yes, I was a physical anthropology major as an undergrad before switching to design + art, and I still have a strong interest in the going-ons of this field.

Anyways, our task for the day was to think about improvements that could be made to the exhibit, as far as interaction design go. In other words, how could we make the exhibit more engaging, inviting, and clearer to understand for the visitors, all of whom come from many age groups, cultural backgrounds, and levels of education.

There was one display in particular which I thought was on the right track, but just didn't quite make it to the finish line, in terms of being easy to use and understand. It was a large back-lit illustrated map of the world, mounted against one wall, with a second display set in front of it, divided into segments corresponding to different regions of the world. Each of these segments had a description of the region it represented, complete with a touch sensitive, die-cut button that activated the faint tracing of a line on the mounted map, representing immigration into those regions. Each region's line had its own color to help it stand out from the others. This, however, was not enough to get everything across clearly.

The immediate problems with this display were the following:

- After touching a region's button (operative word is 'touching', not 'pushing'... something like a qprox touch sensor was used here), a colored line of very diffuse light would begin to slowly lurch its way from one point on the map to another. The light was in fact so diffuse, it was nearly impossible to spot for all but one region.

- The line tracing took place very slowly, with a significant delay after touching a region's button. It felt as though it was broken at times, like nothing was going to ever happen.

- The button itself was problematic. There was really no good reason to have a touch button in place of a traditional push button. There is something very satisfying and final about actually getting to push a button down, and hear it click back up. It affirms for you that an action has taken place, and will (hopefully) result in some kind of action. When I tried to push the buttons installed for this display, it felt incomplete, and very unsatisfying to have this huge cut-out shape unable to be pushed down.

So right away, it'd be great if at least the lines were much brighter and clearer, and if the buttons had a little more tactile feedback for the user. Also, obviously, the time between activating the button and actually seeing something happen on the map, should be shortened.

Wearables + Networked Objects final

I'm documenting my project for wearables + netobjs here:

Joan Dress

It's code named Joan for now, for Joan of Arc, who had divine visions from above (i.e., the 'net, naturally!)

Basically, it's a dress augmented with conductive threads and thermochromic inks. The threads cause the inks to change color via resistance heating, and in response to network activity.

it glows!

it glows!
Originally uploaded by 0x000000.

I experimented with embedding LEDs into platinum-based silicone. This particular kind of silicone is called Dragon Skin Q (the Q stands for 'quick'; i think so anyways... this kind of silicone sets faster than the regular Dragon Skin).

I'm envisioning having many iterations of this hanging around the neck, or maybe attached to the wrists, or a dress. I love the texture of silicone, and having many small chunks laying over each other and bouncing around is something that would be satisfying to look at, as well as to touch. I'm always interested in finding new ways of creating texture, and the silicone-LED combos are fulfilling this endeavor nicely right now.

Datasheet Report: 8-Bit Shift Register

img pulled off of sparkfun electronics

Today I'm looking at the datasheet of a Texas Instruments SN74HC595 8-bit shift register with 3-state output registers.

Download Datasheet

Features
* 8-Bit Serial-In, Parallel-Out Shift
* Voltage operating range of 2V - 6V
* Low power consumption (80µA)
* Low input current of 1 µA max.
* High-Current 3-State outputs which can drive up to 15 LSTTL loads
(btw, LSTTL stands for "Low-power Schottky" Transistor to Transistor Logic, TTL being a kind of solid state logic)
* Shift register has direct clear

The below diagram shows the pin mappings for this chip, depending on which package you are using:



What does it do?
So, what does an 8-bit shift register do? It's commonly used to increase the output capacity of a microcontroller. Data is shifted down along 8 pins (or more, depending on what kind of shift register you get), and passed out through each pin, expanding the number of possible output pins available to your microcontroller. This is also called 'multiplexing' a signal.

How to Connect
At a minimum, three pins of your microcontroller are required to connect to the 8-bit shift register: one for the clear pin (SRCLR), one for the clock pin (which controls the frequency at which signals are transmitted) (RCLK and SRCLK: these can be connected together or independently), and one for the data you are looking to send through the register, i.e., the input pin (OE).

The clear pin, when set to low, clears all the pins on the shift register of their current state (high/low), and when set to high, allows the pins to receive input from your microcontroller. Because this shift register has a D-type storage register built into it, this means that once you set the pins high or low, they retain that state. Therefore, the clear pin is necessary in order to literally 'clear' the current states of the shift register pins.

In order to get the input signals into the shift register, you must PWM (pulse width modulate) a clock signal for 8 cycles, or however many bits your shift register is designed to carry. Most shift registers use 'synchronus' communication, meaning that the rate at which signals are sent to the IC, rely on the clock signal of the microcontroller, which is transmitted via the RCLK and SRCLK pins.



The shift and storage registers each have their own clocks. When connected together, the shift register is always one clock pulse ahead of the storage register. I'm guessing this is so to keep the data moving ahead in order to make room for the next signal coming down the pipe.

Sensors and Time

sensorGraph
Originally uploaded by 0x000000.

I built a little visualisation tool, using processing, for graphing sensor activity. In this case, I was specifically looking at a photocell. The nature of the data being sensed, in this case, light, informed the way I chose to display the data.

There are three parameters being graphed here: raw data, averaged readings, and the standard deviation between readings.

The circuit is really simple. It's just a photocell hooked up to an arduino board analog in pin. My arduino board communicates serially to my processing app, which then displays the data accordingly.

Download my code here: arduino | processing

Playing With Food

My final project for physical computing turned a fork and knife into musical instruments. Sine waves are generated and through max/msp, when you cut into different kinds of food on your table. Full documentation can be found here.

For my final project, i visualized and sonified the new york city subway system, using the cat bus (nekobasu) from My Neighbor Totoro as my inspiration!

To check out the full documentation and downloadable application, click here.

For my final, i want to combine musical performance with visuals, both produced algorithmically. I will generate a score for 2 guitars, based on an as-yet undecided algorithm. The guitars will run through a digital effects processor (not necessarily integral to the project at hand, other than for aesthetic purposes), to a pitch to midi converter, and then into max, where the midi data will be sent out again to processing. Once in processing, a real-time graphic display will be updated.

i am investigating the max object fiddle~ and the processing library maxLink for this. I will be sending midiout from max to my processing sketch via maxLink.

I am still nailing down the details on how i would like to proceed. It is my first time using max, performing publically playing guitar, and doing live image processing, so there should be much to learn and post about along the way!

Living Utensils

For my final intro to physical computing project, I'm making a set of utensils that respond to the user. I have a quick summary about it here:

Project Statement

and a quicktime here.

More updates to come soon.

lab: week 9, midi out

midilab
Originally uploaded by 0x000000.

This lab involves building a circuit that makes it possible to send midi out a midi jack. The push button toggles the note on or off, and the flex sensor selects the note you are sending. The midi cable is connected to a box that connects to my laptop. I'm playing whatever notes i generate through garageband.

This was a pretty straight-forward lab, although i did encounter one issue. All of the notes that were coming out of garageband were super soft. I had all of my volume levels up, yet I could barely hear the notes coming out. This was probably due to my velocity though.

final cat feeder documentation posted

Well, we finished it finally. It ain't the prettiest thing in the world, but hey! It's just a prototype afterall. The functionality works perfectly!

Documentation is posted at http://www.chootka.com/itp/pcomp/intro/catFeeder/.

lab: week 7, dc motor control

fullview
Originally uploaded by 0x000000.

breadboard/arduino setup, wired to a dc motor and push button. This is just a simple lab that demonstrates how to wire up a dc motor, and control it's direction by reversing the current going through it. The current is controlled by the red push button: When it is down, it spins clockwise, when it is up, counter clockwise.

closeup
Originally uploaded by 0x000000.

Close-up of the breadboard/arduino.

jungle
Originally uploaded by 0x000000.

wire jungle!!!

Cat Feeder update!

First, a summary:

Our feeder is set to consist of a mat, which has a force sensor in it, in order to determine which cat is on the mat by weight. We plan on setting up some sort of calibration mode, so that the owner can assign a bowl to each cat in his/her home. Our feeder will also have a timer built into it, so the user can put a serving of wet food in the bowl before leaving for the day, and have the food made available to the cat at the time of day set on the timer. Finally, there will also be an 'open lid' button, an LED indicating power, an LED indicating when the bowl is empty, and an LED indicating when the system is active.

We discussed various ways to deal with the moving lid. We talked about having a lid that rotated 180 degrees to reveal the food underneath, pushing the bowl out from a slot, and simply raising and lower the lid from an armature, all done with a servo. We went with the last option.

Now, the update:

For our timer, we were going to use a variable resistor, that let you set time based on where a slider was positioned along a strip marked with hour intervals. We realised, however, that this was going to be problematic, in the event that the feeder lost power. The clock would be reset, and the timer would no longer be meaningful. i.e. if the clock was set to 5pm, and the user sets the timer to feed the cat at 8pm, but the power goes out, by the time it comes back on, the clock will be reset to some arbitrary time.. therefore rendering our original 8pm feeding time to mean some other hour.

So, to get around this, we decided to go with a digital alarm clock picked up from kmart. The advantage to this is ease of setting the clock and the alarm via a pre-made interface. Plus providing a digital display. The interface is much better than one that we would be able to build in the time we have. Once the alarm goes off, we set the arduino to leave the system activated for one hour following. After the hour elapses, the system deactivates, and the cat can no longer eat.

To determine when the bowl is empty, we are using a limit switch, which clicks on when there is no food left in the bowl. Basically, our bowl sits in a ring, which has an arm that extends into the system, and has a counterweight at the end of it. When the bowl is empty, the counterweight pulls the bowl up, disengaging our switch. When it is full, the bowl outweighs the counterweight, and pulls down in the other direction, tripping the switch. We still need to find a suitable counterweight, so that it balances out with the typical amount of cat food we will be putting into the bowl.

Our next step is to build the mat with the fsrs in place, and to build a housing to contain the guts of our system, and to hold our interface in place. And to find a good counterweight for checking the bowl's food level. stay tuned.

lab: week 5, Serial communication: Serial Poetry

I made a little prototype, involving a photocell sensor and a 255-word crappy poem. The idea is, as you restrict and allow different levels of light into the photocell, a new word of the poem will be printed on screen. The theme being light and darkness. Clever huh!

I got it working finally, though the problem wasn't as big as i thought. It was just a stale lockfile that was preventing my serial port from working correctly. Anyways, it works as expected, except that these photocells don't seem very sensitive. So it's been almost impossible to get to the upper and lower regions of the poem.

Here's a little screen cap:

first_prototype

first_prototype
Originally uploaded by 0x000000.

First prototype of an automatic cat feeder my group is building. This is an automatic *wet cat food* feeder, no less. We hacked about an alarm clock to use as a timer, so you can set for when the feeder lid will be open, in case you aren't home in time to feed your cats yourself.

midterm: Datafall (nee Network Clouds)

Data visualization is something i've been interested in for a little while now. I first became aware of the technique of making normally invisible data visible, in my step-dad's lab. He would run ELISA tests (Enzyme-Linked Immunosorbent Assay) and gel stains on lab results from his experiments. What he was checking for in particular, i'm not 100% sure on, but it doesn't really matter either. I just remember being really impressed with the action of transmuting one kind of information into another (visual) kind.

Thus, here I am, on the computer, and on a network, for 90% of my day, and naturally I find myself interested in what kinds of activity takes place over, ahem, "Information Super-Highways" (yes, i said it). Aside from natural curiousity, this was also inspired, in part, by a piece of software that my friend John made. It is an application which translates network activity into sound. It is written in java and can be downloaded here.

I originally had called my project Network Clouds, because i envisioned making just that.. rain clouds, if you will, each of which represent a port that has activity happening on it. The properties of the raining particles would relate to certain characteristics of the information moving through the port (number of bytes transmitted, frequency of transmission, length of transmission, http response code, ip address the request was coming from, etc).

For the purpose of this particular demo, I went and grabbed some ftp info from The Internet Traffic Archive. This is a pretty neat place on the intarweb where one can find, uh, archived sets of network data.

The waterfall I made relates to the data in the following way:
- The width of each particle stream is determined by the length of transmission time per packet.
- The grey-scale shade is determined by the frequency of packet transmission. (Were there requests every 2 seconds, every 1 second, 6 seconds, etc)

That's it for now, actually, but I am planning on tweaking it more. I'm new to particle systems, so I still have a tendency to break things when fiddling with them. Ideally, it would work like this:

- Width of particle stream is determined by the number of bytes sent per transmission
- Color or shade is determined by the total number of requests made for the packet
- Acceleration of particles is set by the frequency of packet transmission
- Lifespan of particles are determined by the length of transmission time

Current visualization of this project can be seen here.