Dec 12-Final Project

Digital Drum

Students

Brook Bowers, Computer Science

Mary White, Multimedia Marketing and Computing

Description

Digital drum is a pseudo drum head that also allows the user to play an interactive game. The game is an audible version of Simon. Our program plays a sequence of noises and the user is expected to replicate those noises by hitting the appropriate sensor.

Technical Details

Input

The input comes from the user tapping on the piezo sensors in each of the four corners. The input that the Arduino unit reads in is a series of readings of the sound wave generated by the tap. We programmed the Arduino unit to strip out short wavelength readings (to reduce outside noise from interfering). We also had the Arduino determine which sensor had been hit by determining the maximum value in the set of waves read in. We keep track of two pieces of data to transmit then, the number of readings for a particular wave (the magnitude of the hit) and the sensor that was hit (the quadrant). The quadrant and magnitude are then transmitted serially to Processing to specify which sensor was hit and the magnitude of the hit. That data is in turn used to determine struck the right instrument.

Output

Our output is sound played by Processing. We used the standard Processing minim library to load in and play sounds.

Construction

The Drum is constructed out of a sheet of hardboard, 4 piezo sensors, a sheet of acrylic, 4 plastic feet, and some foam core. First we drilled holes in the hardboard and ran the sensor wires through them, hot gluing a piezo in each corner. Then we glued the acrylic to each of the sensors to make sure that the readings would be accurate. Next we used the 3D printer to create feet for our drum head so that the breadboard and Arduino could fit underneath. After gluing these to the hardboard, we created a foam core box that holds the breadboard and Arduino in place so that the drum is portable.

Software

Some of our code is written in Arduino, but the majority of the code is written in 1.5.1 Processing. As stated before, the Arduino unit is programmed to read in the data from the piezo sensors and does a little bit of preprocessing before transmitting that data serially to Processing. There is only one key for our program:

            r: Resets the game back to round 1. The game does not reset on its own, and if a user cannot bear to feel the sting of defeat, then they may use this button to escape failure.

Nov 27 - More Final Project

So this week we've made a lot of progress with our project. We glued on the 3D printed feet, put together our hardware, taped the acrylic and board together to give us a consistent surface, and started working on the programming. Hardware wise, we're done. Now we just have to tackle the software.

So far, we only have the code we've worked with in Arduino. This basically just takes the input from the piezzos. Any time any of the buzzers give an output that is more than 10, four numbers (one for each buzzer) get printer in a line in the serial monitor.

Here's the bit of code we currently have:

const int sensorPin = 0;
const int ledPin = 13;
const int THRESHOLD = 100;

void setup()
{
  pinMode(ledPin, OUTPUT);
  Serial.begin(9600);
}

void loop()
{
  int inp0 = analogRead(A0);
  int inp1 = analogRead(A1);
  int inp2 = analogRead(A2);
  int inp3 = analogRead(A3);  
  
  if(inp0 > 10 || inp1 > 10 || inp2 > 10 || inp3 > 10) {
    Serial.println("Wave Detected!");
    while(inp0 > 10 || inp1 > 10 || inp2 > 10 || inp3 > 10){
      Serial.print(inp0);
      Serial.print(",");
      Serial.print(inp1);
      Serial.print(",");
      Serial.print(inp2);
      Serial.print(",");
      Serial.print(inp3);
      Serial.println();
      
      inp0 = analogRead(A0);
      inp1 = analogRead(A1);
      inp2 = analogRead(A2);
      inp3 = analogRead(A3);
      }
    Serial.println("Wave Ended!");
    }
}

The printing of Wave Detected and Wave Ended is simply a good visual for determining when there are vibrations and when there are not. 

Thursday we're going to start looking at how we are going to use Processing to create a visual display to go with our drum!

Nov 12-Another Final Project update

So after playing with the piezzo's, we grew worried that we might have to change our project. They were not very sensitive and weren't really picking up a whole lot of the vibrations very well. However, with the help of Dr. Hamid, we tried using a resistor with the piezzo's. Suddenly, everything worked brilliantly.

