Intro to Phys Comp: Final Ideas

I want to get my hands dirty with interactive storytelling, so I want to create a project that allows the user to be a part of a film. An idea I have is a Car Chase Simulator. 

The user interface would be the obvious car parts: a steering wheel, a gas and brake pedal, and a gear shifter. There would also need to be a screen to display video, preferably a wide one to simulate the front windshield. The user would start the movie by starting the car. As the user controls the wheel and pedals, the movie changes to different scenes. There would be a large collection of car chase footage from famous movies, so when the user turns left, the scene would change depending on the current state of the movie.

Just thinking about the process of creating this project is giving me a slight panic attack. Although I have a good idea of how all the user inputs would work, the thought of recreating the interior of a car and collecting hundreds of car chase movie clips, and editing them, and then coding the logic... It's a lot of work! But I think it's doable with the skills I currently have. This project would combine a lot of the skills I have and are learning at ITP.

Intro to Phys Comp: Spooky Midterm

Halloween isn't scary enough these days. My partner Rogue and I wanted to create something that would shock and frighten. We created something not of this world. We created... a ghost.

AKA a silhouette of a Halloween mask that follows you around. Spooky!

Since the midterm project was to be Halloween related, I wanted to make something that would primarily be used in the dark. We ended up deciding on a device that detects a user walking along a surface, and depending on where the location the user is currently at on the surface, project a shadow at a corresponding location on the wall.

Our main component to detect the user interaction would be several FSRs embedded underneath a cardboard walkway. The input data from these FSRs are then used to light up specific blue LEDs. The LED will light up depending on which FSR the user has currently applied pressure to. The light from each LED would then cast a shadow off of a central mask, creating a silhouette on the wall.

The circuit design of this project was fairly simple, however the hard part was implementing it into something tangible that a user could use. Our project required a lot of space which was something that Rogue and I were not too accustomed to in our past physical computing projects. The most difficult part was probably the angling and positioning of the lights in order to cast a nice silhouette on the wall. Below is a short montage video that details the process of how we built this project.

Documentation for Ghost Stalk

Issues/Stuff we wish we could have done better

Rogue and I ran into a lot of issues that we had to compromise with in order to finish the project. We had originally intended for the mask to also move by using a servo motor. The motor would then move as the user walks through the cardboard path. Unfortunately, when using the Servo library in Arduino, two pins are disabled (9 and 10). This loss of real estate would not allow us to use the four LEDs, so we decided to do without the motor for now. A solution to that problem was to perhaps use another Arduino board. 

We had also originally wanted to use Red/Yellow/Orange LEDs to cast the light since it fit more with the theme. However, the silhouette created by these warmer colors were not as clear as the blue LED lights, so we had to again scrap an idea. Jeff mentioned how a stronger light source would have made the project much better and I agreed. I hope we learn how to implement stronger components to our projects in future classes.

Overall, the midterm project was an amazing learning experience for me. Being able to turn a kind of silly idea into a working prototype in such a short amount of time was something I had doubts on. But now I know I can do it! Thanks again to Rogue Fong for being a great partner. 

Intro to Phys Comp: Serial Input

I decided to control an ICM project that's still a work in progress. I used two potentiometers as analog inputs to control the movement of an ellipse and a line.

For the Serial input, I used a ":" as a delimiter to separate the two analog inputs. I then mapped 

In p5.js, I used the split function to grab the two analog values of the potentiometer. I then mapped the values to a range that's suitable for my sketch. One value controlled the amplitude, the other value controlled the frequency.

link to p5

The end result worked exactly as how I expected. Having the option to use multiple analog and digital inputs opens so many possibilities for future projects. Because I will be continuing to work on this p5 project, I have many ideas of how to incorporate physical input to its final form.

ICM + PComp: Synthesis

For the synthesis, Stephanie and I implemented a physical analog input into our previous p5.js projects. For Steph's project, we used an FSR to simulate her rain sketch. The harder the FSR is pressed, the more the rain falls.

