Author: Mouza AlMheiri

Concept

This project is a fast reaction game where the user controls a spacecraft without seeing the controls directly. The screen gives instructions like “press red, “flip switch,” or actions using Arduino sensors like “cover the light sensor” or”move closer.” The user has to read the command and quickly do the action on a physical console. It’s timed, so you need to react fast and accurately I might add more elements like once you get over 10 points youll have to start memorizing three tasks at the same time or have new rules added. If you’re right, the game continues, and if not, you lose. The idea is to make simple actions feel intense and engaging using both physical controls and sensor based interaction.

How it uses Arduino

Arduino handles all the physical interaction. It reads inputs from buttons, a switch, a knob, and sensors like a light or distance sensor. For example, if the user presses a button or covers the light sensor, Arduino detects that and sends the data to p5. It also controls LEDs to give feedback, like turning on a light when the user is correct.

How it uses p5.js

p5 is the visual and logic part of the project. It shows instructions on the screen like “PRESS RED” or “MOVE CLOSER.” It randomizes the commands so the game changes every time its still early on on the project so I might hav ethe commands show on screen or on an actual screen next to the control panel or both i’ll decide on which to go with on both depending on what works best. It also checks if the user did the correct action and controls the flow of the game, like score, timing, and game over. It can also send signals back to Arduino for feedback.

Interaction Design

The system works in a loop. First, the screen shows a command. Then the user reacts using the console or sensors. Arduino reads that input and sends it to p5. p5 checks if it’s correct and responds with the next step or a fail. This repeats quickly, so the user is always reacting and the system is always responding.

Inspiration and Originality

This idea is inspired by Bop It, where you follow quick commands like “twist it” or “Spin It” I liked how simple actions become intense when you have to react fast. It’s also inspired by Project Hail Mary, especially the scene where the character is pressing buttons and flipping switches to control the spacecraft under pressure. My project builds on this by adding different sensors, like light and motion, so the interaction is more varied and not just buttons.

Visual and Aesthetic Direction

The visuals will be simple and slightly retro, like an old spacecraft system. The screen will have big, clear text so the user can quickly read what to do. I won’t focus on complex graphics, just clean visuals that support fast interaction and make the game feel intense.

Why this project works

This project works because it combines physical interaction with fast response. The user is actively doing actions, not just watching. It uses Arduino for sensing and p5 for visuals and logic, so both are important. It also gives clear feedback and keeps the user engaged through speed and randomness.

Generated sketch :

 

Examples and tutorials found:

https://www.instructables.com/The-Task-Giving-Arduino-Machine-aka-Making-Your-Ow/

https://projecthub.arduino.cc/Jerepondumie/make-an-arduino-memory-game-c9c093

Exercise 1

Arduino GitHub File:

https://github.com/MouzaAlMheiri/Intro-to-IM/blob/main/week11-exercise1

Arduino Set-up:

Arduino Illustration:

Project Demo:

A4411AE3-AC1F-4272-AE11-D085ADCABB95

Exercise 2

Arduino GitHub File:

https://github.com/MouzaAlMheiri/Intro-to-IM/blob/main/week11-exercise2

Arduino Set-up:

 

Arduino Illustration:

Project Demo:

IMG_1122

Exercise 3

Arduino GitHub File:

https://github.com/MouzaAlMheiri/Intro-to-IM/blob/main/week11-exercise2

Arduino Set-up:

Arduino Illustration:

Project Demo:

IMG_1288

Concept

This week was all about making things communicate. Before this, everything we made stayed inside Arduino. This time, we connected Arduino to p5 so the physical and digital sides could talk to each other.

At first it sounded simple, but it ended up being one of the hardest things we’ve done so far. Not because of the ideas, but because getting everything to connect properly took a lot of trial and error.

Exercises

Across the three exercises, we explored different ways of communication.

In the first exercise, we sent data from Arduino to p5. We used the potentiometer to move a circle across the screen. This helped us understand how sensor values can control something visually.

In the second exercise, we reversed the direction. p5 controlled the LED on Arduino. This made us realize that communication goes both ways, and that sending data is just as important as receiving it.

In the third exercise, we combined both directions. The potentiometer controlled movement in p5, and when something happened on the screen, it sent a signal back to Arduino to turn on the LED. This was the most interesting part because everything was connected and reacting together.

Code Highlight

One part that really helped us was reading the sensor data correctly in p5

let str = port.readUntil("\n");

if (str.length > 0) {

  str = trim(str);

  let sensorValue = int(str);

  if (!isNaN(sensorValue)) {

    x = map(sensorValue, 0, 255, 0, width);

  }

}

This made sure we only used valid data and mapped it properly to the screen. Once this worked, everything became much smoother.

