This page is OBSOLETE.
Use the new NEST Challenge Architecture
Homepage, instead.
UPDATE (Wed 14 Aug 2002): This page is obsolete. Use the new NEST Challenge Architecture Homepage, instead.
It's unclear what the best format for collaboration is for this document. Until we get that resolved, we're keeping it simple:
UPDATE (Thu 08 Aug 2002): A Nest-challenge mailing list has been created specifically for working on this document. This mailing list is the preferred form of communication for collaboration on the Nest Challenge Architecture Document.
You may also send your comments directly to Cory Sharp (cssharp@eecs.berkeley.edu) or post your comments below for everyone to see.
Strictness: We at first thought polymorphism or inheritance would be useful, providing maximum flexibility in the interfaces. We eventually tabled those ideas, instead opting to strictly define each component with minimal flexibility in its interface. We hope this will both facilitate interaction between groups and encourage more concrete thought on the underlying algorithms.
Input/Output Convention: Sensors readings (input) are event driven. Processing dependent on sensor readings are also events, say for filtering data. And, it cascades all the way up; events are fired for both estimating position and initiating the broadcast of those estimates. Actuation (output) is command driven; that includes both movement and outgoing communication (say, actually putting position estimates on the radio).
Send/Receive Structures: We want to abstract from byte-packed messages used for radio communication. Each component that communicates via messages to other components (either on the local mote or remote motes) operates in the context of a structure containing native types. We package all relevant information in a single structure. This reduces the need to redefine interfaces when/if we adjust only the particular data passed between components. This also results in a one-to-one correspondence between message interfaces and message structures.
Filtering and Calibration Interfaces: To filter data or calibrate a sensor or actuator, we intend to create components that both provide and use the interface they are filtering/calibrating. This allows us to chain any number of filters or calibrations transparently.