Uncategorized

This week we had to explore integrating APIs into our sketches. Working with data can be really exciting, but as I learned this week, no API is the same and figuring out how to properly use them into your code can be a long learning process. I played around with a lot of APIs, using the New York Times then looking at the MTA and Nasa. I settled on using the weather’s API because I found it the easiest to work with, but even my final sketch is not as well laid out as i’d like it to be.

I created a button with an input box allowing for anyone to enter a city and find out the current temperature at that place. I did not know how to change the weather output from the weather API from Celsius to Fahrenheit. I figured most of the world uses Celsius, so maybe that was better to use anyways.

Link to sketch can be found here (you’ll need to enter your own API key)

 

For our physical computing midterm, we had to come up with an interactive Halloween project. I worked with Carol and Mark to create a fortune telling mirror that predicted when and how you would die. We recorded scary voices saying to “come closer” and “I have something to tell you” that would prompt the person to come closer to the mirror (if they weren’t already scared by the voices) to read their fortune. The fortune really just served as a distraction to the person, where once they read their reason for “death”, would then be scared by a sudden loud scream and a scary image of a possessed little kid.

Final Project:

The Process

Phase 1 – Creating the Mirror:

We bought a double sided mirror that would be able to show a display behind it. We then created a frame for the mirror by laser cutting cardboard that would fit the dimensions of the mirror and the screen we wanted behind it.

 

We used distance sensors connected to the Arduino that would trigger the scary scream and image once a person came within range of the mirror by using serial communication between the Arduino and our P5.js sketch. The sketch would remain black unless triggered by the distance sensor to produce a fortune with a two second delay before the scary scream and image would pop up on the screen. 

Phase 2 – Troubleshooting:

We encountered problems with our sensor and broke one of them, making us replace it with another. We still had problems with the scream and the image being triggered even if no one was close by as well as it flickering on and off really fast. This was not a popular project for those next to us as other ITP students quickly got sick and tired of having to hear our scary screams and voices.

Our other problem was having an ipad correctly access the local host. While the sensor and the P5.js sketch worked fine locally, when we tried to use the ipad behind the mirror for the finished project, it was less stable and would often get stuck on the scary image of the child, with the sensor not working correctly, but flickering the image (and it’s values).

Arduino Code:

//Libraries

#include “Ultrasonic.h”

 

//Define pins ultrasonic(trig, echo)

Ultrasonic ultrasonci(A0, A1);

 

//Variables

int distance;

 

void setup() {

Serial.begin(9600);

}

 

void loop() {

distance = ultrasonic.Ranging(M); 

//print distance

Serial.write(distance);

delay(500);

}

We did a lot of testing locally on the computer and alone with the sensor to make sure that everything worked. Our biggest hurdle was getting the sketch and sensor to work correctly when we transferred it over to another screen or ipad. In the final project (displayed in the video at the very top, beginning of this post) we ended up using a monitor that was displaying the P5.js sketch from Carol’s computer because of the problems we encountered with the ipad.

This week, I used existing sketches to clean up and organize them by converting my functions and other code into classes, allowing me to repeat my object/drawing multiple times. This was a great exercise for me because it made me think about not just being able to create classes but also be able to convert functions into classes and clean up existing code.

I had some trouble initially, but with some help (thank you Luisa!) I was able to convert one of my sketches into workable code by classes. You can see the full sketch here.

My first problem in converting the sketch was only one of the bubbles showing up, with the other two being static white circles (seen in picture below):

I didn’t know why this was and Luisa helped point out to me that my ordering of calling the class methods, was wrong. I was calling the “moveColor” before the “display” which was causing the white static circles. After changing this, I was able to get the desired result:

 

(I don’t know why my screen record slowed down the bubbles – maybe because I had too many things running in the background)

After, I tried converting another sketch into classes, but this sketch had more different variables and functions to convert, making it slightly harder. I feel like I organized the code right, and when I run it i get no errors, but I cannot figure out exactly what is wrong that is making the sketch not show.

Link to the sketch attempt here.

Labs with Tone Output: This week worked with analog output. I used tone as an output as well as different sensors such as a light sensitive sensor to change the tone’s frequency.

Below is a video from using tone output with a potentiometer to vary the frequency change.

I then changed the potentiometer to a light sensor to vary the frequency on the tone output, also seen below:

My hand covering the light resistor, lowered the frequency (covering light from coming in).

 

Creative Project: I decided to create a box that opens with a servomotor controlled by a potentiometer:

For people too lazy to open the tea box themselves, or maybe a candy dispenser.

Materials: Lipton tea box, two Q tips, Arduino Uno, servomotor, potentiometer.

