Okay, I'm still waiting for a space to set my loom up in. And my cat got sick on my laptop, thereby killing it (it's not salvageable apparently) and cutting my access to my max/msp and arduino files thusfar developed. Not a great week.
But I did make some progress, despite that. I re-did my warp, as it wasn't long enough the first time I made it, and it went A LOT faster the second time around (about 2 hours vs, uh, 10 hours last time). So that is now finally complete and attached to my top beam. Other things completed:
- Got the correct bolts in my top beam supports. It's all bolted up to the uprights and ready to go.
_ Got my shed stick cut and bolted to the bottom of the loom (for separating the front and back threads from each other)
- Put together xbee/accelerometer circuits to go on five of the 24 weights hanging from the warp
- Got my shuttle put together with the wireless accelerometer sensor + a lithium battery
- Rewrote my max patch to where it was before
Oh yes, the xbee is an addition, heh. I am combining this final with my Mesh Networking final, and making the weights wireless devices that send their values remotely. I will be keeping a wired version of the code and board handy though, in case some kind of wireless mishap takes place, which seems to always be a danger, and I don't want any of that at showtime.
This next week is just wrapping everything up I guess and well, getting the xbee stuff all working flawlessly as well as tweaking the sound still.
Showing posts with label arduino. Show all posts
Showing posts with label arduino. Show all posts
Tuesday, November 27, 2007
Tuesday, October 16, 2007
xbee game (as yet unnamed)
My group and I decided to make a little foot-eye coordination game, coordinated to a xbee broadcasted beat. The parts to our project are as such:
- a physical interface consisting of a kick pad with FSRs in them, for recording which pad was kicked and how hard.
- the hardware involving an xbee and arduino, for capturing the broadcast beats and fsr readings
- the software, processing, for displaying our environment, which will be updated per the data sent over from our arduino.
Basically, our processing environment consists of four areas: a forest, a city, a desert, and a river. The screen will be divided into four equal parts for each eco-system. Moving along the bottom of the screen (coordinated to every 2nd broadcast beat) will be a conveyor belt, carrying with it three different kinds of icons: an egg, a baby, or a seed:
These icons will drop onto the conveyor belt in coordination with the broadcasted beat. Depending on which FSR pad you kick, you can send each of these icons out into one of the four environments. How hard you kick the pad will determine how far out 'into' the screen the icon travels. Finally, depending on which icon you kicked and which environment it landed in, the egg/seed/baby will grow into a specific animal/plant/character. For example, if you kick the baby into the city/desert/forest/river, you will get:
So far, we have designed our icons and have the core architecture of the processing program in place. We also have been able to pick up the broadcasted beat and are working on putting together a kick pad.
We have divided up the labor as such:
Shin-yi + Sarah: Graphics/Animation/Processing programming
Daniel + Shilya: Kick pads and hardware programming
- a physical interface consisting of a kick pad with FSRs in them, for recording which pad was kicked and how hard.
- the hardware involving an xbee and arduino, for capturing the broadcast beats and fsr readings
- the software, processing, for displaying our environment, which will be updated per the data sent over from our arduino.
Basically, our processing environment consists of four areas: a forest, a city, a desert, and a river. The screen will be divided into four equal parts for each eco-system. Moving along the bottom of the screen (coordinated to every 2nd broadcast beat) will be a conveyor belt, carrying with it three different kinds of icons: an egg, a baby, or a seed:
 |  |  |
These icons will drop onto the conveyor belt in coordination with the broadcasted beat. Depending on which FSR pad you kick, you can send each of these icons out into one of the four environments. How hard you kick the pad will determine how far out 'into' the screen the icon travels. Finally, depending on which icon you kicked and which environment it landed in, the egg/seed/baby will grow into a specific animal/plant/character. For example, if you kick the baby into the city/desert/forest/river, you will get:
 |  |  |  |
