Cory,
This document is a good attempt at specifying the pursuer-evader problem’s required
interfaces. I have, however, some observations that might be useful. You’ll find those
observations below. Feel free to pass this on for further comment if you wish.
Michael Lemmon
Dept. of Electrical Eng.
University of Notre Dame
lemmon@nd.edu
574-631-8309
It is necessary to make a distinction between specifying “services”, “algorithms”, and
“components”. This document seems to concentrate on the component/algorithm
interfaces and this may unduly restrict M/W providers. We’ve had an opportunity to
think about these interfaces because our baseline demo had to wrestle with the problem of
integrating multiple NEST services from our own programmers on a single platform. In
specifying service interfaces it is necessary to be clear about the messages going into and
out of the service (which is done in the initial document), but it is also necessary to place
some specifications of a quantitative nature. I use the interface to the pursuer as an
example. How often do the pursuers expect to receive messages? How regular these
messages should be? How accurate should the position/velocity estimates be? What is
the agreed upon format for specifying target identity? Should the messages be time
stamped, so that “stale” estimates can be discarded? How regularly should the pursuer
receive estimates? ……..
So with this observation in mind, I suggest the following:
1. Specify the PURSUER’s interface to the sensor network.
a. The specification should consist of a list of the “modules/components” with a
list of messages that the pursuers expect from the sensor network with
specifications on the format of the messages, AM channels used, and
quantitative specs on the rate at which the messages should be delivered as
well as the accuracy of the data. The list in the initial document is a good
start, but it is lacking in details on the actual message format, etc. This has to
be nailed down so that M/W providers can cleanly separate their work from
those at Berkeley concerned with the pursuer/evader software. You can think
of this as a specification for the “pursuer service”.
b. A clear description of what the pursuer service does with the information
provided and sent to the sensor network.
c. A picture that graphically shows the interface. Something like the following:
module pursuer
function: catch
evaders using
sense_net estimates
module sense_net
function: generate
estimates of evader
position/velocity…
interface EvaderDetected
(AM, DEST?, pos.,vel., ident, tstamp)
AM=51;DEST=BCAST or SPECIFIC; pos
accuracy =?; vel accuracy =?; Ident = ?;
Tstamp =?; message frequency and other
specs=?; Purpose = get sense_net estimates.
interface RequestEntry
(AM, DEST?, ID_number)
AM=52;DEST=BCAST or SPECIFIC;
ID_number = ?; Purpose: request entry to
network.
interface PurserMsg( format);
specs on data fields;
purpose of messages
specs on message frequency
2. Specifications on the coordination of NEST services
a. What we’ve found is that NEST services (synchronization, localization,…)
may all execute in a concurrent fashion. It is useful for a node to be able to
respond to sync messages from another node, even though it may be actively
doing something else. Moreover, it is unrealistic to expect that all nodes in
the network will be doing the same thing at the same time. So, if developers
use a paradigm that supports concurrent execution of services, you will need
to specify some way in which to coordinate the services. I think this is
missing from the initial document.
b. What we’ve done is provide a high-level “coordination service” that
periodically requests NEST services to do something, handles signals from
services that trigger the initialization of other NEST services. We’ve
implemented this as a state machine. An example of what we’ve done is
shown graphically below. I think we need something like this to be specified
at the beginning so that other NEST middleware providers have a clear
understanding of how their services will interface with others. I believe, we
can provide some initial functionality based on what the sensor-network
algorithm is going to look like and then let providers make changes to this if
needed. What will remain fixed is the I/F between the sensor network and the
pursuer and the coordinator and the constituent NEST services.
c. A possible graphic for this is shown below. What I’ve shown here is an
interface to a higher level user_app and the coordinator. We probably don’t
need this higher level user_app for the sensor network. But this type of
architecture could also be used on the pursuer and evader and I expect the
user_app in this case would the the control algorithms governing the pursuer’s
motion. The interface between the coordinator and NEST service consists of
two type s of objects; a command and a signal from the service. The
command is used to place the service in some specified set and the event
should be something like a service done/ timedout/ or other thing. I believe
we should probably specify a basic list of service signals (like “done”) as well
as service commands. But the format should be kept sufficiently flexible that
M/W providers can add their own signals and commands while working
within the framework provided by the specification document.
Module: user_app
Interface between NEST service and some
user application. This is probably not
needed her, but we have some projects
where this has become an issue.
Module: NEST_coordinator
I/F between
NEST
coordinator and
Services.
Service event:
done/timeout/etc.
Service command:
start, sleep, ….
Service 1
Service 2
3. Specifications for services should provide some sort of conceptual framework that
everyone can fit into. We’ve found it useful to think of each service as having three
distinct substates: The service can be actively requesting information from the
network. We’ve usually done this in a periodic manner. The service can be passively
responding to signals from the external environment (this can include sensors or
messages over the network), or the service can be disabled. Commands from the
coordinator determine which of the substates the service will enable/disable. In order
to specify a service, therefore, we need to do the following:
a. Describe the service’s functionality.
b. Describe module’s interface in a way reminiscent of the specifications on the
puruser/sensor_network interface. These specifications should include the
following: prototype declarations for each variable in the command/signal
passed generated by the module. A clear description of what that variable is.
What the proper range of values for the variable will be. How frequently the
messages should be sent and so on.
c. We’ve found it useful to divide the interface to the service component as
shown below. Commands from the coordinator (or other components) that
initiate active tasks within the service. Signals from sensors or the network
that initiate passive tasks within the service, and then the commands/signals
that are generated by the component within response to these active/passive
tasks. We can view a service graphically as shown below:
d. Finally, we need a list. My list of NEST services basically corresponds with
the initial documents. I have one major variation that focuses on a module
that implements a shared memory service. This would be used by each
module to store and manipulate “data” about the node’s neighborhood in a
mutually exclusive manner. These are specs on services, rather than
components.
i. Clock synchronization service
ii. Localization service:
iii. Target Detection/Estimation service:
iv. Route Discovery Service:
v. Message Routing/Streaming Service:
vi. Telemetry Service (I believe the initial document refers to this as the
debugger service).
vii. Calibration service
viii. Data Service
EVENTS signaled back
to coordinator such as
SYNC_DONE or
SYNC_BROKEN
Commands from
coordinator:
START
CLOCK_SYNC
AM_MSG’s to neighbors
or
commands to other components.
AM_MSG’s
sync messages
Audio signals from
Microphone.