Author Archives: vkk243

Reading Response: Making interactive art & Physical computing greatest hits and misses

Making Interactive Art: Set the Stage, then Shut Up and Listen:

In an amusing way, the publisher of this blog post Tigoe opened up his discussion about the differences between a descriptive or testimonial and an interactive work of art with the single line “Don’t interpret your own work”. Even if I didn’t read the entire post, I would’ve known what his debate was about already because interpreting your own work as an artist is what artists have been taught to do for several centuries. Tigoe argues that if you want to make something interactive, you should not tell your audience what the artwork is about – just let them figure it out. I would also like to add that the old tradition of teaching artists to describe and present the meaning or lack of meaning (which is also a kind of meaning) of their own work has taught the audience to look at these artworks in the same way. And some viewers continue to approach work of art looking for a meaning and then get frustrated and turn away when they don’t find one. Even if a work of art is interactive, people sometimes still don’t know how to look at it. So the problem of handling artworks as statements and not personal experiences is actually a two-way trap, where artist and viewer is taught to “read” every artwork as a statement.

Also a remark on Tigoe’s likening of interactive work to performance: I think it’s important to make it clear that even this type of thinking can have traps. For example, even though the audience completes the work, if they do it through a set of instructions, they still don’t interact with the work. So there’s gotta be a place or time where the audience can actually manipulate the artwork – the artwork then needs to really change, and either stay that way or perhaps be able to reverse, awaiting the next viewer’s reaction.

Physical Computing’s Greatest Hit’s (and misses):

I found a few very interesting projects in this blog post. Firstly, the not so interactive video mirrors could in my opinion be upgraded to include more interaction. Taking the Text Rain example, I could imagine the audience being able to pick letters and form words of their liking , which then they can pass onto another member of the audience who’s in front of the mirror or back to the computer to reply something to it. Another thing I really liked was not included in Tigoe’s post. I followed a link to Dan Shiffman’s Coding Train Youtube channel, and I found an example where he made 2D water ripples in Processing. You could make ripples with the touch of the mouse or draw continual ripples by dragging the mouse. I think both of these examples are great examples of physical computing precisely because they’re actually bad examples. They present a basic idea that doesn’t offer much interaction but can be developed into an interactive piece. Often what we think of as interaction is actually a very limited form of interaction or just a reaction. The most challenging is realising that not every person’s body is capable of doing the same movements. If something is truly interactive, it should offer that interaction to someone whose senses are limited in one way or another. I think that in interactive media, the closer we get to optimal levels of interactivity, the more we need to keep discussing the ethics of the field and especially the inclusion people with limited sensory perception.

Week 6 Reading Responses: Motors, Motion and ITP Transistor Lab

These were very useful readings and did a very good job at introducing me to motors and other aspects of mechanics, which I haven’t heard about or have forgotten. I also haven’t realised that diodes like the Leds we have been using were so important for our circuits. Chapter 6 for example opened up a bunch of possibilities for future projects that could make things we build, like Rambo, a lot more interactive and fun. While the ITP lab also showed how it can be possible to move a lot of bigger things instead of staying within the microcontroller’s range of power. I think because one of the key aspects of biological existence is motion, it should follow that if you create motion, you will be closer to interacting with other things that have motion. Perhaps when something moves, you relate to it more. I’ve heard many people finding it hard to look at paintings vs movies, for example. I think the same principle in interactivity applies (even though neither movies or paintings are truly interactive) as when we see a robot that stand or a robot that carries out physical tasks. Something dynamic is always more “relatable”. Perhaps this might also be the reason why people say movies are interactive, even though they aren’t because there is no response from the movie to the audience. I have been at an exhibition at the National Science Museum in Hungary, where they introduced us to a talking and moving robot that could to some extent hold a conversation. I was scared of it but at the same time it just felt nice to talk to it. One thing it could do really well was shake your hand, which was fascinating. Hand shakes in general are fascinating because the two hands need to work together and feel the other’s response to react and form a good shake. They would require bigger motors with transistors to control more realistic motions as well, such as the bending of the fingers and the wrist, and especially the elbow, to match the position of the other person/object. It would be really exciting to mimic a handshake using motors and sensors such as touch, pressure, or even moisture sensors. I think this could be something I would love to do.

Midterm Project: Antisocial Robot

It just hates people. It doesn’t like anyone getting too close to it. It will scream at you as you approach. And if you dare to touch…