Problems: The box lid was too light, so it was always slightly open making the servomotor’s effect not as visible. I tried fixing this by taping a penny onto the lid to make it slightly heavier.

The servomotor responded to the direction of movement by the potentiometer, but sometimes it would also jerk quickly in the opposite direction. I don’t know if this was a problem with my servomotor? However, the next day, it didn’t repeat this problem (code stayed the same).

I had to keep tweaking my values with mapping in the code while also adjusting the servomotor correctly so it would open and close correctly. I think what confuses me the most is knowing where the 180 degree angle starts and ends on the servomotor?

Code: Code was taken and adapted from Arduino.cc

//first include servo library

#include <Servo.h>
Servo servoMotor;

void setup() {

//Servomotor is attached at pin 9 on Arduino
servoMotor.attach(9);

}

void loop() {
int sensor = analogRead(A0);
//mapping servomotor angle to 180 from sensor
int servoAngle = map(sensor, 0, 1023, 70, 180);
if(millis() %20 < 2) {
servoMotor.write(servoAngle);
}
}

Schematic Diagram of Phase 1 (before tone was added):

Building Process:

Phase 1: I Connected the servomotor and potentiometer to the Arduino with the correct wiring and put the servomotor in the tea box.

Phase 2: Below is a video of opening and closing the box with the servomotor. I was tweaking the numbers in my map function in the code to get the angle right. There was a problem with my paper and coin getting in the way – I’ll have to smooth out the surface.

Phase 3: I covered the box in paper, to smooth out the surface so nothing interfered with the servomotor from opening the box smoothly. I then tried adding an alarm system (tone output) to my project. 

I added to my code to make it so that when the servomotor was at an angle (so that the lid was open), the alarm would sound. I made the tone to sound anything above 170 (out of 180), but when I tested it, the sound was constantly buzzing. I didn’t know what was wrong until wrote: Serial.println(servoAngle) and looked at the serial monitor and realized when the servoAngle was at 0, it was opening the box, so I had flipped it (thinking 180 was the servoAngle opening the box). Knowing this, I adjusted the numbers and got it to work! 

New code bit added below:

if (servoAngle >=5 && servoAngle <=30) {
tone(5, 700);
} else {
noTone(5);
}
Serial.println(servoAngle);
}

Final Phase: Below is a video of the box opening and the alarm sounding when it is fully opened:

I still experienced a lot of jittering with the servomotor, even when I wasn’t touching the potentiometer and also when I added code to delay it:

This week we played around with loops, functions and classes. Below is a sample of following Shiffman’s videos and using this on creating multiple bubbles without having to write out each individual bubble.

I then tried experimenting with creating circles using cos and sin to make them turn around continuously.

Then I added nested loops to create rotating circles that covered the entire screen (for both the horizontal and vertical planes).

Played around with the fill color on a greyscale…

Then I changed my circles into a function of their own and played around with a grey scale gradient along each of the circles.

The final code and sketch can be seen here.

Overall, I’ve started to understand functions and loops, but still need to practice more with classes and converting existing functions into classes.

I had a lot of trouble this week with writing the correct code to alter the LED switch so that it would need a combination lock (of 3 clicks) to turn the red light to green.

First, I followed the lab for creating a button to switch LED colors, seen in the video below:

Then, I tried to take the basis of this code and alter it slightly to make it so that in order for the light to turn from red to green, the button had to be pressed three times in a row. At first my code got errors:

One of the mistakes from this code was a misspelling and also, according to the error message, I was not declaring digital read in the scope. I changed the code again, this time there was no error message, but I was still not able to get the light to change to green with the press of the button three times.

What I was trying to do was make it so that digital read would have to be equal to button pressed, which was true only when the button was pressed three times. I’m not sure if I was going about this in the right way or if I needed to put it on a counter instead that was positive in groups of threes? Logically this is what made the most sense to me, but I may have approached this problem in the wrong way.

Update: I did some digging into the resources on the Arduino website and realized what was wrong with my code was the lack of a state change detection. So I changed it and had to mess around with adding an int for two LEDs and I wanted to make it so that the light was always red, unless the button was pressed three times, which would make it change to green. I had to mess around with the code and where to place the ”  digitalWrite(ledPin, LOW);
digitalWrite(ledPinn, HIGH);” codes in my Arduino code. The video below shows the final product (nothing too special, but it made me understand the state change in relation to adding LEDs and buttons (pushed multiple times).

Note: I also made many mistakes from stupid things like, not properly uploading my new code and only saving it or realizing the Arduino was not plugged it.

Like the lab below, I could not figure out what was wrong for the longest time until I realized I was not uploading the new code properly (only saving it).