Water Temperature Sensing System. The St. Louis Rowing Club has a rule that if the water + air temperature is less than 100F, you cannot go out onto the water. The air temperature is easily available from various websites (e.g., weather.com), but the water temperature is not. The project is to create a system that 1) measures the water temperature, 2) delivers the temperature readings to a server, and 3) displays the current temperature on a website in real-time. The water temperature sensor must be accurate to within 2.5F, and must wirelessly transmit readings to a base station at a pre-defined rate (e.g., up to once every min). The base station is located approximately 100ft away in a boathouse with concrete walls. It is a standard PC running Windows or Linux that has access to a broadband Internet connection and AC power. It displays the most recent temperature reading on a web page. The base station is the only device in the system that may draw power from the AC. The temperature sensor should operate autonomously and indefinitely, meaning it will have to self-calibrate, harvest energy from the environment (e.g., use solar cells), and be weatherproof. If solar power is used, the system must work all throughout the day, and continue to work 2 hours after sunset, resume working 2 hours before sunrise, and a user must be able to force it to "wake up" at any time. The system must be 99% reliable (up to 1 out of 100 temperature readings may be dropped). If the wireless signal is not strong enough to reach the base station from the sensor, a wireless relay may be necessary, forming a multi-hop network. Only the base station is allowed to be connected to the AC. The relay must also be self-sufficient. This project will require building the water temperature sensor, and developing the control software and routing/power-management algorithms. A bonus would be to store the temperature readings in a database, and allow the user to view graphs showing the temperature over the past day/month/year.
Cricket/GPS Integration. Integrate Cricket motes with GPS. Create a module that automatically switches between GPS and Cricket motes. Calibrate the Cricket coordinate system that match GPS lat/long/elevation coordinate. The Cricket calibration should be automated, possibly by connecting one of the beacons to a real GPS receiver. The software module should seamlessly switch between Cricket and GPS based on availability.
Geographic Routing. Implement and deploy a simple application like data collection on top of CLDP_GFR v2. Experiment with CLDP_GFR, determine the minimum amount of memory required for geographic routing to work. If the project is successful, their work may enable CLDP-GFR to be integrated with Agilla. This will involve a fair amount of integration work. CLDP's website is here: http://enl.usc.edu/projects/gpsr/index.html. Note: The extra memory in Telos motes may be useful here.
TinyCoxswain 2.0. The goal of TinyCoxswain is to monitor a crew as they row to determine how well synchronized they are. A preliminary study was done by Chien-Liang Fok, Mark Tamola, and Dushyanth Balasubramanian in the Fall of 2004 for CSE 521S, the results of which are described here. The study found that sensor networks can be used to monitor crews, but that there was significant noise in the raw sensor readings. This project is to continue this study with new signal processing algorithms, better sensors, etc. The "holy grail" of this project is to deploy pressure sensors on each oar to measure the exact pressure each rower asserts and when.
Develop a Location-Aware Application using Cricket. Cricket is an indoor localization system. Build an application that changes its behavior based on its location using data from the Cricket mote.
Develop a Mobile Application Using Agilla. This project is to develop an application on top of Agilla. Agilla provides a mobile agent paradigm for programming sensor networks. The application must demonstrate the usefulness of mobile agents. Past applications include cargo tracking, fire detection and tracking, intruder detection and tracking, and robot navigation.
Enhance the MobiQuery Prototype. Mobiquery is a protocol that gathers data from a specified region of the network at just the right time. A preliminary version has been implemented and demonstrated at Sensys 2004. This project is to enhance the implementation by providing, for example, the ability for the robot to change its course.
Partial Agent Migration. Modify Agilla to allow agents to perform partial agent migration operations. For example, add instruction pwclone (partial weak clone) that clones only part of the agent to the destination. This will allow agents to "piggyback" on each other. For example, a "mothership" agent may have a smaller "explorer" agent piggybacked on it. When the mothership agent arrives at a interesting location, it deploys the explorer agents using pwclone to search the surrounding area. This is more efficient that sending a message to the base station and injecting the explorer agents at the base station. Note: This also involves defining a "component" and programming model. For example, how does a programmer specify a super agent with multiple subagents? How do the super/subagents communicate/coordinate with each other?
Real-Time Spatiotemporal Agilla Instructions. Add a real-time spatiotemporal instruction to Agilla. For example, add a parameter to the rout instruction that allows an agent to say "insert a tuple into all tuple spaces located to the north of me at a rate of 1m/s". An application is coordinated agent behavior: as the tuples are outed, agents on the hosts react (the real-time spatiotemporal rout instruction orchestrates the behavior of numerous agents spread over multiple hosts). Another idea is to allow an agent to clone itself onto all nodes within a specified region of the sensor network. Note: The key part of this is to implement an extended/simplified version of the SPEED routing protocol.
Advanced Agilla Agent Migration Primitives. Improve upon Agilla's agent migration mechanism. Currently, an agent is moved one hop at a time. This means all nodes along the migration path must have enough resources to hold the entire agent. Suppose one node along the way does not have enough resources. There are three options: 1) abort, 2) try to route around the node, 3) split the agent into pieces, migrate the pieces individually, and reassemble the fragments either on the other side of the node, or at the destination. The current implementation only provides option 1. The course project is to implement options 2 and 3. Note: In general this project is about implementing and comparing different strategies of *reliable* multi-hop agent migration. It will also be nice to integrate this with a real routing protocol.