ink heater the beginnings of a blog

Media Controller

I worked with Nikolas Psaroudakis and Matt Swenson for our Physical Computing media controller assignment. From the outset, we knew wanted to create a physical device that controlled sound, allowed the user to change his/her actions and see in real time how these changes affected the sound.

We all had different ideas about what we wanted to build, some of them being easier and others more difficult. After toying around with numerous concepts, we whittled our ideas down to a MIDI controller that enabled the user to create fairly complex sounds by controlling simultaneous musical loops.

Some rambling sketches from our first brainstorm

Our device would enable the user to compose and perform unique compositions by moving their hands at varying distances above the sensors to control and modify prerecorded sounds, or music. Each sensor on the device would correspond to a different prerecorded sound sample, and the user could control the pitch, tone or tempo of the music.

We used Ableton Live for the music part of our project. We selected a set of sample loops that together nicely when played together and a set of audio filters that would be applied and controlled through MIDI.

Programming the sensors
We chose to use sonar sensors due to their ease of operation. The first step was to connect one sensor for testing. The MaxSonar EZ-1 and the Parallax PING were almost equally priced, so we decided to test both. The Parallax sensor gave more accurate results - but because it was less compact than the MaxSonar sensor, we decided to go with the MaxSonar.

Upon testing the three MaxSonar sensors simultaneously, we discovered some odd errors in the readings that hadn’t occurred when operated individually. After a bit of research, we realized the problem: the sensors were cross-talking, i.e. the pulse of one sensor was detected by another one, making the results very unstable (see below). To eliminate this interference, we could either position them farther apart, or point them in different directions, e.g. on a curved surface.

When we tested all three sonar sensors together, we found that the readings interfered with each other.

The first time the circuit was soldered together, only the sensor on pin 2 was working. Upon double-checking the code for accuracy, we determined that the error must be in the connections - so we unsoldered the circuit board and rewired the components to a breadboard for troubleshooting.

While positioning the sensors at different angles helped reduce interference between them, we found that it was not enough on its own. Readings continued to be unstable, and jumps were experienced at random moments. We decided to employ averaging on the readings and see if that helped, but unfortunately, it didn’t make much of a difference.

Our biggest problem was cross-talking between sensors as well as random jumps in our readings that were causing MIDI send events to take place.

Physical Design & Interface
We loaded prerecorded musical loops on the sensors and played around to determine what gestures made sense to control the levels, and decided that the vertical (up-down) motion of the user's hand above the sensors would provide the most intuitive method of controlling levels varying between high-low; enable the user to remain in place while operating the device; and lessen the chance of accidental interference from external sources.

The curved top surface allowed for fluid, natural hand movements. The positioning of the three sensors enables user can easily switch to right or left hand to control the center sensor.

At this point, the device was almost ready to go - we just had to attach the Plexi on top.

We cut a rectangle of Plexiglas for the curved top of the device, and used the drill press in the shop to make holes for the screws to affix the Plexi to the base. The drill bits in the shop were too small to create holes for the sensors – so John Duane introduced me to the hole saw, a tiny saw in the shape of a circle that fits onto a drill (like a drill bit) and enables the user to cut large holes in fairly thin materials. Fun!

We used a hole saw fitted onto the drill press to make holes in the Plexi large enough to accommodate the sensors.

Matt created a Processing sketch to provide the user with a visual indication of the levels of the sensors.

The Presentation
We tested our MIDI controller in the student lounge on the ground floor of Tisch and were satisfied with the outcome. When the time came for us to present in class, however, the system proved unstable. After troubleshooting for some time, we realized that student lounge was ideal for our experiment due to the high ceiling – and additionally, we were the only people close to our device. In contrast, the classroom’s low ceiling, and perhaps also the presence of others in the vicinity, caused the sensor readings to become unstable.

If we were doing this project again, we’d probably try using IR sensors instead of sonar. We’d also use thinner Plexi, as the Plexi we used developed small cracks when we curved it.

The code we used is below.

