Concept

As part of my exploration into unconventional switches and interactive physical computing, I set out to create a hands-free tilt maze that would light up an LED when a metal ball reached the end. The goal was to design a circuit where the ball itself would act as a conductor, closing the circuit when it landed in the final zone. This would be a simple yet effective way to merge an engaging, movement-based game with basic electronics.

Planning & Execution

1. Designing the Maze

I started with a small wooden tray, which served as the base for my maze. Using thin wooden strips, I created walls to guide the ball along a path. The objective was to navigate the ball from the start to the finish zone using only tilting motions, without touching it by hand.

2. Creating the Conductive Finish Zone

The most crucial part of the project was designing the finish zone, where the ball would complete an electrical circuit. I used copper tape to create two separate conductive paths (Pads A & B) with a small gap between them. When the metal ball landed on both pads simultaneously, it bridged the connection and completed the circuit, allowing current to flow and light up the LED.

3. Wiring the LED Circuit

To keep the project simple, I opted for a basic circuit:

•  Arduino 5V power supply
• Some LEDs
• A 330Ω resistor to protect the LED
• Wires connecting the copper tape pads to the circuit

The LED remained off until the ball touched both pads, acting as a natural switch.

4. Making It Hands-Free

To fully embrace the “hands-free” challenge, I designed the maze to be played by tilting the tray. I experimented with different ways to control the tilt: Holding the tray with some other body part ( added a stick for easy holding later)

The Confusing Part

One of the trickiest parts of the project was ensuring consistent electrical contact when the ball landed on the finish zone. Initially, the ball wouldn’t always complete the circuit properly. Through testing, I identified a few issues:

• Copper tape alignment: If the gap between the two pads was too wide, the ball wouldn’t bridge them effectively.
• Surface roughness: Uneven copper tape or debris could prevent a reliable connection.
• Ball material: Not all metal balls conducted electricity equally well. A steel washer worked best.

and heres “The Video”-

Final Thoughts

This project was a fun way to combine electronics, physical movement, and creative problem-solving. the conductivity issues helped me better understand how to design reliable electrical contacts.

I’m excited to explore more unconventional switch mechanisms in the future. Maybe next time, I’ll design a game that reacts to body heat, breathing, or even sound vibrations!

Will be demonstrating the gameplay on class!

Margaret Hamilton: Her Code on the Moon

Reading “Margaret Hamilton: Her Code on the Moon” deepened my understanding of her pioneering contributions to the Apollo program and the development of software engineering. What struck me is that the article highlights her leadership at MIT’s Instrumentation Laboratory and how it was vital for creating the software for the Apollo guidance computer. I was amazed by the vast scope of the Apollo project, involving more than 400 individuals working on the software by 1968, while Hamilton introduced important innovations such as priority displays and created the term “software engineering” to give credibility to the discipline. I’ve always thought software engineering could come from the Turing Test or other experiments involving web development but hearing it comes from the Apollo project surprised me. The article deepened my comprehension of a software’s essential function in space exploration and I wondered what programming techniques or coding languages were used back then.

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

This has taught me on how aesthetics impact not only perception but also functionality and problem-solving. The notion that appealing designs can enhance the perception of task simplicity by aiding cognitive processing is intriguing, yet I recognize how bad usability can occasionally negate that advantage—similar to Michael Graves’ “Nanna teapot,” which is aesthetically pleasing but often impractical. It made me reflect on how frequently I’ve assessed a product based on its look, only to find out later that appearance doesn’t necessarily indicate user-friendliness. The author’s story regarding early computer displays changing in perceived worth over time also caught my attention, demonstrating how aesthetics can influence our evaluations in ways we might not readily acknowledge. I think it’s intriguing to consider what occurs in the brain when appealing things lead individuals to feel more competent. This reading doesn’t exactly alter my opinions, but it enhanced my understanding of how emotion and design connect, particularly in fields such as human-computer interaction, where it is vital to balance aesthetics and functionality.

Concept

Link: https://drive.google.com/file/d/19TgW5BmcVSER1t9MUOYlwJh5GEUXzX6o/view?usp=sharing

For this assignment, I decided to create a simple light-controlled system using a homemade pressure switch (A foot pedal). This is because I was curious to learn how basic, mundane materials like paper could be used to create an operational input device without using typical components like push buttons. By including this on the Arduino Uno, I could turn an LED on and off with a physical press, demonstrating how simple materials around the house can be repurposed to create interactive electronics projects.

Arduino Code

I changed the original Arduino “Blink” code to make the light not turn on and off by itself, but only turn on when I trigger it using my paper and copper tape switch:

int buttonPin = 2;
int ledPin = 13;

void setup() {
  pinMode(buttonPin, INPUT_PULLUP); // Enables internal pull-up resistor
  pinMode(ledPin, OUTPUT);
}

void loop() {
  if (digitalRead(buttonPin) == LOW) {
    digitalWrite(ledPin, HIGH); // LED ON when pressed
  } else {
    digitalWrite(ledPin, LOW);  // LED OFF when released
  }
}

 

I connected the switch to one of the Arduino’s pins that has the ability to sense if something is being touched. I also used a built-in function that helps the Arduino become aware when the switch is not being pressed. In the code, I instructed the Arduino to switch the light on when the switch is triggered, and off when it’s not. This ensures that the light will switch on directly due to my homemade pressure switch (A foot pedal).

Challenges