I came up with the idea of the antisocial robot because I wanted to use a sensor and associate it with different forms of behaviour, similarly as in the organic world. When we see or touch something, it’s not only one physical or emotional reaction we experience/exhibit, but a bunch of different impulses trigger different reactions. For my robot, these impulses are distance from the robot and touch. If an object is too close, it will react to that object. The form and intensity of the reaction depend on how close the approaching person or object is. I formed a mental map of different cases of how a living thing would react to the presence of something it didn’t like. I think at this point it deserves a name. Let’s call it Rambo.

For the input sensor, I used the ultrasonic distance sensor (a straightforward choice) . Depending on the distance, other components, the RGB Led, the buzzer, the liquid crystal display (LCD) and the servo motor exhibited different behaviours – in the technical term, outputs. Think of the distance sensor as Rambo’s eyes, the servo as its arms, the LCD and buzzer as its mouth and the RGB Led as maybe it’s facial expression. Anything that can express disapproval visually.

Rambo’s behaviour can be summed up in 5 cases:

  1. If you’re within 1m it takes notice of you, it starts beeping but shows a green light so that you know it’s only a little bit bothered. It does write you a grumpy message on the board though: “I see you. Do not come closer.”
  2. If you’re within 60 cm it thinks you’re getting too close. A yellow light and  some higher pitched beeps indicate that it’s not happy. In fact, he says: “Dude, back off.” That should be warning enough.
  3. If you’re not compliant and you come within 30 cm, it will try to annoy you with even higher pitched little screams. It will show you the super-rejective red light, spit a rude “Ooooiiiiiii! LEAVE ME!” at you and even wiggle its little red flag that is attached to his hand (the servo).
  4. The worst you can do is touch it on its face (the “eyes” of the distance sensor) or come within 4 cm of touching it. This statement works as a pseudo touch sensor, because it’s so close to the sensor it’s almost a boolean case. Rambo will not tolerate being touched. It will scream constantly, swing its red flag at you and show all the light it can make – white light. It will also display “AAAAAARRRRRGHHH” on its message board. Boy, it is real upset.
  5. In the last case, you keep your respectful distance, and he won’t do anything. Just sit and look like he is not grumpy at all. But just move close enough again and you will see.

 

Here is Rambo’s circuit schematics:

Here’s the code to determine Rambo’s behaviour using input and output:

/* This sketch uses an ultrasonic distance sensor as the robot's eyes
    to react to an approaching person or object.
    Other elements of the circuit are:
      - servo motor
      - buzzer
      - RGB Led
      - liquid crystal display board (LCD)
      - potentiometer
    The sensor passes the distance value input to several if statements
    and the if statements decide the reaction of the robot to how far
    the intruder is. Another if statement controls the state of the robot
    when nothing is too close to it in the direction of the distance sensor.
*/

/*------------------------- INITIALIZATION ------------------------------*/

// import libraries

#include "pitches.h"
#include 
#include 

// trig = sender, echo = receiver of ultrasonic sound signal
const int trigPin = 4;
const int echoPin = 2;

// define variables used for calculating distance
long duration;
int distance;

// RGb Led gives light signal to the approacher
// to what extent the robot doesn't like the situation

const int rgb_bluepin = 3;
const int rgb_greenpin = 5;
const int rgb_redpin = 6;

// the message displayed is what the robot is saying
const int rs = 7, en = 8, d4 = 9, d5 = 10, d6 = 11, d7 = 12;

// create lcd object
LiquidCrystal lcd(rs, en, d4, d5, d6, d7);

// this is the arm of the robot
Servo servoArm;
int pos = 0;

// this makes the sound of the robot - beware the deafening screams of disapproval
const int speaker = A0;

/*---------------------- START SETUP --------------------------*/

void setup() {
  // communication used to check the distance input in case something is wrong
  Serial.begin(9600);

  // trig pin emits sound wave and echo pin is used in the pulseIn() function
  // receives sound wave and returns travel time of wave in ms
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);

  pinMode(rgb_bluepin, OUTPUT);
  pinMode(rgb_greenpin, OUTPUT);
  pinMode(rgb_redpin, OUTPUT);

  pinMode(speaker, OUTPUT);

  servoArm.attach(A2);

  // set up the number of columns and rows on the LCD
  lcd.begin(16, 2);


}

/*------------------------ FUNCTIONS ---------------------------*/

// function to output values for different colours
// from online tutorial(howtomechatronics.com)
void setColour(int redValue, int greenValue, int blueValue) {
  analogWrite(rgb_redpin, redValue);
  analogWrite(rgb_greenpin, greenValue);
  analogWrite(rgb_bluepin, blueValue);

}

