Category: S2025 – Mang

Physical Computing’s Greatest hits and misses

Reading this text really made me think differently about what it means to design interfaces, especially ones that don’t rely on screens or traditional controls. The idea that your own hands can act as a cursor, like in the Atlas Gloves project, really struck me. It’s such a nice twist on a familiar interaction we use on a daily basis, and it made me realize that innovation can come from reimagining how we use our bodies every day to communicate with technology. Oftentimes, innovation is synonymous to me with inventing entirely new tools, but this showed me that you can use simple materials like a couple of LEDs, gloves, and a webcam and still end up with something cool and interactive.

What also stood out to me was how these projects prioritize experience and embodiment. The Atlas Gloves weren’t just a technical experiment, but rather about movement, spatial awareness, and making the virtual world feel physically accessible. That made me realize that physical computing is as much about how people feel when they use something as it is about how it works. Whether it’s navigating Google Earth with a wave of your hand or playing a theremin-style instrument with motion, there’s a strong emotional and sensory layer involved. That really inspired me to think about my own projects in this class not just as tools or tasks, but as ways to spark connection and curiosity in the people who use them. As a side note, it also really reminded me of kinect sensors on Xbox where you can bowl by doing the motion of bowling or play table tennis my pretending to hold a paddle and smacking.

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

Reading Tom Igoe’s article “Making Interactive Art: Set the Stage, Then Shut Up and Listen” made me reconsider the role of an artist in interactive installations. I used to believe that providing detailed explanations would help audiences connect with my work, but Igoe suggests that over-explaining can limit personal interpretation. He emphasizes creating a context that encourages participants to explore and derive their own meanings, comparing this approach to a director guiding actors without dictating their every move. This perspective highlights the importance of designing experiences that invite engagement and allow for a range of responses, which makes me reflect on how I can craft environments that speak for themselves and foster genuine interaction. It’s also a true testament to how self-explanatory what you create is for people. Like our midterm projects or assignments, we often have to direct our classmates on how to use the controls because we didn’t make it completely obvious. It’s easy to forget that not everyone knows how it was made and how it is supposed to work. Seeing how others try to make it work and whether they get it right rather than explaining makes the interaction much better.

Google Drive Link: https://drive.google.com/file/d/1_hd31ynpr4AzkeD99QR3nakPaNJlEiRF/view?usp=sharing

My idea for this assignment was to have a light that would automatically turn on when it was dark in the room while the other light could be manually turned on. Kind of like a smart light vs a regular light switch light. To do this is use the photoresistor to get the values of the brightness in the room and coded the arduino such that under a certain threshold, the light would automatically turn on.

The circuit diagram looked like this:

The code for it can be seen here:

const int LED_PIN = 9;
const int LIGHT_THRESHOLD = 500;
// the setup routine runs once when you press reset:
void setup() {
  // initialize serial communication at 9600 bits per second:
  pinMode(LED_PIN, OUTPUT);
  Serial.begin(9600);
}

// the loop routine runs over and over again forever:
void loop() {
  // read the input on analog pin
  int sensorValue = analogRead(A2);
  // print out the value you read:
  Serial.println(sensorValue);
  delay(1);  // delay in between reads for stability
  if (sensorValue < LIGHT_THRESHOLD) { //codes the light to turn on when brightness is low
    digitalWrite(LED_PIN, HIGH);
  } else {
    digitalWrite(LED_PIN, LOW);
  }
  delay(100);
}

Overall, it wasn’t too difficult. I just struggled a bit with getting the wires in the correct places and accidentally blew a light because the resistor wasn’t plugged in all the way. It’s tricky dealing with so many wires on the board, I wish it could look more streamlined.

 

Concept:

For my Arduino Sensor LED Control, I wanted to combine analog and digital inputs in a single interactive system. A potentiometer (analog) not only drives the brightness of one LED but also “unlocks” a digital LED toggle. Only when the potentiometer is turned into a specific window (300–700) does pressing the pushbutton flip the digital LED on or off. To make the fade more dramatic, the potentiometer value is squared before mapping to PWM, so small turns near the high end feel much brighter.

Setup:

• Potentiometer: Reads an analog value (0–1023) on pin A0. Its value controls the analog LED’s brightness and gates the button’s functionality.
• Pushbutton: Connected to pin 2 with a pull-down resistor. When pressed, it toggles the digital LED only if the potentiometer value is between 300 and 700.
• Digital LED: On pin 10, turns on or off based on the button toggle (when enabled by the potentiometer).
• Analog LED: On PWM pin 9, its brightness is set by a squared mapping of the potentiometer value, creating a non-linear fade effect (brighter at higher values).

