Monday, February 21, 2011

Process Process

These pictures summarize the past week of process. The first are screenshots of my code in processing as it developed throughout my process. The final code are the last two screenshots. The rest of the photos are the building process for the final physical piece.

















Monday, February 14, 2011

Proof of Concept

When I brought my final concept to class, Nick told me that I should use an infrared sensor instead of the sonar ping sensor I was going to use. This threw a kink in my chain as the code for the ping sensor seems to be endless and I spent hours the first night just trying to find an article that even talked about the sensor I was given. Soooooo after a lot of searching and almost giving up on finding good code to make this infrared sensor work, I got it! I tried probably 4 completely different codes (and a series of meddling with them to see if I could "make" them work) before I came across the one I'm using. It's from this site: http://luckylarry.co.uk/arduino-projects/arduino-using-a-sharp-ir-sensor-for-distance-calculation/ and after now using it, there's only one real thing I don't particularly like about it. The article is about how the Sharp IR sensors have a weird output ratio for data and don't give linear feedback like you would expect something measuring distance should. So this guy did a series of tests on his sensor and created a formula for his specific environment to counteract the wonky numbers. The "problem" is that my setup is obviously not his so his numbers really don't do anything for me (from what my testing tells me at least). Despite my best efforts to simply get rid of the extra formulas he's stuck in the code, it doesn't work as I somehow mess up the syntax and aren't learned enough in Arduino to figure it out. I put the word "problem" in quotes earlier because it's not really a problem...I charted the figures it gave me and I can use those just as easily as if it gave me the non-manipulated numbers as I still don't think it'd give it to me in clear inches or anything. So, it's more of a nuisance than a deal breaker. I've babbled enough, onward with pictures!!


The setup
The initial figures....ALL OVER!
Then I tried to be sneaky and make it convert to inches....yeah.....
Yay some regular readings!
More of the setupConcept prototype
Concept prototype
Concept prototypeWith the board attached

Measuring out the distances from the sensor
marking the distances in half-inch incrementshow I went about charting my data


just a pic of the "resting" state of my sensor in this prototypechart with all of the distances plotted and the numbers output by the sensor

At this point, I have to figure out what I need to do to get around the output data problem inherent to the sensor. It wouldn't be a conflict if there weren't any similar numbers but it becomes a pretty big problem when something 2.5inches and 19.5inches away from the sensor output the same number. Once I sort that issue out, I need to figure out the code for how to make an if statement and apply it to sections of the prototype so that different sounds will be made when different distances are captured. Looks promising, though...I'm optimistic at this point!

Wednesday, February 9, 2011

One Input Final Idea

My initial idea for this project was to create a type of box structure that utilized the sonar sensor as my input. I wanted to create a user driven experience where they interacted with an object of some kind, specifically a ball, and depending on where it landed in front of the sensor, a different experience occurred.

This idea went through a few iterations. Initially, it started as a box with multiple slots that the user could chose which to drop the balls into. This, I decided, was somewhat limiting and not as engaging as the idea could be.



The second development on this idea was to add an element of randomness. I wanted to make the user chose a place to drop the ball, but not know exactly where it would end up. This idea utilized pegs in a kind of "Plinko" situation that would result in the user having less control.



The next iteration which led to my final idea was to have only one slot to drop the ball in; however, the slot was moveable by the user. This allowed more interaction on the users part as well as a larger variety of outcomes for the sensor to receive input from. While before, the sensor would have been limited to say, 6-8 different distance reads, with the user being able to drop the ball in a much broader range of places, the reads can now be extremely small gaps of distance. Additionally, the added element of movement is much more engaging for the user experience, and creates an incentive to continue playing as there is no way of knowing the limits to the sensor reads and how many different outcomes there can be.








My concept for sound output also went through a few drafts. My first thought was that a scale of notes would be the most obvious output of sound as physically the device is moving in a type of scale. My next idea was that instead of notes or melodies, the output could be sounds of chaos: alarms, sirens, etc. This was met with the problem of not having purpose behind these sounds other than to avoid music itself so I away from it.