So now we have our four piezzos wired with header pins and we've cut out our acrylic and board. We also got four little rubber feet to raise up our board. We drilled the holes in our board to make it easy to run the wires through, and then superglued our piezzos onto the board. We also superglued the feet to the bottom of the board.

However, after putting the feet on, we realized that they were too short-we had calculated for the height of the breadboard, but hadn't considered the height of the wires coming out of the breadboard. So with some help, I designed new feet and printed them out on the 3D printer. They should be ready by next class period.

Currently, we've written a program that monitors the input from the sensors and gives us a print of the vibrations. It's a bit hard to read at the moment, but it tells us that each of the sensors are working properly. We'll work on formatting the output a bit better in the future.

Nov 8-Final Project Update

This week we've begun to work on our final project. We've sketched out a few drawings of what we want our drum head to look like and the materials that we will need.

Our drum will be made of two layers, one acrylic and one wood. In between these two layers, we will have four piezzo buzzers (one in each corner) to sense vibrations. These layers will be held together with electrical tape. We plan to run the wires through holes in the wood board so that the only thing visible from the top is the buzzers. The buzzers will each run to an analog pin in the arduino and then to ground. There will also be 4 small rubber feet in each corner to hold the board above the arduino and breadboard.

Nov 6-One Way Serial Communication

Introduction:
This week in lab, we were instructed to do an exercise involving one way serial communication. We were allowed to pick any two input sensors, so we decided to do ours utilizing piezzo buzzers since our final project will possibly involve using these sensors.

Procedure:
First, we hooked up a simple circuit with two piezzo buzzers. Next, we opened Arduino and created a program that would read the results from the sensors in the serial monitor. However the reading that this type of program was giving was just a string of random numbers, which was not helpful for our purposes. So we used CoolTerm to help make sense of the garbage.

Next we imported this to Processing. We used the bytes that were pulled in from the sensors and the Arduino to create a graph.

Here is a screenshot and a video:

Oct 30-Final Project

This week we were assigned to begin thinking about our final project and post a proposal. After much thought and discussion, my partner and I decided that we are going to make an interactive drum set. We will feed data from the drums via pressure sensors to our Arduino, and then use Processing to make the display. The idea is that depending on how hard and fast the drummer is hitting the pressure sensors, different colors and strokes will be displayed on the Processing canvas. This will be done by collecting the feedback from the pressure sensors and assigning them RGB values. It will also use some form of judgment in where the user is hitting to determine whether it should be creating a line or a circle. There will also be feedback for the user in the form of sound. This idea would utilize most of the things we have learned this semester and should yield a fun, interactive project.

Oct 27-Processing

Introduction:
This week, we were practicing using Processing. Processing is a Java based programming language that is especially helpful when producing graphs, images, and animations. Our assignment was to create some sort of image that involved an animation or interaction with either the mouse or keyboard. After thinking about what we wanted to create, we decided to go with an all time favorite-the head tilting Corgi. For those of you who may not be familiar with this phenomenon, here's a video:

Procedure:
The first step in creating our Corgi animation was to actually create our Corgi. We started by looking at various pictures of Corgwn to get a good idea of what shapes we would need to use. Next, we began to sketch out the shapes and how we wanted them oriented. Since neither I nor my partner are particularly talented artists, this took a while...

After we had sketched out how we wanted our Corgi to look, we started working within Processing to make our shapes and build our Corgi. We used a combination of rectangles, ellipses, and curves to make the basic structure.

After construction a Corgi that we were satisfied with, we decided it was time to make the animation. Originally we applied a rotation function directly to the head, using the mouseX and mouseY to determine how the head should be tilted. However, this made it to where the Corgi's head would tilt at odd angles and even entirely upside down. We also had issues with other parts of the Corgi rotating.

To solve the first problem, we introduced upper and lower limits to our Corgi's head. This prevents his head from tilting more than 90 degrees or PI/2 in either direction.