Creative Element: The requirement for the potentiometer to be in a specific range to enable the button adds an interactive challenge, making the system feel like a “lock” that must be “unlocked” by dialing in the right potentiometer position.

Arduino Code:

const int potPin = A0;        // Potentiometer analog input
const int buttonPin = 2;      // Pushbutton digital input
const int digitalLedPin = 10;  // Digital LED output
const int analogLedPin = 9;  // Analog LED (PWM) output

int buttonState = 0;          // Current button state
int lastButtonState = 0;      // Previous button state
bool ledState = false;        // Digital LED state (on/off)

void setup() {
  pinMode(buttonPin, INPUT);
  pinMode(digitalLedPin, OUTPUT);
  pinMode(analogLedPin, OUTPUT);
}

void loop() {
  // Read sensors
  int potValue = analogRead(potPin);  // 0–1023
  buttonState = digitalRead(buttonPin);

  // Control digital LED
  if (buttonState == HIGH && lastButtonState == LOW) {
    // Button pressed, check if potValue is in range (300–700)
    if (potValue >= 300 && potValue <= 700) {
      ledState = !ledState;  // Toggle LED state
      digitalWrite(digitalLedPin, ledState ? HIGH : LOW);
    }
  }
  lastButtonState = buttonState;  // Update button state

  // Control analog LED (non-linear brightness)
  float normalized = potValue / 1023.0;  // Normalize to 0–1
  int brightness = 255 * (normalized * normalized);  // Square for non-linear effect
  analogWrite(analogLedPin, brightness);
}

Schematic:

Demo:

Challenges

• Range calibration: Finding the sweet-spot (300–700) took a few tests—too narrow and the button felt unresponsive; too wide and the “lock” felt trivial.

• Button bounce: Without debouncing, sometimes a single press registered multiple toggles. I ended up adding a small delay in code to ignore rapid changes.

• Non-linear fade tweaking: The square mapping made lower values almost invisible. I had to play with exponent and mapping constants so the fade curve felt smooth.

 

Reading 1

Reading Tom Igoe’s blog post on the “greatest hits (and misses)” of physical computing really made me reflect on how approachable and endlessly creative this field can be. As someone who’s still growing my understanding of interactive technology, I found his message super reassuring, especially the idea that it’s okay to revisit classic project ideas like light-sensitive instruments or pressure-sensitive floors. Instead of feeling like I’m copying someone else’s work, Igoe made me realize that there’s value in reinterpreting those familiar ideas in new, personal ways. It reminded me that creativity isn’t always about inventing something completely new—it’s also about seeing old ideas through a different lens.

Igoe’s emphasis on how machines don’t understand intention—only action- was what caught my attention the most. It got me thinking about how important it is to really consider how people will interact with what I make. It’s not just about the cool factor of the tech; it’s about how people feel when they use it. Igoe’s point about designing systems that are intuitive and human-centered stuck with me. It encouraged me to start paying more attention to how people move, gesture, and react in everyday life—because that’s where meaningful interaction begins.

Reading 2

In “Making Interactive Art: Set the Stage, Then Shut Up and Listen,” Tom Igoe presents a thoughtful perspective on the role of the artist in interactive work. He emphasizes that the artist’s job is to create an environment that invites engagement, not to dictate how people should respond. This idea stood out because it shifts the focus from controlling the audience’s experience to trusting them to find their own way through the piece. Igoe’s comparison to theater directing, where the director sets the scene but lets the actors interpret it, captures this idea well. It reminded me that successful interaction often comes from subtle suggestions, not detailed instructions.

What I found especially valuable was Igoe’s insistence on listening, observing how people interact with a piece instead of trying to steer them. It’s a reminder that interactive art is a two-way conversation, and part of the creative process is stepping back and allowing space for surprise and interpretation. This approach encourages more open-ended, personal experiences for the audience.

Concept

Link:  https://drive.google.com/file/d/1iGY1zePkL1vzLj20TXHqm8l7hkp8WpBZ/view?usp=sharing

For this assignment, I made a circuit that mimics the performance of solar-powered garden lights. The LED automatically turns on when the environment is dark and off when the environment is bright. I used a photoresistor  to sense the light around the environment and included a button for manual control, controlling the LED when the environment is dark. The LED automatically turns on when the light is low. If the button is pressed during darkness, the LED turns off but with a brief delay before turning on again. When there is enough ambient light, the LED turns off automatically.

