Class Projects

Last updated April 28, 2003

Students registering for 4 units will complete group projects in groups of two to four students, and should result both in-depth learning about the topics (and research activities) covered by the course as well as uncover new research opportunities and ideas! These projects will involve software systems for sensor networks focused on programming. Project hardware resources includes

1. an Ember networks development kit, includes one gateway node, eight sensor nodes, and associated software, (Ember network documentation)

2. a Crossbow technologies development kit, called MOTE-KIT311, including three sensor nodes and a gateway node. Relevant software for this system can be found at TinyOS, TinyDB, and Mate Virtual Machine. More information on the system is now available from Crossbow. Board Manuals (Manual1, Manual2), and TinyOS Notes (Note1, Note2).

There are actually two development kits from Crossbow, but the other one is being shared with an ECE class. We will try to get a bit more Crossbow hardware.

Here is a list of project suggestions:

• Design a basic sensor network application using the Ember network hardware. Explore its robustness over a range of deployment structures (increase the number of sensor nodes from 1 to 8, move the sensor nodes, remove the sensor nodes). Characterize the programming effort and application design to create this level of flexibility (work over these deployments). Explore the question of what benefits and limitations the self-configuring network and application structures have for this system. Analyze the power requirements of this application (and resulting system lifetime).
• Design a sophisticated sensor network application using either the Ember network or Crossbow hardware (of your choosing, probably only appropriate if you have a partner with intimate application domain expertise). Implement, debug, and demonstrate the application. Analyze the key intellectual challenges in implementing the application that arise from the wireless sensor network environments. Characterize the programming effort and application design to create this level of flexibility (work over these deployments). Analyze the power requirements of this application (and resulting system lifetime).
• Implement a simple sensor networking data collection application using TinyDB, TinyOS, and the Crossbow Motes. Move the next level of functionality of the application onto the sensor network (data processing, corresponding action), assuming one or several of the motes can serve as the actuator. Characterize the programming effort and application design to create this level of flexibility (work over these deployments). Analyze how well this kind of capability is likely to work for a broader class of sensor networking applications.
• Implement a simple sensor networking data collection application using NesC, TinyOS, and the Crossbow Motes. Move the next level of functionality of the application onto the sensor network (data processing, corresponding action), assuming one or several of the motes can serve as the actuator. Characterize the programming effort and application design to create this level of flexibility (work over these deployments). Analyze how well this kind of capability is likely to work for a broader class of sensor networking applications.
• Implement a simple sensor networking application with either TinyDB or NesC, etc. Explore its scaling properties using Tossim. In particular explore how the system performance, power, and capacity scales as the number of sensors is increased – in a fixed physical space, or one increasing linearly with the number of sensors. It might also be interesting to explore how the system will perform in the face of increasing ambient noise in the communication channel. Given the scaling properties, characterize the programming effort and application design to create this level of flexibility (work over these deployments).
• Explore the tradeoff between power efficiency thru sleeping, data communication latency, local storage required, and the ability to synchronize the nodes – shared clock. Another factor is the node density / network richness. How does the need to communicate data rapidly COST in terms of power consumption. How does the need to communicate data reliably COST in terms of power consumption. How does synchronization and known network structure affect these tradeoffs.

For all of these topics, students are expected to not only make an assessment of the technology they used, but where appropriate to improve

(or at least propose improvements) to the technology.

Other project topics are welcome, but before committing too much effort in that direction, you should speak with the course instructor to make sure that the project topic and goals are okay.

Topics and groups (class enrollment list) must be finalized and described briefly in writing by April 22, 2003. A detailed plan and progress to date in writing turned in by May 6, 2003. In particular, if you are building an application, you should have the application well-defined early in the project. You can email to the entire class here.

Final projects reports are due on June 3, 2003, and project presentations will be made on June 5, 2003 in class.

Projects Teams

• Fire Detection System (Barbara Theodorides and Michael Sirivianos)
• eZ-Park: The Next Step in Hassle Free Parking (Jas Ahluwalia, Alvin AuYoung, Chris Roedel)
• Water Quality Monitoring (John Lynn and Ryan Wu)
• Crossbow BOLT (Johann Ammerlahn)
• Motion Tracking (Tony Chen, Sunjeev Sikand, John Kerwin)

What to turn in:

April 22, 2003 Project and Team

- name of project

- members of team

- a one-page description of project (as specific as possible)

May 6, 2003 Detailed Project Plan and Progress

- all of the information from April 22, updated as changes happen

- detailed project plan which should include:

o all major software and hardware modules required

o all major activities (including time to understand software from others)

o the planned task assignment to group members

o a timeline with very specific milestones (and verifiable that you have reached them), and

o the “demonstration” planned for the system

- summary of progress to date (it should be significant)

June 3, 2003 Final Project Report

- Elements from the Project Proposal and Progress

o Project goals, plan, and approximate schedule

- Project Completion Writeup

o What was achieved

o Software

1. Design description (for what you built)

2. Software changes made (if you modified a package)

3. What worked/how tested

o Experiments: Performance measurements/data, enough description to understand what you did

o Other results / assessment of the state of the art in Sensor networks

o Takeaway" knowledge (what you learned, discovered)

o Who did what parts of the project

o While there are no specific length limits, the first section should be no more than 3-5 pages, and the Project completion writeup no more than 15-20 pages.

June 5, 2003 Project Presentations

Presentations are expected to run about 20 minutes each, extended by questions. In particular, the presentations should cover:

- original goals,

- what was achieved

- performance measurements/data,

- "takeaway" knowledge (what you learned, discovered).

- Order to be determined by a random drawing at class thursday.

Return to CSE 291 web site http://www-csag.ucsd.edu/teaching/cse291s03/

Return to CSAG web site

Return to Computer Science and Engineering web site