One of the main challenges was creating a functioning switch without a supply of crocodile clips, actual push buttons, or normal conductive material. I used paper, copper tape, and jumper wires with some trial and error to develop consistent electrical connection. Getting the copper strips into perfect alignment and holding them together in use took some experimentation. Also, getting a grasp on how to utilize the internal pull-up resistor is necessary to prevent false firing and ensure that the switch is reliable.

IMG_6391

 

This week I decided to create a switch that worked on the basis of water conducting electricity.

With that, I decided to create a switch turned on by the tears of unviersity students.

It was simple: cry enough into the bowl and the LED will light up.

To do this I attached copper strips inside the bowl so that when the water level inside the bowl was high enough the water would ‘connect’ the two copper tape strips into completing the circuit.

Challenges:

One of the challenges was figuring out even if at wall the current would be strong enough to pass through the water.

Another thing was a stupid ‘bug’ where I had used a photoresistor, not a normal resistor, and pondered for a long time why the circuit was not completing.

Future improvements:

One thing I’d like to improve on is to maybe have different circuits of copper tape in such as way that more LEDs light up the more tears there are in the bowl. with 3 lit LEDs representing a full bowl or something like that.

For this weeks assignment, we were asked to create an unusual switch. Passing by the NYU sports gyms, inspiration struck. I decided to create a switch that looked like a basketball hoop, and would light an LED when the ball was in the hoop, thus “completing” the circuit.

For this circuit, I created a basketball hoop within which I implemented wires. I wanted a balance between it actually looking like a hoop, but also still being functional. I wrapped a styrofoam ball with aluminium foil to make sure it would conduct electricity, and thus complete the circuit when the ball was dropped into the hoop, making it the catalyst for completing the circuit.

Upon the successful completion of the circuit, an LED would then light up.

I struggled a bit having the wires stay in place, and ensuring that the ball made successful contact with them everytime. My setup was very rough and could probably have used more aesthetic features, but i was more focused on making sure the idea actually worked. Maybe in the future, it might be worth it to try using copper tape to make sure the switch is completed regardless of the balls position.

Overall, I had fun coming up with an idea, and then implementing it to see whether the circuit would be completed or not.

Video of the switch: https://drive.google.com/file/d/1bRdIRVIdDPK5BbK1ZsrdfVIz8_hRawbn/view?usp=sharing

The remarkable contributions made by Margaret Hamilton to the Apollo moon mission and the advancement of contemporary software engineering are highlighted in the article “Her Code Got Humans on the Moon – and Invented Software Itself”. I had heard about the Apollo missions before reading this, but I had never given much thought to the code and problem-solving that enabled them. It is amazing to see that Hamilton’s contributions not only aided in the successful landing of astronauts on the moon but also significantly influenced the creation of software as a profession. She demonstrated how important software is in high-stakes situations by emphasizing error detection and rigorous programming, which saved the mission when an excess of data nearly led to a failure. This helps me understand how difficult programming is and how much accountability software professionals have to ensure everything functions properly.

Reading about Hamilton’s accomplishments also got me to thinking about how underappreciated certain technological trailblazers are, particularly women in STEM fields. She was doing more than just coding, at a period when there were no official rules or accepted practices, she was establishing the groundwork for software engineering. The difficulty of gaining attention in a male-dominated sector is demonstrated by the fact that she created the phrase “software engineering” in order to have her work considered more seriously. I find myself wondering how many other pioneers have gone unnoticed over the years. Her experience motivates me to believe that programming is about more than simply creating code; it is also about solving problems, coming up with creative solutions, and making sure things work, especially when lives are on the line. I now have a greater regard for the history of computing and the people behind major technological advancements.

I found the initial anecdote of the three teapots to be especially interesting. Norman spends nearly a third of the reading comparing and contrasting them, noting that he might choose one over the others depending on the occasion or his mood. In stark contrast, my first thought was to wonder why anybody would one teapot let alone three. Beauty is really in the eye of the beholder here, since on the rare occasion I make tea it involves a mug and a pre-packaged teabag. Even his mention of displaying them on the windowsill just made me question why he would waste space doing so.

As for the larger discussion on aesthetic/usability and affect/cognition, I have some mixed feelings. The explanation of how the chemicals in your brain can completely warp your perception was very well-done, what with the examples of tightrope walking or opening an emergency door. That being said, the claim that “attractive things work better” feels far too heavy-handed (although Norman himself notes that the claim is heretical). The preceding two sentences mention that a product that looks good will encourage the user to overlook its flaws, and to me that hardly means ‘working better’. You could definitely argue that the emotional aspect could improve the user’s enjoyment, but that is countered by claiming that performance would be better with an uglier, more efficient version. You could also argue that attractiveness helps the product sell, but then you are outright avoiding the point of debate. I would agree more if his claim was about how attractive things face less criticism, and are accepted more easily.

When I first saw the title of this reading, I assumed that it referred to the three mathematicians that starred in Hidden Figures (2016). I was instead pleasantly surprised by a fresh perspective that was similar yet different, and happens to result in the creation of software engineering. As a Computer Science major, it was very cool to see how software was viewed before it became commonplace, and get to learn about the factors that shaped its development into what it is today. It’s still hard to imagine how they managed to put a man on the moon while being stuck in the era where the term ‘physical computing’ was all too literal.

In that sense there is a clear tie-in to our Arduino work, what with having to wire components in by hand and having actual limitations on memory, although thankfully we still have access to an IDE. Even aside from the Interactive Media perspective, I got a lot out of this piece that can apply to the software engineering class I’m taking. For example, having to make asynchronous calls to the backend of our web application and dealing with potential errors. We’re actually currently in the middle of writing system tests for our next deliverable, so reading through the ‘That would never happen’ section was particularly painful.