To fix the second issue, we wrapped our rotation in a pushMatrix and popMatrix. This isolates the rotation to only the head.

After our head tilt was working properly, we decided to make the enhancement that attaches a bone to the cursor. While functionally it has no purpose, it provides a cute visual enhancement to the program.

Here's a video of our program and our source code:

Source Code

Conclusion:
This project, while a little silly, was a lot of fun and I really enjoyed being able to use Processing and create an interactive animation.

Oct 17-Interactive Technology Observation

For this weeks observation assignment, we were instructed to find some sort of electronic interactive device that people use in every day life. After thinking for a little while about what I use on a regular basis, I decided to observe the creation stations at the Burger Studio in Valhala, our schools convenience/fast food shop.

The Burger Studio was put into Valhala last summer during the renovation. Here's a picture of the "store front."

The individualized stations can be seen on the right. They allow students to order a custom burger choosing from all of the available toppings right from the screen. 

The first step is to touch the screen to start. Then you must choose what type of sandwich you want. Our particular branch offers a selection of different burgers and chicken sandwiches. After that you select if you want cheese and if so, what kind. Then the user is given an extensive list of toppings containing everything from Bacon to Caramelized Onions to Honey Mustard. After choosing all of their toppings, they can select if they want a side, and if so, what kind. The option to include a drink is also available.

 In my observation, I found that while the system is fairly intuitive and has clearly marked buttons to help the user find the option they're looking for, the touch screen can be a bit frustrating as it is not very sensitive. It also seemed to lead to some frustration that the options were in fairly small font and the visible buttons for the options were not quite lined up with the actual sensor. This makes it very easy to select a topping that you did not want and sometimes takes several presses to actually select the topping you'd like. The entire process usually takes somewhere between 30 seconds for users who know exactly what they want and are experienced with the machine and two and a half minutes for users who are not as familiar or are indecisive.

Once the burger is ordered, the machine prints a receipt detailing your order, listing all of the toppings and sides you purchased. It also prints a receipt in the kitchen which is what allows the cooks to make your food.  This system helps to eliminate error in the communication process. Often times at fast food chains, there can be confusion on what the costumer actually ordered and what the server heard. This machine takes out the middle man and allows the costumer to order directly from the person who will be preparing the food and both parties have it in print so it is easy to settle disputes. The machines also allow for quicker ordering and less employees as there does not have to be someone taking each order, they only have to prepare each order.

Overall, I think the product was a good addition to Valhala. It allows students to quickly order delicious food and gives them an opportunity to interface with new technologies.

Oct 11-Transistor and H-Bridge Motor Control

Introduction:
This week in lab, we covered different methods of motor control. First, we experimented with using a transistor for motor control, and then we tried using an H-Bridge. Both of these methods seemed to work fairly well and we completed the lab without many difficulties.

Procedure:
To control the motor via transistor, we set up a basic circuit that contained a potentiometer, a diode, a small motor, and a transistor. The idea was to use a transistor to control the amount of voltage going to the motor via the potentiometer. Here's a video of our results:

Next was using the H-bridge for motor control. This circuit required using a larger power supply than our Arduino since we needed more than 5 volts, so we used a desktop DC power supply. For this portion, we set up a circuit following the diagrams provided in the lab. They required using a complicated setup with several resistors and a diode. However, this circuit did not work. Here's an image of that circuit:

We were instructed to rebuild the circuit more simply, plugging the motor directly into the rows of the h-bridge and to remove the diode. After doing that, everything worked successfully. You could hear the h-bridge ticking on and off and you could watch the motor turn on and off with it. We went ahead and made some modifications, first adding an LED. We decided to go with the LEDs that do not require a resistor just to simplify the look of the circuit and keep everything orderly. This circuit arrangment allowed the motor to turn on while the LED was off, and then switch to have the motor off and the LED on.

And then we removed the motor completely and just used two LEDs.

Conclusion:
While short and simply, this lab provided good practical knowledge for learning how to use a power source that provides more voltage than our Arduino and really helped cement our understanding of how to use motors.