Code Highlight (Arduino Code)

const int LED_PIN = 9;             // LED that turns on in dark, or with button
const int LIGHT_SENSOR_PIN = A2;   // Light sensor (photoresistor)
const int BUTTON_PIN = A3;         // Button input (wired to GND)


const int LIGHT_THRESHOLD = 600;   // Adjust based on your light conditions


void setup() {
  pinMode(LED_PIN, OUTPUT);
  pinMode(BUTTON_PIN, INPUT_PULLUP); // Use internal pull-up resistor
  Serial.begin(9600); // Optional: monitor values for debugging
}


void loop() {
  int light_value = analogRead(LIGHT_SENSOR_PIN);
  int button_state = digitalRead(BUTTON_PIN);


  Serial.print("Light: ");
  Serial.print(light_value);
  Serial.print(" | Button: ");
  Serial.println(button_state);


  if (light_value < LIGHT_THRESHOLD) {
    // DARK: turn LED ON automatically
    digitalWrite(LED_PIN, HIGH);
  } else {
    // BRIGHT: turn LED ON only if button is PRESSED (LOW)
    if (button_state == LOW) {
      digitalWrite(LED_PIN, HIGH);
    } else {
      digitalWrite(LED_PIN, LOW);
    }
  }


  delay(100); // Short delay to reduce flicker and serial flooding
}

The code reads the amount of light from a sensor and controls an LED based on that. When it’s dark, the LED turns on automatically. When it’s bright, the LED turns off, but if the button is pressed, the LED will turn on even in the light. The button works like a manual override. There’s a small delay in the code to avoid flickering, and the system checks the light level regularly to adjust the LED accordingly.

 

Challenges

I faced several issues while working on this project. First, it was confusing to make the photoresistor function properly, especially to understand how to make the LED respond to light and darkness. I also struggled to set the correct light threshold so that the LED would turn on at the right time. Plugging in the photoresistor correctly was challenging, and I had to figure out how to use a voltage divider. When I added the button, it didn’t work at first because I didn’t know how to connect it through the internal pull-up resistor. I also had trouble coding to make the LED turn on automatically when it’s dark and just the button when light. It was a lot of trial and error to make everything work the way I desired.

 

Physical Computing’s Greatest Hits(and misses):

I am particularly interested in theremin-like instruments, gloves, and video mirrors. I believe that these three examples of physical compute (in harmony and implemented altogether) have the potential to change the representation of the lived physical world. To extend these concepts, I thought of methods of taking input from the environment. These could be the sounds of birds, wind, the temperature, the perceived luminosity of the sun (at the place of input), as well as small movements (either from the wind or sound). Combining these inputs together and processing them, an algorithm can generate certain sounds. This music then comes together with video mirroring and processing, where the composed music dictates a new perception of the scenery / place of physical compute. I found value in the limitations explained in this reading, as the meaning attributed to the actions performed by physical compute and the method of input is key towards making a truly interactive and valuable physical compute experience. To address those, if I were to use the previous example I would think of a way (through testing) by seeing how people received the experience, and how to fine tune it. Things within this line are intuitive experience (ease of use), meaning from interaction, and ability to interact for a sufficient amount of time whilst maintaining meaningful interaction.

 

 

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

 

This reading builds on ‘Physical Computing’s Greatest Hits (and misses)’ by explaining the intricacies of limitations in the design of interactive art. The concept of intuition in interaction is therefore represented as the ability of a person to understand and find meaning in the interaction with the artwork. I found the organization and flow of this reading very helpful because it helped re-iterate and solidify the concepts of listening (by both the artist and the audience) and the statement made by the artist. The statement (as I understand it) is not a standalone expression, but rather an interactive conversation, that aims to have a meaningful exchange of actions and expressions by both the artist and his/her art and the audience.

 

For this project, I decided to use a photoresistor to create a light that detects a light source nearby.

To implement this, I used two circuits; one connected to 5V power supply and another connected to the analog pins, whose power level could be controlled by the analogWrite on IDE. The circuit was not too complicated, connect a manual toggle switch to one side of the circuit, leading into a photoresistor connected to pin A2, leading into the first LED. This would mean the first LED would only light up if  the switch was toggled on. This meant that we could see an indicator if the device is working. Next, connected to pin 8 the other LED was connected. This meant that we can control this LED digitally with the arduino. In the circuit, we could use the input we got from A2 to determine if power should be sent to pin 8.

IMG_8238

int analogPin = A2;
int lightSensor;
int brightness;
void setup() {
  // put your setup code here, to run once:
pinMode(8, OUTPUT);
pinMode(A2, INPUT);
brightness = 128;

}

