In our final week we decided to use the plastic curved half. The styrofoam encases the breadboard and arduino. 

For the rest of the week we have had some people play with the I-Ve and give us some feedback about their experience.  Based on their experience, we have tweaked the visual design of I-Ve.  We have altered the instructions and added small features.  Below is the demo of I-Ve in action.

The user uses the remote to navigate through the menus.  The top button allows the user to select an option. The bottom button allows the user to go back or cancel their option.  The remote is labeled with the the functions of the remote.

Depending on what menu or screen the user is on, the right sice of bottom portion of the screen displays feedback to let the user know how to rotate the remote.  If they want to select an option they simply press on the top select button.  The LED lights up when the button had been pressed.

During this last week, we also received very shaky values from the accelerometer and it was sometimes jumpy when trying to navigate through the menus.  Professor Shiffman suggested that we use the LERP function to average out the values.  After doing this, our accelerometer seemed to work smoothly.

Processing code

Arduino Code – Serial Communication

Also check out David\’s Blog

In our presentation displayed above, we wanted to make this more of a product pitch than a physical computing project.  Below is our breakdown of I-Ve’s birth and what we hope to accomplish with it. 

We have started working on some code.  The processing book had a lot of tips and code for working with video in processing.

We also re-did the serial communication lab.  The first time we did the lab we did it with two potentiometers.  It was helpful to go over this lab again with an accelerometer.  Below is a picture of the the Arduino and breadboard.  We also recorded our values in the video documentation below.  The values of each axis will eventually be used as thresholds for each action (fast forwarding, rewinding, pausing etc..)

Below is a screenshot of the processing applet from the code we’ve written so far.

The red portion of the window is supposed to be where the final product will end up.  The three surrounding windows are supposed to be raw footage.

Here is the code of what we have been working on so far.

Our next steps are to continue working on the code, and analyze the values of the accelerometer.

David and I decided on creating a video editing program without the user having to use any of complicated editing systems. Ultimately the user would be able to load their video onto their computer and use the controller to scrub through and select which pieces of footage they choose to edit together.
We would be using serial communication with processing. Processing would handle the video viewing aspect. We plan on using an accelerometer in order to read when the user turns the controller left, right, or forward. A push button will also be required for the user to make selections

below is a rough sketch of what the interface would possibly look like…

We wanted the user to be able to easily figure out how to easily to use the controller. Leaning the controller to the left allows the user to rewind. Leaning it to the right would scrub forward through the video. Holding the controller in the middle would allow the user to pause the video. Pointing down would allow the user to make a cut.  

Selecting in and out points for making cuts would be caused by the user pointing the controller down. In and out points in footage would be clearly selected by a designated marker on the screen.

Our intention is that even the person who is not great at keeping up with technological advances and gadgets will be able to use this. We are trying to incorporate natural bodily movements with working the control. People usually wave their hand left in order to signal someone to go back or keep they their hand stationary in order to signal some kind of pause.  Using an accelerometer would allow the movements described.  

Selection is also important in this interface, therefore we are also using pushbuttons.  The sketch has two but the number of buttons is yet to be decided. 

The Video section would look similar to the sketch below…

As of now we would be working on one source of raw video footage.  After the user selects the in and out points from the raw footage section, the selected footage would end-up in the final video section where they can also scrub backward and forward to review footage.  

Of course this version will not have dozens of functions if the user wanted to make fancy transitions or effects. However it will allow for easy, very basic video editing and maybe one type of transition.

Schedule
Week of 11/24

find video footage.
Start writing code
Get a reading of values for X, Y and Z axis from the accelerometer based on movement (re-doing the serial communication lab with an accelerometer)
build controller
Test
Document

Week of 12/1
Debug
Test
Document.

This week we have been going back and forth about how to interface our piano hero.  We decided to focus on Piano hero as being purely entertainment as opposed to educational.  

We brainstormed some ideas for music games.

-Different track lengths moving downward determining how long each key is held down for.  Successfully doing this would in turn would play a track.  

We also looked at demos of these games for inspiration.  