Oct 8-Shift Registers

Introduction:

In today's lab, we were learning how to use shift registers. Shift registers are implemented when there are not enough pins available on your micro-controller to plug in all of your devices.

Procedure:

This lab entailed creating a circuit that initially contained 8 LEDs and one shift register. We quickly wired that up and ran the provided code. Next we moved on to the next step-configuring 16 LEDs using two shift registers. Once again, the wiring was pretty simple. We did run into an issue initially (not all of our LEDs would turn on), but it was fixed quickly when we realized the pins had gotten plugged in to 9, 11, and 13 instead of pins 8, 11, and 12. After we put them into the proper pins, we did not have any issues.

We once again ran the provided code successfully. Here are some videos of the results:

Conclusion:

This was a very practical/useful lab to learn how to make the circuits utilizing shift registers. I'm sure the knowledge gained through this lab will be very helpful in the future.

Oct 4-Kitchen Object

Introduction:
This weeks project was to work on a kitchen object. We were supposed to observe and think about how people function everyday while cooking and come up with a device that would make their lives easier. After thinking about what would be handy to have around the kitchen when I'm cooking, my partner and I decided to make a some sort of vocal thermometer. I noticed that I would put a pot of water on to boil and leave the room to go work on homework or play games. Forty-five minutes later I would come back to put the pasta in and realize that my water had boiled away. We decided it would be really handy to have a thermometer that would make noise when your liquid reached the temperature that you were seeking. And so the Temperature Notification System (or, TNS) was born.

Procedure:
The first steps we took in construction was all of the soldering and wiring. This project required the use of 2 LEDs, a piezo buzzer, a thermometer, and a potentiometer. The simplest part of the TNS was to plug everything up in one nice neat circuit. Here's a picture:

The next step we decided was to create the foam board structure. This is what would hold each of our pieces in place as well as providing an easy to understand interface so that a use could intuitively use our device. Here is our initial foam structure with each piece plugged in. Below is a side view. We wanted to leave the sides open so that the user can see the "guts."

After hooking up all of the circuits and making the foam board structure, it was time to get programming. We needed to be able to set the target temperature by using the potentiometer and an LED. The potentiometer would change the resistance, telling the Arduino what RGB values should be used for the LED.

Next was setting up the actual LED. This was simply a RGB representation of the temperature that the thermometer was reading.

Lastly was the piezo buzzer. We simply wrote a basic code that would sense if the Target and Actual RGB values matched, and if they were within a range of 4, it would set off the buzzer.

We also hand designed another interface that had labels, the title of the device, and control labels.

Here's a picture and a video of our finished product:

Source Code

Conclusion:

Overall this project went smoothly. We didn't really encounter any errors and managed to get everything to run properly. The feedback from the open house where we presented it was all positive. It was great to get to make and show off a practical device.

Oct 2-Analog Output

Introduction:
This week lab, we were dealing with Analog Output. First we used a basic motor, then we used a servo motor, and lastly we used a piezo buzzer.

Procedure:
With the basic motor, we hooked up a basic circuit with the motor plugged into analog pin 0 on our Arduino. We also incorporated a potentiometer. Since our Arduino does not have true analog output, only pulse-width modulation (also called PWM), rather than having a way to only power the motor at half speed, we had to use periods. Our periods were designed to turn the motor off and on so quickly that it seemed like the motor was running at half speed. Next we implemented the potentiometer. By allowing the potentiometer to control the duty cycles, the turn of the knob makes the motor seem like its running faster or slower by decreasing or increasing the amount of time that it is turned off. Here's a video of our results:

Next we were supposed to experiment using a servo motor. Servo motors are motors with gears and consequently are often much stronger than a basic motor like we used for the last exercise. Their arm can rotate up to 180 degrees. The first use of the servo motor was to get it to rotate using pulses that are sent through the analog pin. Here's a video of our servo motor rotating to the full 180 degrees and then back to 0.