Problems Encountered

We had a lot of issues this week, mostly with the connection. The serial port wouldn’t open, or p5 wouldn’t receive any values. Sometimes things worked and then suddenly stopped working again.

We realized most of these problems were small things, like forgetting to close the Serial Monitor or not formatting the data correctly.

Reflection

This week helped us understand that interaction is not just about building something, but about connecting things together. Once the connection worked, everything felt more interactive and responsive.

It also made us more patient with debugging. We learned to check things step by step instead of assuming something bigger was wrong.

Collaboration

We worked on this together, which made a big difference. When one of us got stuck, the other could help figure out what went wrong. It also made debugging less frustrating because we weren’t trying to solve everything alone.

Working together helped us understand the system better and move forward faster.

References

p5.js Web Editorhttps://editor.p5js.orgp5 to Arduino

p5.js Web Editorhttps://editor.p5js.orgp5 to Arduino

p5.js and Arduino serial communication – Send a digital sensor to a p5.js sketchYouTube · Scott Fitzgerald28 Mar 2020

One idea that really stood out to me from Design Meets Disability was the concept of the “golden hand,” especially in the contrast between traditional prosthetics and more expressive designs like Jacques Monestier’s.

What I found interesting is how this shifts prosthetics from something purely functional into something aesthetic and personal. It shows that design doesn’t have to choose between function and beauty it can combine both. As someone with a background in art, this made me think about how designers can transform assistive devices into something meaningful, almost like a canvas for self expression rather than just a medical tool.

Another thing that stood out to me was how the reading emphasizes that artists bring a different perspective to engineering. They focus not just on how something works, but on how it feels and what it represents. This made me reflect on our current Arduino project, where it’s easy to focus only on the technical side, but there’s also potential to incorporate materials and design to make it more visually and personally expressive. The reading also highlights that these designs shouldn’t just be treated as objects, but as personal belongings especially in the case of prosthetics, which are part of someone’s identity. That idea really shifted my thinking, because it suggests design should allow for individuality and expression, rather than trying to hide difference.

It was interesting to see that the author wasn’t trying to provide a solution, but instead wanted to raise awareness of the problem and push further research. He emphasizes that current tools aren’t fully taking advantage of human capabilities, and when discussing things like physical keyboards or styluses, he dismisses them as not being “dynamic mediums.” This made me think about interactive media, where we experiment with more dynamic forms of interaction by combining physical inputs, sensors, and outputs to create systems that respond in real time.

However, I don’t fully agree with his view on voice. While he limits it to simple commands, I think voice has potential as a more dynamic form of interaction, especially when combined with other inputs. When he talks about the three categories of gestures, it reminded me of things like voice assistants, where we use a kind of “vocabulary” to communicate with the system, similar to saying commands like “Hey Siri.” The idea of spatial gestures at a distance also connects to examples we briefly saw in class, where movement controls objects on a screen, even if it can feel indirect. The last example, directly manipulating a virtual 3D space like Iron Man, was a bit confusing to me, but it shows a more ambitious and futuristic idea of interaction. Overall, even though he critiques these methods, I think they still have potential, especially when combined together, rather than being dismissed individually.

What stood out to me was the idea that tools should be designed around what humans are actually capable of doing, not just what technology can do. When he said “if a tool isn’t designed to be used by a person, it can’t be a very good tool” it made me think about how often we accept interfaces that don’t fully match how we naturally interact with the world.

For example, with touchscreens, most interactions are reduced to tapping or sliding, which feels limited compared to how expressive our hands actually are.

This connects to what we’ve been doing in class with circuits and Arduino, where interaction feels more physical and responsive. When building circuits, we’re not just coding something to appear on a screen we’re creating systems where human actions, like touching foil or changes in light, directly affect outputs like LEDs. In my project, I used inputs and conditions to map real world interactions to responses, which felt more aligned with how we naturally engage with objects. This reflects the idea of amplifying human capabilities, because the system responds to touch and environmental changes rather than limiting interaction to a flat surface. It also made me realize that even simple projects like ours explore more meaningful interaction than typical touchscreen interfaces, since they involve feedback, physical input, and a closer connection between the user and the technology.

Arduino GitHub File:

https://github.com/MouzaAlMheiri/Intro-to-IM/blob/main/sketch_ap12_Week10.2.ino

Arduino Set-up:

 

 

Project Demo:

IMG_0334

Images

Concept

This project is a simple musical instrument that uses both digital and analog input at the same time.

The button acts as the digital sensor because it only has two states, either pressed or not pressed. When we press it, the sound plays, and when we release it, the sound stops.

The potentiometer acts as the analog sensor because it gives a continuous range of values instead of just two states. We used that range to select different musical notes, so turning the knob changes the pitch.

