Category: S2026 – Aya

Exercise 1

Arduino GitHub File:

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

Arduino Set-up:

Arduino Illustration:

Project Demo:

Exercise 2

Arduino GitHub File:

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

Arduino Set-up:

 

Arduino Illustration:

Project Demo:

Exercise 3

Arduino GitHub File:

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

Arduino Set-up:

Arduino Illustration:

Project Demo:

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

Driving Game with a Physical Steering Wheel (Steering Beyond the Keyboard)

For my final project, I want to create a simple driving game that is controlled using a real steering wheel instead of a keyboard. The idea is to change how we normally interact with games. Instead of pressing keys, the user will physically turn a steering wheel to control the car on the screen. I am interested in how this makes the experience feel more natural and more connected to the body.

I will be using an actual steering wheel that I can buy online and then connecting it to my Arduino setup. The steering wheel will be attached to a potentiometer so that when it rotates, the Arduino can read the change in position. This value will then be sent to p5.js using serial communication. I will also include a button that can be used to start or reset the game.

On the p5.js side, I will build a simple driving game. The player will control a car that can move left and right across the screen while the road moves forward. Obstacles will appear, and the player has to steer to avoid them. The position of the car will be directly linked to how much the steering wheel is turned, so the movement should feel smooth and responsive. I plan to include basic features like a score counter, a crash state, and a reset option.

The main focus of this project is not just the game itself, but the interaction. I want the system to feel clear and easy to understand. When the user turns the wheel, the car should immediately respond on the screen. This direct connection between input and output is important. It should feel like the user is actually controlling the movement in a physical way, not just pressing buttons.

I also want to make the setup look clean and intentional. I will build a simple base to hold the steering wheel and hide the wires. This will help the project feel more like a complete system rather than just loose components. I may also add small details like labels or lights to make the interaction clearer.

For inspiration, I looked at projects that use unconventional controllers and turn the interface into part of the experience. I also looked at previous student projects where the interaction was very clear and immediate. Those projects showed that even simple inputs can feel impressive if the response is well designed and easy to understand.

To build this, I will use basic Arduino tutorials for reading a potentiometer and sending data through serial communication. For p5.js, I will use examples that show how to read serial data and map values to movement on the screen. These will help me create a stable system before I focus on improving the visuals and overall experience.

Overall, this project is about making a simple but effective interactive system. By using a real steering wheel, I want to create a more engaging and physical way to play a digital game. The final result should feel responsive, intuitive, and easy for anyone to try without needing instructions.

The Design Meets Disability reading made me rethink how I usually see design, because I realized I tend to treat accessibility as something separate from “good design,” like something added later to fix a problem instead of something considered from the start. Pullin challenges that idea by showing how assistive devices often aim to hide disability or make someone appear more “normal,” and I found myself questioning why that feels like the default goal. When I think about it, that approach says more about what society is comfortable with than what people need or want, and I had not really noticed how strong that assumption is until now.

What stayed with me is his focus on expression, because he suggests that assistive design does not have to disappear or blend in, it can reflect identity in a visible way, and that shift feels important. When I think about prosthetics designed to look exactly like a natural limb, I see how design tries to erase difference, but when I picture a prosthetic designed with color or shape or style, it changes the meaning of the object completely. It becomes something personal instead of something corrective. That made me realize how much design controls what gets seen as normal, and how easy it is to follow that without questioning it.

After reading this, I feel more aware of how I approach design decisions, even in small ways, because I see how choices about form, appearance, and function are never neutral. If you design for one type of user, you set a standard that excludes others without saying it directly, and I think that is what I will carry forward from this reading. I need to think about who is included from the beginning, not after, and I need to question why certain designs try so hard to hide difference instead of allowing it to exist openly.

The author claims that the strive toward the “discreetness” of medical devices enforces a stigma around them, sending a message that needing these devices is shameful. However, while the primary purpose of these devices is functional, on a social level, many people of determination who wear them simply want to feel included and navigate the world without drawing unwanted attention. While I certainly do not condone making people of determination feel left out, and I believe that eliminating stigma starts with changing society’s mindset rather than hiding a disability, I am also realistic. It is extremely difficult to change societal behavior and opinions overnight. Therefore, it can be highly beneficial to create devices that are discreet. Providing these options is ultimately about offering choice: it caters to those who prefer not to draw attention to themselves. Realistically, many people face intense social pressure and would rather blend in than stand out. Years down the line, I hope all medical devices can achieve a destigmatized success story like eyewear, where users have the agency to be as bold or as subtle as they wish. In the meantime, however, making discreet devices is not necessarily a negative thing; it is a necessary accommodation for the social realities people currently face.