The next element to incorporate was a potentiometer. The code for this set up was designed to allow the potentiometer to change the direction of the motor based on the resistance from the potentiometer. Here are our results from that portion:

Lastly was implementation of the piezo buzzer. Piezo buzzers work through playing quick pulses of sound at different frequencies to create a melody. Our video didn't turn out very well since my partner was playing dj, but here is a brief sample of what it sounds like:

Conclusion:
I was once again pleasantly surprised by how well our lab went. We really didn't encounter any errors with our circuits or with our codes. I'm looking forward to finishing up our analog kitchen project and working more with analog output in the future.

Sept 24-Analog Input

Introduction:
This week in lab, we were working on sending analog input for our Arduino. At first I was worried since we had so many issues learning how to do digital input, but surprisingly the analog went quite well. This lab covered using analog input with a potentiometer, a photo-resistor, a thermometer, and a force sensitive resistor (FSR).

Procedure:
My lab partner and I decided to start with the potentiometer. This required hooking up a basic circuit with an LED and running a code that caused the LED to blink. The potentiometer pin was set to change the speed in which the LED blinked based on how much resistance there was. Here's a video showing our results.

Next it was time to tackle using the photo-resistor. The photo resistor gives resistance based on the amount of light that it senses. Once again, it was connected to our basic LED circuit, allowing the LED to get brighter or dimmer based on the amount of light the resistor sensed. Here is a picture of our circuit when we were shining a light on the photo-resistor.

Using the thermometer was next. For this step, we simply plugged the thermometer into our Arduino and placed it in warm water. We tracked the temperature using the serial monitor window. We then removed it from the water and compared the temperatures.

Lastly, we used the FSR. This was connected to our LED circuit. The more pressure applied to the sensor, the brighter the LED was. 

Conclusion:
Overall I was happy with the lack of struggle that we had completing this lab. I finally feel like I'm getting the hang of circuitry and am beginning to get a better grasp on programming in C.

Sept 18-Thoughts on an Article

For this assignment, we were supposed to list (in bullet form) some of the most important developments that we saw from this article: http://www.doc.ic.ac.uk/~frk/frank/da/hci/The%20Psychopathology%20of%20Everyday%20Things%20(Norman).pdf

Here are some of the ones that I observed:
     
·        The author makes it clear that form follows function. A pretty object does nothing if it is not functional.

·        Along those same lines, the function needs to be clear and obvious. If a user cannot determine how to use the object, it is considered non-functional.

·        To make sure that the object is functional, you need to test it and make sure that its function is fairly intuitive and user friendly.

·        If there is something about your object that is not intuitive or obvious to the user, you need to make sure to provide clear concise documentation on how to use the object.

·        If you’re going to provide documentation, it needs to be understandable and easily accessible so that the user can actually find and comprehend the information being communicated.

·        If there are pieces of the object that the user will often have to manipulate like buttons or switches, put them in an easily accessible location where it is convenient for the user to reach them.

·        Functions that are not necessary and not particularly useful in ordinary situations are often better left out, simply because they complicate the device and make it harder for the user to interpret operational procedures.

Sept 17-Digital I/O

Introduction:

For this week’s homework project, my partner and I decided to recreate the Pirate Isle game that I had to program in Racket last semester for CSC 120. It is a simple game that requires two inputs and seven outputs.  At first I was intimidated as I tried to think through what all was going to be involved, remembering the painful hours I spent last semester trying to hammer out exactly how to make the game work, but once we got started, it was a lot easier to break it all down and accomplish our task.

There were definitely more than a few moments where I felt like this,

But after fiddling with all of the hardware and debugging the code, everything came together and works exactly as intended.

Procedure:

The Game

This is what the game map looked like in Racket.

The user began on Pirates’ Island and tried to navigate to Treasure Island by pressing either the “A” or “B” on the keyboard.  The green circle would move to indicate which island you were currently on.