-DDR, 

-Karaoke Revolution

-Samba De Amigo

The screen based game design in processing would be completely dependent on the physical interface developed.  We also discussed having this project be collaborative (multiplayer), or networked.  

We also asked ourselves what if the feedback from pressing the keys manipulated a physical object such as a puppet (through the use of servos).  

We are still brainstorming alot of ideas and also looking at what type of sensors can be used to make this game more physically involved.  We are interested in using an accelerometer to measure some type of movement.  We also thought about doing our own orchestra where the user would be their own director.  Depending on how the wand or baton is waved, the accelerometer would be programmed to trigger a specific instrument(s) to play.  

Piano Hero Demo!

For my final project I’m doing an extension of my very basic midterm project Make Your Own Sountrack

I’m a big fan of Guitar Hero, therefore I decided I wanted to do something that was similar.  I also wanted to create a simple interface that would somewhat mimic real piano keys.  I am still keeping my midterm idea of allocating keys to certain notes.  The midterm will be much more visual and interactive.  And I am also using Arduino to create my interface. 

The idea of the project (which hasn’t been fully worked out yet) is to have actually notes (whole notes, half note) falling.

Processing sketch(In progress)

 Each key would represent a note. The user would have to press the corresponding keys to match the notes that are about to touch the top of the key.  After having pressed the key the note will either disappear or turn another color (for testing purposes it turns another color). My intention is that if a user does not press a the correct key at the right time the song will either stop or the user will hear some type of sound effect.

David is joining me on this project. We researched piano hero and found out that there is an actual piano hero already out there. We brainstormed many ideas and we thought it would be cool to also do something visual.  Having a stick figure move on screen according to the piano chords or maybe having an actual wooden model move (this can be done in physical computing).  Having the user create some sort of avatar of themselves. We also brainstormed the idea of people being able to collaborate and play over a network.

 David has more video on his blog.

For this week’s lab i decided to do the H-brigde lab. The purpose of this lab is to control the direction of the DC motor.

The first step was connecting the breadboard to power and ground as usual and then adding a pushbutton switch and connecting it to digital input 2 on the Arduino.

This lab uses the SN754410 H-bridge.

This particular chip has 4 half-H bridges, and can therefore control 2 motors. It can drive up to 1 amp of current, and between 4.5 and 36V. This H-bridge has two bridges, one on the left and right side of the chip.
According to the lab, every H-bridge has the same basic features; pins for Logic input, motor supply voltage, logic voltage, motor supply output and pins for ground.  The lab was a little confusing for me.  I followed the schematic portion of the lab, but I became a little confused as to whether it was supposed to resemble the picture included.  I also did not know that the notched part of the Hbridge was supposed to point up on the breadboard.  

The first part of the lab was pretty straightforward with connecting the pushbutton switch. 

The second part of the lab failed me the first time I wired everything up and ran the code.

Looking at the code as compared to what the schematic displayed confused me a little.  

int switchPin = 2;    // switch input
int motor1Pin = 3;    // H-bridge leg 1
int motor2Pin = 4;    // H-bridge leg 2
int speedPin = 9;     // H-bridge enable pin
int ledPin = 13;      //LED 

The bolded part of the code confused me as compared to the picture of where everything was

supposed to go.  Below is the rest of the code.  Eventually the motor worked and I realized I had

the pin plugged into 3 volts and not 5.

void setup() {
  // set the switch as an input:
  pinMode(switchPin, INPUT);

  // set all the other pins you're using as outputs:
  pinMode(motor1Pin, OUTPUT);
  pinMode(motor2Pin, OUTPUT);
  pinMode(speedPin, OUTPUT);
  pinMode(ledPin, OUTPUT);

  // set speedPin high so that motor can turn on:
  digitalWrite(speedPin, HIGH);

  // blink the LED 3 times. This should happen only once.
  // if you see the LED blink three times, it means that the module
  // reset itself,. probably because the motor caused a brownout
  // or a short.
  blink(ledPin, 3, 100);
}