// function to convert duration in ms to distance in cm
// from Arduino example Ping
long microsecondsToCentimeters(long microseconds) {
  return microseconds / 29 / 2;
}

/*----------------------------- START LOOP ---------------------------------*/

void loop() {

  // this was supposed to define the force sensitive resistor
  // for a pressure reading input on top of the robot's head
  /*initialize FSR (force sensitive resistor) and set as reading input
    const int fsr_Read = analogRead(A5);
    int didTouchAlready = false;*/


  /* Set up the working of the distance sensor */

  // clear trig pin to stabilise reading
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);

  // set the trig pin on high to send the sound wave signal
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);

  // as signal bounces off approaching object and is returned,
  // echo pin reads the time taken for the sound to travel in ms
  duration = pulseIn(echoPin, HIGH);

  distance = microsecondsToCentimeters(duration);

  // print distance on Serial Monitor
  Serial.print(distance);
  Serial.print("cm");
  Serial.println();

  //delay between readings. the bigger (within reason),
  //the less confused the robot is with changing distances
  delay(200);


  /* Write the 5 cases defining the robot's responses to
      changing distance */


  if (60 < distance && distance <= 100) {
    lcd.clear();
    lcd.setCursor(0, 0);
    lcd.print("I see you. Do");
    // move the cursor to the second line
    lcd.setCursor(0, 1);
    lcd.print("not come closer.");

    setColour(0, 255, 0);

    tone(A0, NOTE_D1, 500);
    delay(500);
  }

  else if (30 < distance && distance <= 60) {
    lcd.clear();
    lcd.setCursor(0, 0);
    lcd.print("Dude.");
    // move the cursor to the second line
    lcd.setCursor(0, 1);
    lcd.print("Back off now.");

    setColour(255, 15, 0);

    tone(A0, NOTE_G3, 500);
    delay(500);
  }

  else if (4 < distance && distance <= 30) {
    lcd.clear();
    lcd.setCursor(0, 0);
    lcd.print("Ooooiiii");
    // move the cursor to the second line
    lcd.setCursor(0, 1);
    lcd.print("LEAVE ME!");

    setColour(255, 0, 0);

    tone(A0, NOTE_A7, 500);
    delay(500);

    // small wiggle
    for (pos == 0; pos <= 180; pos += 1) {
      servoArm.write(pos);
      delay(1);
    }
  }

  //when almost touching or actually touching the robot
  else if (distance <= 4) {
    lcd.clear();
    lcd.setCursor(0, 0);
    lcd.print("AAAAAARRRGGHHHHHH");

    setColour(255, 255, 255);
    tone(A0, NOTE_G6);

    digitalWrite(rgb_redpin, HIGH);
    digitalWrite(rgb_greenpin, HIGH);
    digitalWrite(rgb_bluepin, HIGH);
    delay(200);
    digitalWrite(rgb_redpin, LOW);
    digitalWrite(rgb_greenpin, LOW);
    digitalWrite(rgb_bluepin, LOW);
    delay(200);

    // big sweep
    for (pos == 0; pos = 0; pos -= 1) {
      servoArm.write(pos);
      delay(1);
    }

  }

  // this is the case when nothign is too close
  // setting such a case stabilises reactions
  // otherwise, random flashes of light or sound can occur

  else if (distance > 100) {
    lcd.clear();
    noTone(A0);
    analogWrite(rgb_bluepin, LOW);
    analogWrite(rgb_greenpin, LOW);
    analogWrite(rgb_redpin, LOW);
    servoArm.write(pos);
  }


  // case for when the robot is touched on the head
  // reaction same as when touched on the "face"
  // but different messages are displayed depending on whether the
  // robot has been touched or not
  /*else if ((didTouchAlready == false) && (fsr_Read > 0)) {
    lcd.clear();
    lcd.setCursor(0, 0);
    lcd.print("DON'T TOUCH ME");
    lcd.setCursor(0, 1);
    lcd.print("!!!");

    setColour(255, 255, 255);
    tone(A0, NOTE_A7);

    digitalWrite(rgb_redpin, HIGH);
    digitalWrite(rgb_greenpin, HIGH);
    digitalWrite(rgb_bluepin, HIGH);
    delay(200);
    digitalWrite(rgb_redpin, LOW);
    digitalWrite(rgb_greenpin, LOW);
    digitalWrite(rgb_bluepin, LOW);
    delay(200);

    didTouchAlready == true;
    }

    else if (fsr_Read > 0) {
    lcd.clear();
    lcd.setCursor(0, 0);
    lcd.print("Dude why");
    lcd.setCursor(0, 1);
    lcd.print("??????");

    setColour(255, 255, 255);
    tone(A0, NOTE_A7);

    digitalWrite(rgb_redpin, HIGH);
    digitalWrite(rgb_greenpin, HIGH);
    digitalWrite(rgb_bluepin, HIGH);
    delay(200);
    digitalWrite(rgb_redpin, LOW);
    digitalWrite(rgb_greenpin, LOW);
    digitalWrite(rgb_bluepin, LOW);
    delay(200);
    }*/

}

