Thursday, August 13, 2009

Final Project

I took this class to learn some technologies that I could use to create a musical kite. Ultimately I would like to create a kite that "plays" a dynamic song. This song would be made up of rhythmic changes that are determined by various sensor inputs, and then the melody would be created by wind pipes (that would also serve as the frame of the kite).

For my final I knew I could not finish all of this, so I decided to follow through on the efforts the card project that Roy, Nathan and I started but were not able to get working.

For this project, I envisioned:

Kite/Radio 1 (coordinator) queries Kite/Radio 2(router) for signal strength
Kite/Radio 1 then sends the signal strength to Radio 3(router) that would be on the ground.
Radio 3 would send this data through the serial port to then have some computer program process it.

So, I used the library that Roy created to have radio 1 read the signal strength from radio 2. I then wrote some code to send an API packet: transit request to send the signal strength value to the 3rd radio. I managed to get all three radios talking together. The third radio was sending the signal strength readings as ASCII data across the serial port. Given time constraints I just wrote a very simply arduino program that would light up 1-10 LEDs based on the values of the signal strength.

Unfortunately, on the day of class, my three radios wouldn't work together!! All three radios showed that they were on, and receiving data. However, signal strength value was not making it to the third radio; or at least the signal strength value was not being read across the serial port. I found it very disappointing.

****