void loop() {
  // if the switch is high, motor will turn on one direction:
  if (digitalRead(switchPin) == HIGH) {
    digitalWrite(motor1Pin, LOW);   // set leg 1 of the H-bridge low
    digitalWrite(motor2Pin, HIGH);  // set leg 2 of the H-bridge high
  }
  // if the switch is low, motor will turn in the other direction:
  else {
    digitalWrite(motor1Pin, HIGH);  // set leg 1 of the H-bridge high
    digitalWrite(motor2Pin, LOW);   // set leg 2 of the H-bridge low
  }
}

/*
  blinks an LED
 */
void blink(int whatPin, int howManyTimes, int milliSecs) {
  int i = 0;
  for ( i = 0; i < howManyTimes; i++) {
    digitalWrite(whatPin, HIGH);
    delay(milliSecs/2);
    digitalWrite(whatPin, LOW);
    delay(milliSecs/2);
  }
}

Fiona D.
Aaron Uhrmacher  Aaron\’s Blog
David Golan David\’s blog

We are in our last week of the Interactive Elevator. A lot of ups and downs….a lot of both failed and successful attempts. However, the elevator was a huge success and we all worked together quite well to bring some type of interaction to this otherwise boring space called an elevator. 

Although we were very successful, we often encountered problems were unsure as to whether it was the code or the components we were using.  We came to the conclusion that our structure was not very stable and could be a contributing factor to some of those failed trials.  We used little methods to get around some of our problems.  We placed scotch tape over the photocells for the purpose of spreading the laser beam, which worked out quite well actually.  The casing for our lasers held the lasers in place.  Sometimes we had a finagle with the laser position to make it point directly unto the laser

 Nevertheless, we were victorious in seeing our work in action and working the way it was supposed to. 

This week we were faced with the daunting task of combining both the Waveshield/Audio with the break-beam code.  We decided to use a force sensor to trigger the audio cues.  We planned for the code to work in such a way that the beam would count the number of people entering the elevator; based on this, the door would close triggering the sensor and calling the audio cue allocated to the number of people in the elevator.  Here are some more audio cues that were recorded (several Audio cues are included in week 2’s post.)

Audio clip1

Audio Clip2

Audio Clip3

Audio Clip4

People that listened to these audio cues, thought they were pretty funny.

We were all very excited to use the Waveshield. The instructions on the Lady Ada instructed us to change our audio files into  uncompressed 22KHz, 16bit, mono Wave (.wav) files.  I looked up the audio shield library and found some sample code.  After having much done much research on the Arduino waveshield we had intentions of this piece performing as it did in the video below.

http://ladyada.net/make/waveshield/faq.html

HOWEVER, when we attempted to use the waveshield we received an error or a failed attempt error.  I double checked to see if all of the right pieces were in tact (everything seemed to be in tact).  This was very frustrating as we invested money and were excited to use this part.  The Waveshield is fairly new on the market and not much people around ITP knew much about how it works.  

Therefore, we decided that our time would be better spent not worrying about how to get this piece to work.  We instead decided to use the Minim library.
 

http://code.compartmental.net/tools/minim/

We went through all of the motions of downloading the minim library and evaluating our code. We tested the code on its own to see if it was able to play the audio cues first and then implemented our serial communication knowledge to merge both Arduino and processing.

We also messed around some more with the construction.  We still settled upon using foam but tried to brainstorm ideas to make the structure much more stable and level.  

We taped off an area by a door in order to simulate an elevator space.  We also placed the FSR (force sensing resistor) on the door frame with the intent that the closing the door would trigger the sensor.  

Below are our photocells.  The laser beams on the other side of the door would directly be hitting these photocells.  

Our week consisted of testing and retesting.  As far as our structure goes, we initially had the senros at leg level but then realized that each sensor might be tripped twice with each leg.  Therefore we moved the sensors chest level to ensure that we would receive a more accurate reading.  Sometimes it worked perfectly and sometimes it didn’t.  We often had to change the threshold of the FSR so that it registered some type of values that it was pressed.  In talking to some people at ITP, we were advised that FSR’s are not the most reliable sensors to use for this type of testing and retesting as they are very delicate.

 We set up a video camera and recorded all of our trials, in hopes that it would work a few times for documentation purposes.  Below is the demo video of the few times when our project was a success and also a demo of what we hope this project will accomplish. 