void loop() {
  // put your main code here, to run repeatedly:
lightSensor = analogRead(analogPin);
if(lightSensor > 500){
analogWrite(8, 1000);
} else {
analogWrite(8, 0);
}
}

The challenges were that it took a long time to make sure the code and the circuit were both correct. One being correct while the other being wrong would mean the whole thing would not work. Hence, in my making process, I took time testing the two parts individually. Initally there was some confusion on my end pertaining to the difference between analog and digital writing, as using the wrong one meant my LEDs were not lighting up.

This project could definitely be made more complex. I think adding a variety of lights and changing the different thresholds to which each individual LED would light up is a good way to make this project more useful.

For this assignment I started by connecting one push-switch to one LED, and I used that as the basis of my draft schematic and work. I then re-drew my schematic and included the photoresistor (LDR) sensor. Here I faced challenges in both the hardware and software, specifically within the timing of the code. Initially, the light would stay on for too long, and I rechecked the timing of my Arduino code and adjusted it to be in a shorter high (on) state.

 

const int ldrPin = A2;              // LDR connected to analog pin A0
const int buttonPin = 2;            // Push button connected to digital pin 2
const int ledAnalogPin = 10;         // PWM LED pin
const int ledDigitalPin = 11;       // On/off LED pin

void setup() {
  pinMode(buttonPin, INPUT);
  pinMode(ledAnalogPin, OUTPUT);
  pinMode(ledDigitalPin, OUTPUT);
  Serial.begin(9600);
}

void loop() {
  int ldrValue = analogRead(ldrPin);        
  int brightness = map(ldrValue, 0, 1023, 255, 0);  // This adjusts the brightness

  analogWrite(ledAnalogPin, brightness);

  int buttonState = digitalRead(buttonPin);

  if (buttonState == HIGH) {
    digitalWrite(ledDigitalPin, HIGH);
  } else {
    digitalWrite(ledDigitalPin, LOW);
  }

  delay(100);
}

For the schematic I followed the fritz schematics format:

 

 

 

Video Demonstration:

https://drive.google.com/file/d/1kAYD6v6C86fbftmEfKM37j6jtumxzql1/view?usp=sharing

 

Some challenges I would still like to overcome and solve better are the output of the LED from the photoresistor (LDR) sensor, as I wanted the output to be stronger. I will address these issues by having a closer adherence to the schematic and a better methodology of implementing the changes to the circuit (thinking of what would happen if I added a certain connection or made a specific change before making that change).

 

For this week’s assignment, we were tasked with building a project that controls at least one LED using a digital sensor and another using an analog sensor. Inspired by the iconic flashing lights of police sirens, I created a setup where two LEDs alternate in a flashing pattern, mimicking the red and blue lights with a twist, you can control the flashing speed in real-time.

Video link :
https://drive.google.com/drive/folders/162WwnI-EoY3XR8ZpefkEw1aVkdSKWeLl?usp=drive_link

Components used :

– Arduino Uno
– Push Button (Digital Sensor)
– Potentiometer (Analog Sensor)
– Red LED
– Blue LED
– 2 330Ω Resistors
– Breadboard & Jumper Wires

How it Works:

The system is activated with a push button, which acts as the digital trigger. Once pressed, the LEDs begin their alternating flashing sequence, simulating the back-and-forth of police siren lights.

The potentiometer controls the speed of the siren lights. Its analog value is read and mapped using the map() function to determine the timing of the red LED’s fade cycle. The red LED smoothly fades in and out using analogWrite(), and the duration of this full cycle is used to time the LED transitions.

When the red LED finishes fading out, the blue LED turns on and remains lit for the same duration that the red LED is off. As soon as the red LED begins its next fade-in cycle, the blue LED turns off. This creates a continuous alternating pattern between red and blue LEDs, closely resembling the flashing of police lights.

One of the main challenges I faced was ensuring that the blue LED only turns on when the red LED is completely off. Initially, the timings between the LEDs were slightly off, which caused both LEDs to overlap or leave gaps between transitions.

Perfecting the fade timing and ensuring the blue LED’s on-time was synced precisely with the red LED’s off-time took some fine-tuning. I had to carefully balance the delays and the mapped potentiometer values to make the flashing appear smooth and consistent, without any flicker or overlap.

// Pin definitions
const int POT_PIN = A2;      // Potentiometer connected to A2
const int BUTTON_PIN = 2;    // Push button connected to D2
const int RED_LED_PIN = 9;   // Red LED connected to D9 
const int BLUE_LED_PIN = 10; // Blue LED connected to D10