What we liked about this setup is that both inputs have completely different roles. The button controls when the instrument is played, while the potentiometer controls what sound is produced. It made the difference between digital and analog feel really clear and actually useful.

Code Snippet We’re Proud Of

int index = map(potValue, 0, 1023, 0, 7);

if (buttonState == LOW) {

  tone(buzzerPin, notes[index]);

} else {

  noTone(buzzerPin);

}

 

This part is where everything comes together. The potentiometer gives a value from 0 to 1023, and we use map() to convert that into a smaller range that matches the number of notes we have. Then we use that number to pick a note from the array.

At the same time, the button decides whether the note should actually play. So one input controls the pitch, and the other controls when the sound happens, which made it feel more like a real instrument instead of just a buzzer making random noise.

Problems Encountered

The biggest challenge was honestly the wiring. Even when everything looked right, one wire in the wrong row would break the whole circuit. We had to be really precise with the breadboard and double check every connection.

The button also gave us trouble at first. It either didn’t work or stayed on all the time, and we realized it was because of how it was placed across the gap and which rows we were using. Once we fixed that, it started behaving correctly.

Another challenge was understanding how the potentiometer connects to the sound. At first it felt random, but once we understood that the Arduino reads values from 0 to 1023 and that we needed to map that to our notes, it made a lot more sense.

Reflection

This project helped us actually understand the difference between digital and analog input instead of just memorizing it. The button made sense as something binary, while the potentiometer showed how values can change continuously.

It also made us more comfortable working with sound. Before this, the buzzer just felt like something that makes noise, but now we understand how pitch is controlled and how different inputs can affect it.

If we were to improve this project, we would probably expand the number of notes or organize them into a more structured scale so it feels more like a playable instrument.

Overall, it was a really successful assignment and working in pairs made it a lot easier to think and refine ideas and carry each other throughout the trial and error process of the entire project!

References

https://projecthub.arduino.cc/SURYATEJA/use-a-buzzer-module-piezo-speaker-using-arduino-uno-cf4191

Arduino Project | Play Melody with Passive buzzer using Arduino UnoYouTube · IoT Frontier3 Jul 2023

YouTube · Tech Explorations1.3K+ views  ·  1 year ago[240] Arduino Getting Started: Make noise and beeps with the passive buzzer

Github link

https://github.com/MouzaAlMheiri/Intro-to-IM/blob/main/Week%209-%20Digital%20and%20Analog

Concept:

For this project, I knew I wanted to combine what we learned in class with something I could build on myself. I decided to use a light sensor to control one of the LEDs and a switch to control the other LED. This allowed me to explore both types of input in one system.

The interaction is split into two parts. One LED is controlled digitally using the switch, meaning it turns fully on or off. The second LED is controlled using the light sensor, where its brightness changes depending on the amount of light detected. This means one LED is controlled digitally, while the other is controlled in an analog way.

By combining both digital and analog inputs in the same project, I was able to create a system that shows the difference between these two types of control

Code Im proud of:

 // if statment so that the LED can be controlled digitally by switch
 if (switchState == LOW) {
   digitalWrite(digitalLED, HIGH);
 } else {
   digitalWrite(digitalLED, LOW);
 }

 // read light sensor
 sensorValue = analogRead(ldrPin);
 Serial.println(sensorValue);

 // keep readings in my range
 sensorValue = constrain(sensorValue, 330, 650);

//when its reads the light if its dark the LED will be bright and light the LED will be dimmer 
 brightness = map(sensorValue, 330, 650, 255, 0);

 // sets the analog LED brightness
 analogWrite(analogLED, brightness);

The part of the code I am most proud of is the section where I used the if statement together with the light sensor readings to control the LEDs. In this part, I was able to combine both digital and analog inputs in one system.

I used the if statement to control the digital LED based on the switch input, which helped me understand how conditional logic works in Arduino. At the same time, I used analogRead () to read values from the light sensor and store them in a variable. I then applied constrain () to keep the readings within a specific range, and used map () to convert those values into brightness levels for the LED.

This allowed me to control the second LED in an analog way, where its brightness changes depending on the light in the environment. This part of the code reflects what we learned in class, but I was able to apply it on my own and integrate it into a larger system. I am proud of this because I was able to understand how the sensor values translate into output and use that to create a smooth and responsive interaction.

Process :

I first began by deciding what I wanted to include, which I knew was a light sensor and a switch. I wanted to make sure I was using both types of inputs that we learned in class.

I then started by setting up my breadboard and making sure it had power. I connected 5V from the Arduino to the positive rail on the breadboard, and then connected a black wire from GND to the negative rail to complete the circuit.