So far, we have designed our icons and have the core architecture of the processing program in place. We also have been able to pick up the broadcasted beat and are working on putting together a kick pad.
We have divided up the labor as such:
Shin-yi + Sarah: Graphics/Animation/Processing programming
Daniel + Shilya: Kick pads and hardware programming
Sunday, October 07, 2007
ROCK/PAPER/SCISSORS
My partner and I each built a device with an arduino and xbee radios that can wirelessly play rock/paper/scissors with the other. We got it 100% working now, but until today, there were two strange bugs causing me (the programmer) a major headache.
ARDUINO SRC
The Problems :(
The first bug was how the win/loss/tie was being tallied; only one of us ever got the results back from our match (had one of our win/loss/tie LEDs switch on), and it was always opposite of what it should have been. For example, if I rolled first, and chose rock, and then she rolled and chose scissors, her 'win' light would turn on (even though she should have lost), and I would have no outcome LED turn on at all.
The second bug (which turned out to be the reason for why one of us wouldn't have an outcome LED light up) was causing the character 'A' to be sent out the serial port, after each round played. Whenever we started a new round, the program would run through the whole switch statement, and then for one us, begin to start a new round up again, without having triggered the program to do so. This also caused one of us to not have an outcome LED turn on, because I programmed the game to turn off all LEDs on the board (to reset the board, essentially) at the start of each new round.
The Answers! :)
The first bug was due to my dyslexic coding. After I make a choice and send it to my opponent, and receive my opponent's choice, i run the data through a function that compares the two choices and switches on the appropriate outcome LED (win/tie/loss). Well, the issue turned out to be that I was comparing the opponent's choice as though it was *mine* and my choice as though it was my *opponent's*. Thus, we were getting the results backwards and the wrong outcomes. Once I fixed this, we were getting the right outcome LEDs to turn on.
The second bug was due to us not having put any delays in our main switch statement. After adding a 1 second delay before setting the game back into 'gameOver' mode (in the last case statement), we finally weren't getting any extra characters sent out the serial port (which was screwing up the whole game flow). Basically, I have a function in the main loop that is constantly checking the status of the play button. If the play button is high (is depressed) *and* the game's current status is 'gameOver', it sets the game's status to 'start', sends an 'A' out the serial port (to start the handshake with the other device), and randomly picks a number corresponding to rock/paper/scissors while waiting for the other guy to start their game too. Essentially, it starts a new round of rock/paper/scissors. Well, what was happening was that the program was playing and processing one round faster than we could finish pushing the button. Which is pretty damn fast. So adding a 1 second delay in there gave our lowly human hands enough time to stop pushing the button before the game was over.
Other than those issues, we only had one other pitfall, which I'm sure plagues 90% of people working with xbees. At least when you first start working with them, and have been up coding for 12 hours straight: We assigned the same id's to each radio. We figured that problem out early on, but it's still worth mentioning. Make sure your radios actually have someone else to talk to. Talking to yourself doesn't get you too far in the world of wireless communication.
ARDUINO SRC
The Problems :(
The first bug was how the win/loss/tie was being tallied; only one of us ever got the results back from our match (had one of our win/loss/tie LEDs switch on), and it was always opposite of what it should have been. For example, if I rolled first, and chose rock, and then she rolled and chose scissors, her 'win' light would turn on (even though she should have lost), and I would have no outcome LED turn on at all.
The second bug (which turned out to be the reason for why one of us wouldn't have an outcome LED light up) was causing the character 'A' to be sent out the serial port, after each round played. Whenever we started a new round, the program would run through the whole switch statement, and then for one us, begin to start a new round up again, without having triggered the program to do so. This also caused one of us to not have an outcome LED turn on, because I programmed the game to turn off all LEDs on the board (to reset the board, essentially) at the start of each new round.
The Answers! :)
The first bug was due to my dyslexic coding. After I make a choice and send it to my opponent, and receive my opponent's choice, i run the data through a function that compares the two choices and switches on the appropriate outcome LED (win/tie/loss). Well, the issue turned out to be that I was comparing the opponent's choice as though it was *mine* and my choice as though it was my *opponent's*. Thus, we were getting the results backwards and the wrong outcomes. Once I fixed this, we were getting the right outcome LEDs to turn on.
The second bug was due to us not having put any delays in our main switch statement. After adding a 1 second delay before setting the game back into 'gameOver' mode (in the last case statement), we finally weren't getting any extra characters sent out the serial port (which was screwing up the whole game flow). Basically, I have a function in the main loop that is constantly checking the status of the play button. If the play button is high (is depressed) *and* the game's current status is 'gameOver', it sets the game's status to 'start', sends an 'A' out the serial port (to start the handshake with the other device), and randomly picks a number corresponding to rock/paper/scissors while waiting for the other guy to start their game too. Essentially, it starts a new round of rock/paper/scissors. Well, what was happening was that the program was playing and processing one round faster than we could finish pushing the button. Which is pretty damn fast. So adding a 1 second delay in there gave our lowly human hands enough time to stop pushing the button before the game was over.
Other than those issues, we only had one other pitfall, which I'm sure plagues 90% of people working with xbees. At least when you first start working with them, and have been up coding for 12 hours straight: We assigned the same id's to each radio. We figured that problem out early on, but it's still worth mentioning. Make sure your radios actually have someone else to talk to. Talking to yourself doesn't get you too far in the world of wireless communication.
Monday, October 01, 2007
Quick pcomp sketch
So I was asked to make a little device that addresses a problem on the ITP floor. Well, 'problem' is a very subjective term, and it turned out that my 'problem' with the ITP floor wasn't as much of one for anyone else, thereby pointing out that I might be a little OCD. oh well.
The problem I chose to tackle was the one of the pcomp lab's tool box drawers not always being fully shut (photo coming soon). It's not a *huge* problem to me, but an issue nonetheless, however petty it might be. And anyways, it's the one I chose to solve, so here you go:
doorbell
Originally uploaded by 0x000000
This device is just a photocell + a doorbell buzzer. When the arduino reads a value off the photocell of less than 200 for more than 10 seconds (ideally, this would be set to a couple minutes, so people have time to open the drawer and shuffle about for their item), a very loud, obnoxious, annoying buzz goes off, until the drawer is fully shut again.
arduino src
The problem I chose to tackle was the one of the pcomp lab's tool box drawers not always being fully shut (photo coming soon). It's not a *huge* problem to me, but an issue nonetheless, however petty it might be. And anyways, it's the one I chose to solve, so here you go:
doorbell
Originally uploaded by 0x000000
This device is just a photocell + a doorbell buzzer. When the arduino reads a value off the photocell of less than 200 for more than 10 seconds (ideally, this would be set to a couple minutes, so people have time to open the drawer and shuffle about for their item), a very loud, obnoxious, annoying buzz goes off, until the drawer is fully shut again.
arduino src
Sunday, September 23, 2007
Wireless LED Glow
I can make an LED glow wirelessly!
xbee_glow
Originally uploaded by 0x000000
okay, here's what it involves: 2 XBee radios, 2 microcontrollers (I used arduino minis), 2 power sources, 2 variable resistors, and a couple LEDS to control (i'll call these analogue LEDs from here on out). I tried to keep my wires on my board tidy, as wires generate their own radio waves which can create interference with the radio signals your xbees are trying to send out. I didn't do the absolute best job with the tx/rx wires, but it didn't seem to cause any transmission problems, so I let it slide.
Basically, this exercise controls the brightness of an LED on one board (the analogue LED), from another board, via values generated from a potentiometer and sent out wirelessly through an xbee radio. So we go pot 1 --> microcontroller1 --> xbee 1 --> xbee2 --> microcontroller 2 --> analogue LED 2. And this of course, works going the other way as well. Each board can control the brightness of the other's analogue LEDs.
One little pitfall that derailed me for a moment, was having the analogue LED on an analog i/o pin vs adigital i/o PWM pin. While it was tied to an analog i/o pin, i wasn't able to turn it on at all. Make sure the analogue LED is on a digital i/o PWM pin, which you then analogWrite to in order to get it to glow.
xbee_glow
Originally uploaded by 0x000000
okay, here's what it involves: 2 XBee radios, 2 microcontrollers (I used arduino minis), 2 power sources, 2 variable resistors, and a couple LEDS to control (i'll call these analogue LEDs from here on out). I tried to keep my wires on my board tidy, as wires generate their own radio waves which can create interference with the radio signals your xbees are trying to send out. I didn't do the absolute best job with the tx/rx wires, but it didn't seem to cause any transmission problems, so I let it slide.
Basically, this exercise controls the brightness of an LED on one board (the analogue LED), from another board, via values generated from a potentiometer and sent out wirelessly through an xbee radio. So we go pot 1 --> microcontroller1 --> xbee 1 --> xbee2 --> microcontroller 2 --> analogue LED 2. And this of course, works going the other way as well. Each board can control the brightness of the other's analogue LEDs.
One little pitfall that derailed me for a moment, was having the analogue LED on an analog i/o pin vs a
Monday, April 23, 2007
Actions, Events, and Filtering
I wrote a program in processing that reacts to how vigorously you shake an accelerometer.
The arduino communicates the sensor's readings through a serial connection to processing. I used a smoothing function, in my arduino code, to get clean values from the accelerometer, which tends to give very eradict readings otherwise.
When you first open up the processing app, it is a calm, blue day.
If you make it so that the sensor's readings match up on the x- and y-axis, you plant flowers on the screen.
Slightly shaking it causes the blooms to blow...
Quickly shaking it causes a rain storm (and all the flowers blow away)
Leaving the sensor alone for 10 seconds let's the storm go away, returning you to a clear day.
Download Processing and Arduino code
The arduino communicates the sensor's readings through a serial connection to processing. I used a smoothing function, in my arduino code, to get clean values from the accelerometer, which tends to give very eradict readings otherwise.
When you first open up the processing app, it is a calm, blue day.
If you make it so that the sensor's readings match up on the x- and y-axis, you plant flowers on the screen.
Slightly shaking it causes the blooms to blow...
Quickly shaking it causes a rain storm (and all the flowers blow away)
Leaving the sensor alone for 10 seconds let's the storm go away, returning you to a clear day.
Download Processing and Arduino code
Thursday, April 05, 2007
Wearables + Networked Objects final
I'm documenting my project for wearables + netobjs here:
Joan Dress
It's code named Joan for now, for Joan of Arc, who had divine visions from above (i.e., the 'net, naturally!)
Basically, it's a dress augmented with conductive threads and thermochromic inks. The threads cause the inks to change color via resistance heating, and in response to network activity.
Joan Dress
It's code named Joan for now, for Joan of Arc, who had divine visions from above (i.e., the 'net, naturally!)
Basically, it's a dress augmented with conductive threads and thermochromic inks. The threads cause the inks to change color via resistance heating, and in response to network activity.
Saturday, February 10, 2007
Sensors and Time
I built a little visualisation tool, using processing, for graphing sensor activity. In this case, I was specifically looking at a photocell. The nature of the data being sensed, in this case, light, informed the way I chose to display the data.
There are three parameters being graphed here: raw data, averaged readings, and the standard deviation between readings.
The circuit is really simple. It's just a photocell hooked up to an arduino board analog in pin. My arduino board communicates serially to my processing app, which then displays the data accordingly.
Download my code here: arduino | processing
There are three parameters being graphed here: raw data, averaged readings, and the standard deviation between readings.
The circuit is really simple. It's just a photocell hooked up to an arduino board analog in pin. My arduino board communicates serially to my processing app, which then displays the data accordingly.
Download my code here: arduino | processing
Subscribe to:
Posts (Atom)
