Category: F2025 – Aya

Concept

For this week’s assignment, my overall concept is pretty similar to the one I did last week because it also has something to do with sleep. This time, I created a light system: for the first one, I used a button to turn on a single LED manually, and for the second one, the yellow LED turns on when the lights are turned off, just like a night light! I got inspiration for this idea from my little sister when we were kids, because she always used to sleep with a night light on.

Code

int buttonPin = 8;
int greenLED = 7;  // pin for green LED
int lightSensorPin = A2;
int yellowLED = 6;  // pin for yellow LED

void setup() {
  Serial.begin(9600);
  pinMode(buttonPin, INPUT_PULLUP);  
  pinMode(greenLED, OUTPUT);
  pinMode(yellowLED, OUTPUT);
}

void loop() {
  int sensorValue = analogRead(lightSensorPin);
  Serial.println(sensorValue);  // prints sensor value from light sensor

  if (digitalRead(buttonPin) == LOW) {  // button pressed
    digitalWrite(greenLED, HIGH);
  } else {
    digitalWrite(greenLED, LOW);
  }

  if (sensorValue < 175) {
    digitalWrite(yellowLED, HIGH);
  } else {
    digitalWrite(yellowLED, LOW);
  }
}

So basically, I used conditional statements for when I wanted each LED to turn on. The green LED was connected to the digital pins, so I used a button to turn it on and off: when the button is pressed, the LED lights up, and when it’s not pressed, the LED turns off. For the yellow LED, it checks the light sensor’s value, and when that value goes below 175, the LED turns on (so when the lights are off, the yellow LED acts as a night light!).

Hand-Drawn Schematic

Schematic diagram and Photo:

Video Demo

Reflection and Future Improvements

Honestly, it was pretty hard to come up with a concept for this project, but when I did, I’m satisfied with how it turned out. Another thing was that I underestimated how much time this would take, it took me way too long to figure everything out and fix the issues on the circuit. In the future, I plan on practicing wiring more often and getting a better understanding of circuit logic.

Reading Tom Igoe’s Physical Computing’s Greatest Hits (and Misses) made me think about how creative patterns tend to repeat, especially in hands-on, tech-driven projects. Igoe doesn’t frame repetition as a lack of originality, which I appreciated. Instead, he treats these recurring themes—like theremin-like instruments, drum gloves, or video mirrors—as open-ended ideas that people keep revisiting because they’re fun, expressive, and adaptable. I related to that idea a lot because I’ve definitely hesitated before, thinking something wasn’t worth doing since it had “been done before.” But the more I read, the more I agreed with his point that originality isn’t about inventing from scratch; it’s about finding your own way into an existing form. What stood out to me were the projects that relied on the body as the main input—like gloves that create rhythm through tapping or instruments that react to gestures. Those projects feel personal and direct, and I like how they blend instinct with technology. Igoe’s descriptions made me realize that the best physical computing ideas don’t just respond to touch or movement; they build a relationship with the person using them.

Some parts of the reading also made me laugh or nod along because I’ve seen those same trends pop up in classes or exhibits. The “video mirrors,” for instance, are always visually striking but usually shallow in interaction—you wave, something moves, and that’s it. Igoe’s critique there made sense. It reminded me that while technology can catch attention, meaning comes from how people connect to it, not just how it looks. I was also drawn to the more poetic examples like “Mechanical Pixels” or “Fields of Grass,” where simple mechanisms create quiet, almost meditative experiences. Those pieces blur the line between machine and nature, which I find really compelling. Even the sillier categories, like “Things You Yell At,” showed how emotional interaction can be when it’s physical and immediate. Overall, the article made me think about how I might approach projects differently: not trying to avoid what’s been done, but trying to make it feel a bit more like me.

Concept