Rather than just using an image, we decided to use LEDs to represent Islands and Pushbuttons instead of a keyboard.  The game consists of 2 buttons and 7 islands. There is a set path that the LEDs will follow based on which button is pushed. The user will have to discover the path to make it to treasure isle.  Rather than a moving green circle, the currently occupied island will be indicated by the LED being turned on. Once the game is completed, the LEDs will trace the path that the user followed and flash the Treasure Island LED

Programming and Circuitry

Circuitry was definitely our problem child with this project. It seemed like as soon as we got part of the circuit working, another part would stop. Pushbuttons seemed to be the root of all of our problems.

Finally, after moving around wires and trying several different layouts, we managed to get the LED to turn on when the button was pressed and turn off when the button wasn’t pressed. 

Next, we decided to try to get the button to turn on with the press of the button and stay on until the next press of the button, allowing the pushbutton to act like a light switch. At first it seemed that we had figured it all out, but the light would turn on or off erratically, or dim instead of turning off. After reading some documentation, we realized this was caused by “debouncing.” This is from an extra signal being sent to the Arduino because the contacts in the pushbutton bounce. Basically, when the button is pushed, it makes contact twice instead of once. While this happens in less than a second, the microcontroller is able to read the input even faster. So to fix this issue, we added a delay in our code so that the microcontroller would only react to the button push after half of a second. This eliminated the debouncing and allowed our light to work properly.

The next thing we wanted to do was connect a second LED so that we could start writing the program for multiple LEDs. We decided to write the program to have different states. State 0 was when both LEDs were turned on, State 1 was when the red LED was on and green LED was off, State 2 was when the red LED was turned off and the green LED was turned on, and the final state was the same as the initial-where both LEDs were turned off. We designed the program to change between states on the press of the button.

Once that was working properly, we redesigned the code for the specific needs of our project. Keeping in mind the idea of states, we designed if statements for each of the buttons to determine which LED should be lit up using our predetermined path. For example:

