My ITP Camp Project

First of all I must say, that I had an overwhelmingly amazing time at ITP Camp!

In my attending for one week, and after experiencing the environment for the first day or two, I was inspired to attempt to construct something using Arduino, Processing, and a PIR motion sensor. Win, lose, or draw, I knew that I would have a valuable experience in simply attempting to put something tangible together. My goal wasn’t necessarily to have a functional installation to show in the ITP Camp Art Show, but the prospect of showing something was definitely motivation for me to push myself to complete a piece.

I began by hacking an audio/visual library for Processing:
http://explodingart.com/soundcipher/tutes/unlimited_art/unlimited_art_tute.html

Then, after attending his “Projector Jam!!” session, I took my hacked Processing application to camp counselor Matt Tennie, who provided me with invaluable encouragement, and challenged me to add an interactive element. Matt saw potential in my piece, but pushed me to develop it further, and introduced me to Arduino functionality and libraries that would enable some level of interactivity. Matt suggested motion detection, which meant I had to find a motion sensor…. somewhere.

Enter camp counselor Jen Shannon who gave me the basics on “The Shack”. She described for me the nuances of finding and selecting the correct sensor for my project, and also gave me much needed reassurance and encouragement.

After an impromptu self guided walking tour of the area surrounding NYU,

I stumbled upon a PIR sensor for sale  in Chelsea… (after visiting FOUR of “The Shacks”)

Sensor secured!

With sensor in hand, and after a few more conversations and advice from Matt and Jen, I added a bit of code from this library to my Processing application to enable serial communication from my Arduino. The code example also added an additional reactive visual element.
http://www.learningprocessing.com/examples/chapter-19/example-19-8/

Next I uploaded code to my Arduino from a PIR motion sensor tutorial that I found on Instructables.com , and followed the wiring diagram.

Part of Matt’s original advice was to project the Processing application using several different projectors, with the aim of creating an immersive audio/visual generative environment. I went with that idea first, and attempted to hook up multiple projectors to my Netbook. Try as I may and mightily, I could not get the piece to project the way I wanted. After asking Kate Hartman if I could use a full room to house my piece, and with her kind approval, an equally effective alternative presented itself. With the piece set up in its own room, and utilizing the rooms existing audio/visual infrastructure, my piece became an installation.

The result for the ITP Camp art show was this:

Essentially, the PIR sensor connected to the Arduino detects motion in the room, which then triggers the audio/visual response generated by the Processing application.

 

———————————————-

 

All said, I had a great time at camp!

Thanks again to Matt Tennie, Jen Shannon and all the ITP Camp Counselors, Kate Hartman, fellow campers, ITP Faculty and Staff! It was a great environment for which to experiment and grow creatively… I feel I have taken away so much from this experience. Until next year… CHEERS!

 

——–

 

http://twitter.com/510_teh_beast
http://flightorchestra.com/

 

 

 

UNITY Reschedule

Campers,

I’m holding a rescheduled Unity session for tomorrow (Friday @ 1:00 pm).
If you could please show up to class with a borrowed projector and a kinect, we will be going through how to integrate projection mapping with gestural tracking.
Hope to see you there!
Matthew

Xbee, trial and error ref. Documentation of, inc. useful+ not-so

OK, Udated so access is now possible – helpful huh!

http://xbeeresource.tumblr.com/

Speed of Light-modulating light with EL wires and FSR sensors by Johanna + Bert

We successfully built our first arduino proto shield!  We are articulating walking and running speed through sensors built into footwear:  as you run faster, light from the el wires pulses faster.  Here is what we used so far:

-EL wire 1.2mm

http://www.coolight.com/product-p/01c-bg.htm

-arduino board

-arduino proto shield

-fsr sensor

-TRIAC

-inverter

-resistors

Video link: Speed of Light

 

Great class by Matt Tennie in how to use Isadora. It’s like Max, but super fast to use. Click to enlarge and see explanations:

Makerbot class

What happens to a world where a makerbot can make makerbots? Is it inevitable that this world will someday be nothing but makerbots? Until that day where the robots rule, we can make our own objects!

Tutorials at http://curriculum.makerbot.com/index.html

A simple explanation:

step 1: Go to tinkercad.com (or use 3D program to design object)
step 2: If using tinkercad export a 3D object as .stl

step 3: Open the .stl file of your 3D object in a free program called ReplicatorG.

There are options here in Replicator G (like setting the temperature based on size and type of plastic, or you can “make a raft” to ensure it won’t roll), but mainly you just click “move” and Put On Platform”. Then you can scale it up or down.

Step 4: click “generate GCode”

Step 5: Put Gcode on SD card and feed the data to the replicator.