Parking lots can often be a frustrating experience, especially when it’s hard to tell whether a spot is free or occupied without driving around aimlessly. I wanted to create a simple, interactive system using Arduino that mimics real-world parking indicators: a yellow light that changes brightness when a car is moving in or out, and a red light that turns on when a spot is occupied. This way, drivers can quickly see which spots are available and which are taken, making the parking process smoother and more intuitive.

Implementation

To achieve this, I used an ultrasonic sensor to detect the movement of cars. The sensor works by sending out a pulse from the trigger pin, which bounces off an object and returns to the echo pin. The Arduino then calculates the distance based on the time it takes for the pulse to return. I mapped this distance to the brightness of a yellow LED, so that the closer a car gets to the parking spot, the brighter the yellow light becomes. A slide switch allows us to manually indicate when a car is parked: flipping the switch turns on a red LED and turns off the yellow light, clearly showing that the spot is occupied. Two 330-ohm resistors ensure the LEDs operate safely without drawing too much current.

cardemo

Code I’m proud of

// Trigger pulse 
digitalWrite(trigPin, LOW);
delayMicroseconds(2);
digitalWrite(trigPin, HIGH);
delayMicroseconds(10);digitalWrite(trigPin, LOW);

// Read echo
duration = pulseIn(echoPin, HIGH);
distance = duration * 0.0343 / 2.0;

I’m particularly proud of the code I wrote for this project. Writing it taught me a lot about how ultrasonic sensors work and how to use the trigger and echo functionality effectively.

Future Developments

For future development, the system could be expanded to include a green LED, which would light up to indicate available parking spots. In that scenario, the green light would show availability, the yellow LED would indicate movement, and the red LED would signal when a spot is taken. Eventually, this could be automated further so that the sensor alone detects whether a car is parked, eliminating the need for the manual switch. Overall, this project was a great exercise in combining sensors, outputs, and user interaction to create a functional and visually intuitive system.

Idea:

Since the problem is to create two types of control, I already created a switch using the idea to use photoresistor to control the circuit. I will just apply the other switch with basic switching on/off control.

Schematic:

It is a simple schematic, where I use A0 to read the LDR values and then programmed so that it affect how the built-in LED(D13) changes accordingly.

Then I use D2 to read the switch status and change how the LED light would perform(D9).

Code:

if (value <= lightThreshold) {
    digitalWrite(ledPin, HIGH);   // Dark → LED ON
  } else {
    digitalWrite(ledPin, LOW);    // Bright → LED OFF
  }

This is the part of the code where I control the light based on the A0 values.

if (reading != lastButtonState) {
    lastDebounceTime = millis(); // reset timer if state changed
  }

  if ((millis() - lastDebounceTime) > debounceDelay) {
    // If the button is pressed (LOW because of INPUT_PULLUP)
    if (reading == LOW && lastButtonState == HIGH) {
      // Toggle LED state
      ledState = !ledState;
    }
  }

This i the part of the code that I apply to change the LED light status.

The lightThreshold value is determined by experimenting and printing out the A0 value when cover/uncover the LDR.

Serial.print("Light level: ");
Serial.println(value);

Reflection:

I still need more practice on connecting the board as I am not familiar with how to design the board to make the wiring more clean and beautiful. I also could come up with more creative idea on how to control the LED.

Idea:

Since the problem is prompted to create a switch that should use the human body (but not the hands), I instantly come up with the idea to use photoresistor to control the circuit. As photoresistor reacts to the light intensity, basically you could use any body part to control the system as long as it cover/uncover the photoresistor.

Schematic:

It is a simple schematic, where I use A0 to read the LDR values and then programmed so that it affect how the built-in LED(D13) changes accordingly.

Code:

if (value <= lightThreshold) {
    digitalWrite(ledPin, HIGH);   // Dark → LED ON
  } else {
    digitalWrite(ledPin, LOW);    // Bright → LED OFF
  }

This is the part of the code where I control the light based on the A0 values.

The lightThreshold value is determined by experimenting and printing out the A0 value when cover/uncover the LDR.

Serial.print("Light level: ");
Serial.println(value);

