This project is part of Berkeley WEBS: Wireless Embedded Systems
Individual NEST Research Goals -
9/4/2002
Barbara
Chris
Cory
Jason
Joe
Kamin
Luca
Naveen
Phil
Rob vB
Sarah
Shawn
My plans:
1) Ivy testbed (w/ Jaein) - demo Sept 22
Work on getting these sensor projects on Ivy.
a) Equipment Iventory System - in Cory
b) Intelligent Watt Meter - in Etcheverry
c) Center for Environmental Design Research - in Wurster
d) LBL and campus information system - ?
Some background:
The testbed is in Cory which consists of mote software,
database, and web user interfaces. There are two types of
motes: network (ivy_net) and application (ivy_eis). The network
motes are fixed and multi-hop messages back to a base station
where they are logged to a database. The EIS application motes
are placed on BSAC equipment, and send connectivity information to
the Ivy network.
see:
http://www-bsac.EECS.Berkeley.EDU/projects/ivy/
2) scheduling algorithm (w/ Lance D.)
Work on a power efficient multi-hop routing and
low power cycle synchronization protocol.
3) SNPA paper (w/ Lance D.), Oct 22
4) Prepare for Quals Spring 2003
I may or may not make the meeting based on what time it is but,
Goals for Fall 2002:
1) Implementation of baseline link-layer security architecture for TinyOS.
2) I just finished a submission to NDSS'03 on routing security in sensor
networks outlining attacks and potential countermeasures. The next step is
the actual design of a secure routing protocol.
3) Maybe looking at how routing and link layer security will interact with
the (future) network layer interface, Mate, and network reprogramming.
Continue developing the NEST Challenge Architecture Document. Many of you
_should_ be interested in this, because it will shape a dominant API into
TinyOS:
 http://webs.cs.berkeley.edu/tos/api/
* Coerce the other NEST groups into doing their share of the NEST Challenge
Architecture Document. This will involve regular teleconferences.
* Maintain and extend the tracking and pursuit/evasion demos. Initially this
involves rewriting said demo in NesC. As the semester progresses, this
involves incorporating new whiz-bang components as they develop -- such as
Sleep, Time-Sync, Robust Multi-hop Routing, Self-Localization, Tracking, etc.
* Maintain and extend other targeted demos so appropriate sets of people can
be duly impressed. Right now this includes the MPH tabletop demo with Eric P.
for Intel Demo Day and a rollout map demo for Vijay.
* The vision-based localization for ground truth is robust and probably useful
to the other NEST groups as they develop toward the midterm demo. It'd be
nice of me to prettify, document, and commit it into the CVS tree. A binary
distribution would also be useful because a couple pairs of SWIG generated
DLL's and JAR's are involved.
*** Develop single-chip wireless mote device
*** Include hardware accelerators as per Mica generalize architecture
*** Send out complete processor/transmitter engine on sept 20.
*** Debug and test current single-chip prototype
*** Include encryption engine for encryption primitive used on wireless
link. Hopefully based on Chris's results
*** Determine power budget and analyze application-level performance of
single chip architecture
My plans:
#1) Prelim, Friday September 13th.
#2) Talk at WSNA '02
#3a) Respin of weather board (~late sept-oct)
  (in conjunction with xbow, intel, and UCLA)
#3b) Sensor/actuator interface (w/ xbow) and discovery
  (to be done in conjunction with weather board)