// Variables
int potValue = 0;            
bool buttonState = false;    
bool lastButtonState = false; 
bool systemActive = false;   

// Red LED fading variables
unsigned long fadeStartTime = 0;
int fadeDuration = 2000;     // Default fade duration (in ms)
int currentBrightness = 0;   // Current red LED brightness
enum FadeState { FADE_IN, FADE_OUT, GAP, IDLE };
FadeState fadeState = IDLE;

void setup() {
  // Initialize pins
  pinMode(BUTTON_PIN, INPUT_PULLUP);
  pinMode(RED_LED_PIN, OUTPUT);
  pinMode(BLUE_LED_PIN, OUTPUT);
  
  // Start with all LEDs off
  digitalWrite(BLUE_LED_PIN, LOW);
  analogWrite(RED_LED_PIN, 0);
}

void loop() {
  // Read potentiometer and map to fade duration (100ms to 5000ms)
  potValue = analogRead(POT_PIN);
  fadeDuration = map(potValue, 0, 1023, 100, 5000);

  buttonState = digitalRead(BUTTON_PIN);
  
  if (buttonState == LOW && lastButtonState == HIGH) {
    // Toggle system on/off
    systemActive = !systemActive;
    
    if (systemActive) {
      // Start the cycle
      fadeState = FADE_IN;
      fadeStartTime = millis();
    } else {
      // Turn everything off
      fadeState = IDLE;
      digitalWrite(BLUE_LED_PIN, LOW);
      analogWrite(RED_LED_PIN, 0);
    }
    delay(50); // Debounce delay
  }
  lastButtonState = buttonState;

  // Only process fading if system is active
  if (systemActive) {
    unsigned long currentTime = millis();
    unsigned long elapsedTime = currentTime - fadeStartTime;
    
    switch (fadeState) {
      case FADE_IN:
        currentBrightness = map(elapsedTime, 0, fadeDuration, 0, 255);
        digitalWrite(BLUE_LED_PIN, LOW); // Blue off during fade
        
        if (elapsedTime >= fadeDuration) {
          fadeState = FADE_OUT;
          fadeStartTime = currentTime;
        }
        break;
        
      case FADE_OUT:
        currentBrightness = map(elapsedTime, 0, fadeDuration, 255, 0);
        digitalWrite(BLUE_LED_PIN, LOW); // Blue off during fade
        
        if (elapsedTime >= fadeDuration) {
          fadeState = GAP;
          fadeStartTime = currentTime;
          digitalWrite(BLUE_LED_PIN, HIGH); // Blue on during gap
        }
        break;
        
      case GAP:
        currentBrightness = 0;
        
        if (elapsedTime >= fadeDuration) {
          fadeState = FADE_IN;
          fadeStartTime = currentTime;
          digitalWrite(BLUE_LED_PIN, LOW); // Blue off when fade starts
        }
        break;
        
      case IDLE:
        // Do nothing
        break;
    }
    
    // Update red LED brightness
    analogWrite(RED_LED_PIN, currentBrightness);
  }
  
  delay(10);
}

 

In the end, it all helped me better understand PWM control, timing logic, and how to coordinate multiple components using both analog and digital inputs on the Arduino.

Physical Computing’s Greatest hits and misses

This article provides an intriguing perspective on consistent themes and what are some aspects needed to understand what is physical computing. The conversation about theremin-like devices as popular starter projects, highlighted by their ease of use with photocells or distance sensors, is logical, just as the description of glove-related initiatives like Megatap 3000, which are captivating because of their link to daily tasks. From the reading, I noticed that there exists a favorable bias toward initiatives that promote significant physical involvement and creativity, illustrated by the criticism of “hand-waving” interfaces compared to the commendation for more organized interactions such as drum gloves. The reading didn’t explicitly alter my beliefs, but it offered a more defined structure for examining prevalent patterns and design issues in interactive systems.

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

Tom Igoe’s discussion on interactive art show that creators ought to “prepare the environment, then remain silent and observe.” His case against pre-planned audience interpretation echoes student reflections, with some applying his concepts by eliminating directions from their projects or realizing that interactive art promotes open discussions instead of presenting a singular perspective. The comparison to guiding actors—where proposing intentions is acceptable but imposing emotions restricts authenticity—really suggests the notion that the audience should have room for their own true reaction. The text made me consider how interactive art can be practiced, similar to a performance, to enhance audience involvement without excessive guidance.