Sensorbaysianglobal
Download
1 / 39

SensorBaysianGlobal - PowerPoint PPT Presentation


  • 69 Views
  • Uploaded on

SensorBaysianGlobal. Alfredo Garcia Enrique Campos-Nanez Matt Spear. Agenda. The Algorithm: A Quick Overview The Simulator: Structure The Simulator: Examples The Messages An Alternative formulation of the algorithm. The Algorithm: Definitions.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' SensorBaysianGlobal' - sutton


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Sensorbaysianglobal

SensorBaysianGlobal

Alfredo Garcia

Enrique Campos-Nanez

Matt Spear


Agenda
Agenda

  • The Algorithm: A Quick Overview

  • The Simulator: Structure

  • The Simulator: Examples

  • The Messages

  • An Alternative formulation of the algorithm


The algorithm definitions
The Algorithm: Definitions

  • A node is covered iff it or one of its neighbors is ON

  • lis the probability that a node will be ON

  • A node is ON iff it is sensing

  • For now we assume that a nodes communication radius is the same as its sensor radius.

  • Nodes are static and have a position in R3

  • Nodes have a list of their neighbors

  • Turning ON has a COST · 1/(|Neighbors|)

  • A Node has two functions:

    • Update

      • For each neighbor update the information (l and the state of said node)

    • BR (Best reply)

      • Decide the best course of action given the probability that a neighbor node is on


The algorithm general formulation
The Algorithm: General Formulation

If sensors could see all other sensors, they will choose their actions to solve a common payoff function. This way sensor i, will choose its action ai = {0, 1} to solve the optimization problem:

maxUai(ai, a-i) = åj=1N(1{sensor j covered under (ai, a-i)} – c · aj)

With c < 1, the cost of a Node turning on.


The algorithm local formulation
The Algorithm: Local Formulation

Let N(i) = {j | j can cover i}, i.e. the neighbors of i, and let

