Category: S2025 – Shiloh

Concept

For my project, I developed a traffic light system that uses sound to provide directions. This solution addresses the challenge pedestrians face in reading traffic lights during the day, particularly when sunlight makes the signals hard to see. The system uses an LDR (Light Dependent Resistor) to detect light levels above a certain threshold, activating a buzzer that beeps twice for “go” (green) and once for “stop” (red). This feature helps pedestrians who may struggle to see the traffic lights in bright sunlight. At night, when the lights are easily visible, the buzzer remains off, reducing unnecessary noise.

Implementation

The project uses the following components: 6 LEDs, an LDR, a buzzer, resistors, wires, and a switch. The switch is particularly useful for stopping and resetting the system. The buzzer is triggered when specific LEDs are on, and the LDR reading exceeds a set threshold. The LEDs are divided into two groups: one for pedestrian signals and the other for vehicle signals. The buzzer sound is dependent on the pedestrian signal’s color: it beeps twice when the light is green and once when it is red.

Images and sketch

Code Highlights

I’m particularly proud of how I managed the buzzer’s beeping pattern using functions, classes, and conditional statements. Below are some key snippets of the code. 

void beepOnce(int note, int duration) {
  tone(buzzer, note, duration);   // Play the note on the buzzer
  delay(duration + 50);           // Wait for the note to finish
  noTone(buzzer);                 // Stop the sound
}

