Assignment Overview:

The goal of this task was to create a simple interactive circuit using one digital sensor (a pushbutton) and one analog sensor (an LDR) to control two LEDs on the Arduino Uno. The digital LED turns on and off when the button is pressed, while the analog LED smoothly changes brightness depending on the amount of light detected by the sensor. This task helped me understand how digital and analog inputs behave differently and how they can work together in one circuit.

My Circuit:

Planning the Schematic:

I started by sketching a schematic on my iPad on procreate to visualize how each component would connect. The schematic represents the button on pin D2, the LDR with a 330 kΩ resistor forming a voltage divider to A0, and two LEDs connected to D8 and D9, each with their own 330 Ω resistor to ground. Planning it out first helped me avoid confusion later when placing components on the breadboard and made the whole process smoother. Of course when actually going to build the board a few elements moved around but the schematic mainly shows my thought process and “map” while planning this assignment.

Building the Circuit

Next, I built the circuit on the breadboard, carefully following the schematic. I color-coded my jumper wires to stay organized: red for power, black for ground, green for digital signals, and yellow for analog. One small challenge was understanding that the breadboard’s left and right halves are not connected across the middle gap. Once I fixed that mistake, the circuit started to behave exactly as expected.

(Its kinda hard to see but when I cover the sensor the blue LED shifts in brightness, and the button turns the yellow LED on)

Coding Elements:

This Arduino code connects both a digital and an analog input to control two LEDs in different ways. The process starts with defining pin connections: the pushbutton on pin 2, the LDR sensor on analog pin A0, and two LEDs on pins 8 and 9. In the setup function, the button uses input pullup so it naturally stays HIGH until pressed (no external resistor needed). The digital LED on pin 8 simply turns on when the button is pressed and off when it’s released. The LDR, wired as part of a voltage divider, continuously sends changing light readings to A0. In the loop, these readings (ranging 0–1023) are mapped to 0–255 with the map function so they can control the brightness of the second LED through analogWrite on pin 9. The small delay at the end makes the light level changes smooth and stable. Overall, the code demonstrates how digital and analog signals can be read simultaneously to control different outputs in real time.

// Pin setup 
const int buttonPin = 2;   // Button connected to D2 
const int ledDigital = 8;  // Digital LED (on/off)
const int ledAnalog = 9;   // Analog LED (brightness control)
const int ldrPin = A0;     // LDR sensor connected to A0

void setup() {
  pinMode(buttonPin, INPUT_PULLUP); 
  pinMode(ledDigital, OUTPUT);
  pinMode(ledAnalog, OUTPUT);
}

void loop() {
  // Digital LED controlled by button 
  bool pressed = (digitalRead(buttonPin) == LOW); // LOW = pressed
  digitalWrite(ledDigital, pressed ? HIGH : LOW);

  // Analog LED controlled by LDR light level 
  int lightValue = analogRead(ldrPin);        // Reads LDR 
  int brightness = map(lightValue, 0, 1023, 0, 255); 
  analogWrite(ledAnalog, brightness);         // Set LED brightness

  delay(10); 
}

Troubleshooting and Adjustments 🙁

The most challenging part was honestly just starting this task. It was very overwhelming since I never used arduino before and had no experience in coding C++. It took me a few hours to look through videos and articles just to get a better understanding of how the board works, and I even gave myself a few warm up tasks, like a simple blink test which I will show later in this documentation. In this particular assignment, one of my main challenges was getting the circuit itself right. The first few times I tried to setup the button the led wouldn’t turn on and I felt like I had so many wires and it was hard to focus on what the problem was. To combat this, I took the time to properly think about my schematic as a map, then followed that instead of blindly building my board first then drawing my schematic after. This really helped me when I got frustrated, and I also took many breaks in between so I could come back to the task with fresh eyes.

Random Blink Test Experiment:

Before starting the full circuit, I experimented with a simple blink test using just one LED. I uploaded the basic Blink example to the Arduino IDE to see the LED turn on and off every second. This small test helped me understand how the digital pins, resistors, and ground connections actually worked together in a real circuit. Since it was my first time using Arduino, doing this warm-up made me more confident in reading pin numbers, placing components correctly, and recognizing how code controls physical outputs on the board.

Reflection 🙂

Overall, I really want to emphasize that i’m very proud of myself for this assignment. This showed me how coding and wiring work hand in hand, the schematic guided the hardware setup, and the code brought it to life. This was a rewarding first experience combining both analog and digital sensors in one interactive circuit.

Concept

I got the idea for this assignment after watching a campus cat swiftly pounce upon a tiny lizard on the wall in front of the arts center. It got me thinking about reflexes and reaction times and how I can create a mini-game out of this using Arduino. The game basically works like this:
There are two LEDs, one red and one green, one button, and one potentiometer. When the green LED turns on, the player must press the button as fast as they can. If they press it in time, the green LED flashes thrice, indicating a win, otherwise the red LED flashes, indicating the loss. If the green LED flashes, they can see their reaction time in milliseconds on the screen as well. The potentiometer controls the difficulty of the game in two ways. Firstly, it controls the random waiting period (i.e. how long the Arduino waits before turning on the green LED). A decrease in the delay between instances would need the player to be on higher alert. Secondly, it controls the reaction time threshold (i.e. how fast the player must press the button to win). At the easiest setting, the player has 400ms to react, and at the hardest, only 100ms.

Image & Video Documentation

The code

// potentiometer (A0), button (2), red LED (9), green LED (8)