My final idea for sound is to have each output be a note; however, they will not be in an order from highest to lowest, or in any order for that matter. The notes will be random, to create even more of an incentive to continue playing with the device, to find a particular sound if the user is looking for one, or to just figure out through interacting, how many notes there really are. Additionally, there will be a sort of "easter egg" implement where if the sensor triggers the same distance measure twice within a small period of time (say within half a second of the initial read) the note will begin to loop and will not stop until that exact distance is triggered again. This creates the potential for singular notes to become beats that hold rhythm and melody and entices the user to experiment with the two different types of balls that will be provided for dropping: ones that bounce, and ones that do not. By adding this element of looping, the user can begin to layer and combine notes and beats to create their own new sounds.

Wednesday, February 2, 2011

ɥɔɹɐǝsǝɹ ʇnduı ǝuo

Resistor
A Resistor is a device that resists the flow of electricity. This resistance to the flow of electricity can be used to limit the amount of current flowing into an electrical component. Their ability to resist current is measured in Ohms [R] or [Capital Omega].

"Arduino Playground - Components." Arduino - HomePage. Web. 02 Feb. 2011. .

Variable Resistors

A resistor may have one or more fixed tapping points so that the resistance can be changed by moving the connecting wires to different terminals. Some wirewound power resistors have a tapping point that can slide along the resistance element, allowing a larger or smaller part of the resistance to be used.

Where continuous adjustment of the resistance value during operation of equipment is required, the sliding resistance tap can be connected to a knob accessible to an operator. Such a device is called a rheostat and has two terminals.

Potentiometers

A common element in electronic devices is a three-terminal resistor with a continuously adjustable tapping point controlled by rotation of a shaft or knob. These variable resistors are known as potentiometers when all three terminals are present, since they act as a continuously adjustable voltage divider. A common example is a volume control for a radio receiver.

Accurate, high-resolution panel-mounted potentiometers (or "pots") have resistance elements typically wirewound on a helical mandrel, although some include a conductive-plastic resistance coating over the wire to improve resolution. These typically offer ten turns of their shafts to cover their full range. They are usually set with dials that include a simple turns counter and a graduated dial. Electronic analog computers used them in quantity for setting coefficients, and delayed-sweep oscilloscopes of recent decades included one on their panels.

"Resistor." Wikipedia, the Free Encyclopedia. Web. 02 Feb. 2011. .





Sooooooo I was quite excited after learning about all these sensors last class. I personally picked up a sonar sensor and it got me thinking. I began researching some of the ways people have used sensors like this one.


this first video shows how a sensor can react to motion and cause LEDs to light up. Pretty basic, but it's different than what we saw in class since Nick used the light sensor to draw digitally instead of getting a physical output. The sensor that is being used in this (and the next two videos) is a PIR motion sensor. You can get them for around about $8 here:
http://www.seeedstudio.com/depot/tiny-pir-motion-sensor-module-p-277.html



I thought this second one was cool for two reasons. First is that the author is a student, so that's kind of cool to see how other students have dealt with arduino based projects. Second is that the purpose of this project is for a safety purpose. Being alerted that someone is behind you could be an extremely useful tool for people walking alone at night, etc. It's interesting how that could be utilized in the real world.



this one is also really cool. it obviously uses more than one sensor, but it's tracking motion and having a device follow it. Pretty cool stuff.

So that motion sensor is really cool, but the one I picked up from class is actually a sonar sensor. So I did a bit of looking and found this video that uses a sonar sensor (though it's not the same one I have)


This is really cool because it allows for distance calculation instead of simply movement. This is a really intriguing idea to me and it's exciting to see how quickly the sensor can take in the distance information (see end of that video)



My preliminary ideas relating to this brief is to use some kind of motion sensor to detect the location of something and feed back an output of either sound or light that can essentially be used to guide the user in navigation. I think it would be really cool to force users to try and move through some kind of obstacle with only sensory information as directional feedback. My instinctual hesitation is that I would need more than one sensor to accomplish this on a big enough scale, but it's all rough ideation for now.