Month: April 2024

Both of this week’s readings led me to consider interactive art’s relationship with previously understood notions of human interaction and the production of art.

The reading on physical computing led me to identify two forms of approaching human-centred interactive design. The first of which is the repurposing and reapplication of interactions that already exist in the ‘real world’. The two examples that caught my eye which fall under this category were the ‘drum gloves’ and ‘video mirrors’. To me, the latter elevates the universal, almost reflex-like desire to look at oneself in the mirror and creates space for a quite direct form of symbolism (i.e “seeing x in yourself”). The former effectively borrows ‘gestural language’ from the ‘real world’ act of tapping one’s hands to make a beat. Again, this is an example of a familiar act being elevated but introduces an element of learning which is not present in video mirrors. I feel that this point introduces a spectrum of effort required by the user to uphold their side of the ‘conversation’ upon which interactive designs must place themselves. In this case, if video mirrors are like conversation with a talkative person, drum gloves aer like trying to connect with an introvert (i.e it is possible, it’ll just take some time).

Conversely, the reading on making interactive art provided me with a new perspective on its place within the larger artistic space. Previously, I would attempt to receive interactive art in the same way that I would receive other forms of contemporary art. The point raised by the reading that the role of an interactive artist is not to present a complete narrative but to best prepare the user to experience the narrative provided an interesting perspective which I have accepted. With this in mind, it is not unfair to double-down on the notion that interactive art is not complete without the input of the user. Rather than present a complete story, the role of the interactive artist is to facilitate a conversation between the art itself and the user which, hopefully, leads to a meaningful interaction at the end.

Let’s look at what I need to do…

(Post documentation on blog): Get information from at least one analog sensor and at least one digital sensor (switch), and use this information to control at least two LEDs, one in a digital fashion and the other in an analog fashion, in some creative way.

Hmm… so I can do something along the lines of

• Ultrasonic Sensor (Analog)
• Switch (is a requirement)
• 4 LEDs (3 controlled by digitalWrite, and one fade In/Out through analog PWM)

In some creative way?? Hmm, how about we turn the entire project into a detective game, where you have to guess the murderer by pointing at one of the 3 suspects, then Arduino will tell you whether you got it right or wrong.

Guess Who’s Murderer

Hence, my project…

The player step into the shoes of a cunning detective, whose aim is to unravel the identity of the true culprit among the Crimson Enigma, the Emerald Marksman, and the Honey Hitwoman.

Using their hand, the player must point to one of the suspects. An ultrasonic sensor, detects the location of the player’s hand, illuminating the corresponding LED to indicate their suspicion.

To make their guess official, the player presses a pushbutton. If the guess is correct, a green LED softly fades in and out. However, if the player points their accusatory finger at the wrong suspect, the game’s buzzer sounds.

The demo video is below.

Art

All artworks are generated with midjourney… and some photoshop thrown in.

CODE

The code is below. Note that I am implementing a entire thing as a state machine, where the game alternates between the

{ SELECT_MURDERER, GUESS, CORRECT_GUESS, WRONG_GUESS }

states. This makes the code clean. The microcontroller randomly selects the murderer using a random number generation algorithm, which is triggered at the start of each new game loop.

// Pin Definitions
const int buttonPin = 12;   // Pushbutton pin
const int buzzerPin = 7;    // Buzzer pin
const int greenLedPin = 44; // Green LED pin
const int redLedPins[] = {3, 6, 10}; // Red LEDs for murderer selection
const int trigPin = 2;      // Ultrasonic sensor trigger pin
const int echoPin = 4;      // Ultrasonic sensor echo pin

// Game state definitions
enum GameState { SELECT_MURDERER, GUESS, CORRECT_GUESS, WRONG_GUESS };
GameState currentState;

// Variables for game logic
int murderer = 0;
int guess = -1;
int buttonState = 0;
int lastButtonState = LOW;
unsigned long previousMillis = 0; // for non-blocking delays

void setup() {
  Serial.begin(9600);
  pinMode(buttonPin, INPUT);
  pinMode(buzzerPin, OUTPUT);
  pinMode(greenLedPin, OUTPUT);
  for (int i = 0; i < 3; i++) {
    pinMode(redLedPins[i], OUTPUT);
  }
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);
  randomSeed(analogRead(0));
  currentState = SELECT_MURDERER;
}

void loop() {
  switch (currentState) {
    case SELECT_MURDERER:
      selectMurderer();
      break;
    case GUESS:
      manageGuess();
      break;
    case CORRECT_GUESS:
      handleCorrectGuess();
      break;
    case WRONG_GUESS:
      handleWrongGuess();
      break;
  }
}

void selectMurderer() {
  murderer = random(0, 3); // Randomly select a murderer among 3 LEDs
  Serial.print("Murderer is: LED ");
  Serial.println(murderer);
  currentState = GUESS;
}

void manageGuess() {
  lightRedLEDsBasedOnDistance();
  readButtonState();
  if (buttonState == HIGH && lastButtonState == LOW) {
    Serial.println("Button Pressed");
    checkGuess();
  } else if (buttonState == LOW && lastButtonState == HIGH) {
    Serial.println("Button Released");
  }
  lastButtonState = buttonState;
}

void lightRedLEDsBasedOnDistance() {
  long distance = measureDistance();
  Serial.print("Distance: ");
  Serial.print(distance);
  Serial.println(" cm");
  for (int i = 0; i < 3; i++) {
    digitalWrite(redLedPins[i], LOW);
  }
  if (distance >= 2 && distance < 6) {
    digitalWrite(redLedPins[0], HIGH);
    guess = 0;
  } else if (distance >= 6 && distance < 9) {
    digitalWrite(redLedPins[1], HIGH);
    guess = 1;
  } else if (distance >= 9 && distance <= 12) {
    digitalWrite(redLedPins[2], HIGH);
    guess = 2;
  }
}

void readButtonState() {
  buttonState = digitalRead(buttonPin);
}

void checkGuess() {
  if (guess == murderer) {
    currentState = CORRECT_GUESS;
  } else {
    currentState = WRONG_GUESS;
  }
}

void handleCorrectGuess() {
  fadeGreenLED();  // Handles the fading of the LED over 4 seconds
  currentState = SELECT_MURDERER;
}

void handleWrongGuess() {
  buzzBuzzer(3);   // Buzzes the buzzer 3 times
  currentState = SELECT_MURDERER;
}

void fadeGreenLED() {
  for (int i = 0; i <= 255; i += 5) {
    analogWrite(greenLedPin, i);
    delay(30);
  }
  for (int i = 255; i >= 0; i -= 5) {
    analogWrite(greenLedPin, i);
    delay(30);
  }
}

void buzzBuzzer(int count) {
  for (int i = 0; i < count; i++) {
    digitalWrite(buzzerPin, HIGH);
    delay(300);
    digitalWrite(buzzerPin, LOW);
    delay(300);
  }
}

long measureDistance() {
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);
  long duration = pulseIn(echoPin, HIGH);
  return duration * 0.034 / 2;  // Calculate distance in cm
}

Jihad Jammal

Intro to IM

Professor Aaron Sherwood

Reading Reflection Week 10

April. 15, 2024

Re-evaluating Creativity

Tom Igoe’s perspectives on physical computing and interactive art present a compelling reevaluation of how creativity is often framed, particularly the expectation of producing entirely novel works. He argues persuasively for the value of revisiting and reinterpreting existing themes, thus challenging the traditional pursuit of absolute novelty in both art and technology. This approach strikes me as both practical and liberating, suggesting that innovation can flow from iteration—a continuous dialogue with established ideas—rather than emerging ex nihilo. This notion that revisiting familiar concepts can be a rich soil for personal expression and originality really resonates with me, encouraging a more inclusive and sustainable model of creative practice.

Building on Igoe’s redefined approach to creativity, his analogy of interactive art to a stage set for audience participation further deepens the dialogue about the creator-audience relationship. This model, which advocates for minimal intervention by the artist after the artwork’s initial presentation, challenges traditional notions of artistic control and opens up new possibilities for viewer engagement. Personally, I find this perspective transformative; it shifts the completion of an artwork’s meaning to the realm of audience interaction, thereby changing how art is consumed and interpreted. This democratization not only makes art more accessible but also enhances its depth by welcoming a multitude of interpretations.

Citations:

www.tigoe.com. (n.d.). Physical Computing’s Greatest Hits (and misses) – hello. [online] Available at: https://www.tigoe.com/blog/category/physicalcomputing/176/.

Anon, (n.d.). Making Interactive Art: Set the Stage, Then Shut Up and Listen – hello. [online] Available at: https://www.tigoe.com/blog/category/physicalcomputing/405/.

Concept & Inspiration

For this assignment, my aim was to create a simple gamified experience that engaged the user. I used to play this intuition game with my sister where she would think of a random number and I would try to “read” her mind and guess what that number was. With context clues of how “warm” or “cold” my guess was, I would eventually be able to get to the correct answer. My circuit is effectively a realization of this in hardware form.

Implementation