Some elements have been put together using built in examples, for example the ones for the LCD, the others have been written by me.

And here is a video from the first time it was assembled:

I also built a paper cover around Rambo to make it resemble a body and look more realistic and 3D. Once fully assembled, Rambo looked like this:

The contrast on the LCD board can be adjusted with the potentiometer, if the light in the room is too bright:

The whole interaction:

Rambo doesn’t sense whether you’re approaching or walking away. An improvement could be to include a for loop in the code that iterates as the distance between you and Rambo is increasing. In that way, if you’re walking away, a different message could be printed on the LCD, something like: “Good job. Keep walking away.”

 

Evaluation of the project

Rambo was successful in what I wanted it to do, and my code created commands and responses well and in an efficient sequence.

There were some steps during the implementation which were problematic, and one of these was finding the RGB values for an orange/yellow colour. It was harder than it might seem because the red Led in the RGB Led was dimmer than the blue and green Leds. It ended up being only 15 green and 255 red, which gave the yellow colour seen on the video.

Connecting the distance sensor was a challenge, as I didn’t really know how to start or write code for it. I learned some basic code and rules of implementation from this website of online Arduino tutorials, which I found very helpful: https://howtomechatronics.com/tutorials/arduino/how-to-use-a-rgb-led-with-arduino/

Stabilising the readings of the distance sensor was also a challenge. Thus, I added a delay of 200 milliseconds after each reading was taken. I found that without a delay at least this large, it was easy to confuse the sensor and there was much more room for errors., for example jumping to the next message on the LCD and suddenly back, changing the Leds too fast, all because the reading of distance changes too fast.

Some parts of the algorithm, for example when to clear the board or where to insert delays. For case 4, I first used the blinkWithoutDelay example but it messed with the Leds and made them blink in the other cases as well, so I abandoned it. The delay() function works better for this example because it is regular for the set interval in the if statement. Sometimes the delays get longer as the function loops, but I tend to like this mistake because it makes Rambo a bit more random and like a real person. In fact, I preferred this kind of behaviour the most:

It is so messy and disorganised, it is much more human than the cleaner responses. However, for the sake of an accurate project I made Rambo a bit more predictable in the end. He has his crankiness nonetheless.

There is also a problem with the distance sensor being smaller than my body. If I walk towards Rambo and I sway, I noticed that the Serial Monitor sometimes reads an unbelievable value – eg. from 65 to 305 – but when I strictly keep walking in a straight line, this problem doesn’t arise.

Because I wanted my code to work well for this project rather than be perfect, I didn’t end up addressing the problem of many if-else if statements. I initially wanted to use switch case statements, however, I couldn’t figure out how to use them for the interval values of the distance sensor. I hope to learn the switch cases soon.

One other big problem I couldn’t address was the implementation of the force sensitive resistor. Because of the box around the circuit and to look realistic and sensible, the FSR should have been placed on top of the box. This was going to be a solution for Rambo only seeing in one direction and not having a real touch sense. Although not a real touch sensor, the FSR would have been acting closely like one, as seen in the long commented parts in the code. If it senses any pressure, Rambo’s reaction would have been slightly different according to whether he has been touched “on top of its head” before or not. I simply couldn’t get this part of the circuit together as seen in this example:

https://learn.adafruit.com/force-sensitive-resistor-fsr/using-an-fsr

I tried attaching long wires to the ends of the sensor but it was so slim that my tape could not hold it in place and the whole arrangement kept coming apart. The 10 ohm resistor was also hard to connect with the FSR and the board because it wasn’t actually pinned into the board – again, the flimsy tape and sensor combo did not help. The FSR, or a touch sensor is something I would like to use in another project later in the semester.

 

Tiny Orchestra