One idea that stuck with me even after the reading is that eyewear is a space where fashion and disability overlap. The text explains how glasses are no longer seen only as medical tools but also as items people wear to express themselves. This connects to my own experience. When I was younger, I saw my friend’s glasses as more of a fashion statement than something related to vision problems. I would even try them on because I thought they looked good on me. At that time, I didn’t really understand the difference between graded glasses and fashion glasses since they looked similar and came in many styles and colors. It was only later, when I developed farsightedness myself, that I realized their actual purpose. Looking back, I see that my experience reflects what the text describes, that glasses can function both as a medical tool and as a form of self-expression. I also noticed that, as mentioned in the reading, glasses are often visible and even desired, unlike many assistive devices that are designed to be hidden. This shows how eyewear challenges the idea that disability-related products should always be discreet.

On the other hand, I liked how the author pointed out that invisibility is not always the best approach for disability design. Instead of hiding, creating a positive and confident image can change how people see disability. This made me think that trying to make assistive devices invisible can make them seem like something to be embarrassed about. This also made me realize that design doesn’t just solve a problem, it also affects how people feel about themselves and how they are seen by others. A good example of this from the text is Aimee Mullins, who embraces her prosthetic legs and uses them to express herself, similar to how people choose different outfits. Through this example, I realized that design for disability goes beyond just function. It also plays an important role in someone’s confidence, identity, and how people choose to express themselves.

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.

I was inspired by Color Twister, a game where players follow color-based instructions by placing their hands and feet on matching spots. I wanted to take that idea further and make it less about quick reactions and more about thinking, memory, and control, so I came up with Echo Move.

In this game, players are shown a sequence of visual signals on screen for a few seconds. Once it disappears, they have to recall and perform the sequence using their body on the “Echo Move Board,” which is connected to an Arduino. The challenge is to remember the information and use it accurately on time.

Echo Move doesn’t just tell where to step, it also tells the player how to interact. When the pink color appears in the sequence, the player should step into the zone and hold it until the level ends. If it’s yellow, the player should step once and remove it afterward. Holding too long or stepping on it again results in a loss. If it’s black, the player should be aware that it is only for deceit. They should avoid it completely, even if it appears in the sequence. Because of this, players have to interpret each signal before acting. It’s not just about memorizing positions, it’s about understanding instructions, timing movements, and controlling the body.

The game has four levels. Each level gets harder. It adds more complex sequences, tighter timing, and trickier signals. These elements test the player’s memory and decision-making skills.

Another key aspect is that the physical board itself has no colors, only neutral zones. All cues come from the screen, which means players must mentally map what they see onto the board. This adds abstraction. It forces them to turn visual cues into actions without direct help.

P5 and Arduino

In this game, P5 handles the game logic, visuals, and state control, while Arduino handles the physical input.

Each zone on the Echo Move board uses force-sensitive resistors (FSRs) to detect when a player presses on it. Arduino constantly reads these sensors and converts them into simple signals, such as pressed or not pressed. In addition to the FSR sensors, the Arduino will also read inputs from physical buttons connected to the system, including on/off, play, and pause/stop. These buttons control the state of the game and send signals to P5 when pressed. Arduino then sends all input data to P5 through serial communication in real time.

The P5 program, on the other hand, controls the game logic and what the player sees on screen. It displays the sequence of colors and signals that the player needs to remember. After a few seconds, the sequence disappears, and the player must perform it on the board. As Arduino sends input data, P5 reads both the sensor inputs and button signals. The buttons are used to control the flow of the game, such as starting, pausing, or stopping. P5 then checks if the player is following the correct order, timing, and actions, such as holding, tapping, or avoiding certain zones. Based on this, P5 decides if the player wins or loses and can send a message back to Arduino to control the game state. 

Stipend Usage

I’ll be using my stipend to buy the main parts I need for the Echo Move board, especially the force-sensitive resistors (FSRs) and longer jumper wires. These will help me properly detect player input and make sure the connections across the board are stable and flexible.

Preliminary Concept: Pressure-Based Digital Instrument

For my final project, I plan to create a physically interactive musical instrument using Arduino and p5.js. The idea is to build a simple keyboard-like interface where users can play notes by touching pressure sensors.

Instead of using buttons, I will use Force Sensitive Resistors (FSRs) so that the interaction feels softer and more natural, similar to placing fingers on a piano. Each sensor will represent one note (C, D, E, F, G, A, B, C, including sharps/flats).   Below picture will have only 4 FSR406 and 4 FSR402, I will buy them more and also 16 channel analog multiplexer to complete my project soon. 