Reflection:

It took me longer than expected to complete this as I am not familiar enough with working with the board. Nonetheless, it is a fun experience experimenting with both the hardware and the software at the same time. Future improvements would center around controlling other than built-in LEDs and improving the circuit design.

Physical Computing’s Greatest hits and misses

This blog lists a number of interesting ways of interacting with the art piece. It reminds me part of the reading from previous weeks that try to re-define what is an interactivity for a designed system. From that perspective, these designs provide us with idea to interact other than the usual input(computer text input). Other body components such as hands, eyes, or even our entire bodies are powerful enough tool to provide information that alter the system output. Also, the response from the system or the output from the system could also be varied. From this blog, I seen response including forms of sound, image, and combination of both.

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

This blog suggests interactive art artists to let audience dictate the interactive experience. I partially agree. First, I agree that there should be hinted guidance from the art that guides the audience to interact with the device. However, I do not agree that artists should be completely silent in the process. If audiences are not careful enough and they just miss some of the hint, there should be message from either the device or the artist that guides the audience back to the track to the intended interactive experience. A careful or well-designed system should indeed be very informative themselves but for complex enough system, visual hints themselves are not informative enough to guide the correct experience.

Norman,“Emotion & Design: Attractive things work better”

The reading provide us with a new perspective on aesthetics design: rather than solely serving a “beauty” function, it improves people’s attention span, positive emotions when interacting with the design, which might end up in improving the problem solving of the product/design. I highly agree with this perspective. For example, when computers were first invented, they dominated with command-line control interface which prevents the majority from using this advanced-system. However, later on, designers of Apple and Microsoft realized this problem and design separately two systems that are heavy with image interfaces. Today, all systems inherit that idea and people today interact heavily with these more well-designed systems.

Her Code Got Humans on the Moon

Other than impressed by the great works done by Margaret Hamilton and her strong spirit that overcomes all the adversaries, I am particular interested in anecdote of the reading where Hamilton proposed that there might be error in the program when preloading P01, her leaders refuse to add error-checking within the software. Though the astronauts are the most well-trained, they still trigger the error during the real mission. This story reminds me the importance of error-preventing programs. Even though something might seem stupid when people first develop them, people might really end up in this “stupid” situation. Luckily, during this mission, the problem is resolved. However, there are numerous examples in history related to how a minor computer error lead to billions of losses.

,

In “Making Interactive Art: Set the Stage, Then Shut Up and Listen”,  the author emphasizes the importance of not defining an interactive work, since unlike a traditional art piece, an interactive piece is not just an expression but a medium that will inevitably be interpreted differently by the users. I found myself agreeing with this statement, especially since it does apply to traditional art in some cases as well. There is something exciting about being the viewer or the user, and being able to not only produce our own interpretations of a creative piece, but also being able to engage with it, whether it is through a computer program or something tangible. It also reminds me of when I write creative stories; sometimes it is better to leave certain details unsaid rather than reveal everything about a setting or a character, as readers often enjoy filling in those gaps with their imagination. Ultimately, like any creative work, I agree with the author that an interactive piece can resemble a performance more than a finished painting or sculpture, allowing something beautiful and engaging to emerge. 

Similarly, in “Physical Computing’s Greatest Hits (and Misses)”, I found it interesting how the author notes that when people learning about physical computing realize a particular ideas has been done before, they often give up on it because they believe it’s not worth it since it is no longer original. My first thought was that this happens in art and writing as well. When a writer wants to explore a familiar theme, like reincarnation, they might hesitate because it has been done many times before. Before reading this text, I hadn’t realized that the struggle for originality and authenticity is just as applicable in physical computing as it is in other creative or noncreative fields. Now I feel like I share much more in common with this field than I initially imagined. 

Concept:

For my project, I wanted to create a system that could control multiple LEDs in both a digital and an analog fashion, and I drew inspiration from traffic lights. Instead of just two LEDs, I decided to use three LEDs to mimic a simplified traffic light sequence. When the push button is pressed, the system cycles through the lights in order: red → yellow → green, which demonstrates digital control, as each LED turns fully on or off with each button press.

For the analog aspect, I incorporated a potentiometer connected to an analog input pin on the Arduino. By adjusting the potentiometer, users can control the brightness of the LEDs, allowing for smooth, variable light intensity. Together, the push button and potentiometer create an interactive system: pressing the button cycles through the traffic light colors, while turning the potentiometer adjusts their brightness. This combination not only makes the project functional and educational but also connects to the familiar real-world concept of traffic lights.

Arduino Setup and Demonstration: 

Setup

Arduino video

Hand-drawn schematic

Coding:

Arduino File on Github

// Pins
const int POTENTIOMETER_PIN = A0; // Analog input pin for potentiometer
const int BUTTON_PIN = 2; // Digital input pin for push button
const int RED = 5;  // Digital output pin for RGB LED (red)
const int GREEN = 6;  // Digital output pin for RGB LED (green)
const int YELLOW = 9; // Digital output pin for RGB LED (yellow)

// Variables
int potentiometerValue = 0; // Potentiometer value
bool buttonState = false; // Button state
int colorIndex = 0; // Index of current color

void setup() {
  pinMode(POTENTIOMETER_PIN, INPUT);
  pinMode(BUTTON_PIN, INPUT_PULLUP);
  pinMode(RED, OUTPUT);
  pinMode(GREEN, OUTPUT);
  pinMode(YELLOW, OUTPUT);
}

void loop() {
  potentiometerValue = analogRead(POTENTIOMETER_PIN);
  
  // Map potentiometer value to LED brightness
  int brightness = map(potentiometerValue, 0, 1023, 0, 255);
  
  // Set the LED color based on the current color index
  switch (colorIndex) {
    case 0:  // Red
      analogWrite(RED, brightness);
      analogWrite(GREEN, 0);
      analogWrite(YELLOW, 0);
      break;
    case 1:  // Green
      analogWrite(RED, 0);
      analogWrite(GREEN, brightness);
      analogWrite(YELLOW, 0);
      break;
    case 2:  // Yellow
      analogWrite(RED, 0);
      analogWrite(GREEN, 0);
      analogWrite(YELLOW, brightness);
      break;
  }

  // Check button state
  if (digitalRead(BUTTON_PIN) == LOW) {
    if (!buttonState) {
      // Toggle color index
      colorIndex = (colorIndex + 1) % 3;
      buttonState = true;
      delay(200);
    }
  } else {
    buttonState = false;
  }
}

Physical Computing’s Greatest Hits (and misses)

I agree with Igoe’s idea of recurring “hits and misses,” but I don’t think a project has to be deeply meaningful to count as a hit. Sometimes, a piece can still be successful if it’s creative, interesting, or just fun to interact with. I also think context plays a role in making something feel meaningful, especially through how users receive feedback. For example, the Monsters Inc. scream canisters in Disneyland Paris come to mind. As a kid, I loved screaming into them and watching the energy bar go up to the top, it’s a perfect example of feedback making the interaction more memorable.

I used to get hesitant about working on projects that weren’t completely original, feeling like I needed to come up with something new. But Igoe’s words reminded me that even if an idea’s been done before, I can still make it mine by adding my own personal touch.

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

I found Igoe’s idea of “setting the stage and shutting up” really interesting because it shows just how much power interpretation has in interactive art. When artists or designers immediately tell their audience what something means, it limits how people can experience it. I think there’s this sort of psychological effect that once you’re told what something is, it’s hard to see it in any other way. So I think it’s more effective to let users come to their own conclusions, even if it means they interpret the project differently from what was intended.

While making my own projects, I understand how my project works but users might not. By actually watching and hearing how they interact with it, I can figure out what’s confusing or what needs improvement. Feedback like that helps me refine my designs to make them more intuitive and engaging.