int analogPin1 = 0;
int analogPin2 = 1;
int analogPin3 = 2;
int digPin12=12; //Set BW pin to HIGH
int digPin13=13; //Set pimn to HIGH after 250ms
int switchPin=2;
int sensorValue = 0;
int switchState=0;
int prevState=0;
int state=0;
int n=1;/// average over n times
int maxLevel=3000;
int cnt=0;
boolean started=true;
void setup()
{
  // start serial port at 9600 bps:
  pinMode(switchPin, INPUT);
  //pinMode(digPin12,OUTPUT);
  //pinMode(digPin13,OUTPUT);
  Serial.begin(9600);
  establishContact();
}
void loop() {
  //digitalWrite(digPin12,HIGH);
  initSensors();
}
void initSensors(){
  if (millis()>=250){
    if (started==false){
      //digitalWrite(digPin13,HIGH);
      delay(30);

      started=true;
    }
    else {
    //  digitalWrite(digPin13,LOW);
      readSensors();
    }
  }
}
void readSensors(){
  switchState = digitalRead(switchPin);
  if (switchState==1 && prevState==0){
    state=state%3;
    state++;
    prevState=1;
  }
  else if (switchState==0 && prevState==1){
    prevState=0;
  }
  if (Serial.available() > 0) {
    // read the incoming byte:
    int inByte = Serial.read();
    // read the sensor:
    sensorValue = avgReadings(analogPin1,n);//analogRead(analogPin1);
    // print the results:
    Serial.print(maxSense(sensorValue,maxLevel), DEC);
    Serial.print(",");

    // read the sensor:
    sensorValue = avgReadings(analogPin2,n);//analogRead(analogPin2);
    // print the results:
    Serial.print(maxSense(sensorValue,maxLevel), DEC);
    Serial.print(",");
    // read the sensor:
    sensorValue = avgReadings(analogPin3,n);//analogRead(analogPin3);
    // print the last sensor value with a println() so that
    // each set of four readings prints on a line by itself:
    Serial.print(maxSense(sensorValue,maxLevel), DEC);
    Serial.print(",");
    Serial.print(state,DEC);
    Serial.println("");
  }
}
void establishContact() {
  while (Serial.available() <= 0) {
    Serial.println("hello");   // send a starting message
    delay(300);
  }
}
int avgReadings(int pin,int n){
  int avg=0;
  for (int i=0;ilevel){
    return level;

  }
  else {

    return sensorValue;
  }
}

The processing code follows:
(File midiController.pde)

import promidi.*;
import processing.serial.*;
MidiIO midiIO;
MidiOut midiOut;
Controller controller,controller2;
//int inByte=20;
Serial myPort;
sonarSwitch switches;
int nSonars=3;
void setup () {
  size (1024,768);
  switches = new sonarSwitch(nSonars,0);
  background (0);
  smooth();
  initMidi();
  initSerial();
}
void draw(){

}
void myDraw() {
  //println("NO height is:"+height);
  switches.draw();
  fill(0,10);
  rect (0,0,width,height);
}
void serialEvent(Serial myPort) {
  switches.serialStuff(myPort);
  myDraw();
}
void initMidi(){
  //switches=new sonarSwitch(1,0);
  midiIO=midiIO.getInstance(this);
  midiIO.printDevices();
  midiOut=midiIO.getMidiOut(0,0);
}
void initSerial(){
  println(Serial.list());
  myPort = new Serial(this, Serial.list()[0], 9600);
}

(File dotColumn.pde)

class dotColumn {
  dotTrack[] dots;// = new dotTrack [1000];
  int r,g,b,x;
  int nLines=50;
  int nLinesCurrent=0;
  dotColumn(int _x, int _r,int _g, int _b){
    r=_r;
    g=_g;
    b=_b;
    x=_x;
    dots =new dotTrack[nLines];
    for (int i = 0; i < nLines; i++) {
      dots[i] = new dotTrack(x, height-i * 10, 6, 0, r,g,b, 23);
      //println("Height is:"+height);
    }
  }
  void  draw(){
    for (int i = 0; i < nLinesCurrent; i++){
      dots[i].dotDraw();
    }
  }
}

(File dotTrack.pde)

class dotTrack {
  float x;
  float y;
  int w;
  float ySpeed;
  float xSpeed;
  int r,g,b;
  int inByte;
  int h;
  dotTrack (int x_, int y_, int ySpeed_, int xSpeed_, int r_, int g_, int b_, int inByte_) {
    xSpeed = xSpeed_;
    ySpeed = ySpeed_;
    x = x_;
    y = y_;
    r=r_;
    g=g_;
    b=b_;
    inByte = inByte_;
  }
  void dotDraw() {
    noStroke();
    fill (r,g,b);
    float x2 = random (x,x+40);
    ellipse (x2,y,5,5);
  }
}

(File sonarSwitch.pde)

class sonarSwitch {
  int nSonars;
  boolean firstContact = false;
  dotColumn[] columns;
  int[] sonarON_OFF;//=new int[0];
  int [] sonarON_OFFprev;  //previous state
  int[] sonarLevel;//=0;
  int button=1;
  int thres;
  boolean state=false;
  String mySt;
  int check;
  int upperLevel=100;
  int lowerLevel=60;
  int sonarLevelMax=50;
  public int[] sensors;
  boolean[] states;
  sonarSwitch(int _nSonars, int _thres){
    nSonars=_nSonars;
    // sensors
    columns=new dotColumn[nSonars];
    //println("The number is: "+columns.length);
    //println("Switches are: "+nSonars);
    thres =_thres;
    states=new boolean[nSonars];
    sonarON_OFF= new int[nSonars];
    sonarON_OFFprev= new int[nSonars];
    sonarLevel=new int[nSonars];
    for (int i=0; i< sensors.length-1; sensorNum++) {
          if (sensors[sensorNum]>upperLevel){
            sensors[sensorNum]=upperLevel;
          }
          //print("Sensor " + sensorNum + ": " + sensors[sensorNum] + "\t");
        }
        // add a linefeed after all the sensor values are printed:
        println();
        if  (sensors.length==nSonars+1){
          // println(sensors[nSonars]);
          for (int i=0;i 1) {
            switches.checkSwitches(sensors[nSonars]);
            switches.checkSliders(sensors[nSonars]);
            // println(sensors[nSonars]);
          }
        }
        myPort.write("A");
      }
    }
  }
  void checkSwitches(int button){
    // println("Switch "+button);
    for (int i=0;ithres&&columns[i].nLinesCurrent

PComp Lab: HBridge

In this lab, we learned to control the direction of a DC motor, i.e. reverse the direction of the current in the motor, using a H-Bridge circuit. I'd previously learned while doing the transistor lab that the motor I was using operated on between 3.3-5V, so I connected the motor to 5V in this lab instead of 12V - and as expected, the motor worked perfectly.

When the circuit is powered, the motor spins in one direction - and when the switch is pressed, it spins in the reverse direction.

H-Bridge lab from katherine keane on Vimeo.

Code

  const int switchPin = 2;    // switch input
  const int motor1Pin = 3;    // H-bridge leg 1 (pin 2, 1A)
  const int motor2Pin = 4;    // H-bridge leg 2 (pin 7, 2A)
  const int enablePin = 9;    // H-bridge enable pin
  const int ledPin = 13;      // LED 

  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(enablePin, OUTPUT);
    pinMode(ledPin, OUTPUT);

    // set enablePin high so that motor can turn on:
    digitalWrite(enablePin, 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);
    }
  }

