Physical Computing - Week 3 (24-09-17)

Lab Activity 1 - Tone Output

This week we learned about pulsewidth modulations (PWM), first by exploring more possibilities with tone output through a speaker. The exercise in the lab walked us through how to map the played frequency to the analog sensor's readings. I was particularly interested in the other components of the code, especially the delay.
The audio clip on the left features a 50 millisecond delay, while on the right features a 20 millisecond delay. 

This distortion reminds me of image blurring or pixilation and I imagine using this feature as a form of interaction where the output quality relies on proximity. For example, to properly hear an audio file, the user must use their hand to follow an invisible path (maybe with a phototransistor or distance ranger), and more consistent the user follows the path, the clearer (less delay) the audio file plays.

Next we played with more complex outputs such as melodies and varied notes on different switches. I was curious to see if I was able to combine the two features of playing different melodies with different switches. Ideally, using the same coding structure as the example provided (including a snip-it on the right). 

I couldn't quite figure out how to include the varying melody notes and note durations into a single tone() call function, so I ended up working with what I was familiar with and used if/else statements.

From this, I thought of some other projects that I would like to explore in the future.

• I wonder if there is a way to simplify the code?
• What if I only wanted 1 switch and have it randomly play one of the 3 melodies?
• What if I want to change the quality of the melody depending on the interaction? (force on FSR or distance from phototransistor)

Lab Activity 2 - Servo Motor Control

This might have been my favorite part of this week's labs! Something about a moving object is just so exciting!
I wasn't able to get a wide enough range with the phototransistor and I did not love the interaction from the potentiometer, so I opted to use the FSR with the servo motor. Once I had a decent understanding of the servo motor code, I wanted to build a switch interaction where one FSR turns the motor clockwise and the other turns the motor counter clockwise. To add a layer of complexity, I'd like the motor speed to correlate with the pressure applied on the FSR, (ie, the harder the user presses, the faster the motor turns).

first I started by building code that could control the motor with two different FSRs. One ("rightSensor" on A0) to increment the servoAngle by 1, the other ("leftSensor" on A1) to decrement the servoAngle by 1. Below is the code I used achieve this.

​There is a problem with this code - after the servoAngle reaches its physical limits (0 or 176), if the FSR is still engaged, the servoAngle value continues to update. This code still works, but the farther the servoAngle value gets from the range, the longer you have to hold the opposite sensor to bring it back within range. 

My initial thought was to add a couple more if statements to bring the servoAngle back to the limits (see on the right), but later realizes that its not the most effective way to keep the servoAngle value in range. Instead, at the top of the loop function, I added a constrain for the servoAngle value to keep it within 0 - 176 (see image below). 

proThe next step was to change the speed of the motor in relation to the pressure applied to the ​FSR. 
I did this by creating a custom variable for the speed, so I could map the incrementing value of the rotating "speed" to the sensor readings, which is approximately between 0 - 950. Since the servoAngle does not change unless the FSR reading exceeds 50, I mapped the range between 51 - 950.
​And then finally, I added a delay of 50 milliseconds so that the movements could be more observable in realtime. I found that any delay value more than 100 looked almost "glitchy". See below the video for the final code.

If I have more time to develop this project, I would like to explore the different things I could attach to the motor. Perhaps some sort of moving puzzle that requires intricate touch to solve. Or even the complete opposite where the user may have a ridiculously large interactive interface or object to control the tiny motor movements.