My idea was to build an instrument that can emit at least two different sounds and play interesting tunes. Having written my program and while building my first circuit, I realised after some tests that my larger breadboard had broken connections inside and my speaker tunes were all over the place. So I changed my breadboard to the small one – thus making a REALLY tiny orchestra of just two instruments.

For this smaller version, I’m using 4 switches as piano keys to play tunes on a speaker and 2 servos with handles and larger metal plates attached to them, which act as two arms playing a cymbal. It was hard to come up with a role for the servos in this setup, but after finding several stainless steel tea and jars at home, the task was set.

Here is a schematic for the tiny orchestra:

I used 10K resistors for the switches.

And here is the code:

/* Project 4: Making a Musical Instrument
    A Tiny Orchestra

    Summary: 4 button switches are used to play tones on a speaker. Play them like on a piano keyboard,
    and you can compose a kiddy song of 4 notes.
    An additional element in this digital I/O circuit is the cymbal. The cymbal is made of 2 servo
    motors and handles with round metallic plates attached to their arms. When the servos sweep,
    their plates hit each other producing a sound resembling that of a cymbal.
    Use the tone function and chuck the servo position in a for loop.
    The tiny orchestra is ready to play.
*/

//import libraries

#include "pitches.h"
#include <Servo.h>

//initialize global constants

//this is the switch to sweep the servos thus playing the cymbal
const int redSwitch_servoSwitch = 2;

//these are the switches to control speaker sounds
const int redSwitch = 3;
const int yellowSwitch = 4;
const int greenSwitch = 5;
const int blueSwitch = 6;

//initialize servos and set their original position to 0
Servo servoOne;
Servo servoTwo;
int pos = 0;

//initialize speaker
const int speaker = 10;


void setup() {

  //set switch pins as input pins
  pinMode(redSwitch_servoSwitch, INPUT);
  pinMode(redSwitch, INPUT);
  pinMode(yellowSwitch, INPUT);
  pinMode(greenSwitch, INPUT);
  pinMode(blueSwitch, INPUT);

  //and speaker as output pin
  pinMode(speaker, OUTPUT);

  //attach servos to pins
  servoOne.attach(11);
  servoTwo.attach(12);

}

void loop() {

  //set the original state of the switches to 0
  int ServoState = 0;
  int redState = 0;
  int yellowState = 0;
  int greenState = 0;
  int blueState = 0;

  //determine read input state for switches
  ServoState = digitalRead(redSwitch_servoSwitch);
  redState = digitalRead(redSwitch);
  yellowState = digitalRead(yellowSwitch);
  greenState = digitalRead(greenSwitch);
  blueState = digitalRead(blueSwitch);

  //control both servos with one if statement
  //servos sweep together to play cymbal

  if (ServoState == 1) {
    for (pos = 0; pos <= 180; pos += 1) { servoOne.write(pos); servoTwo.write(pos); delay(1); } for (pos = 180; pos >= 0; pos -= 1) {
      servoOne.write(pos);
      servoTwo.write(pos);
      delay(1);
    }
  }

  //state which button produces which sound in the speaker when pressed
  if (redState == 1) {
    tone(10, NOTE_G4, 250);
  }
  else if (yellowState == 1) {
    tone(10, NOTE_C4, 250);
  }
  else if (greenState == 1) {
    tone(10, NOTE_G3, 250);
  }
  else if (blueState == 1) {
    tone(10, NOTE_E3, 250);
  }

}

The tiny orchestra worked out very well, although there was only space for one single hand to play it. It is a simple solution to the project, yet given the resources and the broken breadboard, I feel satisfied with the result. The structure of the cymbals could be improved with more durable materials that hold together tighter. It was very hard to place them in an angle relative to each other so that they could make a sound, and even in my circuit their contact could be smoother. Regarding the sounds, they could be better if played by someone experienced with a keyboard, but even under my hand’s control they played a soothing chaos. Let me know if people in the class would like to record a song at the end of the year. I think it could be fun.

Here are some videos of me playing the tiny avant garde orchestra:

Distant Solutions – Response to Victor’s Rant