else if(button == 2){
    if(state == 7)
      {state = 8;}     

This tells the program that if the board is in state 7 (read: LED 7 is lit up and the rest are turned off) and button two is pressed, change to state 8 (where LED 8 is lit up and none of the others are). By having an if statement for each of the possible states (since the LEDs were plugged in to pins 7-13, states 7-13), we were easily able to tell the program which light should be on. To make sure that the other lights got turned off, we used another simple function.

void turnAllOff(){
 for (int i = 7 ; i < 14; i++)
  {digitalWrite (i, LOW);}

This walks through and writes each LED pin, starting at 7, and rewrites them at low (or, in simple terms, turns them off).

We decided the next step was to plug up all of the wires and both buttons to make sure that they all worked and to test our program. We encountered a few basic errors and made minor mistakes such as plugging an LED to a wrong pin, etc. but the majority of the process went smoothly.

Once all of that was successfully working, we decided to attack design-how to make the game look pretty. First, I cut a piece of foam board to the size I wanted the game to be, and printed an image of the island map. After hot gluing the map onto the board, I punched small holes in the middle of each island for the LEDs and cut two holes near the bottom for the pushbuttons to make a face plate. Then, I took two more pieces of foam board and made legs for the plate so that it would be suspended above our breadboard. I then took another piece of board and glued it to the bottom, making a 2-sided box so that the game would be neat, clean, and easy to transport, but so that it was still easy to see the wiring inside.

Next, we had to solder wires to each of the LEDs and to each of the pushbuttons so that they could be pushed into the faceplate without being too far from the breadboard. Soldering seemed much easier this time around and all of that went smoothly.

Now that all of the coding was taken care of, the hardware was prepared, and all of the exterior design was done, it was just a matter of plugging everything up. We pushed the LEDs and pushbuttons through the holes we had made in the map face plate and plugged in all of the wires.

Voila! The finished product.

Conclusion:

In the end, I learned a lot about circuitry as well as programming in C. It was really neat to go from being completely lost and confused on Thursday to halfway understanding the concepts over the weekend and then gaining mastery of everything and seeing it come together on Monday. I really enjoyed being able to do this project and can’t wait to do another! 

Source Code

Sept 10-Find My Fido

This is Find My Fido.  It works through the utilization of magic fairy dust. I use it to find cute dogs in my area. I love it when it helps to save the life of a pound puppy. I hate it when it isn’t used because people don’t know about it.

The first function of this device is to analyze any dog that you point the device at. The device analyzes the angles of the head, body, legs, and tail as well as the size and shape to determine what type of dog it is. It’s incredibly easy to operate. You simply point the device at the animal and push the “Ancestor” button and it searches through billions of entries in a database to determine what breeds are in the dog’s pedigree. This device would be incredibly handy for animal lovers and shelter workers across the globe. Aside from being able to walk down the street and find out what kind of mutt your neighbor has, shelter volunteers would be able to more adequately identify the dogs that are in their shelters. By accurately knowing the breed of the dog, it is easier to find specific rescue organizations, foster homes, or adopters to take in the homeless animal.

Find My Fido correctly identified this dog as a Cardigan Welsh Corgi!

The second function of the device has to do with finding these homeless animals a family. Twenty years ago, the only options for finding a new friend was to get one from the local shelter, find a breeder in your area, or to pick up a stray off the side of the road. In this day and age, there are many websites that facilitate the adoption of animals that are in shelters all across the nation. This device would allow for easier and more widespread placements. On the bottom half of the device are several input buttons. There is a button for each “portion” of the animal. There are buttons for tail type, ear type, color, coat length, height, weight, leg length, shape of head, bark pitch and volume, and every other possible feature of a dog that you can think of. Shelters are then able to quickly scan the dogs in their cages using the first function of the device and then the device will upload the dog information to the database, categorizing the animals by their features. That way when a family is looking for a new pet, they simply have to pick up the device and search for the type of animal they’re looking for and the device will locate the top 50 matches for their specifications in the area.

Sept 4-Electricity

Introduction:

In this lab, we were learning how to create basic circuits on a breadboard, use multimeters, read resistors, and use a potentiometer.

Procedure:

In the beginning, we tried using a battery to power our breadboard, but after testing it, we realized that the battery was not putting out the right amount of voltage. So instead of using the battery, we decided to use the arduino. Next, what we needed to do was use the multimeter to ensure that the arduino was indeed putting out 5 volts. We did this by touching the leads on the multimeter to the wires that were plugged in to our arduino. Through following these steps, we confirmed that the arduino was putting out the right amount of power.

Next, we started to form our circuit. We user a Resistor Color Code Chart like the one above to calculate how much resistance each resistor gave so that we could make sure that our LED would be getting enough, but not too much power. We double checked our suspicions with the multimeter to make sure that our calculations were correct. It took a few tries to get the right resistor, but eventually we were successful.

To make a serial circuit, we plugged the red wire in to the arduino and then plugged that in to the first column on our breadboard. That supplied power to the first row. From there, we ran another read wire to the row where our resistor started. On the row where our resistor ended, we placed the LED’s. Then, we plugged a blue wire from the row with the LEDs to a higher row. From there, we plugged in a white wire that connected to our ground column, which was then connected via black wire back to our arduino. Really, we did not need the blue wire-we could have plugged the white wire directly from our LED row to our ground column.

Before power

After power

Next we decided to make a parallel circuit. Starting with our already completed serial circuit, we added a switch on the row with the read wire and first resistor. This switch was so that when the button was pushed, our second resistor would receive power. This second resistor ran to another row that had two more LEDs and a yellow wire. This yellow wire ran from the LED row back over to the row with the blue and white wires, completing that side of the circuit.

Before button pushing

During button pushing

Ideally we were hoping to design a circuit that would allow the first set of LEDs to be on when the button was not pushed and then the second set of LEDs to turn on while the first turned off when the button was pushed. However, we were informed that we did not have the materials on hand to complete this type of circuit.

Next we learned how to use the potentiometer. With the potentiometer we created a very simple circuit with only one LED. With the breadboard still connected to the arduino in the same way it was before, we connected an orange wire from the power column on the breadboard to the potentiometer to supply it power. Next, we connected the brown wire from the potentiometer to the ground column to provide ground for the potentiometer. Finally, we connected the green cable to the row on the breadboard that contained the LED and the white cable that was providing ground for the LED circuit. We did not need to use a resistor as that is what the potentiometer does. The potentiometer allows the resistance to be change with the twist of the knob on top.

Our circuit with the potentiometer

Conclusion: 

In this lab I learned a lot about how circuits work. Also, I had heard the term multimeter numerous times before, but had never actually used one. This lab was a good chance to be able to. I gained a lot of hands on experience that I think will help me in the future both in this class and hopefully in the real world (It also reaffirmed in my mind that my lab partner can’t follow instructions. At all. Ever.)

Sept 3-Sensor Walk

Today I took a walk around Centennial to observe what types of sensors are used every day.

This motion sensor detects whether there is someone who is about to open the door. It locks the door when there is no motion and unlocks it when there is motion.

These sensors are outside of and throughout every dorm building. They  require a scan from a key card . If the key card has the rights to enter the building or hall, the light turns green and the door unlocks. If there is no scan or the card isn't set to allow the user in that specific area, the door will remain locked and the light will stay red.

This is an example of a sensor that was designed to assist those with disabilities. This button is at a level that is reachable by those in wheelchairs and when pressed allows the door to open itself.

The sprinkler system is an example of a sensor that is for the safety of the residents. When smoke fills the room, this sensor is triggered, turning on sprinklers that will put out any fire.

An elevator button is also a good example of a sensor that we use in everyday life.

These hand sanitizers that are installed all across campus have motion sensors in them. When a hand is placed below the dispenser, the canister automatically deposits the correct amount of sanitizer. 

While those are only a few of the sensors that can be found around Centennial, I think it is clear that we all interact with sensors far more than we realize on an every day basis. This assignment was interesting to me since it gave me cause to pay more attention to my surroundings and notice sensors that I probably would not have thought about otherwise.

Aug 30-Soldering

Intro:

In class, we did an introduction on how to solder. Soldering is a term used to describe the process most commonly used to connect two metal objects together. It is done by heating up the metal and applying the solder (a compound that is usually made of tin or lead). The combination of the hot metal and the solder causes a chemical reaction that makes all three compounds bind together to form a bond that, once cool, is strong and allows electricity to flow through it.

Procedure:

In this lab, our instructions were to solder a battery snap to a power plug and then solder wires from a power jack to a header pin. We were then supposed to test our device using a pre-prepared breadboard that had an LED light. The desired result was that when the battery snap was placed on top of the battery and the header pin was placed in the breadboard, the LED would light up.

All of our materials before we started

We started out by preparing the wires that would run from our power jack to the header pin. First we had to cut the wires and strip the covering off of both ends so that the solder would stick to the metal. Next, we pre-applied the solder to the wires to hopefully make it easier to get the wire to stick to the header pin. Unfortunately, in our case, that seemed to make it more difficult to get the wire to meld, so we ended up applying more solder as we were trying to connect them. After adding more solder, the solder melted and the metals fused properly.

The other issue we ran into was not being careful when choosing how to connect the wire to the power jack. We soldered our wire on perpendicular to the jack, and then realized that it would not fit into the sleeve. Because of that error, we had to reheat the metal, take off the wire, and re-solder the entire piece.

After finishing the piece that would connect the breadboard to the jack, we began working on the piece that connects the battery to the plug. This time, we avoided the errors we made with the jack and managed to get everything soldered quickly and properly.

Our finished battery clip and header pin

Then the only thing left was to test our pieces using the breadboard. We placed the header pin in the breadboard, clipped the battery snap on the battery, and achieved success.

Success!

Conclusion:

Overall, I really enjoyed learning how to solder. It was really interesting to me to see how something that was liquid a few moments ago could cool off and form a strong bond. It was also neat to be able to make something so easily that could provide power for a breadboard. I learned a lot in this lab and I am excited to see what we get to make next!