After that, I began building the circuit itself. I started with the light sensor, making sure it was connected to the analog pin AO.I added a 10k resistor to create the voltage divider, and then added a wire to connect it to power.

Next, I connected the switch. I made sure it was connected to a digital pin on the Arduino, and I added a black wire from the switch to ground so that it could complete the circuit when activated.

Finally, I added the two LEDs. Each LED was connected with a 330 resistor to protect it. At this point, the full circuit was complete, with the light sensor controlling one LED and the switch controlling the other.

Reflection/ Future:

This project helped me better understand how to use different parts of the Arduino Uno board, especially the difference between digital and analog pins. I was able to use both types in one system, which is something I think will be very useful in future work. It made me more confident in connecting components and understanding how the hardware and code work together.

I also learned how different types of inputs can create different kinds of interactions. The digital input was simple and direct, while the analog input required more thinking and allowed for more gradual control. This helped me see how I can design more dynamic and responsive systems in the future.

In future projects, I would like to experiment with combining more sensors or creating more complex interactions between inputs and outputs. I also want to explore how I can make the system more interactive or meaningful, possibly by connecting it to a real world use case or adding more complexity to the design.

 

Photos:

Video:

IMG_0129

Drawn circuit

Digitalcircuit

:

Refrences:

https://electronicsclub.info/circuitsymbols.htm

https://www.pcbasic.com/blog/led_symbol.html

 

The part about artists telling the participant what each element means instantly brought me back to my installation art class, where we talked a lot about the moment you have to let go of the work and allow the user to take over. The reading’s point that once you start explaining everything, you re basically telling the participant how to think and act felt very familiar. In class, we discussed how the artwork should guide the user through visual cues, placement, and logic, not through the artists explanations. The reading frames this as the beginning of a conversation you set the context, arrange the space, and design the behaviors, but then you step back. That idea aligns with what I learned before about trusting the user to make sense of the work on their own terms.

The emphasis on listening to how people interact with the piece also reminded me of earlier readings about the relationship between creator and audience. The author describes how the user’s actions whether they understand, misunderstand, or reinterpret what you designed become part of the artwork itself.

That perspective made me think about what makes a “proficient conversation” between the work and the user: clear affordances, intentional choices, and removing anything that distracts from the interaction. It reinforced the idea that interactive art isn’t a finished statement but an ongoing exchange, where the audience completes the work through what they do and how they respond.

The floor pad section reminded me strongly of my own midterm project, not because of dance, but because of the game like logic of stepping onto the correct color at the right moment. That mechanic simple, instinctive, and satisfying made me realize how powerful familiar actions can be in interactive design. Reading about how common these themes are in physical computing made me want to keep this in mind if I ever develop my project further. I’ve been thinking about exploring Al driven speech, so the idea of having the color appear on a screen and be spoken aloud feels like a natural extension. It could make the interaction more accessible, more dynamic, and more playful. I’m also open to developing completely new ideas, but this reading helped me see how my earlier work fits into a broader category of physical interaction games, and it introduced a perspective that encourages me to build on what I already created rather than dismiss it as “too simple.”

As someone who enjoys art and painting, the discussion about originality resonated with me on a personal level. In visual art, people constantly revisit the same subjects, styles, and techniques, yet each artist brings something distinct through their interpretation. I see the same pattern in interactive media: even if a theme has been explored many times, the expression is still unique because it reflects the designer’s perspective, intentions, and sensibilities. This reading made me think about how I can translate the mindset I use in painting experimenting, layering meaning, trusting my instincts into physical computing. Instead of worrying about whether an idea is new, I’m more interested in how my artistic intuition can shape the interaction, the atmosphere, and the emotional tone of a project. It makes me excited to explore how creativity moves across mediums, from canvas to sensors to screens.

One idea from the reading that really stood out to me is how Margaret Hamilton’s work highlighted the importance of accounting for human error in design. Her insistence on adding error checking systems even when others believed “that would never happen” ultimately helped prevent serious failures and showed how crucial software was to the Apollo mission.

A moment that stuck with me was when “the software realized it didn’t have enough room to do all the functions it was supposed to be doing, it went through its error detection process and focused on the highest priority job.” This shows how the system was designed to think logically under pressure, prioritizing what mattered most instead of failing completely.

This really connects to how we write code in interactive media. For example, when we use it/ else statements, we’re also creating systems that make decisions based on different conditions basically preparing for different possible outcomes, including errors. It’s a similar mindset of anticipating what could go wrong and guiding the system to respond correctly.

I also found it interesting how they had to “simulate everything before it flew,” which reminds me of how we test our projects, especially with Arduino. Before fully running a system, we constantly test and debug to make sure everything works as expected. It shows that even at a much larger scale, the same fundamental process of testing, refining, and preparing for failure is essential.