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.