As for my project, I used a potentiometer to control my "Repetition" p5.js sketch. (https://alpha.editor.p5js.org/projects/SyZG0BV6)

I had some trouble setting up the connectivity between the Arduino and the p5 library, but eventually got it after some troubleshooting. In the original sketch, I controlled the animation by holding and releasing the mouse button. After reading the values from the analog input of the potentiometer, I changed the original code of the sketch to control the animation based off those physical variables.

https://alpha.editor.p5js.org/projects/SyZG0BV6

Intro to Phys Comp: Analog Output

Mega Man was my inspiration for the lab this week.

During last week's class, the analog sound output reminded me of Mega Man's charge shot sound effect. So I decided to create a toy that kind of replicates all of the functionalities of Mega Man's blaster... sans the blaster part. I had some old gloves lying around, so I figure I'd use that as the form for my project. 

I sat and stared at my hand for longer than I would have liked. It was very difficult for me to wrap my head around designing the circuit around my glove. After wrecking my brain for a good half hour, I decided to set up the project on my breadboard first.

Setting up the project on a breadboard was surprisingly easy. It didn't take long for me to create the circuitry of what I wanted in my head. I used the FSR as an analog input, and several LEDs and a speaker for the analog output. As the user presses down harder and harder on the FSR, the brightness of the lights and the pitch of the sound coming from the speaker both get higher. This is to simulate the "charging" of the toy gun. And then depending on when the user lets go of the FSR, a "blast" sound will output. The type of sound depends on the number of LEDs that the user manages to light up. 

Now that all I had to do was "copy" what I had just done, except onto a glove. Now that I had a template, it was much easier to implement. I had to learn some new tricks, such as soldering wires to my FSR. I also used some conductive thread, which I didn't think was necessary, but thought what the heck. It took me a decent amount of time to connect it all, especially since I only one had for most of the time since my right hand was often used as a mannequin.

I definitely did not do everything as efficiently as I could have, but I think it was a good learning experience for me to kind of hack my way into getting what I wanted done. I'm sure to ask a little more help from my more experienced peers next time. I need to improve on how to present my prototypes a bit more aesthetically. 

As for the Arduino code, it wasn't too complicated. I used some of the logic from my previous piano project to detect when the user has released the FSR. Other than that, the major difference was that I had to map the range of values needed for the brightness and frequency. I mapped the brightness to several ranges in order to get the LEDs to gradually increase in brightness one by one. Below is the code:

Intro to Phys Comp: Observation

I chose the elevator at ITP to observe for this week's assignment. One aspect I have always enjoyed about an elevator is that it gave a physical feedback that is uncommon in most other technologies: momentum. Although momentum is found in almost every mode of transportation, an elevator is different because there are usually no windows. You must rely on your sense of momentum to determine if something has gone horribly wrong.

Assumptions and expected results:

People request an elevator to go up or down. They get in the elevator and select the floor they wish to go on. Once enough time has gone by with no interruptions, the elevator goes to the desired floors. The doors open and the person exits. It is always used when a person needs to travel vertically within a building.

Some observations:

• A solo ride takes approximately 20 seconds from door opening to stepping outside of the door on the fourth floor. A group ride right before class takes 45 seconds, more than double of that.
• Riders almost always face towards the door, unless they are with friends.
• The time it takes to wait for an elevator varies depending on the current status of the elevator. It has taken up to 95 seconds at times.
• The behavior of the users also depend on the order they get into the elevator. Early riders will always press the button they wish to get on. Late riders were more often to check the light that indicates a pressed floor, but they usually press the button regardless. 

A design flaw I noticed is that the complexity of the elevator increases depending on the number of people simultaneously using it. There is also the issue of people having to squeeze through others in order to get off on their floors. This is a big problem with the large elevator in ITP due to it's shape. Unlike most elevators which have the door centered, the large elevator at ITP is off to one side of the rectangular space inside. This makes it harder for the other riders to move aside for riders that need to disembark the elevator.

In the readings, there was detail on how aesthetics can make a design feel so much better to a user, even if the functionality remains the same. I can immediately relate to this in regard to elevators. The elevator for my apartment building is very new. It's silver, shiny, and glossy. Even though the functionality between the elevator at ITP and my apartment are approximately the same, the elevator in my apartment feels cold yet luxurious while the elevator in ITP feels familiar and a bit rundown.

Intro to Phys Comp: Week 3 Lab

Below are the on and off states of the Digital Input and Output with Arduino lab. It was fairly simple to set up physically on the breadboard and digitally in the code.

The creative lab was to create a combination lock of sorts. This reminded me of a scene in the movie Batman Begins. Bruce Wayne opens a secret entrance to the Batcave by playing several notes on a piano. I knew I couldn't unlock a secret entrance (yet), so I decided to tweak the idea a bit. However, I first needed to create the "keyboard."

I repeated the switch portion of the lab multiple times to create the keys on a typical piano. I then connected them to different pins so that I am able to digitally read whenever each switch was pressed. The coding portion was also relatively easy since it was just repeating the same lines of code for the additional pins.

I then moved on to the audio portion of the project. I wasn't sure how sound worked in Arduino, so I looked at the toneMelody example in the IDE. This example played a simple melody. In this example, it used an external file called pitches.h that contained all the musical notes. I only needed a couple (C-G) so I just looked for the values of these constants to use in my project. 

Now that I learned how to implement these sounds in the code, I needed to figure out how to physically play the sound. I didn't have a speaker, so I went to the shop to look for one. The person at the help desk (Aaron) helped me greatly by hacking together this makeshift speaker from a broken pair of headphones. I treated the speaker like an LED light since I figured that digital output, sound or visual, should be the same. I then assigned each switch with it's own pin. And by using digitalRead, I would play a specific tone out of the speaker whenever a respective switch is pressed. 

I found that the switches didn't really give me the feel of a piano keyboard. So I got some cardboard, cut some flaps to represent keys, and created a very crude keyboard. I then took off the switches for each pin, and taped the negative wire to the bottom of each flap. I then used a long piece of foil and connected a single wire that connected it to the positive current. By pressing down on the flap, the ends of the wire would touch the foil and complete the circuit for the pin.

I learned that wire management is an artform in itself. Although it worked, my project looked incredibly messy with all the different length wires. I decided to clean it up a bit, which took quite a bit of time since I had to rewire everything on the breadboard. This taught me that I definitely need to prepare and carefully plan the positioning of my components and wires for any future projects.

As for the combination lock assignment, I coded it so that when a specific sequence of notes are played, a secret song would play out. In this case, if the first five notes of "Mary Had a Little Lamb" was played in the correct sequence, the combination is complete and it "unlocked" the rest of the song. 

The most difficult part of the project was to figure out how to detect when a note is played once. Since everything is in a very fast loop, I couldn't just digitallyRead whenever a certain pin was read as HIGH because then the combination sequence wouldn't work. I needed to figure out exactly when a note was pressed AND released. I eventually figured it out by keeping track of two global values that detect when a key is pressed and released. Another obstacle was debugging my project. My combination lock logic was not completely working at first. I ended up adding a lot of printlns to the console in order to figure out what was going wrong. I have added the code below.

Intro to Phys Comp: Week 2 Lab

The lab this week was a great learning experience for my introduction to physical computing. Since I come from a background of software engineering, I am used to testing my work with little consequence. Physical computing is NOT the same. I am sorry, my poor green LEDs. I did not mean to burn you and your brothers out. Eventually, I was able to get the current voltage for the LEDs via resistors and choosing a lower voltage from the Arduino chip. I hope it gets easier!

Intro to Phys Comp: Physical Interaction

I agree with Chris Crawford when he said that interactions should be a measurable attribute, rather than a binary yes or no. Like a conversation, the amount of physical interaction also depends on the amount of effort put into listening, thinking, and speaking by both "actors." This effort goes along Bret Victor's proposal on how the human body contains an infinite-like amount of interaction output methods and we should not limit these interactions to only our fingers. I define physical interaction as a sliding scale that measures the combined effort that actors communicate among each other. You can think of it as how "in love" these actors are with each other. When the communication is forced and awkward, there is no second date. But when that spark appears, and conversation is seamless and enjoyable, that is when physical interaction would be at its best.

Now that I think about it, there isn't very much digital technology that would be considered something with high physical interaction. Like Victor said, we rely so heavily on our hands that we often forget the rest of our body. I think that smartphones are surprisingly not as physically interactive as they should be. The only recent feature I could think of that gives feedback to the user would be Apple's 3D touch, and even that feature is kind of wasted since it is typically used to the exact same extent as a long hold press. Although having more haptic feedback is a step in the right direction, the step is far too small for my liking.

Nitish, Ari, and I worked on creating a self sustaining shoe for our fantasy device. Although our first major concern seemed to be how a shoe could self sustain itself, we also started to think of ways the shoe could act as a sort of "smart" shoe.

After the readings, I started to think of what physical interactions we could implement to such a shoe. I immediately thought of using toes as a method of input. People who have lost their arms have learned to adapt and utilize their feet and toes to do tasks that many would find difficult without hands. I think that studying the behavior of those who are forced to change the way they interact with the physical world could reveal interesting possibilities for future technologies.