Our goal:

To create movable lanterns that provide feedback on the the audio levels in a room by using the height and color as output.  We wanted to ask how we could create an ambient device that would give subtle feedback on the level of motion or chaos in a room, to counteract the input. We decided to continue the form of our group project, the door monitoring sensor network but we wanted each lantern to be independent allow the lanterns to be modularly spread out.

Phase 1:

Initially we used API mode to control just an RGB LED and we were successful.

Phase 2:

Next we solidified that we wanted to use audio input as a control source, so we switched to AT mode with Arduino’s running Firmata.  Firmata allowed us to use OSC and Max/Msp which is great for developing this further.  This required switching the baud rates of all Arduinos which sadly proved more troublesome than expected.  This eventually was a failed endeavor because we could not identify each individual Xbee using this method.

Phase 3:

Next, we switched to custom code on the arduino, and thus had to switch the baud rates again.

Phase 4:

Our servos’ rotation was not great enough so we modified one of them to see how much control we would have over them.  We were quite successful with the one we modified so we continued to modify the rest but this yielded mixed results.  Some servos would sweep, some would not, and some were just inconsistent.  In the end, we had no way to salvage our project and we had to accept it as a failure.

Why did this not work?

Because we changed the scope of our project several times, our results and goals changed as well.  We learned that with each change we would have to go back into XTCU and re configure the Xbees, which ended up being a more time consuming endeavor than expected.  Because of this, we were unable to proceed to stabilizing our circuit design or software input.

What would we do differently next time?

Create a more detailed objective sheet with our finalized project scope. Also, we were trying to keep the project as affordable as possible so we had many different kinds of servos.  I think consistency in our parts would make debugging much easier.

To view the presentation in pdf form, visit : http://dl.dropbox.com/u/133348/reactive%20lanterns.pdf

I was assigned to be a silent observer in an environment for an hour for my Sociable Objects class with Rob Faludi.  Since this class inherently deals with networks, when I began the assignment my mind immediately was drawn towards recognizing networks in my surroundings.  I began to pay attention to dynamic audible systems.  An example might be wind pressure increasing, causing a leaf to fall into and crickets to stop chirping.  The environment I chose to monitor was isolated in the woods in upstate new york.  Because of the stillness around, the systems could interact over further distances.

I decided to repeat this assignment again when I returned home, but this time on my rooftop in brooklyn.  The chaos and constant signal over the networks prevented me from being able to observe direct relationships.  I then began to question weather there is a threshold for inductive and deductive reasoning when a system becomes too complex.  Or in another way to put it would be: If you increase the amount of nodes on a dynamic network, at what point can you no longer directly observe the connection between action and reaction.  Also, how would this be tested?

Michael Edgcumbe and I collaborated to create a hypothetical sensor based network we call Current-See.  Current-See allows us to observe how currency moves through our economy.  The goal of the network is to observe the connections and history a single bill makes as it is tracked through its entire life cycle.  This data can then be aggregated to give us a better view as to how currency moves through our economy.  Of course there are drastic privacy laws that prevent this method of data polling, this is why Current-See is a “hypothetical network”.