Prototypes: Invision-ing

Let me begin by saying that Invision is not my friend. I haven’t used it much, and boy, if anyone tells you there isn’t a learning curve, they are lying. That being said, I think that working through this process has been enormously helpful to me. Even being able to show the prototype to my parents has reveals interesting pitfalls and insights (more on this later). These prototypes sit pretty evenly between the look/feel and role/interaction arms of the triangle. I prototyped look/feel alone in some sketches (see this post to explore that process), but I felt that it was important to test the relationship between the graphic design and the navigation. I’m hoping to use a unique but potentially non-intuitive system of navigation between the nodes and home menu. The purpose of this prototype is to see if users are confused by the navigation system, which is tightly tied to the graphic design.

Within the invision, there are two seperate prototypes. The first is in the yellow and purple color scheme and uses the logo in the upper left as its menu. The second is in the white and purple scheme, and uses a limited search bar as its menu structure. In this prototype, the logo on the left acts as a home button. I’ve also considered switching the search bar out for a standard hamburger menu (prototype coming soon).

I intend to do more intense user testing and several observations and walkthroughs over break, but initial responses are lukewarm at best.  While I was working, my dad looked over my shoulder and immediately said, “What is that egg supposed to be?” I was, at the time, working on the close up of the story node my initial color scheme (purple and yellow, to add warmth). It is supposed to look like a star, but it really does look like an egg. I created a second invision using white and purple and changed the node display to a much larger circle, both giving me more room for text, and making it look less egg-like.

My dad is a UX/UI design lead for a large education company, so he tends to be a bit traditional when it comes to user interface design. My mum has no interest in UX/UI at all. She just wants the website to make what she wants to do easy and obvious. This makes her a perfect tester. After giving her a short description of the project, I gave her the first screen of my invision prototype and asked her to interact with the website. The first screen doesn’t have much in terms of direction—it is just a field of stars with a logo in the corner. It took her a long time to figure out that she could click on the stars, and she said that if she had encountered the site as a user, she probably would have left it before she thought to do that. We talked some more about how I could make the fact that the stars are “buttons” more obvious, and decided that if they pulsed and the titles flashed when the user first loaded the webpage, she would be much more likely to click on them.

I’m looking forward to doing more intense usertesting on both the white and yellow color schemes, but the menu system is my largest concern. If users can’t figure out how to navigate the site, it isn’t much use at all.

Check out the invision prototypes here.

Prototypes: Sketchy

Sketching is always a good place to start a project. The objective of this prototype was to begin outlining the visual appearance (look/feel) and basic interaction (role) of my capstone project. I only drew a few slides, but they were enough to walk my interviewees through the general concept of the project.

The sketched artboards are below:

(Artboard one shows home, the menu, a search bar, and hesitant “star” groupings)

IMG-1639

(Artboard two shows what happens if you click on a star. It expands to fill the screen, and the text of the story is written on the star.)

IMG-1640

(Artboard three shows the utopia linked to the story in the previous star. It is accessed by clicking “And so I dream” or whatever text on the bottom of the previous page.)

IMG-1641

And here is a rough information architecture that I came up with as I sketched:

IMG-1642

Initially, I was really convinced that this was the “right” graphic and artistic style for this project, but as I go, I’m becoming less convinced. This means that more sketches will probably be coming, so stay posted.

 

Project 2: Milestone 2

Component hierarchy, states, and props: We are using three components in our advent calendar app. They are (from largest to smallest) Calendar, Day, and Fact. Calendar is the holder for the 25 days and is responsible for rendering them. It has a state called today that gets the date. Day takes today and day as props. Today is from Calendar, and day is the number that Day represents. Day checks if today is less than or equal to the day clicked, and if it is, Day’s state, access, switches to true. Fact is only called and rendered if access is true. Fact takes the day (Day’s prop) as a prop as well. Fact contains an array of objects with day and fact as keys. Fact then gets the fact from the prop, day, passed to it and renders that fact.