void beepTwice(int note, int duration) {
  tone(buzzer, note, duration);   // Play the note on the buzzer
  delay(duration + 50);           // Wait for the note to finish
  noTone(buzzer);                 // Stop the sound
  delay(100);                     // Short delay before second beep
  tone(buzzer, note, duration);   // Play the note again
  delay(duration + 50);           // Wait for the note to finish
  noTone(buzzer);                 // Stop the sound
 
ldr_value = analogRead(ldrpin); // Read the LDR sensor value
  if (ldr_value > 600) {  // Only beep if LDR value is greater than 600
    beepTwice(NOTE_E4, 300);  // Beep twice when Side 1 is Green
  }
 
ldr_value = analogRead(ldrpin); // Read the LDR sensor value
  if (ldr_value > 600) {  // Only beep if LDR value is greater than 600
    beepOnce(NOTE_C4, 300);  // Beep once when Side 1 is Red and Side 2 is Yellow
  }

 

Additionally, I learned how to define musical notes in Arduino, and I believe this will be useful in future projects.

const int NOTE_C4 = 261;   
const int NOTE_E4 = 330;     

Challenges and Future Improvements

I faced challenges in synchronizing the color patterns of the traffic lights, but after some time and effort, I was able to get it right. Moving forward, I plan to deepen my understanding of buzzer functionalities and work on streamlining and optimizing my code.

Demonstration

video

I completely understand the view brought up in the reading “Physical Computing’s Greatest Hits (and misses)” on how so often I think to myself, “I don’t want do to that, it’s already done” and give up on the idea because I think it’s not original. However, my horizons broadened when I realised through the reading that even recurring themes can have a lot of room for originality, if I try to add a notable variation / twist to these themes. As the reading discusses specific examples of ideas of physical interaction, I think it is great how it contains not only a description of it and its positive aspects, but also its limitations. For instance, with Theremin-like instruments, moving a hand over a sensor can have little meaning – but it can be developed through a twist involving a physical form and context for the sensors that affords a meaningful gesture. I see gloves as a way that affords much more meaning because we use the way our fingers bend and which fingers bend can result in so many variations and convey some meaning – whether someone is stressed vs relaxed, the way to play an instrument, etc. Another limitation that stood out to me was with the Scooby-Doo paintings, where designers of this type of project commonly confuse presence with attention (as I personally have). Someone’s presence does not necessarily mean that person is paying attention. Hence, I made a mental note to pay attention to this to any similar future projects I might undertake, where I could integrate detection of eyes and face, for example.

The next reading “Making Interactive Art: Set the Stage, Then Shut Up and Listen” brought to my attention a problem that I still need work on. So often, artists make artworks, describing their work and their interpretations. Personally, if I were the audience of such an artwork, it feels more difficult to interpret the work differently because I’ve been directed in the way to think. However, I think the audience will enjoy it more when they receive the opportunity to spend some time taking in the artwork through their senses… to think about what each part means, which parts afford contact or control, and which parts don’t.  In letting them interpret the parts, and decide how to respond – rather than prescribing their response, they could be more engaged and discover more. My question is, what is the balance between describing the environment and letting the audience discover the artwork?

Week 9 – Reading Response

 

Physical Computing’s Greatest Hits (and misses):

This text offers us a thoughtful overview of the recurring themes in physical computing projects. The text highlights that ideas in physical computing, even when they seem overused, can still offer immense and creative potential. The author states that even if a project concept has been done before, the nuances of how an individual implements it can still lead to meaningful experiences. The text also highlights the significance of human gestures in making an engaging interface.  Projects that use physical computing are less about the technology and more about the quality of the interaction it creates, even if it is a subtle hand-waving over a sensor.

The author also touches on how we can expand the idea of interaction and what physical computing can be. Examples such as interactive paintings (like the Scooby-Doo-inspired projects) and remote hugs, demonstrate how we can stretch the concept of interaction. These projects show that physical computing can be a tool not just for entertainment, but for communication, empathy, and even therapy. Lastly, the author mentions that the evolution of tools and technology is extremely crucial. Projects that once took weeks to develop are now able to be prototyped in hours because of advances in technology. This evolution emphasizes that there is a change in the speed of innovation, and it also allows for an easier and broader range of creators to engage in physical computing.

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

This text serves as a significant reminder that interactive art is not about control, but rather about conversation. The role of the artist changes from just being a storyteller to becoming a stage-setter, creating spaces and experiences that invite, not dictate, meaning. For the artist, this means that instead of pre-defining what every element “means,” they come up with something that encourages exploration, play, and personal response. So instead, we should attempt to build something and then step back, observe, and listen to how others engage with it. This brings up the idea of intentional design, where the artist leaves behind clues or emotional cues, then steps away and allows various unique interpretations to emerge.

Why We Love Things We Can Yell At: The Joy of Simple Interactions in Physical Computing

Have you ever wondered why it’s so satisfying to yell at things, and even more so when those things respond? One idea from the article “Physical Computing’s Greatest Hits (and misses)” particularly stood out to me: the visceral pleasure people experience when interacting through yelling or loud noises.

There’s something fundamentally cathartic about making noise—perhaps it’s the primal simplicity or the sheer emotional release of shouting out loud. Now, combine this human instinct with technology, and you’ve got an instant recipe for delight. Projects like Christopher Paretti’s SpeedDial, which reacts simply to sound level, tap directly into our innate desire for immediate feedback.

But what makes this seemingly straightforward interaction so compelling? On the surface, it might feel gimmicky—after all, you’re just shouting at a microphone. Yet beneath that playful exterior, there’s a subtle layer of emotional connection. When a device instantly reacts to our voice, we feel heard—even if it’s just a blinking light or an animation triggered on-screen. There’s an emotional resonance in being acknowledged, even by an inanimate machine.

From a practical standpoint, these projects are remarkably accessible. Unlike complex systems relying on intricate gestures or detailed body tracking, shouting requires no special training or sophisticated movement—anyone can participate instantly. This ease-of-use encourages playful exploration and inclusivity. It democratizes the interaction, inviting everyone—from seasoned technologists to kids—to engage without hesitation.

However, simplicity doesn’t mean there’s no room for depth. The article hints at this by suggesting more sophisticated interactions like pitch detection or voice recognition, achievable on more powerful devices. Imagine yelling commands at your smart home system or your car responding differently depending on your tone of voice—there’s immense potential here.

At its core, the beauty of “things you yell at” lies in their simplicity and directness. They remind us that effective physical computing interactions don’t always need layers of complexity. Sometimes, the purest and most joyful connections between humans and technology arise from the most fundamental forms of expression.

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

There’s something refreshingly humbling about Making Interactive Art: Set the Stage, Then Shut Up and Listen. It gently nudges artists—especially those new to interactivity—toward a kind of creative ego check. The central message? Once you’ve built the world, let go. Really, let go. No guiding hand, no long-winded artist’s statement explaining what each LED, wire, or wooden block means. Just let people enter, experience, and respond.

And honestly, this advice hits at the core of what makes interactive art so compelling—and so tricky. Most of us come from traditions where art is this deeply personal monologue: Here’s what I think. Here’s what I feel. Please receive it. But interactive art flips that script. It’s not a monologue anymore. It’s a dialogue. Or better yet, a jam session.

What I really like about this piece is how it compares creating interactive art to directing actors—without micromanaging them. The idea that you don’t tell your actor what to feel, but rather create space for them to discover the emotion on their own, is such a smart analogy. It’s not about control. It’s about suggestion. Curation over explanation.

There’s something incredibly respectful in that approach. You’re treating your audience like active participants, not passive viewers. You’re saying: “I trust you to make something meaningful here, even if it’s not the meaning I imagined.” And that’s powerful. It also requires a certain vulnerability from the artist, because the outcome is never fully in your hands.

From a design perspective, that’s where things get really interesting. The choices you make—what you include, what you leave out, how you shape the space—aren’t about decoration or symbolism as much as they’re about affordance and invitation. Do I want someone to touch this? Then I better give it a handle. Want them to linger? Don’t make the space feel like a hallway.

So maybe the best takeaway from this essay is that interactive art is more about listening than speaking. It’s not about being understood in the traditional sense. It’s about being felt, experienced, and maybe even misunderstood—but in ways that are meaningful to the person engaging with it.

Set the stage. Then, really—shut up and listen.

Week 9 – Analog Input & Output

For this assignment, I decided to expand on my previous assignment of the unusual switch. I was thinking about a way to expand on it in a practical and useful way. Since I already had a digital sensor, for the analog sensor, I decided to use the light sensor. I was thinking that this would be a beneficial addition to the idea of the shoes because it allows it to not only glow when they are put on, but also has a built in LED light that automatically adjusts its brightness based on the ambient light. The idea of this is that the LED light is brighter when it is dark, so that you can easily find the shoes, and it dims when it is brighter because you have a clearer vision. This idea came from the countless times I’ve woken up in the middle of the night or early in the morning and wished I had a light source that would guide me without stumbling around for a switch in the dark.

I started by gathering the materials I needed: 

• Arduino
• Breadboard
• Wires
• Resistor (330k, 10k)
• LED (multi-colour, blue)
• Cardboard
• Aluminum
• Sponge
• Tape
• Scissors

I started by cutting out a piece of cardboard in the shape of a shoe, then cut two smaller cardboard pieces to act as the soles. I wrapped each sole in aluminum foil and built a sandwich-like structure. 

→ Taped the first aluminum sole to the base of the shoe

→ Placed a sponge layer over it as a barrier

→ Placed the second foil-wrapped sole on top

 

The sponge was necessary as it acts like a spacer that keeps the two foil layers apart unless pressure is applied (someone steps on it). When someone steps on the shoe, the pressure compresses the sponge, which allows the two foil layers to touch and complete a circuit.

After that, I set up the arduino and breadboard by starting off with what we have done in class. First, I made sure that the LED is connected to a digital output pin (pin 13) instead of directly to 5V. Then I added a wire to the bottom foil and connected it to GND and added another wire to the top foil and connected it to Digital Pin 2. Lastly I updated my code, and made sure to print in order to test the output, (0 = foot pressed→LED ON, 1 = no contact → LED OFF). 

Then, I added the light sensor circuit, connected a voltage divider using 10k and 330k resistors. I connected this to analog pin A2 and added a blue LED on pin 9, which allows me to control its brightness using analogWrite(). I chose this colour because I was hoping it would provide a more calming feeling. Using the Serial Monitor, I was able to verify that the LDR readings worked correctly. In the dark, the LED brightness increased and when I turned on a flashlight on the sensor, the brightness decreased. In the video demonstration, you can see that the brightness numbers of the LED were high when it was darker, and once I put a flash light on top of it, the brightness numbers went down. This allowed me to double check it was working correctly, even if the change was not as drastic.  

Code highlight:

int brightness = map(lightLevel, 1023, 0, 0, 255);
analogWrite(ledAnalog, brightness);

This allows the LED to fade dynamically depending on the amount of light in the room. The darker it gets, the brighter the LED glows, which is useful for locating the shoes at night.

 

Challenges and Future Improvements:

One of the challenges I faced was ensuring that the foil switch is stable. At first, it was difficult to get consistent readings from the foil layers. The sponge helped, but I also experimented with the positioning and pressure to make sure it only activated when stepped on.  Also, at first I thought the LED brightness was not changing, however, using the Serial Monitor I was able to confirm that it was working, even if the brightness was subtle. For future improvements, I was thinking that I could even add a soft chime when the shoe is worn in the dark so that it can enhance the feedback and add a helpful alert. Additionally, I could also work on the aesthetic aspect of it a little more. Overall, I am very satisfied with the way the shoe turned out.

Link to photos of the process

Link to final video demonstration

Physical Computing’s Greatest Hits (and misses)

The reading gives a nice overview of recurring themes in physical computing, from glove controllers and theremin-like instruments to meditation devices and LED-heavy projects. What stood out to me is how these categories reveal both the creativity and the comfort zones of makers in the field. Igoe doesn’t criticize repetition, but rather suggests that familiarity in concept doesn’t make it not innovative. It reminds us that an idea can still be original by putting our own twist on it, even if it has been done before.

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

​The second reading emphasizes the importance of allowing interactive artworks to speak for themselves without over-explaining their meanings. It mentions how the artists often provide detailed interpretations alongside their interactive pieces, which can inadvertently dictate the audience’s experience and limit personal engagement. Igoe advocates for creating environments that invite participants to explore and derive their own interpretations, suggesting that the artist’s role is to set the context and then step back to observe how the audience interacts with the work. I somewhat agree with this, as I do believe the interactive art should speak for itself. But also I do think that some interactive artworks do need explanation, as having users “mess” with it however they like might break the design or change the important pre-set setting. I guess the design should make it obvious what is to be touched and what not, but I think sometimes people can interpret it wrong without proper instructions.

Concept

When thinking about this weeks assignment I wanted to make something that is interactive and also fun to use. I was thinking for a while and then I decided to make a game where we play against the Arduino. The game is simple, the Arduino thinks of a random number and we need to try to guess it. But out of all numbers how would we guess which one Arduino thought of. Well by turning the potentiometer left or right we are adjusting the number that is the representation of our guess which we lock in by clicking on the switch. The closer we are to the number Arduino thought of the brighter does the blue LED become and when we think we got the answer we press on the switch and we either get a green or a red light from the LEDs, depending on if our answer is correct or not.

Implementation

The design, as mentioned above uses a potentiometer to change change the value of the choice number the user will select. A pushbutton switch is used to lock in the answer and get feedback from the LEDs. A blue LED is used as an indicator on how close we are getting to the answer and the red and green ones are used to give feedback if the answer is correct or not. The design also uses one 10k ohm resistor for the button and three 330 ohm resistors for the LEDs.

Her is the schematic of the circuit.

Code I am proud of

int potValue = analogRead(potPin);           // 0–1023
int guess = map(potValue, 0, 1023, 0, 100);  // Convert to 0–100 range

int difference = abs(guess - targetNumber);     // Distance from correct
int brightness = map(difference, 100, 0, 0, 255); // Closer = brighter
brightness = constrain(brightness, 0, 255);
analogWrite(blueLEDPin, brightness);

This part of the code took some time to get right. I used the map function we recently used in class to make the LED brighter the closer we got to the correct number.

Challenges and future improvements

I again faced challenge with the cable management. The breadboard sometimes feels too small for all of the cables, sensors and resistors to fit and a lot of time when I would finish plugging a resistor in I would accidently unplug a cable with my hands. This is something I definitely want to work on for future projects. As for this design specifically, I would like to implement a reset button so the whole device doesn’t need to be reset every time a guess is made, also some audio queues would probably be a nice addition to the whole concept. Maybe also including a screen from which the user could see what numbers they are choosing would bring the game to a whole another level. Overall working with Arduinos is very fun and I enjoy it even more with every project we do.

Physical Computing’s Greatest Hits (and misses):

The first category that popped up was a theremin-esque instrument and that’s exactly how I described my week 9 assignment with sound produced based on distance/motion. It’s interesting how motifs get repeated constantly in physical computing. Core functionalities repeat, but how you make it different and your own spin on the functionality makes physical computing worth pursuing. This blog brought up an important point about interactions that have meaning. Rather than simply mimicing a user’s actions or mapping one to one interactions, thinking about why certain interactions are valuable can fuel a physical computing project even more. For example, I really liked the accessibility examples provided like the one where a someone uses their wheelchair as a painting tool as opposed to their limbs.

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

Interactive art is a mix of design and art — your piece should invoke the right emotions without having the tell the users how to feel. Just like how a sign doesn’t need to say push or pull on a door — it should be intuitive (design principles). An interactive piece is a conversation, not a one-sided story where the artist tells the user how to feel or approach the piece. The piece can grow and evolve with feedback or reactions the users provide. By listening to their side of the conversion, you can learn a lot about how people behave with your piece and ways to change it. This brings me back to a previous reading response we had about interactivity as not just a response to users’ actions, but a tool for users to create with. By giving users a sense of agency, they’re able to creative the art with you. We as artists might feel inclined to spell out our intentions for audiences and explain how complex our projects are, but if a project is truly complex and thoughtful, it shouldn’t need explanation.

Description:

I really wanted to try using the ultrasonic motion sensor for this week’s assignment and control both audio and visuals with it. Being able to have your hand control something without touching it seemed cool to me, kind of like the theremin instrument that allows musicians to wave their hand in the air to produce different notes. My assignment is much simpler, but has a similar idea in that the closer your hand gets to the sensor, the lower the pitch. I also have LEDs hooked up that get dimmer the closer your hand gets and brighter the farther away. For the digital sensor, I have a button controlling my 4 LEDs; the button allows you to toggle between the LEDs individually. Once you’ve gone through all the LEDs and press the button again, all of them turn on. 

Video demonstration:

Schematic:

Difficulties:

I had a hard time with the button because it wasn’t as simple as pressing it to toggle between the LEDs. When you press the button, you’re technically holding it and giving it HIGH voltage for multiple frames. That means within one button press, I’m toggling between who knows how many LEDs. However, I only want one button press to change one thing. I did some scouring online and found this state-changing example that made me realize I can just detect when the button goes from LOW to HIGH (off to on). By keeping track of the last button state and current button state, I can detect when the user clicks the button. That instance determines whether or not to toggle between the LEDs: https://docs.arduino.cc/built-in-examples/digital/StateChangeDetection/

Button state change:

// compare current and previous button states, see if there's change
if (buttonState != lastButtonState) {
   // if HIGH, button went from off to on
   if (buttonState == HIGH) {

Mapping distance to LED brightness:

analogWrite(LEDarr[currentLED], map(dist, 0, 20, 0, 255));
if (dist < 3) {
  analogWrite(LEDarr[currentLED], 0);
}

It was also difficult making the different pitches noticeable since the motion sensing isn’t the most accurate and there’s not a huge range to work with. To counteract this, I chose notes that were very far apart from each other to make the change in sound due to distance more apparent. I also made sure to print out the distances to how far a person would comfortably go away from the sensor and used that as my max.

Looking forward:

In the future, it would be nice if maybe I map a specific LED/color to a specific note or melody so that when I play songs from the speaker, the lights match accordingly. It would also be cool if I can play a song from the motion sensor and choose what notes to play given the distance/motion.