Victor has managed to identify and describe again a problem that has been identified and described so many times: the limitations of today’s technology on our bodies and minds, on how we function and how we grow. But I thought him doing it from the point of view of interaction design was interesting, and it at least helped me to understand this new elusive concept a little bit more. When people talk about how modern technology, such as smartphones, smart watches and virtual assistants like Siri limit our interaction with the world, they usually mean at a psychological level. You get sucked into your phone and reach a stage of “brain death”. I really agree with Victor’s stance in that our minds are limited by these not so interactive technologies because they restrict the movements of our bodies and our real physical, face-to-face interactions with others and our surroundings. I think this thought is great. It would be even greater if the future technology could not only maximise our interactions with machines and the surrounding world but also with our local communities and closest friends. I’m under the impression that the future of interactive design is also about bringing people closer together as well as connecting them to the design materials themselves. I can already feel just by writing CS assignments that making something happen within a computer, asking it to do something through some lines of code is a solitary activity, even if you work on huge projects in a big team. I would even say that the future of interactive design should include opportunities to directly and physically engage with computers. But this idea is also problematic, because computers can only interact as much as you design them to do so. And design is also often politically motivated. Because here we are in this modern technologically “advanced” age, trying to imitate and reconstruct life itself – we also need to know why we are doing so.

Week 3 Reading Responses – The Art of Interactive Design, The Design of Everyday Things

Reading 1: The Art of Interactive Design

This reading has clearly addressed the different or no levels of interaction with books, movies, performance and between people, whom the author called actors. I was missing the consideration of video and computer games though, which I think is also very important because of just how many people enjoy them so much that they end up “interacting” more with their computer than their friends and family. Computer games do often have the illusion of being more interactive than they really are. Players identify with the characters in the games, often feeling the sense of adventure, danger or delight consequential to the characters’ actions in their own skin, especially when the screen is large and thus acts like an alternate reality. The same things can happen with movies. My friend identifies with certain characters of Game of Thrones so much that they seem to feel the strong emotions (grief, anger especially, or joy) of their favourite characters. Computer games, tv-shows or movies create an illusion of interactivity between the players/spectators and their own components that may not actually be there, yet many people believe they are and thus begin to devote more time to their favourite fabricated environments than their real ones. For instance, my aunt and her husband once took a sick day off from work to stay at home and watch the new season of The Last Kingdom.

To us, it does not matter how interactive these things actually are. No one really thinks about this in their leisure time. But the fact that they mimic interactivity so well places them in an interesting position in this chapter’s debate.

However, while missing work to watch TV might just sound bad, oftentimes non-interactive things like movies, tv-shows and books initiate the deepest interaction between two or more people, which can increase our sense of connectedness.

Reading 2: The Design of Everyday Things

This phrase from page 22 has stuck with me the most: “Machines that give too much feedback are like back seat drivers.” It is interesting to look at this simile because even though machines are not as interactive as we might like them to be, we still think of them as at least partially “alive”. Consider my friends giving names to their cars, or me naming my GPS once after an annoying, stupid TV commercial to associate it with well, being stupid. Even though we as a society deny being too dependent on technological devices, I think the reality is that we do want these devices to be part of our lives more efficiently. To some people, human interactions might seem to be too much effort compared to an AI that will tell you anything you want to hear and in any fashion you want to hear it. I think the fundamental principles of interaction such as affordances and conceptual models are all very important parts of making usable, enjoyable and perhaps very smart designs, but design aspects such as signifiers or mapping also allow the designer to not make these devices too interactive. For commercial designs, I think it is important to reinforce the idea that it is “just a machine”. The really good design aspects the author mentions would be better reserved to create bridges between us and those members of our society who have natural limitations of interacting with other people, instead of isolating those of us who would otherwise be persuaded to interact with others.

LED Fun Circuit – Rhythm Generator

Changes to integrate Week 3 Project:

I attempted to modify the circuit and include 2 switches, each switch sending one of the rhythms to one of the 2 additional LEDs according to the value of the potentiometer. I only kept 3 of the original rhythms and varied their speed so that they are more clearly distinguishable.

The schematics for the new circuit:

The code:

I wrote the rhythm sequences as functions in order to make reading the code easier and not having to paste them into every command I used them for.



//Program objectives:
//Use a series circuit of LEDs to generate 3 different rhythms, 
1 going at a faster pace to allow easy distinction
//Vary the order of rhythms playing using a switch. 
When the switch is on, mix up the order.
//Using another switch, play one of the rhythms 
on an additional LED when the switch is on.
//The reading from a potentiometer dictates 
which rhythm will play on the additional LED.

int yellow_switch = digitalRead(11);          //initialize switches
int blue_switch = digitalRead(12);

int pot_meter = analogRead(A0);               //initialize potentiometer

void setup() {
  Serial.begin(9600);

  pinMode(2, OUTPUT);            //Declare output pins. Declare input pins for quick remembrance.
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  pinMode(5, OUTPUT);
  pinMode(6, OUTPUT);

  pinMode(8, OUTPUT);

  pinMode(11, INPUT);
  pinMode(12, INPUT);

}