The static version of our app is currently on the server here: http://creative.colorado.edu/~alfa8405/FED/Projects/Proj2/

Team and responsibilities: Ally Faller and Sophie Foster

Both: Work through logic, find facts, individually prototype design.

Ally: find and add facts

Sophie: fight with flexbox

 

Project 2: Milestone 1

Description:

This project will be an online advent calendar to countdown to Christmas! Our inspiration is the physical advent calendars that we (myself and Sophie Foster) both had and enjoyed as children (and also now). The intended audience for this project is people who celebrate and adore the holiday season, and either don’t want to invest in a physical advent calendar or enjoy having as many advent calendars as possible. Essentially, this calendar will work by having a visual of a traditional holiday scene overlayed with little date boxes. When the user clicks on the box with the date, the advent calendar will reveal a note with a fun holiday fact or story for the user to enjoy. The site will also link out to other fun games for kids and adults to enjoy, so the advent calendar has a “prize” in the square in the form of a new game in addition to the fun fact. If the user clicks on a box with the wrong data (to far in the future), the site will not permit them to open it. However, they can return to all previously “opened” dates at any point.

Content and sources: 

 

Visual Design: 

We are considering a few different color palettes. Christmas colors can be a little overwhelming, so the palette may change in the final implementation of the design. The three palettes below are currently my top choices.

Screen Shot 2019-11-17 at 10.46.39 AMScreen Shot 2019-11-17 at 10.46.44 AM

A very rough sketch of the layout and the interaction is included below. IMG-1605

We may also consider adding more functionality like an interactive Christmas shopping list, but that is dependent on how smoothly creating the advent calendar goes. There are a few big hurdles to clear when considering how to create the calendar in a sleek, aesthetically pleasing, and fun way using react. Once we have successfully done that, we can add additional functionality.

 

 

Team Members:

Ally Faller and Sophie Foster

 

Lab 5: Motor Control

In this lab, we focused on motors! We used DC and Stepper motors (which is a bummer because we are using a continuous servo in our project..). The motors were pretty fun, though the schematics made me feel super blind.

Part 1: DC Motors

First, we worked with the DC Motor. The wiring was a touch easier, though the code was a bit harder. The [very very complicated] schematic looks like this:

IMG-1594.JPG

When working with a DC motor, if you want to change directions, you have to use an H-bridge. The H-bridge essentially just switches the flow of electricity through the motor, which allows it to change directions. The switch changes the direction of the motor, as is visible below.

The code that makes the motor run is here:


void setup() {
// put your setup code here, to run once:
const int switchPin = 2; // switch input
const int motor1Pin = 3; // H-bridge leg 1 (pin 2, 1A)
const int motor2Pin = 4; // H-bridge leg 2 (pin 7, 2A)
const int enablePin = 9; // H-bridge enable pin
pinMode(switchPin, INPUT);
pinMode(motor1Pin, OUTPUT);
pinMode(motor2Pin, OUTPUT);
pinMode(enablePin, OUTPUT);
digitalWrite(enablePin, HIGH);
}
void loop() {
// put your main code here, to run repeatedly:
int switchRead = digitalRead(2);
if(switchRead == HIGH){
digitalWrite(3, LOW);
digitalWrite(4, HIGH);
} else{
digitalWrite(3, HIGH);
digitalWrite(4, LOW);
}
}

view raw

DCMotor.ino

hosted with ❤ by GitHub

Looking at it, it seems really simple, but it definitely took me a moment to figure out that I needed to use digitalWrite and how to initialize the enable pin.

Part 2: The Stepper