We also decided that our elevator needed a name.  A name to go along with that pre-recorded voice that all three of us grew so fondly of hearing =].  We decided to name him “VANCE”, which is an acronym for Voice Automated Number Counting Elevator.  For presentation purposes, VANCE proved to be very friendly.  

We also took into consideration people that were using crutches, wheelchairs, hearing impairments or anything that might cause this experience to be one in which it was not intended.  However, we do see this as a project that we can work on long term..maybe as a final project and hope to take any other factors into consideration.  

Here is the Processing code for the Audio (Processing)

import ddf.minim.*;

import processing.serial.*;

Minim minim;

AudioPlayer song;

Serial myPort;

void setup() {

  minim = new Minim(this);

  //println(Serial.list());

  myPort = new Serial(this, Serial.list()[0], 9600);

}

void draw() {

}

void serialEvent(Serial myPort) {

  int inByte = myPort.read();  //inByte = counter!

  println(inByte);

  playMyAudio(inByte);

} 

void playMyAudio(int numPeople) {  //numPeople can only be 1-4

  int randAudio;

  if (numPeople == 2) randAudio = int(random(1, 5));  //1-4

  else randAudio = int(random(1, 6));  //1-5

  song = minim.loadFile(numPeople + “” + randAudio + “.wav”);

  song.play();

} 

void stop() {

  song.close();

  minim.stop();

  super.stop();

}

During week two of our interactive elevator midterm we bought some supplies that would get us on our way to building the main components for our elevator.

1. photocells (radio shack…or can be found at the bookstore)

2. Laser pointer (Canal street)

We initially were going to build an entire elevator but later decided that we weren’t going to in an effort to save money and spend it on other important parts of the “elevator.”  Therefore, we decided to build a small wooden model that would hold both the photocells on one side and the lasers on the other. The first picture is a rough simulation of how the pieces would go.  The second picture is one side of the model holding the lasers and the third picture is holding the photocells.

While the wooden pieces were drying (we used wood glue) we worked on some code for getting the laser beam or “break beam” to count the number of people entering and exiting the elevator.  As the picture shows,

The first round of testing the “break beam” code we used 4 LED’s in order the simulate the passengers.  We also placed photocells on the breadboard in order to simulate the breakbeam.  Whenever we directed the laser onto the photocell and broke the beam, one of the LED’s would light up.  With each break of the beam, more LED’s would light up (signifying more people on the elevator. )

The Waveshield also arrived on time ($22.00)  As explained in week 1’s blog, the purpose of the Waveshield is to play audio without having to connect directly to the computer.  By hooking up the Arduino to the Waveshield, it can be powered externally, eliminating the need for computer attachment.  The Waveshield contains an SD card input for storing and playing audio files.  The Waveshield also came with its own kit which contains many pieces that need to be soldered together. The Lady Ada Waveshield site is referenced in week 1’s blog post.

Aaron had a friend come in and record the audio tracks for playback in the elevator.

Here are a few of the clips recorded

Elevator Audio Clip 1

Elevator Audio Clip 2

Elevator Audio Clip 3

We went through several materials trying to find something that would accurately hold the photocells and lasers.  We then decided to use foam.  For testing purposes we used a doorway to simulate the elevator space.

We aligned the beams with the photocells. The beam on the left side counts the number of people entering and the beam on the right counts the number of people exiting.  One of the most consistent challenges that we had was to keep the beam directly on the photocells. Also, we encountered the problem of batteries dying or becoming weak during our trial testing.  We couldn’t test our construction in an actual elevator . Initially we were going to use IR sensors, but realized after talking to several people that photocells would be a better choice.

This is the code from our first round of testing the break-beam with the LED’s (picture above)

Serial lab #2