void loop() {
  // set up conditions for green and red switch
  // change potentiometer to call functions
  // for loop to change return from red/green switch condition

  int pot_meter = analogRead(A0);
  Serial.println(pot_meter);

  //int yellow_switch = digitalRead(11);
  //int blue_switch = digitalRead(12);

  if (yellow_switch == HIGH) {
    /*digitalWrite(8, HIGH);  //test red switch
    delay(400);
    digitalWrite(8, LOW);
    delay(400);*/
    
    for (int counter = 3; counter > 0; counter --) {
      transfer_rhythms(8);                      //play rhythm on red LED 3 times
      }
  }
  else if (blue_switch == HIGH) {
    /*digitalWrite(9, HIGH);
    delay(400);
    digitalWrite(9, LOW);
    delay(400);*/

    rumba();
    soukous();
    clave_son();
    
  }
  
  else {
    rumba();
    clave_son();
    soukous();
  }
}

//functions make it easier to pass rhythms 
to conditional statements in main loop
//intervals for 3 distinct rhythms

void clave_son() {
  digitalWrite(2, HIGH);
  delay(200);
  digitalWrite(2, LOW);
  delay(400);
  digitalWrite(3, HIGH);
  delay(200);
  digitalWrite(3, LOW);
  delay(400);
  digitalWrite(4, HIGH);
  delay(200);
  digitalWrite(4, LOW);
  delay(600);
  digitalWrite(5, HIGH);
  delay(200);
  digitalWrite(5, LOW);
  delay(200);
  digitalWrite(6, HIGH);
  delay(200);
  digitalWrite(6, LOW);
  delay(600);
}

void rumba() {
  digitalWrite(2, HIGH);
  delay(200);
  digitalWrite(2, LOW);
  delay(400);
  digitalWrite(3, HIGH);
  delay(200);
  digitalWrite(3, LOW);
  delay(600);
  digitalWrite(4, HIGH);
  delay(200);
  digitalWrite(4, LOW);
  delay(400);
  digitalWrite(5, HIGH);
  delay(200);
  digitalWrite(5, LOW);
  delay(200);
  digitalWrite(6, HIGH);
  delay(200);
  digitalWrite(6, LOW);
  delay(600);
}

void soukous() {
  digitalWrite(2, HIGH);
  delay(50);
  digitalWrite(2, LOW);
  delay(100);
  digitalWrite(3, HIGH);
  delay(50);
  digitalWrite(3, LOW);
  delay(100);
  digitalWrite(4, HIGH);
  delay(50);
  digitalWrite(4, LOW);
  delay(150);
  digitalWrite(5, HIGH);
  delay(50);
  digitalWrite(5, LOW);
  delay(10);
  digitalWrite(6, HIGH);
  delay(50);
  digitalWrite(6, LOW);
  delay(200);
}

int transfer_rhythms(int led)  {
  if (0 < pot_meter && pot_meter < 350) {   
//varying the value of the reading from potentiometer 
decides which rhythm to play on red LED
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(100);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(100);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(150);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(50);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(150);
  }
  else if (350 < pot_meter && pot_meter < 750) {
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(100);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(150);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(100);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(50);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(150);
  }
  else if (750 < pot_meter && pot_meter < 1023) {
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(100);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(100);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(150);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(10);
    digitalWrite(led, HIGH);
    delay(50);
    digitalWrite(led, LOW);
    delay(200);
  }
  
  return led;
}

And some pictures:

Unfortunately, this code didn’t work. I modified it many times and I could get the blue switch to work, but never the yellow one. Some of the other students checked my circuit and the connection between switches and the Arduino seemed right. I suspect it might be something with how I coded the last function but nor I or my helpers could debug it.


 

Idea: In my freshman year, I took a core class called Rhythm with Prof. Godfried Toussaint, which was about using computer science for the structural analysis of music, especially focusing on certain mathematical properties of rhythm such as geometry or divisiveness. The rhythms we examined first arrived in America at the dawn of the slave trade and have been inherited through many generations. They are still alive as part of African, African American as well as Latin American music. I imagined LEDs in a series circuit the same way the timelines of these rhythms are constructed, which gave me the idea to “play” these rhythms using an LED string.

I would like to thank Prof. Toussaint for researching these rhythms extensively and making them known for us. I will be playing them on my circuit as he taught them, without modification.

Objective: To build an electronic circuit which can play multiple rhythms at the same time at a given command.