const int potPin = A0;
const int buttonPin = 2;
const int greenLED = 8;
const int redLED = 9;

void setup() {
  pinMode(greenLED, OUTPUT);
  pinMode(redLED, OUTPUT);
  // use a resistor in the microcontroller instead of on the breadboard
  // causes inverted logic: not pressed - HIGH, pressed - LOW
  pinMode(buttonPin, INPUT_PULLUP); // Internal pull-up resistor
  Serial.begin(9600);
  randomSeed(analogRead(A5)); // Add some randomness
}

void loop() {
  Serial.println("Get ready");
  digitalWrite(redLED, LOW);
  digitalWrite(greenLED, LOW);
  delay(2000); // brief pause before start

  // Read difficulty from potentiometer
  int potValue = analogRead(potPin);
  int waitTime = map(potValue, 0, 1023, 1000, 3000); // 1s to 3s random wait range
  // potValue = 0 then threshold = 400 ms; 
  // potValue = 1023 then threshold = 100 ms (hard)
  int threshold = map(potValue, 0, 1023, 400, 100);  

  // Random gap time before LED turns on
  int randomDelay = random(1000, waitTime);
  delay(randomDelay);

  // Start the test
  digitalWrite(greenLED, HIGH);
  unsigned long startTime = millis();

  // Wait for button to be pressed or timeout
  bool pressed = false;
  unsigned long reactionTime = 0;

  while (millis() - startTime < 2000) {       // 2 seconds max to press button
    if (digitalRead(buttonPin) == LOW) {
      pressed = true;   // player successfully pressed the button
      reactionTime = millis() - startTime;    // calculate the player's reaction time
      break;
    }
  }

  digitalWrite(greenLED, LOW);    // turn off green LED

  if (pressed && reactionTime < threshold) {
    // Player wins
    // Display reaction time
    Serial.print("Your reaction time: ");
    Serial.println(reactionTime);

    // Flash green LED thrice to indicate win
    for (int i = 0; i < 3; i++) {
      digitalWrite(greenLED, HIGH);
      delay(150);
      digitalWrite(greenLED, LOW);
      delay(150);
    }

  } else {
    // Player loses
    Serial.println("Too slow!");
    // Flash red LED thrice to indicate loss
    for (int i = 0; i < 3; i++) {
      digitalWrite(redLED, HIGH);
      delay(200);
      digitalWrite(redLED, LOW);
      delay(200);
    }
  }

  delay(1000); // small 1s pause between game rounds
}

Reflection & Future Improvements

I had a lot of fun making this project. I think the physical setup was not too complicated, and still gave an effective output through the implemented code. In future versions, I think it would be nice to have a buzzer that gives different sounds on win/loss conditions, and maybe also implement a score counter that keeps track of how many times the player won throughout multiple rounds. I believe it would also be effective to add another LED (probably yellow) that blinks during the “get ready” phase of each round.

Tom Igoe’s “Making Interactive Art: Set the Stage, Then Shut Up and Listen” advocates for a shift in the role of the artist in interactive work: the artist must stop controlling the experience and instead facilitate a conversation with the audience. Igoe’s key argument is that interactivity only truly begins when the artist relinquishes interpretation and allows the audience to complete the piece. This concept challenges the creator’s ego and promotes a more humble, open-ended form of art. While I appreciate the insight, I find Igoe’s emphasis on “shut up and listen” a bit idealistic. In practice, many audiences need some level of guidance to fully engage with an interactive installation. Too much ambiguity can easily lead to frustration. Nonetheless, his metaphor of the artist as ‘a director—staging a conversation rather than dictating a lecture’ resonates strongly. At its core, this advice serves as a reminder that interaction requires mutual respect: artists must listen as much as they create.

In “Physical Computing’s Greatest Hits (and Misses),” Igoe reflects on recurring projects in interactive art, such as theremins, drum gloves, and video mirrors, and contemplates why they keep resurfacing in new forms. He doesn’t dismiss these repetitive ideas; rather, he sees their evolution as evidence of growing refinement and deeper understanding. Igoe suggests that repetition is a form of progress, not stagnation. In physical computing, each reimagining of a “classic” project offers new possibilities, whether it’s smarter sensors, more intuitive designs, or deeper contextual relevance. Igoe also rejects the notion that novelty for its own sake is the ultimate goal, calling attention to the often-overlooked value in revisiting older concepts. This stance challenges the modern fixation on innovation for innovation’s sake, emphasizing that novelty must be paired with genuine engagement and a willingness to learn from the past, not just chase aesthetics or trends.

Synthetically, both essays stress the importance of humility in interactive art. Whether talking about listening to the audience or refining established ideas, Igoe places the artist’s role not in the creation of definitive, controlled experiences but in the facilitation of dialogue and discovery. The act of interacting with art, according to Igoe, is an ongoing process that requires responsiveness and openness. The artist’s task is to create the conditions that encourage curiosity, rather than rigidly scripting the conversation. In the end, good interactive art is about paying attention to what the interaction itself reveals and adjusting accordingly, facilitating a space where discovery is as important as design.

Physical Computing’s Greatest Hits (and misses)

The article highlights that originality doesn’t always mean creating something entirely new from scratch. Many people shy away from existing physical computing ideas because they think someone else has already done them, but that’s not the point. What matters is how we, as artists and engineers, can bring our own perspective, creativity, and purpose to these ideas. The author emphasises that real creativity lies in reimagining how people interact with technology in expressive and human centred ways.