CSE466 Lab 8: “The Flock”

Objectives

The goal of this lab is to implement a TinyOS application that will implement some behavior loosely corresponding to a bird in a flock. It will use a well-defined rule set to contribute sounds as part of a group of similar nodes. You and your lab partner will contribute two nodes (one for each partner) to this class wide project to produce a cellular automata-like system for bird songs. The combination of all the nodes will hopefully produce a sound similar to a flock of birds. In this lab you will learn the following:

Important Warnings

1. DO NOT power the mote from the AC adapter and batteries at the same time. ALWAYS turn off the mote’s battery power before placing it in the programming board. Only one mote should be plugged into the MIB510 programmer.
2. Be careful when placing your mica2dot into your MIB510 programmer - do not bend the pins.

Important Notes

1. The types of motes you will be using in lab are the "mica2" and "mica2dot". Make sure to compile your program for the correct piece of hardware. (e.g. 'make mica2' NOT 'make mica') For mote programming you will be using the MIB510 serial programming board.
2. When testing your nodes, use your lab partner number (from the lab partner assignments page - for the second group of labs) as your group number in hex. Please make sure to type in your group number as a hex number. NOTE: For the final demonstration you will ALL need to use 122 at the GroupID.
3. The mica2 and mica2dot are built around the ATmega128 microcontroller not the ATmega16. Register names may vary slightly between the two chips.
4. Use the default radio frequency and programming board. If you don't specify the radio frequency or programming board it will automatically choose a correct value.

Make sure your MOTECOM variable is properly set when trying to communicate to the devices over serial. The mica2 communicate at 57600 baud while the mica2dots communicates at 19200.

Resources

TinyOS Tutorials
ATmega128 datasheet
avr-gcc manual – located at: C:\WinAVR\doc\avr-libc\avr-libc-user-manual\index.html
nesC 1.1 Language Reference Manual (in course pak)

Suggested Steps

1. Read the Flock Specification and draw a state diagram of how the program should work. NOTE: You may want to create more states than are listed in the specification. The turn in requirements include a state diagram that shows all transitions and includes specifics on how your code  handles the transition (e.g., event, radio message, etc).
2. Implement theFlock Specification. Bird song phrases are available in birdsongs.h. Timbre initialization in timbres.c to see the bird song module generate the bird calls. cse466_progspace.h is available here. You will also need the module SongDecisionM and the interface SongTracker and header file BirdGlobals.h (SongDecisionM/SongTracker were updated on 3/2, and BirdGlobals.h was updated 3/7)
   NOTE: This specification may need to be updated if any ambiguities or bugs are found. Please check the online version of the specification frequently to make sure the modification date is the same. All changes to the specification will appear in red starting at 2:30pm on Tuesday. Be careful if you print the description out early as small changes may occur to the specification until the first lab begins.
   
3. Use the test fixture provided by the course staff to test your algorithm. You will need to create your own testing scripts to verify your implementation of the flock protocol. Please feel free to generate elaborate testing scenarios and to share those testing scenarios with other members of the class. The more testing completed before the final check off the better. DO NOT SHARE YOUR CODE, you may only share the testing scripts. 

Demos

• Flock Qualification: Sign up here. The qualification will take place in CSE405.
  NOTE: You and your partner may only occupy ONE time slot at a time. If the course staff finds that you are holding more than one timeslot, we will remove BOTH reservations.
  After your meeting is finished, you may schedule another qualification time to be retested. Remember you will not be able to receive full credit once you have been tested (you can get partial credit for fixing bugs).
• Flock Demonstration: The flock demonstration will occur during the last class, 12:30pm, on Friday, March 10 in the atrium. Attendance is required.

Deliverables

For all files turned in, the comments at the top of the file should contain:

• Both partners' full name, login and student number.
• The lab number (i.e. “Lab 8”).

1. The flock application is not designed to be robust to birds that do not follow the specification. This means that any bird that does not follow the flock specification could cause problems and prevent the flock from behaving as expected. Therefore, we need to verify that your solution is reasonably complete and correct before your bird (mote) can participate in the flock demonstration. Your bird will need to qualify by passing a series of tests preformed by the TAs. Sign up here
   1. This final set of tests MUST be completed before the final demo and the results of the tests will account for the largest chunk of your project grade. You should bring a mote to the tests that you are HIGHLY confident has no errors.
   2. For every error discovered by the TAs during the qualification tests you will be allowed to fix the bug; however, you can only receive HALF the points back. NOTE: Every time the TAs perform a test and discover an error the amount of points you can receive back for fixing that error will be reduced by half. If the TAs discover the same error twice you can only get a quarter of the points back.
   3. Once your bird passes all the screening tests it is qualified to participate in the final demonstration in the atrium.
2. The flock demonstration will occur during the last class, 12:30pm, on Friday, March 10 in the atrium. Attendance is required.
3. Turn in a hardcopy of your commented nesC code for the flock application. We will be looking for the following when grading your code:
   1. State transitions are labeled in the code with comments
   2. If you use an atomic statement, you MUST justify its use in your code comments. Reasonable use of atomics is encouraged. The indiscriminate use of atomic blocks will count against you! Be sure to describe in your comments why an atomic block was necessary, and why it is better than a different design. Your compile should not show any atomic or async warnings; we may check this during the grading process. If you choose to ignore the warning you will be asked to explain why you ignored it and it will be up to the TAs to determine if there was another design that you could have chosen that would have worked better and eliminated the warning. Essentially, the course staff will be grading based on whether you and your partner understood the TinyOS concurrency model and put thought into your design.
   3. Do not use the norace keyword in your application.
   4. When grading, we will be paying attention to how well you followed the TinyOS coding conventions.
4. Email a copy of your bird’s code to cse466-tas@cs.washington.edu (make sure to include ALL relevant files in a single message).
5. Turn in at least 3 testing scripts you used to test the flock with an explanation of why the test scripts helped to convince you that your program works correctly
6. Turn in a state diagram that shows how your state machine works. The state diagram should show all transitions and include specifics on how your code  handles the transition (e.g., event, radio message, etc).