N(i) = N(i) [ {i}.

Sensor i’s view of the problem is to choose between the action ON, or OFF.

To select its best action given an action profile a−i for the other sensors, sensor i can compare

U(1, a-i) – U(0, a-i) = |N(i)| - c – Ki(0, a-i)

Where

Ki(0, a-i) = åj 2 N(i)(1{sensor j covered under action profile})

  • Notes:

  • Ki(0, a-i) is simply the number of Nodes that can cover i if i is OFF

  • All information can be computed locally


The algorithm l
The Algorithm: l

Sensor i keeps track of an empirical frequency (l) for each neighbor where:

l(a-i) = (Iterations in which a-i was used) / (Total iterations)

With l the best reply is selected by comparing:

E[U(1, a-i)] - E[U(0, a-i)]

And this expectation is taken with respect to l


The algorithm update
The Algorithm: Update

Update() {

foreach(Node n 2Neighbors) {

n.isOn = IsNeighborOn(n);

if(n.isOn)

n.l = T/(T+1) · n.l + 1/(T+1);

else

n.l = T/(T+!) · n.l;

}

if(received reply from all neighbors) {

Me.isOn = BR();

if(Me.isOn)

Me.l = T/(T+1) · Me.l + 1/(T+1);

else

Me.l = T/(T+!) · Me.l;

}

}


The algorithm br
The Algorithm: BR

State BR() {

COST = 1/(|Neighbors|);

probMeCovered = 1 – Õ(Node n 2 Neighbors)(1 – n.l);

if(COST – 1 > -1 · probMeCovered)

returnOFF;

else

returnON;

}


The simulator
The Simulator

  • Main goal was to make it extensible and to implement the algorithm we were testing, the following is our framework.

  • Five main classes:

  • Node.java

    • Abstract, subclasses must override Update()

    • Represents the information of a Node

  • SBGNode.java

    • The implementation of the Node that uses this algorithm

  • Communicator.java

    • Static class that allows a Node to send a message to its neighbors (those within its communication radius)

  • Simulator.java

    • Abstract, subclasses must override Update(int numSteps)

  • SBGSimulator.java

    • The implementation of our simulator.

  • SimGUI.java

    • The GUI for the simulator (only allows visualization of nodes in R2)


The simulator node
The Simulator: Node

  • Node.java maintains:

  • int id The unique ID for the node

  • double x, y, z The position in R3

  • double sensorRadius The sensor radius

  • double commRadius The communication radius

  • boolean on If the node is ON

  • ArrayList neighbors The set of neighbors

  • int myTime The local time

  • ArrayList messages The queue of messages

  • double batteryLife The percentage of battery left

  • SBGNode.java also maintains:

  • double cost The cost of turning on

  • double lambda The l

  • int countOfNodes The number of Nodes that have responded


The simulator simulator
The Simulator: Simulator

  • Simulator.java maintains/implements:

  • static int time The actual time

  • static ArrayList nodes The set of nodes to simulate

  • static int maxTime The maximum time to run

  • double width, height, depth The volume the nodes are in

  • boolean isNeighbors(Node a, Node b) True if a is within b’s comm. radius

  • int numberOn() The number of Nodes that are ON

  • int numberOff() The number of Nodes that are OFF

  • SBGSimulator.java simply implements:

  • Update(int numSteps) Runs the simulation numSteps

  • int numberCovered() The number of covered Nodes


The simulator communication
The Simulator: Communication

  • Communication is broadcast to all Nodes in the initiator’s communication radius

  • Messages are a byte array and a timestamp of when they are sent (used to determine which Messages are available to a Node and which have not reached it, i.e. as the Simulator is synchronous “later” Nodes receive message for the current time but these would actually not be seen until the next time step in an asynchronous environment so they should be ignored)

  • Communicator.java adds the Message to a Node’s Message queue

  • Will explain Messages we defined later.


The simulator gui
The Simulator: GUI

  • The dialog box to create a new simulation. Specify:

  • Width

  • Height

  • Location to save the CSV output to

  • Location to save the sequence of images to (as png)

  • The number of nodes

  • The sensor radius

  • The amount of change for the sensor radius

  • The communication radius

  • The amount of change for the communication radius

  • The maximum simulation time

  • Whether to draw images

  • Whether to draw the comm. radius

  • Whether to draw the sensor radius (if the Node is on)

  • Grid drop (rounds number of nodes as needed) or randomly dropped


The simulator gui1
The Simulator: GUI

The simulator with a grid, 31x31 size, sensor radius only.

The simulator with random, 31x31 size, comm. and sensor radius.

The simulator draws Nodes as circles, green denoting ON and red denoting off, yellow for the sensor radius, blue for the comm. radius, all colors are alpha-blended; clicking run runs the simulation until max time is reached.


The simulator output
The Simulator: Output

Grid: 143 nodes, 31x31, c.r = s.r = 3.0, c.r.D = s.r.D = 0.0


The simulator output1
The Simulator: Output

The Simulator: Output

Grid: 143 nodes, 31x31, c.r = s.r = 3.0, c.r.D = s.r.D = 0.0


The simulator output2
The Simulator: Output

The Simulator: Output

Grid: 143 nodes, 31x31, c.r = s.r = 3.0, c.r.D = s.r.D = 0.0


The simulator output3
The Simulator: Output

The Simulator: Output

Random: 150 nodes, 31x31, c.r = s.r = 3.0, c.r.D = s.r.D = 0.0


The simulator output4
The Simulator: Output

The Simulator: Output

Random: 150 nodes, 31x31, c.r = s.r = 3.0, c.r.D = s.r.D = 0.0


The simulator output5
The Simulator: Output

The Simulator: Output

Random: 150 nodes, 31x31, c.r = s.r = 3.0, c.r.D = s.r.D = 0.0


The simulator output6
The Simulator: Output

The Simulator: Output

Random: 1500 nodes, 31x31, c.r = s.r = 1.5, c.r.D = s.r.D = 0.0


The simulator output7
The Simulator: Output

The Simulator: Output

Random: 1500 nodes, 31x31, c.r = s.r = 1.5, c.r.D = s.r.D = 0.0


The simulator output8
The Simulator: Output

The Simulator: Output

Random: 1500 nodes, 31x31, c.r = s.r = 1.5, c.r.D = s.r.D = 0.0


The messages
The Messages

  • Defined five messages for the algorithm:

  • PING (1 byte)

    • Discovery packet

  • PONG (5 bytes)

    • Reply to a ping

  • STATE_REQUEST (5 bytes)

    • A request for the states of the neighbors

  • STATE_REPLY (6 bytes)

    • A reply to a state request

  • QUIT (Not used)


Alternative algorithm compact rep
Alternative Algorithm: Compact Rep

A key note is that the difference:

E[U(1, a-i)] - E[U(0, a-i)] = |N(i)| - c - åa-i[å{j 2N(i)}(Ki(0, a-i) )] · l(a-i)

Can be computed with local information. This can be achieved if sensor i maintains:

l(k) = (Iterations in which k nodes were covered) / (Total iterations)

With this representation i will choose to be ON if the difference

E[U(1, a-i)] - E[U(0, a-i)] = |N(i)| - c - åk = 0|N(i)|[k · l(k)] > 0






Alternative algorithm duty cycles
Alternative Algorithm: Duty Cycles

Suppose we want to build M partitions of the sensors such that the nodes in each partition can cover all other nodes, and that energy consumption is minimized. This can be used to build fixed time duty cycles (as in ASCENT), where nodes in each partition alternate their ON and OFF states.

Instead of selecting an action ai2 {0, 1}, we can model the game as sensor i choosing which partition to join, i.e. ai2 {0, 1, . . . ,M}. The overall utility can be written as:

U(a) = åi = 1N[åm = 1M(1{i covered in partition m under action profile})] – c · 1{ai ¹ 0}


Alternative algorithm duty cycles1
Alternative Algorithm: Duty Cycles

Similar to our prior analysis, sensor i can decide which partition, if any, to join using only local information, namely, the number of covered sensors in the neighborhood on each partition.

Given an action profile a−i, sensor i can compare between actions m, m’ > 0 by looking at the difference:

U(m, a-i) – U(m’, a-i) = Kim(0, a-i) – Kim’(0, a-i)

Where Kim(0, a-i) is the number of sensors in the neighborhood N(i) covered under partition m.

Let m* = argminm = 1, …, M[Kim*(0, a-i)], then i should choose to join m* if

|N(i)| - c - Kim*(0, a-i) > 0

I.e. if it is economical to turn on given the coverage in partition m*


Duty cycles example
Duty Cycles: Example

Grid: 72, M = 2


Duty cycles example1
Duty Cycles: Example

Grid: 102, M = 2


Duty cycles example2
Duty Cycles: Example

Grid: 102, M = 3


Duty cycles example3
Duty Cycles: Example

Grid: 102, M = 3


Duty cycles example4
Duty Cycles: Example

Random: 50, M = 2


Duty cycles example5
Duty Cycles: Example

Random: 500, M = 4


Work in progress
Work In Progress

  • A better coverage test. Verify that all of a sensor’s radius of action is covered (Voronoi test).

  • Adaptive partitioning. Suppose that the number of partitions depends on recharge (solar) ability

  • Convergence to Endogenous Correlated Equilibria. since the localized versions of the algorithm shown here are equivalent to the global game (with sensors accessing all available information), we speculate that a minor revision of Garcia’s et al (2005) will show convergence to ECE’s.



ad