PComp Lab: Using a transistor to control high current loads

The purpose of this lab was to learn to control a high-current DC load - in this case, a DC motor - from a microcontroller. I used the DC motor and 12V DC adapter that came in our PComp kit.

Once I'd put together the circuit, it made clicking sounds but didn't move... and so the troubleshooting began: I triple-checked the wiring, used a multimeter to record the voltage between various points, changed out all the components one by one, and switched out the 10K ohm resistor for the 1K ohm.

The video clip embedded below depicts three different attempts to make this circuit work as the lab intended.

• Take 1: The motor moves somewhat erratically, and the Arduino seems to be resetting itself.
• Take 2: The motor moves at a SLOW constant, and emits a high-pitched buzz that sounds like bagpipes (easily my least favorite musical instrument in the world).
• Take 3: Finally, we unplugged the 14V DC adapter and used 3.3V from the Arduino to power the DC motor, adjusting the speed with the pot. This worked perfectly - but defeated the purpose of the lab, which was to use a high current load.

PComp: DC Motor control using transistor with Arduino from katherine keane on Vimeo.

Phantom limbs, cognitive/sensory function and virtual tactility (and Kat’s nightmares)

Amputation is one of my greatest fears. I can't count the number of times I've awoken with a jerk and immediately checked to see that my limbs are still there. The existence of phantom limbs is new to me - after the initial traumatic experience of amputation, I can't fathom what it must be like to sense things as if the missing limb remained in place. Cognitive function is a crazy thing.

In chapter seven of "We Create What We See," Donald Hoffman argues that we construct everything that we sense and perceive, including all that we taste, hear, smell and feel. We also construct the location and point in time in which we sense and perceive things. Of all the senses, touch poses "the biggest impediment."

If we construct all that we feel, we "should be able to construct feeling in any body part, even if that part is amputated." Conversely, if an individual's constructive processes or cognitive functions are impaired, that individual will have difficulty with touch, even if the body part remains. Therefore, it's possible to create virtual realities -  or, more accurately, "virtual tactilities" - based on touch sensation.

I'm relieved that Donald Hoffman concludes this chapter with a discussion of the medical possibilities afforded by these findings, because I kind of expected him to go down the gaming/virtual worlds route. Once upon a time, when Second Life was the Next Big Thing, I played around with it for a while. Cool concept and all, but I felt it was a waste of real-life time to hang out in a virtual world that felt so, um, virtual. I'm all for using my imagination and whatnot, but I have enough to do in this joint without pottering around another world learning to fly, walk and talk.

Returning to Hoffman, this was a pretty intriguing read. I'd be interested in checking out any PComp projects (or those from more advanced classes) that explore or employ virtual tactility.

The sweet music of continuity

Soldering, I've discovered, is nothing like riding a bicycle. My initial attempts at soldering a DC power connector to a set of wires for a breadboard were alarmingly, embarrassingly awful. Entirely unreflective of previous hours spent in secondary school with soldering iron in hand (for constructive purposes, promise).

I attribute my initial failures to the "helping" hands, which wouldn't seem to stay put, no matter how much I coaxed them to cooperate. After an hour or so, about six inches of solder, mass header pin destruction and multiple clippings of the red and black wires, I congratulated myself on my decision to use eight inches of red and black wire at the beginning of this project, rather than the suggested 4 inches.

Upon successful attachment of the wires to the header pins, everything appeared to be okay - but still, it was with trepidation that I dragged out the multimeter to test for continuity.

Center pin to red wire: BZZZZ!
Outside rim to black wire: BZZZZZ!

Understanding electricity is pretty, erm, fundamental for physical computing. I'll admit that I don't quite "get" it all yet. Therefore, it's time for me to spend some serious hours in the shop playing around in an attempt to really figure it out. Circuits can't be that hard, right?

Arduino is but one of the things I'm hoping to master...