The circuit is composed of one RGB LED, three LEDs, a potentiometer, and a momentary switch. The game starts with the user pressing on the momentary switch (the digital sensor), upon which the Arduino program initializes a random number to be guessed. Upon activating the circuit, the RGB LED lights up in a pink color, indicating that the game is underway. The user then has to guess the number by using the potentiometer (the analog sensor) to find the correct value. The blue LED is lit if the current guess is far away from the correct number. The red LED lights up if the user is within a close range of the answer (±100 in my implementation). Once the number is guessed, the green LED lights up and the game is won. If the game is won, the RGB LED light show starts to celebrate the win, with different colors illuminating in succession. The user can turn off all the LEDs and restart the game using the momentary switch.

Code Snippets

The function setColor controls the color of the RGB LED in an analog fashion. This function is called when the game is started using the switch to set the color of the RGB LED to pink, and when the game is won, transitioning the RGB LED from having a static color to a dynamic light show (implementation below). The principle of blinking without delay is used to ensure the RGB LED seamlessly transitions from one color to the next and that the user is able to turn off all the lights without lags using the momentary switch.

void setColor(int redValue, int greenValue, int blueValue) {
  analogWrite(redRGBPin, redValue);
  analogWrite(greenRGBPin, greenValue);
  analogWrite(blueRGBPin, blueValue);
}

if (won && gameState){
  if (millis()>timer){
    timer = millis()+interval;
    i = (i+1)%5; 
  }
  if (i == 0){
    setColor(255, 0, 0); // red
  }
  else if (i==1){
    setColor(0, 255, 0); // green
  }
  else if (i==2){
    setColor(0, 0, 255); // blue
  }
  else if (i==3){
    setColor(255, 255, 255); // white
  }
  else if (i==4){
    setColor(170, 0, 255); // purple
  }
}

The game logic occurs inside the loop function, where the potentiometer value is read and compared against the number to be guessed. The potentiometer controls which LED lights up based on its value’s distance from the correct number (blue if the guess is far away from the correct answer, red if the guess is close, and green if it is correct).

if (gameState && !won){
    setColor(227,50,121); // pink     
    if (abs(pentSensorVal - randNum) == 0){ // if number is guessed correctly
      digitalWrite(greenPin, HIGH); 
      digitalWrite(bluePin, LOW);
      digitalWrite(redPin, LOW);
      won = true; 
    }
    else if (abs(pentSensorVal - randNum) < 100){ // getting warmer 
      digitalWrite(greenPin, LOW); 
      digitalWrite(bluePin, LOW);
      digitalWrite(redPin, HIGH);
    }
    else{ // you are way off
      digitalWrite(greenPin, LOW); 
      digitalWrite(bluePin, HIGH);
      digitalWrite(redPin, LOW);
    }
  }

Circuit Schematic

Here’s the schematic of the wiring of the hardware components:

Demo

Reflections and Extensions

After last week’s reading, I wanted to focus more on the creative idea than the technical complexity of the hardware components. It proved to be quite challenging to think of building something creative with the input sensors and output devices that we have been using in class. I spent a lot of time ideating and the implementation portion was not as time-consuming, especially since I made sure to diagram the schematic and outline the software logic prior to wiring the circuit and connecting the Arduino. One thing that I should have anticipated, however, is how easy the game would be due to the limited directionality of the potentiometer. If you know that your guess is not correct by dialing the potentiometer all the way to the left, for example, the answer must be found by dialing it all the way to the right. To make the game a little harder, I made the trivial modification of adding a second potentiometer. The guess is considered correct if the sum of the potentiometer readings is within 50 of the number to be guessed. I increased the “warm” range from ±100 to ±500 as it was getting extremely difficult to play the game.

sum = pentSensorVal1 + pentSensorVal2; 
if (abs(sum - randNum) < 50){
  digitalWrite(greenPin, HIGH); 
  digitalWrite(bluePin, LOW);
  digitalWrite(redPin, LOW);
  won = true; 
}
else if (abs(sum - randNum) < 500){
  digitalWrite(greenPin, LOW); 
  digitalWrite(bluePin, LOW);
  digitalWrite(redPin, HIGH);
}
else{
  digitalWrite(greenPin, LOW); 
  digitalWrite(bluePin, HIGH);
  digitalWrite(redPin, LOW);
}

Admittedly, adding a second analog sensor introduced complexity that came at the expense of interpretability. It becomes harder to strategize one’s guesses, partly due to the nature of the potentiometer values being hard to track.  Perhaps using a display, like an LCD, to reveal the current potentiometer values would be helpful.