Arduino will read the sensor values and send the data to p5.js through serial communication. In p5, the input will be used to generate sound and simple visual feedback. I will use the computer’s speaker for audio output instead of a buzzer to improve sound quality.

Since I need to use multiple sensors, I will use a CD74HC4067 multiplexer to expand the number of inputs. This allows Arduino to read many FSRs efficiently.

The system will also include a feedback loop. For example, when a note is played, p5 can send a signal back to Arduino to turn on an LED. This creates a simple two-way communication between Arduino and p5.

The goal of this project is to explore how physical touch can be translated into digital sound and visual feedback in a clear and responsive way.

 

Inspiration

This project is inspired by different types of interactive musical interfaces:

* Digital MIDI controllers and touch-based instruments
* Piano keyboards, especially the idea of soft and responsive touch
* Interactive installations where physical actions directly control sound
* Simple expressive systems that focus on user interaction rather than complexity

I am particularly interested in how small physical gestures, like lightly touching a surface, can create meaningful digital outputs such as sound.

 

References / Tutorials

Here are some references and tutorials that informed my idea:

* p5.js Sound Library (official reference)

https://p5js.org/reference/#/libraries/p5.sound

* Basic FSR (Force Sensitive Resistor) guide
https://learn.adafruit.com/force-sensitive-resistor-fsr

* Multiplexer (CD74HC4067) explanation
https://learn.sparkfun.com/tutorials/multiplexer-breakout-hookup-guide

 

Sketch Description

The system will be arranged like a simple keyboard:

* FSR406 → white keys (main notes)
* FSR402 → black keys (sharps/flats)

For my final project, I am creating a physically interactive maze game that uses both Arduino and P5.js. So I decided to pick minnie mouse and mickey mouse as my two characters. The idea is to guide minnie mouse through a maze using two physical potentiometers instead of a keyboard or mouse. The player’s goal is to move minnie mouse from the start of the maze to the end, where mickey mouse is waiting.

The interaction works in a simple cycle of listening, thinking, and responding. The Arduino will be the “listener” because it reads the positions of the two potentiometers. One knob controls left andright movement, and the other controls up and down movement. When the player turns the knobs, Arduino senses the changes and sends those values to P5.js. P5. will be the “thinker,” because it takes those values and turns them into movement on the screen. The game then responds by moving the character in real time and showing whether the player is controlling minnie mouse in staying inside the maze or hitting the walls. I want to consider adding a celebration melody when minnie mouse reaches mickey mouse. I might as well make the LED blink when Minnie hits a wall to alert the player about it.

The maze itself will be drawn in P5 using simple shapes or a custom layout. I will have a start screen and instructions screen. The character will move smoothly through the pathways, and basic collision detection will prevent it from passing through walls. When the player reaches the goal area, the game will display a small celebration animation or visual cue to show that the objective has been completed. The experience is meant to feel playful, fun and slightly challenging, since the player must learn how to control movement using physical knobs instead of controlling it with the laptop. I will probably take photos of minnie mouse and mickey mouse of the internet and use them as my characters.

Reading Design Meets Disability made me rethink what I previously considered “good design.” I used to associate good design with aesthetics and general usability, but this reading challenged my assumption by showing how design is deeply tied to social attitudes toward disability. The section on “discretion” stood out to me, where assistive devices like hearing aids are designed to be hidden in order to avoid stigma. This made me question whether invisibility is actually a positive goal, or if it reinforces the idea that disability should be concealed. I found myself reflecting on how design choices are not neutral and that they reflect cultural values about what is considered “normal.” The tension between fashion and disability also left a strong impression on me. While making assistive devices more fashionable can empower users, it also risks emphasizing appearance over accessibility. This contradiction made me realize that design often operates between competing goals rather than clear solutions.

This reading also connected to my previous understanding of user-centered design but expanded it in a way I had not considered before. It made me realize that “the user” is often imagined as a narrow, able-bodied group, which doesn’t take into account many real experiences. The idea of “simple meets universal” raised an important question for me that is it actually possible to design something that works for everyone, or does inclusivity inevitably introduce complexity?   This challenges the assumption that simplicity is always better. Personally, this reading shifted my perspective from seeing design as purely functional problem-solving to understanding it as a more cultural and ethical practice that shapes how people are perceived and included. It also made me more aware of the limitations in the designs I encounter daily and how they really reflect broader biases rather than just technical decisions.