I am told you can make a life sized head (scan yourself with Kinect or if you have an iPad, you can use http://www.123dapp.com/catch and take photos all around the object. Ideally the object is not on white, but rather a complex background like news print. This allows the computer to extract 3D data. The material is relatively cheap, a chess piece like the owl (I will upload later) is under 50 cents, a life sized head would be about $20 of material – depending on how big your head is!

Cool links

http://www.makerbot.com/blog/2012/06/12/remixing-the-met-we-met-heads-on/

http://www.thingiverse.com/

http://www.123dapp.com/catch

http://store.makerbot.com/makerbotr-water-soluble-pva-1kg-spool-1-75mm.html (To buy materials)

http://curriculum.makerbot.com/index.html

http://www.openscad.org/ (if you are into math generated 3D)

http://www.netfabb.com/download.php

http://replicat.org/download (to get ReplicatorG)

https://tinkercad.com

LED Sequencer by Ezra, Tiffany and Nicole

WE DID IT.

w/

+ 1 Arduino

+ 1 TLC5940

+ 16 LEDS

+ a good tutorial http://code.google.com/p/tlc5940arduino/

and some enthuasism.

HAPPY CAMPERS

 

 

WATCH THE VIDEO HERE!    ledMOVESn

 

 

 

Controlling the Color Kinetics LEDs over ethernet

Live blogging as I figure out how to control the Color Kinetics controllers over ethernet. There was some concern that we’d be unable to do so without knowing the IP address of the power/data supplies.

Turns out, there’s a pretty easy solution, QuickPlay Pro, available here: http://www.colorkinetics.com/support/addressing/

When installed and run, QuickPlay Pro immediately identifies the data supplies it finds on the network. It also has the ability to change the supplies’ addresses.

I’m starting by testing out the PDS-60ca (the smaller power/data supply) with the iColor Tile 2:2.

To test, I put QPP on one of the shop computers. I also checked out an ethernet switch (and cables), and connected both the laptop and the PDS-60 to the switch.

Since the laptop is already connected to the wifi network, it now has two IP addresses. You can specify which network interface for QPP to use from the Preferences window in QPP (it needs to be the interface connected to the switch). I ran ifconfig in the terminal to see my network connections. The wired network connection corresponds to en0. inet specifies the IP address.

After choosing the network interface, I refreshed QPP, and the PDS-60 appeared in the list of controllers.

At this point, you can play with the pre0programmed behaviors. You can select a port (or choose ‘all’), and specify channels. I’m seeing different numbers than in the Addressing Configuration Guide (available on the same page as QPP). According to my tests, each port has 216 available channels, representing a 36×6 grid. For each port, channels 1-36 are the innermost row (at the middle of the fixture), and move outward as the row increases. It may be possible to reconfigure this mapping in QPP, not sure yet.


Straightforward for the other lights, too. The other controller is a PDS-150e. The channels are different. I found out what type of light I’m using by going to the Fixture Configuration pane. Apparently, this one is a ColorBlast 12. The light’s DMX Address appears to correspond with a channel on the controller. The light appears to be addressed in sets of 3, so I’m using channels 1-3 (after setting the light’s DMX address to 1).

We also have a ColorBlast 6. Works the same. 3 channels, currently set to channels 4-6.


Just fixed the other ColorBlast 12 (the W wire had come out of the plug). It was set to DMX Address 1, so as soon as I plugged it in, it started lighting the same pattern as the other CB12 – clearly multiple lights can be addressed on the same channel.

The PDS-150e has 6 sockets, 2 for each of Group A, B, and C. So far, the groups seem insignificant – I’m addressing lights in different groups just based on their channels. There might be more to it, though.


I’m working off of this code sample to write packets to the PDS-150e: https://github.com/dlitz/color-kinetics-control-example/blob/master/make-it-so.py

That code contains the magic header to include in the packet. The data beginning at the 25th byte is the channel values, I think. This is also a reference link: http://www.directionless.org/color-kinetics/Cktalk.pde


I’m now able to control the iColor Tile over a UDP socket. I have a Ruby module that sends UDP packets and has some generic light behaviors and utility functions. I haven’t figured out how to write an individual pixel without overwriting all of the others yet – probably requires a tweak to the header.

I’ll be putting the code up online somewhere in the near future. Here’s the GitHub repository: https://github.com/aac/Color-Kinetics


Some useful links:

Dumbrella parts order and reading lessons

Today I bought some stuff from sparkfun , hopefully all small enough to fit inside an umbrella handle.

 

Since the arduino’s internal watchdog timer only lasts 8s, an external timer is necessary if I want the whole solution to sleep for 30 minutes at a time. After reading up a bit more about the WiFly module, I realized the RTC is totally unnecessary, as the WiFly can be configured to have a pin go high when it is associated and has a valid ip address. Thankfully sparkfun has an awesome return policy, and just in case I cannot get the WiFly configured right, the RTC will act as a backup.

In fact the WiFly module has a TON of features, including automatically opening tcp connections on wakeup, and has 4 available GPIOs.

So far, the nominal cost of parts I plan on using from this order is $62. It can be brought down another $15 just by eschewing the mini pro and burning onto an attiny, which should be plenty powerful. Appropriate for a cost reduction but not for this prototype.

Dumbrella

So after chatting with a few wonderful campers I decided to tackle an umbrella that lets you know when you should bring it along.

Design considerations in order of importance is speed of development, ease of use, durability, size of solution, power consumption,  price and name.

Ideally, the dumbrella v0 will

  • be done by camp’s end
  • be standalone
  • accurately indicate if it is going to rain in your zip code that day
  • survive in the rain
  • fit inside an umbrella handle
  • have batteries that last a while unattended
  • have easily replaceable batteries
  • cost me less than $100
  • have a better name, possible related to PR Nelson

The current thought is a hollow wooden handle, with a wi-fi enabled microcontroller that polls every 30 minutes some website to check if its going to rain in the next 24 hours based on its geoip location. If the forecast says rain, it lights up all sorts of crazy.