The purpose of this lab is to demonstrate how to send data from multiple sensors to a program on the computer (processing).  The example in this lab used an accelerometer.  However, if we did not have an accelerometer, we could also use two analog sensors and a push button switch. The pot’s controlled the X and Y axis position and the switch controlled the color of the ellipse.

The first step is to wire the breadboard to the Arduino. Instead of using the accelerometer, i wired up the two potentiometers as usual and then the pushbotton. The pushbutton went to digital pin 2.  The potentiometers went to analog pins 0 and 1.  

The code for the arduino is as follows

int analogOne = 0;       // analog input
int analogTwo = 1;       // analog input
int digitalOne = 2;      // digital input

int sensorValue = 0;     // reading from the sensor

void setup() {
  // configure the serial connection:
  Serial.begin(9600);
  // configure the digital input:
  pinMode(digitalOne, INPUT);
}

void loop() {
  // read the sensor:
  sensorValue = analogRead(analogOne);
  // print the results:
  Serial.print(sensorValue, DEC);
  Serial.print(",");

  // read the sensor:
  sensorValue = analogRead(analogTwo);
  // print the results:
  Serial.print(sensorValue, DEC);
  Serial.print(",");

  // read the sensor:
  sensorValue = digitalRead(digitalOne);
  // print the last sensor value with a println() so that
  // each set of four readings prints on a line by itself:
  Serial.println(sensorValue, DEC);
}

After uploading the code to the Arduino, the next step was the run a program in processing.  The code in processing reads the data from the Arduino program.  Setting up this code was a little confusing for me, as I followed each group of code in detail.  However, when i compared my code to the final code in its entirety, i was missing certain things.  Since the code was made for an accelerometer, we had to change the last bit of code so that it can correspond to having two pot’s and a pushbutton.  

Here is the sample code with the ending of the code values changed and in bold. 

import processing.serial.*;     // import the Processing serial library
Serial myPort;                  // The serial port

float bgcolor;			     // Background color
float fgcolor;			     // Fill color
float xpos, ypos;		             // Starting position of the ball

void setup() {
  size(640,480);

  // List all the available serial ports
  println(Serial.list());

  // I know that the first port in the serial list on my mac
  // is always my  Arduino module, so I open Serial.list()[0].
  // Change the 0 to the appropriate number of the serial port
  // that your microcontroller is attached to.
  myPort = new Serial(this, Serial.list()[0], 9600);

  // read bytes into a buffer until you get a linefeed (ASCII 10):
  myPort.bufferUntil('\n');
}

void draw() {
  background(bgcolor);
  fill(fgcolor);
  // Draw the shape
  ellipse(xpos, ypos, 20, 20);
}

// serialEvent  method is run automatically by the Processing applet
// whenever the buffer reaches the  byte value set in the bufferUntil()
// method in the setup():

void serialEvent(Serial myPort) {
  // read the serial buffer:
  String myString = myPort.readStringUntil('\n');
  // if you got any bytes other than the linefeed:
  if (myString != null) {

    myString = trim(myString);

    // split the string at the commas
    // and convert the sections into integers:
    int sensors[] = int(split(myString, ','));

    // print out the values you got:
    for (int sensorNum = 0; sensorNum < sensors.length; sensorNum++) {
      print("Sensor " + sensorNum + ": " + sensors[sensorNum] + "\t");
    }
    // add a linefeed after all the sensor values are printed:
    println();
    if (sensors.length > 1) {
      xpos = map(sensors[0], 0,1023,0,width);
      ypos = map(sensors[1], 0,1023,0,height);

      fgcolor = sensors[2] * 255;

    }
  }
}

The first screenshot are the sensor values when the pot's are turned and the pushbutton is 

pressed. Sensor 0 and 1 are the pot. value.  The pushbutton corresponds to sensor 2, which

only gives off 0 and 1 as its value since it is a digital switch.

Get Creative

Looking at the two potentiometers, I was reminded of an etch-a-sketch.  Therefore, it would be 

fitting to create a computer version of an etch-a-sketch, where the pots were used to draw lines