#4) Look at novel things we can do with the 128:
- optimized sleep modes
- hardware i2c
- adc noise-cancellation
- self-programming/network-reprogramming (w/ rob)
- perhaps look at the implications of the above in the
application space of home-automation or environmental monitoring
I'm also interested in eric's home-automation ideas. I think that we
could do some rather cool stuff with the Mica DOT motes that xbow is
producing and an atmega128 low power listening mode with watchdog off.
This problem could be the exact opposite problem that we designed for
GDI--GDI has a transmit only low-power system; a first step at
home-automation may be a receive only low-power system. Either way, I'd
certainly like to get rid of the X10 stuff in my house ;)
- Explore non-linear parameter estimation techniques, e.g. MCMC, probabilistic inference, for calibration
- Integrate TOF ranging with main source tree in TOS (done)
- Tutorial (done)
- Integrate TOF ranging with main source tree in NesC
- Refine calibration code in matlab
- Refine localization code in matlab
- Package the entire ranging/localization/calibration system with a nice interface and tutorials so it is usable by the general community. Sarah B. will be a test user.
- Upload new, faster Matlab environment that uses Java back-end
- Integrate MIG with matlab back-end
- Maybe start design phase of TOF board with xbow
** Tracking for Pursuer/Evader kit
** analysis at many level of distributed vs hierarchical control:
why distributed control rather than hierarchical ? what are the
differences and analogies ? where are the trade-offs? in particular I
plan to attack the problem in the following way:
- literature search and critical analysis of distributed and
hierarchical control
- examples of distributed control in industry
- examples of distributed and hierarchical control in nature. this
is actually the topic I am mostly interested in. My plan is to
propose and study biomimetic algorithms for a various control
tasks
- propose a how to use NEST to evaluate these algorithms
- hopefully have preliminary results
Link layer security (w/ ckarlof, umesh)
- implement link layer crypto into tos tree.
- look at entropy sources & stronger prng
location authentication
- submitted ndss paper
- simulate "minefield protocol" for security properties
- look at new sound based protocol for loc authentication.
 (possibly w/ umesh). should be easily implementable.
prelims
- hopefully pass them :)
[1] TinyOS 1.0 release
[2] Write paper with Nelson Lee on simulator for SIGMETRICS
[3] Write paper with David Gay et al. on nesC for PLDI
[4] Develop Bombilla's capsule forwarding mechansism to be
scalable (gossiping algorithms, etc.)
more secure
[5] Start preparations and chart a roadmap for TinyOS SOSP paper
* Work with David G. and Phil on the nesC submission for PLDI
* Work on next stage nesC
- richer component semantics (state machines / petri nets / ??)
- additional compile-time checks & safeguards
- interaction with runtime system for better handling of
- atomicity
- task resource scheduling
- generalize to other environments
* Meta-programming tools
- use nesC as intermediate language
- higher level program style similar to threads ?
- higher level data handling primitives (similar to TinyDB?)
I have three primary goals for the coming semester:
Feedback Control through the network (September '02 - November '02)
I would like to off-load sensing capabilities that are usually located
on the robot to a sensor network. Using Kamin's current localization
techniques, I will demonstrate such tasks as following a line of sensors
and a sentry program in a grid of motes. I will also be working on a
coverage algorithm (where the robots spread out to uniformly cover a
given area) towards early November.
Pursuit-Evasion Kit (December '02)
As promised at the last PI meeting in July, these robots will be
integrated into a Pursuit-Evasion Kit to be delivered next January.
MotorBoards and software need to be finalized and produced and a code
base for pursuit evasion will need to be developed. It is likely that
this software will build on that developed during the previous goal.
Documentation (throughout)
Documentation will include specification documents for the
Pursuit-Evasion Kit and hopefully a masters thesis.
**Continue to contribute to the pursuit-evader test bed/demo:
-Intel demo test bed
-RFS demo
-Pursuer/Evader Kit
**Continue to contribute to the pursuit/evasion architecture document
**Develop theoretical tools to support distributed control
Taking a bottom-up approach to modeling of distributed systems, we will
start by listing several examples (academic and real-world) of what
distributed control may be. From these examples, we can extract important
problem features that will allow us to distinguish one control problem from
another (for instance: distributed dynamics, distributed control
computation, communication in the control loop, etc). Next, as we develop
new models (or explore the connection with classical models), we can
hopefully categorize problems based on important features, and determine the
interesting control metrics within these frameworks. In the long run, a
very important question we must ask is "why distributed?" What do we hope
to achieve qualitatively? More specifically, with our new models and
controls, can we demonstrate better performance with respect to the emerging
metrics?
Home | Download | Support | Publications | Hardware Designs | Related Work | Internal