NEST Challenge Architecture
Send comments to Cory Sharp <cssharp@eecs.berkeley.edu>
Version 002 -- Tuesday, August 06, 2002
Berkeley's role
- Provide the initial architecture
- Review and integrate changes proposed by other groups toward the demo
- Supply infrastructure for collaboration
o SourceForge facilities / repository
o Mailing list
o Web site for collaboration
o Point-of-contact for each group
- Set revision dates
- Provide the demo kits as well as the final demo test bed
Middleware groups' role
- Work within the framework of the provided architecture
- Conform to changes in revisions of the architecture
- Suggest changes to the architecture
- Use the collaborative infrastructure and facilities
- Provide component implementation of the interfaces
Challenge Architecture document goals
- Specify the interfaces and their dependencies and derivations necessary for the Challenge Demo and to be included as a part of the Demo Kit
- Use nesC to specify interfaces initially
- Work to abstract to a more general description, which will define the architecture
- Also specify common types / structures used between components
Top-Down Description of Demo
Decide: Is the pursuit intelligence in the motes or the pursuers? While it seems "cool" to have it in the motes (the network is more "alive"), it seems more appropriate to have that intelligence in the pursuers. That way, the motes only act as a smart sensor network, thus accommodating any number and types of pursuers and pursuit algorithms.
So, cast it like this:
- The pursuers want to catch the evader(s). They have at their disposal the motes, which act as a sensor network.
- That's in contrast to, say, the motes detect the evader and command the pursuers to it.
- Decide: However, the pursuers should have their own channel for communication. The other option is to have them communication through the mote sensor network. That doesn't seem necessarily appropriate (it's a sensor network, not a communication network). Or maybe it does if you consider that the pursuers may be out of communication range, but the motes have robust routing algorithms.
Algorithm Summary
The pursuers enter the sensor network. They start listening for streaming estimates from the sensor network. The estimates should be routed to the pursuer(s) and include position, velocity, and identity estimates of all pursuers and evaders in the sensor network. The pursuers possibly communication and coordinate with each other and actuate to capture the evader.
Algorithm Outline
P) Pursuer robots/motes:
interface StdControl { ... }
module CritterListM { ... }
interface SendCritterListMsg { ... }
interface ReceiveCritterListMsg { ... }
typedef struct { ... } critterList_t;
typedef struct { ... } critterPosition_t;
typedef struct { ... } pursuit_t;
interface SendPursuitMsg { ... }
interface ReceivePursuitMsg { ... }
interface RobotControl { ... }
module RobotControlM { ... }
module PursuitAlgorithmM { ... }
interface Debugger { ... }
S) Sensor motes:
interface StdControl
interface SensorCalibrate { ... }
module LocalizationM { ... }
interface SendLocalizationMsg { ... }
interface ReceiveLocalizationMsg { ... }
typedef struct { ... } localization_t;
interface ReceiveStampedMsg { ... }
interface Actuator { ... }
interface Position { ... }
typedef struct { ... } position_t;
typedef unsigned int time_t;
module TimeSyncM { ... }
interface SendTimeSyncMsg { ... }
interface ReceiveTimeSyncMsg { ... }
typedef struct { ... } timeSync_t;
interface Time { ... }
module PacketRoutingM { ... }
module EstimateCrittersM { ... }
interface SendEstimateCrittersMsg { ... }
interface ReceiveEstimateCrittersMsg { ... }
typedef struct { ... } estimateCritters_t;
interface CrittersPosition { ... }
module FilterSensor { ... }
interface Sensor { ... }
typedef struct { ... } sensor_t;
· module CritterListM
· interface Debugger
E) Evader motes (Human controlled for midterm demo):
Algorithm Outline with Specifications
P) Pursuer robots/motes:
· interface StdControl {
command result_t init();
command result_t start();
command result_t stop();
}
· module CritterListM {
provides {
interface ReceiveCritterList;
}
uses {
interface ReceiveCritterListMsg;
interface SendCritterListMsg;
}
}
interface SendCritterListMsg {
command result_t sendCritterListMsg(
critterList_t* msg
);
event result_t sendCritterListMsgDone();
}
interface ReceiveCritterListMsg {
event result_t receiveCritterList(
critterList_t* msg
);
}
typedef struct {
unsigned int length;
critterPostition_t* critters;
} critterList_t;
typedef struct {
int id;
position_t pos;
} critterPosition_t;
· typedef struct {
int command;
int value;
/* ... maybe other stuff goes in here ... */
} pursuit_t;
· interface SendPursuitMsg {
command result_t sendPursuitMsg(
pursuit_t* msg
);
event result_t sendPursuitMsgDone();
}
· interface ReceivePursuitMsg {
event result_t receivePursuitMsg(
pursuit_t* msg
);
}
· interface RobotControl {
command result_t setSteeringWheel(
int value
);
command result_t setSpeed(
int value
);
command result_t getSteeringWheel(
int* value
);
command result_t getSpeed(
int* value
);
}
· module RobotControlM {
provides {
interface RobotControl;
}
uses {
}
}
· module PursuitAlgorithmM {
provides {
interface StdControl;
}
uses {
interface ReceiveCritterEstimates;
interface RobotControl;
interface SendPursuitMsg;
interface ReceivePursuitMsg;
}
}
· interface Debugger {
command result_t led_int(
int value;
);
command result_t message(
char* msg
);
}
S) Sensor motes:
· interface StdControl
· interface SensorCalibrate {
/* ... maybe nothing can actually _abstract_ here ... */
}
· module LocalizationM {
provides {
interface Position;
}
uses {
interface SendLocalizationMsg;
interface ReceiveLocalizationMsg;
interface Actuator as Sounder;
}
}
interface SendLocalizationMsg {
command result_t sendLocalizationMsg(
localization_t* msg
);
event result_t sendLocalizationMsgDone();
}
interface ReceiveLocalizationMsg {
event result_t receivePursuitMsg(
localization_t* msg
);
}
typedef struct {
int moteID;
/* .. and other pertinent stuff ... */
} localization_t;
interface ReceiveStampedMsg {
event result_t receiveStampedMsg(
TOS_MsgPtr msg,
time_t* time
);
}
interface Actuator {
command result_t setValue(
int value
);
}
interface Position {
command result_t getPosition(
position_t* position
);
}
typedef struct {
int xPos;
int yPos;
int zPos;
} position_t;
typedef unsigned int time_t;
· module TimeSyncM {
provides {
interface Time;
}
uses {
interface ClockTicks; /* or something similar */
interface ReceiveStampedMsg;
}
}
interface SendTimeSyncMsg {
command result_t sendTimeSyncMsg(
timeSync_t* msg
);
event result_t sendTimeSyncMsgDone();
}
interface ReceiveTimeSyncMsg {
event result_t receiveTimeSyncMsg(
timeSync_t* msg
);
}
typedef struct {
/* ... define me ... */
} timeSync_t;
interface Time {
command result_t getTime(
time_t* time
);
}
· module PacketRoutingM {
provides {
interface ReceiveMsg;
}
uses {
interface ReceiveMsg as IncomingMsg;
interface SendMsg;
}
}
· module EstimateCrittersM {
provides {
interface CrittersPosition;
}
uses {
interface Position; /* wired to Localization */
interface ReceiveEstimateCrittersMsg;
interface SendEstimateCrittersMsg;
interface Sensor;
}
}
interface SendEstimateCrittersMsg {
command result_t sendLocalizationMsg(
estimateCritters_t* msg
);
event result_t sendLocalizationMsgDone();
}
interface ReceiveEstimateCrittersMsg {
event result_t receivePursuitMsg(
estimateCritters_t* msg
);
}
typedef struct {
/* ... define me ... */
} estimateCritters_t;
interface CrittersPosition {
event result_t newCrittersPosition(
critterList_t* list,
);
}
· module FilterSensor {
provides {
interface Sensor;
}
uses {
interface Sensor as IncomingSensor;
}
}
interface Sensor {
event result_t sensor (
sensor_t* value
);
}
typedef struct {
int srcID;
int value;
int valueError;
} sensor_t;
· module CritterListM /* ... see above ... */
· interface Debugger /* ... see above ... */
Bottom-Up Interface and Component Grab Bag
Description:
1. List all possible components and interfaces.
2. Prefix with (*) to mark as necessary for the Challenge Demo.
3. Only components/interfaces necessary for the Challenge Demo should/will be given definitions in this Architecture Document.
TODO:
1. Add any missing interfaces/components from the list
2. Mark (*) which components are necessary for the Challenge Demo
(*) Time synchronization
Resource scheduler
(*) Localization
(*) Self localization
Reliable MAC layer
(*) Reliable delivery / routing
(*) Data aggregation
(*) Clustering
Power management
Failure detection
Synthetic failure
(*) Logger
Debugger
Mote state sharing
Mote identification
Encryption
(*) Calibration
IO interfaces:
Temperature
(*) Magnetometers
Light sensors
(*) LEDs
(*) Microphone
(*) Sounder
(*) Power/battery level
(*) Radio
(*) Serial
Specification of the Specification
1. This is a specification of the middleware interfaces and components.
2. Application-level specification (global coordinate system, etc) will be defined elsewhere in the document.
Use nesC, define skeletons for
- Types / structures
- Interfaces
- Components
- Modules
The idea for using nesC for the initial specification is to ensure that the abstraction we develop maps cleanly and directly back onto nesC. Otherwise, the likelihood of any person or group actually using the architecture document seems low.