The coding for the stepper motor leans pretty heavily on the stepper library, but the complicated schematic definitely took a moment. I used every single wire I had (and some random solid core wires, which was… fun. The schematic is here:

IMG-1595

The code is here:


#include <Stepper.h>
const int stepsPerRev = 505;
Stepper myStepper(stepsPerRev, 8,9,10,11);
void setup() {
// put your setup code here, to run once:
myStepper.setSpeed(60);
Serial.begin(9600);
}
void loop() {
// put your main code here, to run repeatedly:
Serial.println("clockwise");
myStepper.step(stepsPerRev);
delay(500);
Serial.println("counterclockwise");
myStepper.step(-stepsPerRev);
delay(500);
}

view raw

stepperCode.ino

hosted with ❤ by GitHub

When I got the motor working, the circuits looked like this:

IMG-1588

IMG-1593

IMG-1592

IMG-1591

The motor turns a full revolution (either 32, 2037, or 500 steps, depending on what data sheet you read), pauses for 500ms, and then reverses direction.

Overall, this lab went medium-smoothly! I can only hope that the motor work in the project will be as friendly.

Project 1 Milestone 4: How’d it go?

This project was a squeeze for me. Like all coding projects, I ended up spending around thirty hours fighting with a single javascript function that just refused to do what I wanted. Eventually, I am sorry to say, I surrendered and did the best I could with a hacked fix. Post-project, I’ve done more research and now have a better idea of some possible solutions. Too little, too late though, I suppose.

My thirty-hour bug is in the google books API. I used JQuery for all of my JavaScript code, including the API, which may have been a mistake. The way I currently have it set up, the function just appends the name, author, and thumbnail image of the book to an empty div. What I would like to do is place each book’s information in its own div. This doesn’t sound that difficult, but believe me when I say I tried every possible combination of placement for declaring and appending divs within that function and nothing worked. Either I ended up with a bunch of empty divs (because JQuery automatically closes tags for you…usually nice, but not in this case) or with book one in a div, then book one and book two in a div, then book one, two and three, and so on. There were a couple of other variations of results, but essentially nothing that I wanted. My solution was to set the images to a certain height, then set the div to a certain height and use flowbox to force them into the arrangement I liked. It mostly works (on my screen) but gets a little messed up if the screen is too large. This is how it looks on my computer:

Screen Shot 2019-11-05 at 8.17.03 AM

There were a few other bits that I could have used the time to fine-tune—essentially I think all of the issues I encountered would be totally solvable if I had another fifty or so hours to put into the site. Sadly, I do not.

Regarding things that could have been improved on the creative side, I would love to change up the information being offered. If I were to do it again, I think I would spend a little more time thinking about the information architecture and purpose for the user. I think the site is okay, but there are certainly more and different features that I could add to make it more functional and appealing. Next time, I think some beta testing or user testing would be really good on a conceptual level. This would probably come in the form of chatting with people about barriers to getting out into nature and how those can be overcome. As it is, I feel like I’ve just consolidated information from a bunch of different government websites. Maybe a good thing, but it could probably be more useful.

On to the positive things!

I think it is visually appealing, which is nice. The style is pretty cohesive. It could be more energetic, but the point of the message is the ways nature can soothe the brain, so I think the calm aesthetic does pretty well.

Screen Shot 2019-11-05 at 8.14.24 AM

Technically, I’m happy with the way the toggle works for the text on the first page. I think that is very clean. Figuring out the this.next thing took a bit of effort and presented some challenges when it came to changing the images. At first, the image of the brain was always going to be static, but then, in the first round of feedback, my team mentioned that it would be cool if the image changed based on the text. This was a last minute addition for me and took some figuring out. I thought I had it solved with this.nextAll() in JQuery, but I was using CSS grids to style the image. With my grid, I needed the new image to be in the exact same place as the old image, which meant that it had to be a direct child of the grid. However, nextAll() only works on siblings. This means that the image had to be outside of the sections and nextAll() would not work. I figured out a different solution (which I could definitely fine tune—it could be cleaner and has some logic holes) using a new and interesting method of passing arguments.

Overall, I’m not completely thrilled with the final result. I sunk too much time into parts that didn’t end up working and were minor details, which allowed some larger elements to be less polished than I would really prefer. But, that being said, the aesthetics are nice, and I learned a lot!

Object Lab 4: Serial Communication

This may take the cake for the most frustrating lab yet. I thought I knew how to code in JavaScript, but no, p5.js was out to prove me wrong. I could get approximately nothing to do what I wanted. So, I suppose let’s start at the start, and go forward from there.

The first part of the lab asked us to make sure that the arduino was able to take information from two analog inputs and send it (via serial) to p5.js. This whole process is a little non-intuitive for me because you have to actually use serial.print within the arduino to send it to p5.js, but you can’t open the serial monitor. (Serial can only be used by one application at a time, so either the p5.serial.control app or the arduino serial monitor.) Then, you have to use console.log within p5.js to make sure that you are receiving correctly. The proper format is to separate the values from the two potentiometers by a comma, then have a line break at the end of each reading (450, 220 /n). P5 can read this in (as a string), then stores it in an array. Below is the schematic for my circuit and a video of my p5 console printing out the values the arduino sent via serial.

IMG-1567

The next step was getting p5 to talk back to the arduino, which is pretty simple. From the p5 side, it is as easy as serial.write(); In arduino, I included an if statement to make sure that there was actually data coming in from the serial communication. If there is and it is greater than 0, the light on pin 9 flashes. Here is a video of the light flashing when I push the key “R”. The write is included in my keypressed function, which only looks for the key R, so the light only flashes when R is pressed.

Finally, I needed to use p5 to make a game. I thought of several ideas and made some sketches before finally settling on the idea of a maze game. I wanted the user to navigate a ball through a maze to the finish. Easy, right?

No. Not easy at all. Turns out that adding physics in p5 was going to take a LOT of lines of code. So basically, making the ball (controlled by the potentiometers) bounce off the walls of the maze was way too much. So, I changed my mind and decided to make a drawing game, where the user drew a path using the ball to a final destination. After several hours of work, I got to the point where I could get p5 to eternally draw a rectangle that followed the ball around. Not at all the point. The issue here is that the draw loop is on eternal repeat, so it updates the position of the rectangle every time you move the sensors. I couldn’t figure out a place to put a boolean statement that made it so that the rectangle was only drawn when the key was pressed and STAYED in that location. Very frustrating. Then, I decided I would make a game where all of the rectangles would change into different colors when you clicked on them, and the point of the game would be to make all the rectangles the same color. (P.S. by clicked, I mean hovered over them and hit the “R” key.) Well, the fill command changes the colors of all the rectangles, not just one, so they all change color simultaneously, making the game really easy. I figured out how to make each rectangle a different color using an array of colors and a for loop, but then the nightmare that was trying to figure out which color it is so you could change it on keypress defeated me. Then, I finally landed on the current game (which sucks, but you know what, I’ll take what I get).  The point of the game is to find the rectangle that makes all the other rectangles disappear. They all change color together, but they all turn different colors. Here is a video of my rather lame game:

And here is the code that makes it run from p5:


/*
This P5 sketch is a template for getting started with Serial Communication.
The SerialEvent callback is where incoming data is received
By Arielle Hein, adapted from ITP Phys Comp Serial Labs
Edited March 12 2019
*/
var serial; //variable to hold an instance of the serial port library
var portName = '/dev/cu.usbmodemFA131'; //fill in with YOUR port
var sensor1;
var sensor2;
var pot1;
var pot2;
var placeR = 0;
var placeR2 = 0;
var counter = 1;
var circlesize = 50;
var drawRect = false;
function setup() {
createCanvas(600, 600);
serial = new p5.SerialPort(); //a new instance of serial port library
//set up events for serial communication
serial.on('connected', serverConnected);
serial.on('open', portOpen);
serial.on('data', serialEvent);
serial.on('error', serialError);
serial.on('close', portClose);
//open our serial port
serial.open(portName);
//let's figure out what port we're on – useful for determining your port
// serial.on('list', printList); //set a callback function for the serialport list event
// serial.list(); //list the serial ports
}
function draw() {
background('purple');
var circlesize = 50;
//make circle follow potentiometers
pot1 = map(sensor2, 0, 255, 0+circlesize/2, width-circlesize/2);
pot2 = map(sensor1, 0, 255, height-circlesize/2, 0+circlesize/2);
ellipse(pot1, pot2, circlesize);
//make many rectangles that all change color
rect(0, 0, 50, 50);
rect(100, 100, 50, 50);
rect(200, 200, 50, 50);
rect(300, 300, 50, 50);
rect(135, 450, 50, 50);
rect(200, 300, 50, 50);
rect(300, 400, 50, 50);
rect(500, 200, 50, 50);
if(placeR < 170 && placeR > 130 && placeR2<480 && placeR2 >440){
fill("black");
}
if(placeR < 230 && placeR > 180 && placeR2<330 && placeR2 >280){
fill("green");
}
if(placeR<330 && placeR >280 && placeR2<430 && placeR2 >380){
fill("blue");
}
if(placeR<530 && placeR >480 && placeR2<230 && placeR2 >180){
noStroke();
fill("purple");
}
if(placeR < 140 && placeR > 80 && placeR2<140 && placeR2 >80){
fill("orange");
}
if(placeR < 230 && placeR > 180 && placeR2<230 && placeR2 >180){
fill("white");
}
if(placeR < 330 && placeR > 280 && placeR2<330 && placeR2 >280){
fill("pink");
}
if(placeR < 80 && placeR > 0 && placeR2<80 && placeR2 >0){
fill("grey");
}
}
function getLocation(){
placeR = pot1;
placeR2 = pot2;
}
//This is a function that sends the key stroke to the Arduino
function keyPressed(){
drawRect = false;
if(key=='R'){
serial.write(key);
console.log(key);
fill("red");
placeR = pot1;
placeR2 = pot2;
drawRect = true;
counter++;
console.log(pot1);
console.log(pot2);
}
}
//all my callback functions are down here:
//these are useful for giving feedback
function serverConnected(){
console.log('connected to the server');
}
function portOpen(){
console.log('the serial port opened!');
}
//THIS IS WHERE WE RECEIVE DATA!!!!!!
//make sure you're reading data based on how you're sending from arduino
function serialEvent(){
//receive serial data here
var inString = serial.readLine();
//print(inString);
if(inString != ""){
var stringArray = split(inString, ",");
sensor1 = Number(stringArray[0]);
sensor2 = Number(stringArray[1]);
}
}
function serialError(err){
console.log('something went wrong with the port. ' + err);
}
function portClose(){
console.log('the port was closed');
}
// get the list of ports:
function printList(portList) {
// portList is an array of serial port names
for (var i = 0; i < portList.length; i++) {
// Display the list the console:
print(i + " " + portList[i]);
}
}

view raw

labFour.js

hosted with ❤ by GitHub

And from arduino:


int pot = 0; //potentiometer variable
int pot2 = 0;
int incoming = 0;
void setup() {
// put your setup code here, to run once:
Serial.begin(9600); // initialize serial
}
void loop() {
// put your main code here, to run repeatedly:
pot = analogRead(A0);
pot2 = analogRead(A1);
int lightVals = map(pot, 0, 1023, 0, 255);
int light2Vals = map(pot2, 0, 1023, 0, 255);
Serial.print(lightVals);
Serial.print(",");
Serial.println(light2Vals);
delay(1);
analogWrite(9, lightVals);
analogWrite(10, light2Vals);
if(Serial.available()>0){
incoming = Serial.read();
if(incoming>0){
analogWrite(9,255);
}
}
}

view raw

labFour.ino

hosted with ❤ by GitHub

I think p5 isn’t my very favorite coding language. Between the epic lagginess of my computer and the eternally looping draw function, this was a struggle. Very fun premise, but I think given more time and a different library, I could probably do better.

Hiroshi Ishii on Pixels and Tangible Interfaces

Attending the talk by Hiroshi Ishii was an inspiring and enlightening experience. I’m very glad that I took the time to go. It is so easy to feel like there is nothing new under the sun, that everything interesting has already been done. Listening to Ishii speak was a wonderful reminder that new and innovative work is still being done and that we have a ways to go.

One part that was particularly touching and interesting for me was the topic that Ishii glanced upon at the end of the presentation. He talked a little about the junction between art and science and the role that art should play in our lives. I think that art is so important, but it is horribly undervalued in general society. It was nice to hear an (obviously) extremely intelligent and creative person advocate so strongly for the importance of art.

I am a double major in TAM and English, with a specialization in creative writing and, particularly, poetry. This means that I have to spend a lot of my time trying to justify why poetry is important and “deserves” its place in the world. To me, while not speaking directly about poetry, Ishii defended this topic beautifully. His thoughts on how art’s role is to encourage people to think in different ways, to bring disparate ideas together, and to nurture creativity of all types echoed ideas that I have been struggling to put into words for a long time. In particular, I think the idea that not everything needs to be functional is incredibly valuable. Yes, functionality is what drives the world, but without art, without the creative generation of ideas that have never breathed before, there will be no new functions. His project with the blocks that moved on their own (and moved around the ball) was beautiful, but useless. An eternal (and endlessly annoying) question that lingers in my mind is: is beauty enough? In a world with limited resources, for a person with very little time, is it “worth it” to spend time creating things that are beautiful alone? I think that watching the person interact and play with the project (maybe was this project called “moveable bits”—the one with all the white pegs that would raise and fall in waves with motion or music? It was a museum exhibit.) answers the question. These beautifully useless things can inspire a new way of interaction, a new way of thinking. Breaking out of the the same traditional patterns is how truly innovative projects are developed.

Motion, too, is an interesting thing to think about that stuck with me from Ishii’s talk. My favorite project was the biofeedback bacteria based clothing. I love the idea of using bacteria to open and close flaps according to heat and moisture, and watching the dancers was fantastic. While the project itself was incredibly interesting, I think the best part was a single quote. The dancer stated that she loved dancing in the suit because not only did it assist her in her sport, but it actually encouraged her to dance differently because of the way it felt. I think this is a fascinating feedback loop to investigate. How do we design things that are so wonderful to use, that make people feel powerful, graceful, different, and magical in a way that inspires new use? How do we get innovations to breed and grow into new and different innovations and comprehensions of the world?

I’m very happy that I took the time to attend the talk—it was both a wonderful regrounding experience in my values and an injection of new thoughts, ideas, dreams and questions for me to ponder.

Project 1: Milestone 2

So far so good (in my opinion) on the project. My prototype is a coded wireframe rather than something in invision because I decided it was more important to make a prototype of the code than of the aesthetics. It lives here. My reasoning for this is that the code determines what I can actually, feasibly do with the aesthetics. I often make aesthetic decisions before I actually consider the feasibility of the code, then get very frustrated and struggle for many hours before changing my design. 

From my sketches, I had a pretty good idea of what I wanted the site to look like and how I wanted it to flow, so I jumped straight into coding. A few things that I am currently grappling with are:

  1. Right now, I have pages for resources, maps, learn more, and home, but I’m not sure what exactly the difference is between resources, maps (aren’t maps resources?) and learn more.
    1. Potential solution: Get rid of learn more and have resources, home, and maps only.
  2. My API is not working the way I think it should. I can get the promise back, but I’m having a bad time extracting and displaying the information. More on the API later.
  3. What will it look like on a mobile device? Just boxes of facts for the home page? I guess that isn’t terrible, but it isn’t very interesting either.
    1. Potential solution: Have the facts “flip” on touch, like little flashcards. But I’m not sure how to do that quite yet.
  4. How much attention do I want people to be paying to the background? So should I use really beautiful nature images? Or something a little more muted?
  5. Can I make the brain “light up” in the spots that the facts are talking about?
    1. Potential solution(s): add to my javascript so that “on click” the src of the image changes to the same brain, but with that section highlighted. BUT, this causes the image to load every time the user clicks, and that isn’t fast. OR, also in my javascript on click, add a transparent box image over the right section of the brain? That will be faster, but will require some serious nested grid wrangling, which I’m not sure I’m up for. TBD on what happens here.

I think that is all I have in terms of roadblocks. I’m still working on the layout, background, and essentially all the important details, but the gist of it is there!

For the maps page, there will be thumbnail images of maps with a list of locations next to them. When the name of the location is clicked on, the map will expand to show where in the U.S that park or wildlife area is.

On the resources page (which, for now, I will combine with the learn more page), there will be blurbs describing the difference between the different types of land, and external links to relevant government websites. This page will also be the home of my API (see below).

In terms of the API, I am using the news API (lives here: https://newsapi.org/) to display recent news about the national forest, parks, and wilderness areas on the resources page (probably in an aside). I can get it to return the promise, but I can’t figure out how to get into the promise and display the data.

I’m also using the JQuery library, which is working fine! It is included in my prototype, but (for convenience), the click function that is currently used on the home page is below.


console.log("js in house");
//What I need: on hover (probs toggle), text to appear.
function revealFact(){
$(this).next('.factp').slideToggle("slow");
var nextThing = $(this).next('.factp');
console.log(nextThing);
$(this).toggleClass('close');
}
$(document).ready(function(){
$('.factp').hide();
$('.factbox').click(revealFact);
});
//code plan for maps page:
/* on click, set all images with class map to hide.
get this.next image with "map" class.
show image at top of page (will replace previous image). */

view raw

proj1.js

hosted with ❤ by GitHub

Sorry this post is a little ugly! Hope it hits the right boxes!

Lab 3: Analog Sensor Box

 

In part one of the lab, we created a circuit with variable input. In my case, I decided to use a pressure sensor and a potentiometer to change the brightness on LEDs.

In order to create this circuit, I first drew out a plan.

IMG-1539

Next, I connected the potentiometer and used the serial monitor to confirm that it was working. It connected to power, ground, and pin A0.

Then, I added the pressure sensor and used the serial monitor to confirm that both sensors were working. It connected to pin A1 and power, with a 10K drop down resistor.

Once I confirmed that both of the sensors were giving me input, I added the LEDs in series (each with a 220ohm resistor).

img-1496.jpgIMG-1497IMG-1498

The code for illuminating the lights using input from the sensors is below.


int pot = 0; //potentiometer variable
//adding for a photoresistor
int pressure = 0;
void setup() {
// put your setup code here, to run once:
Serial.begin(9600); // initialize serial
}
void loop() {
// put your main code here, to run repeatedly:
pot = analogRead(A0);
pressure = analogRead(A1);
Serial.println(pot);
Serial.print(" pressure ");
Serial.println(pressure);
int lightVals = map(pot, 0, 1023, 0, 255);
int light2Vals = map(pressure, 0, 1007, 0, 255);
analogWrite(10, lightVals);
analogWrite(9, light2Vals);
}

view raw

labThreeAnalogInput.ino

hosted with ❤ by GitHub

At first, the light connected to the pressure sensor wasn’t working, so I thought I did something wrong. I tried changing the LED though, which worked, so I guess I just had a dead LED. Yay for easy fixes! Here is a video of the sensors dimming the lights.

Part two of the lab involved using two of the lab was to use two photo-resistors to determine the tone a speaker is emitting. This is interesting because normally when you use variable resistors, you use a voltage divider circuit. However, instead of using a fixed resistor as the voltage divider, we are using a second variable resistor. I understand how this works after learning a little more about potentiometers, because that is essentially what they are. So, potentiometers work because they are made of a wiper (strip of conductive metal and a ring of non-conductive or insulation material (usually some sort of carbon, I think). The closer the wiper is to power, the less resistance between power and the pin (which is connected to signal, which is connected to the wiper) and then more between the pin and ground. The closer the wiper is to ground, the more resistance between it and the pin. Thus, a variable resistor.

Most variable resistors don’t have this kind of voltage divider circuit built in though, so you have to make it. This usually involves adding a fixed resistor that goes to ground, but in this case, is a second photoresistor. Pretty neat!

I got the speaker to make sounds pretty easily, though determining the range of the sensors was a bit of a task. Here’s some pictures and a video of the terrible noises it makes!

IMG-1541IMG-1542IMG-1543IMG-1544

And here is the code that I used to make it make those terrible noises!


int photo = 0;
//adding for a photoresistor
void setup() {
// put your setup code here, to run once:
Serial.begin(9600); // initialize serial
}
void loop() {
// put your main code here, to run repeatedly:
photo = analogRead(A0);
// Serial.println(photo);
int toneVal = map(photo, 130, 900, 100, 1000);
tone(8, toneVal, 10);
}

view raw

labthreeP2.ino

hosted with ❤ by GitHub

Part three of the lab was to combine part one and two and then shove them in a box. Easy-peasy. NOT. I needed two inputs and two outputs, which doesn’t sound like an excessive number of things to put in a box. OR SO I THOUGHT! Then, things went awry and I ended up with my breadboard and arduino shoved in the box, which was not the original plan. I based the dimensions of my box on just having the arduino fit in it, with all the components on break out boards, but quickly realized a few things:

  1. I didn’t have enough power and ground pins on the arduino for all the components.
  2. I didn’t have the time to perfect the way that components would need to be laid out on the breakout boards.
  3. I didn’t have time to solder breakout boards, and I really didn’t have time to solder them wrong, unsolder them, and redo them.

So, lame, yes. But still real problems. Hence, the breadboard is shoved into the box. On the positive side, it is a super tight fit, so it should meet Arielle’s expectation of “the box doesn’t make noise if you shake it”. Here is the original plan for the box and the electrical schematic:

img-1556.jpgimg-1555.jpgIMG-1556img-1557.jpg

And here is the box in progress:

 

 

 

 

 

Here is the code that allows it make irritating noises and bright lights:


int photo = 0; //photoresistor variable
int pot = 0; //potentiometer variable
void setup() {
// put your setup code here, to run once:
pinMode(5, OUTPUT);
Serial.begin(9600); // initialize serial
}
void loop() {
// put your main code here, to run repeatedly:
photo = analogRead(A0);
pot = analogRead(A2);
Serial.print("pot: ");
Serial.print(pot);
Serial.print(" photo: ");
Serial.println(photo);
//Making the speaker controlled by the potentiometer
int speakerVal = map(pot, 0, 1023, 100, 1000);
tone(8, speakerVal, 10);
//this works.
//Now make photo resistor talk to lights. Make the light turn on if a certain level of dark is reached
//and turn off if it is bright out.
int lightVal = 0;
if(photo<700){
lightVal = 255;
} else{
lightVal = 0;
}
analogWrite(5, lightVal);
}

view raw

labThreep3.ino

hosted with ❤ by GitHub

I’ve decided to call it the box of annoyance. I can market it to younger siblings, very useful for driving older siblings insane. Here is the finished annoyance box product (order yours today!):

Here’s a few images of the completed box since you can’t see what is is made of at all in the video (P.S. is is mostly made out of hot glue and tears):

Design a site like this with WordPress.com
Get started