***

To start, I looked an image of the six traditional rhythms from a slide Prof. Toussaint presented in class. An onset can be understood as a beat and pulse the sum of all beats and silences. The length of 1 pulse is the meter.

From a computer science perspective, these rhythms can be represented as:

1000101000101000, 1001001000101000, 1001001000110000, etc.

Therefore, they can also be played by blinking LEDs. Because these unique rhythms all have 5 onsets, I chose to play 5 rhythms with 5 LEDs: son, shiko, soukous, rumba and gahu.

I began the process of computing these rhythms by isolating just one of them, the son, and writing a program for one LED that would play it by blinking at certain intervals. Because pulses in these rhythms are of equal length (hence, playing every pulse gives the meter), I counted each 0 or 1 as a quantity P. Thus, every onset (blink) is P long, while the silences are products of P and the number of silent pulses.

I used the pinMode function in the Arduino to declare one digital pin as OUTPUT for each of the 5 LEDs.

I experimented with different values of P until I found the value I thought worked best for the blinking LEDs, P=200. So, every onset became 0.2 seconds long, and every silence between onsets calculated in multiplies of 0.2 seconds.

The code for the first blink would look like this:

I saved the code 5 times and modified it for each rhythm. Though I ended up with 5 codes, which is unnecessary from a programming point of view, I still felt the need to see how each one looked before I complicated the circuit further.
I then set up the circuit with 5 LEDs, 5 resistors and the Arduino.
It was the lamest and messiest circuit I’ve built so far.

But then I made it neater, improving the timing of the LEDs by allowing for clearer connections using fewer wires…

… and played all the rhythms with a white paper behind the LEDs to make them look pretty.

With this modification in the code, I could also play each rhythm on a distinct LED (See video).

 

To make the circuit interactive, I inserted a potentiometer be able to play multiple rhythms using the same code. Here is a schematic drawing and a photo of the new circuit:

           

For this, I reworked one of the examples from class and assigned an interval of the reading of the potentiometer to each output pin.

Now I can play each rhythm using the same code and setup by changing the direction of the arrow on the potentiometer and looking at the written output of the analogRead function. Though one has to pay close attention to the circuit to see when the rhythm changes, I am still happy with the way this circuit visualises these interesting rhythms.

(Disclaimer: It is a little hard to see when the rhythms change. The order of the rhythms is still the same: clave son, shiko, soukous, rumba and gahu. I left every rhythm to play 2-4 times.)

***

Evaluation and possible improvements:

Though my circuit was successful in that it looks engaging and because I achieved my goal, the result is still somewhat dull. One of the reasons is definitely the fact that these 5 rhythms are similar in structure. They are very interesting rhythms because of their popularity, but for this demonstration, more varied rhythms would have been more suitable. I didn’t have much reference material left from the Rhythm class, perhaps an improvement could be to make my own rhythms and play with them.

Another improvement would be to make the circuit even more interesting by synchronising the blinking LEDs as much as I can. I tried a few versions of code to achieve this, but sadly came nowhere. It would be easy to set up a loop for each LED and play them at the same time, but unfortunately as I learned from here,

https://arduino.stackexchange.com/questions/37684/can-i-make-multiple-void-loops-with-arduino-uno/37685

it is not possible.

I tried grouping the first onsets and silences, then the second ones, etc, like this:

But this didn’t get me closer to my second goal either and by now I ran out of time to try new solutions.

Overall, thought my circuit didn’t turn out as exciting and funky as I planned it to, it was still an interesting discovery and I enjoyed practicing building it and writing the code for it. Ultimately, I was left with many new lessons.

 

 

Project 1_Handless switch

Components:

  • battery (Arduino)
  • light bulb
  • resistor
  • piezos
  • 2 drinking bottled or something tall to use as stands for the wires
  • wires

Idea: The light bulb is switched on when the 2 piezos are blown against each other.

Image 1 shows a trial of setting up a basic series circuit and touching the piezos (closing the switch) to test the connection between them and the wires.

Image 2 shows the whole circuit with the wires wrapped around the stands to secure them above the table. The goal was to leave enough length of wire for the piezos to move but at the same time secure them tight enough so they don’t become floppy. This length was quite hard to find as the wires always wanted to fall. Once the circuit was completed, I tested whether the current flows through when the switch is closed.

It was hard to get the piezos to touch and the connection was unreliable, but it worked. (Yey!) The only limitation of the circuit is that the piezos have to be fairly close to each other to start with, otherwise the switch can’t be closed at all.