Here is the code that was installed on a mini arduino attached to Radio 1 (note, you would have to include Roy's library for the first part of the code to work):

#include
#include

XBee radio_one; // my radio

/* :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

SETUP

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: */
void setup()
{
Serial.begin( BAUD_RATE ); // BAUD_RATE is 9600

// address of local radio
set_64_bit_address_on( radio_one, "0013A2004031F8FF" );
}

/* :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

LOOP

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: */
void loop()
{
static byte response;

// remote radio addr , at command
send_remote_at_query( radio_one, "0013A2004030CFCC", "DB" );
read_at_query_into( &response ); // returns reponse and waits a half a second


Serial.print(0x7E, BYTE); // start byte
Serial.print(0x00, BYTE); // high part of length (always zero)
Serial.print(0xF, BYTE); // low part of length (the number of bytes that follow, not including checksum)
Serial.print(0x10, BYTE); // 0x10 is a Transmit Request API ID
Serial.print(0x0, BYTE); // frame id set to zero for no reply
// ID of recipient, or use 0xFFFF for broadcast
Serial.print(0x00, BYTE);
Serial.print(0x13, BYTE);
Serial.print(0xA2, BYTE);
Serial.print(0x00, BYTE);
Serial.print(0x40, BYTE);
Serial.print(0x30, BYTE);
Serial.print(0xCF, BYTE); // 0xFF for broadcast
Serial.print(0xDB, BYTE); // 0xFF for broadcast
// 16 bit of recipient or 0xFFFE if unknown
Serial.print(0xFF, BYTE);
Serial.print(0xFE, BYTE);
Serial.print(0x00,BYTE); //sets maximum number of hops that can occur
//send each character value read from Kite 2 as byte
Serial.print(0x00,BYTE); //non-optional option, set all other bits to 0
Serial.print(response, BYTE);
// checksum is sum of all bytes after length bytes
long sum = 0x10 + 0x0 + 0x00 + 0x13 + 0xA2 + 0x00 + 0x40 + 0x30 + 0xCF + 0xDB + 0xFF + 0xFE + 0x00 + 0x00 + response;
Serial.print( 0xFF - ( sum & 0xFF) , BYTE ); // calculate the proper checksum
delay(1000);

}

****

Here is how the three radios were setup:













Card Project

This was a group effort. I joined Nathan and Roy. We each had a card: Urban Surprise; Go Long; and Funny, Cry, Happy. We decided on a project that was sort-of a mix of all the cards together.

We pondered for a while what to work on, and Roy had heard earlier about the kite I wanted to do for my final project, and suggested that we do some twist on this for our card project. So we went with that. We decided to use the signal strength as a way to measure how close two kites were together, and then use this measure to light LEDs up on the kite.

Roy offered to work on the code, and Nathan and I would work more on the hardware and such. I went away to get us kites (which was actually slightly harder than I had expected), and we agreed to meet the next day. When we got back together we spent way to much time on the "weight" of the kite. Our thinking was that 9v batteries were going to be just too heavy. So, we spent quite a bit of time stripping 50+ ft of wires apart and trying to twist them into string. We then spent some time trying to decide how to quickly get the components "solid" enough to stay put in the air. Nathan thought that he would be able to heat shrink the wires.

As the evening got late, we realized we had no time, and just would cobble something together. I even bought balloons the day of our presentation. Our thinking was that the balloons would help bare the weight and get our kites in the air. But then Roy's code didn't come together. So...fun to try and get working...but not a working prototype in the end.

Sensor Actuator Project

The sensor actuator project was a group project. I thought the group's idea was cool and funny: when someone flushed the toilet a fountain would go off. In terms of the final outcome, I think it was a great prototype.

I also think the concept might be worth taking beyond a prototype. We had the fountain sitting at the class table. And if someone went to the restroom the fountain would start going. And each time, I found it humorous (as well as several others in the class); and it never seemed to lose the appeal. The "flush" was brought to mind every time the water started (though I am sure that if I sat next to every day I could become desensitized). I guess, one critique would be--if a future fountain was created, it would be worth giving some more thought to how the message of water "waste" could be emphasized more.

As far as the group project went there were a few things worth commenting on:
1. one we had troubles getting everyone together. Finally a group of us were able to get together on Sunday at my work's offices. Which was convenient. And on Monday I believe only Roy and I showed up to finish things off.

2. The work needed "management" if we were to be able to really share the workload. Without it, Loren and I often just felt like "observers" and didn't have a role. At one point I had put together the physical components so that we could use to test on code; and those working on the code just ignored this and went ahead and created their own. Some of this was just out of pure logistics. People wanted to go their own ways, use their own stuff, etc.


Video of the project in action:

http://www.youtube.com/watch?v=d_ba8nGSbjQ

Simple Sensor Network

This was our first group project; and was quite fun. Though, from a technical perspective I didn't really have an opportunity to get involved. I did propose a vision for our network. And I documented the project. Of course documentation is always important and often the task left out. So, at least I also helped document our project:

http://sites.google.com/site/thermonetwork/

Imagined Socialable Objects

For this assignment I proposed a food finder; to enable someone like me with strict food restrictions to find tasty food I can eat on NYC grocery store shelves--where space is a premium so there is never a guarantee. As a proponent for "real" foods, and a friend of several people active in the food co-op/organic farming industry and in restaurants that serve local foods, I imagine that it could also be used for locating certain local foods.

This mesh network would a few major components:

1. end devices = food on grocery shelves
2. routers = radios strategically placed in the grocery stores
3. coordinator = this radio would send data to the web radio
4. x4 web interface = this would be an interface to all of this data to stored in a database
5. Database + web interface = way for people to search/locate food on the network and for vendors and farmers to list food that is not "shelve" ready

See presentation.

Wednesday, July 15, 2009

Romantic Lighting Sensor

OK. I actually really wanted to document this lab for a couple reasons.

1. It was terribly frustrating and documenting its success feels nice.
2. I thought recording some of what I went through would serve as a nice reference in the future when I attempt this again.

1st: Installing the firmware.
PCs have great difficulty reading the maxstream usb hardware. I have since ordered a usb/serial xbee piece. Not here yet. But I think with these radios it so worth the investment.

I tried:
1. The maxstream board with X-CTU
--it would not recognize that the usb port was there
2. The radio on an arduino
This didn't work. The pc was able to recognize the port at least, but it could read or write. I have since learned you also have to connect DTR and RTS pins between the arduino and the xbee, not just the RX and TX. I haven't tried installing the firmware since I learned about this, but good to know for the future.

Finally did get the radio's flashed. But did so with a borrowed USB/serial hardware on a PC that already had drivers installed that were proved to read the USB/serial hardware

2. Getting the radios talking
After I set my boards up as I thought was good and installed my appropriate Romancing code; I wasn't getting any flashing lights (as it was supposed to do). So, I tried many a thing. First I wanted to use LEDs on the radio pins to understand what was going on. Well, I didn't get this right. I counted 1-10 top>down on the left side and then again 11-20 top>down on the right side. This was incorrect. The pins read 11-20 down > top (not top>down). Rob Faludi pointed out my mistake and once we had the LEDs in, it was clear that the radio were talking to each other. Yay! Such a small post. But they worked.










Sunday, July 12, 2009

Doorbell Activities

Ok. I have spent several hours unnecessarily trying to write to an zigbee with an Arduino program. I thought that I had to bring the zigbees into command mode, in order for them to be able to send data between the radios. After becoming somewhat frustrated I became smart enough to just try Rob's code.

And this is where I am so far:
I am just using an LED at this second. And the controller zigbee is still hooked to a maxstream usb board. So next step, switch out the maxtream board for another arduino board.
__
OK. My switch from the one arduino board is now causing my LED to blink. Yay. This was my setup for the 2nd arduino + breadboard: