Wireless OEP Breakout Session David Culler & Shankar Sastry University of California, Berkeley

Wireless OEP Breakout Session

David Culler & Shankar Sastry

University of California, Berkeley

6/5/2001 NEST Wireless OEP Breakout 2

Agenda

• Additional Technical Background on HW/SW platform

• Additional Technical Background on Challenge Application Development

• Identify how each project will use the platform

• Solicit platform requirement input in preparation for Aug. freeze

• Identify components that projects will contribute


NEST Program Structure

SW platform

coordination

services

synthesis

services

composition services

Challenge Application

HW platform

sensors processing communication actuators storage


NEST Program Structure – evolution

SW platform

coordination

services

synthesis

services

composition services

Challenge Application

HW platform

sensors processing communication actuators storage

year

0

1

23

Composition Open Platform

initial low-power wireless

Open Platform

100+ tiny devices for alg. dev.


Platform Background

• material provided as reference

• coverage directed by discussion


Characteristics of Network Sens/Act

• Small physical size and low power consumption• Concurrency-intensive operation

– multiple flows, not wait-command-respond

• Limited Physical Parallelism and Controller Hierarchy

– primitive direct-to-device interface– Asynchronous and synchronous devices

• Diversity in Design and Usage– application specific, not general purpose– huge device variation=> efficient modularity=> migration across HW/SW boundary

• Robust Operation– numerous, unattended, critical=> narrow interfaces

sensorsactuators

network

storage


HW Platforms

• Current: SmartDust MacroMOTE => Renes =>

• Phase 1: 6 months => algorithm studies– Mote++, MEMS sensors, TinyOS

– more microcontroller

» atmega163 => 2x storage

» atmega103 => 128K flash, 4k ram

» TIMSP430 => 60k flash, 2k ram, HW *, ...

» many subtle factors

– RFM with ASH

» too early for bluetooth

– 100+ nodes for < 20K$

• Phase 2: 30 months => composition of alg’s– ARM-power, Bluetooth physical

– integrated system

– OS??


Isun Motherboard: Processor Core

• Atmel AVR• Clock speed: 4 MHz• Memory

– 8 Kbytes of program memory (flash)– 512 bytes of data RAM– 512 bytes of EEPROM on chip (write: 4 ms/byte)– 32 8 bit registers

• IO capabilities– 32 general purpose IO lines

» Some lines also serve more specialized purposes, e.g. UART» 10-bit 8-channel ADC

– Connector interface means that the IO lines serve a more specific purposes

• Interrupts– No interrupt queuing

• 256K EEPROM secondary store over I2C


Radio Circuit

• RFM Monolithics TR1000 916 MHz radio – On/off keying at 10 kbps (max. 19.2 kbps)

– Capable of 115 kbps using amplitude shift keying

– Capable of turning on in 30 us

• Processor interface– Raw, unbuffered access to transmit (RFM TX) and receive (RFM RX)

» TX current => signal strength

– Requires DC balanced signal – an equal number of 1’s and 0’s in the signal

– Sampling on reception and modulating on transmission done is software

» Too much noise in received signal to use UART for sampling

• Signal-strength Sensing and Control


Expansion Connector

• Documented hardware interface– Swap components on either side of the connector while

preserving investment in sensors or main boards

• Sensor interfaces– 4 lines dedicated to switching components on and off– 7 analog voltage sensing lines– 2 I2C busses– SPI– UART lines

• Debugging aids– All radio-related signals: RX, TX, base band, control signals, signal

strength

• Programming interfaces– SPI and reset signals for the main processor and the coprocessor

• Ground, Vcc for both analog and digital circuits• 12 lines reserved for future use


Sensor Boards

• Basic Sensor Proto– Photo resistor – PW1 and ADC1

– Thermistor – PW2 and ADC2

– Prototyping area

• Vibration Sensor– Photo resistor: PW1 and ADC1

– Thermistor: PW4, ADC6

– 2 axis accelerometer: ADC2 and 3, PW2

– Digital temperature: I2C Bus 1

• 2 axis magnetometer– Convert magnetic fields into a differential output

– Field range -2 to +2 gauss

– Sensitivity 3.2mV/V/gauss

– Resolution: 27gauss at 10Hz

– Bandwidth: 5MHz


Basic Power Breakdown…

• But what does this mean?– Lithium Battery runs for 35 hours at peak load and year at

minimum load!

– A one byte transmission uses the same energy as approx 11000 cycles of computation.

– Idleness is not enough, sleep!

» short and long control loops

Active Idle Sleep

CPU 5 mA 2 mA 3 μA

Radio 7 mA (TX) 4.5 mA (RX) 12 μA*

EE-Prom 3 mA 0 0

LED’s 4 mA 0 0

Photo Diode 200 μA 0 0

Temperature 200 μA 0 0

Panasonic CR2354

560 mAh

* 10 uA for Dallas digital pot


A Operating System for Tiny Devices?

• Traditional approaches– command processing loop (wait request, act, respond)

– monolithic event processing

– bring full thread/socket posix regime to platform

• Alternative– provide framework for concurrency and modularity

– never poll, never block

– interleaving flows, events, energy management

– allow appropriate abstractions to emerge


Tiny OS Concepts

• Scheduler + Graph of Components

– constrained two-level scheduling model: threads + events

• Component:– Commands, – Event Handlers– Frame (storage)– Tasks (concurrency)

• Constrained Storage Model– frame per component, shared stack, no

heap

• Very lean multithreading• Efficient Layering

Messaging Component

init

Po

we

r(m

od

e)

TX

_p

ack

et(

bu

f)

TX

_p

ack

et_

do

ne

(s

ucc

ess

)RX

_p

ack

et_

do

ne

(b

uff

er)

Internal

State

init

po

we

r(m

od

e)

sen

d_

msg

(ad

dr,

ty

pe

, d

ata

)

msg

_re

c(ty

pe

, d

ata

)

msg

_se

nd

_d

on

e)

internal thread

Commands Events


Application = Component Graph

RFM

Radio byte

Radio Packet

UART

Serial Packet

ADC

Temp photo

Active Messages

clocks

bit

by

tep

ac

ke

t

Route map router sensor appln

ap

pli

ca

tio

n

HW

SW

Example: ad hoc, multi-hop routing of photo sensor readings


Storage Breakdown (C Code)

0

500

1000

1500

2000

2500

3000

3500

4000

Multihop Router

AM light

AM Temp

AM

Packet

Radio Byte

RFM

Photo

Temp

UART Packet

UART

i2c

Init

TinyOS Scheduler

C Runtime

3450 B code 226 B data


DARPA 29 palms demo

• UAV drops nodes along road,– hot-water pipe insulation for package

• Nodes self configure into linear network

• Calibrate magnetometers

• Each detects passing vehicle

• Share filtered sensor data with 5 neighbors

• Each calculates estimated direction & velocity

• Share results

• As plane passes by, – joins network

– upload as much of missing dataset as possible from each node when in range

• 7.5 KB of code!


TOS Execution Model

• commands request action– ack/nack at every boundary

– call cmd or post task

• events notify occurrence– HW intrpt at lowest level

– may signal events

– call cmds

– post tasks

• Tasks provide logical concurrency

– preempted by events

• Migration of HW/SW boundary

RFM

Radio byte

Radio Packet

bit

by

tep

ac

ke

t

event-driven bit-pump

event-driven byte-pump

event-driven packet-pump

message-event driven

active message

application comp

encode/decode

crc

data processing


Dynamics of Events and Threads

bit event filtered at byte layer

bit event => end of byte =>

end of packet => end of msg send

thread posted to start

send next message

radio takes clock events to detect recv


Event-Driven Sensor Data

• clock event handler initiates data collection• sensor signals data ready event• data event handler calls output command• common pattern

char TOS_EVENT(SENS_OUTPUT_CLOCK_EVENT)(){

return TOS_CALL_COMMAND(SENS_GET_DATA)();

}

char TOS_EVENT(SENS_DATA_READY)(int data){

return TOS_CALL_COMMAND(SENS_OUTPUT_OUTPUT)((data >> 2) &0x7);

}


Component Composition

include modules{MAIN;SENS_OUTPUT;INT_TO_LEDS;CLOCK;PHOTO;};

MAIN:MAIN_SUB_INIT SENS_OUTPUT:SENS_OUTPUT_INIT MAIN:MAIN_SUB_START SENS_OUTPUT:SENS_OUTPUT_START

SENS_OUTPUT:SENS_OUTPUT_CLOCK_EVENT CLOCK:CLOCK_FIRE_EVENTSENS_OUTPUT:SENS_OUTPUT_SUB_CLOCK_INIT CLOCK:CLOCK_INIT

SENS_OUTPUT:SENS_OUTPUT_SUB_OUTPUT_INIT INT_TO_LEDS:INT_TO_LEDS_INITSENS_OUTPUT:SENS_OUTPUT_OUTPUT_COMPLETE INT_TO_LEDS:INT_TO_LEDS_DONESENS_OUTPUT:SENS_OUTPUT_OUTPUT INT_TO_LEDS:INT_TO_LEDS_OUTPUT

SENS_OUTPUT:SENS_DATA_INIT PHOTO:PHOTO_INITSENS_OUTPUT:SENS_GET_DATA PHOTO:PHOTO_GET_DATASENS_OUTPUT:SENS_DATA_READY PHOTO:PHOTO_DATA_READY

CLOCK INT_TO_LEDS

MAIN

SENS_OUTPUT

LED

hardware.h

PHOTO


TinyOS Execution Contexts

Hardware

Interrupts

eve

nts

commands

Tasks


Typical application use of tasks

• event driven data acquisition

• schedule task to do computational portion

char TOS_EVENT(MAGS_DATA_EVENT)(int data){

struct adc_packet* pack = (struct adc_packet*)(VAR(msg).data);

printf("data_event\n");

VAR(reading) = data;

TOS_POST_TASK(FILTER_DATA);

...

mags.c


Filter Magnetometer Data TaskTOS_TASK(FILTER_DATA){ int tmp; VAR(first) = VAR(first) - (VAR(first) >> 5); VAR(first) += VAR(reading); VAR(second) = VAR(second) - (VAR(second) >> 5); VAR(second) += VAR(first) >> 5; VAR(diff) = VAR(diff)-(VAR(diff) >> 5); tmp = VAR(first) - VAR(second); if(tmp < 0) tmp = -tmp; VAR(diff) += tmp; if((VAR(diff) >> 5) > 85){ TOS_CALL_COMMAND(MAGS_LEDg_on)(); VAR(led_on) = 255; }}• 128 Hz sampling rate• simple FIR filter• dynamic software tuning for centering the magnetometer signal (1208 bytes)

• digital control of analog, not DSP• ADC (196 bytes)


Tasks in low-level operation

• transmit packet– send command schedules task to calculate CRC– task initiated byte-level datapump– events keep the pump flowing

• receive packet– receive event schedules task to check CRC– task signals packet ready if OK

• byte-level tx/rx– task scheduled to encode/decode each complete byte– must take less time that byte data transfer

• i2c component– i2c bus has long suspensive operations– tasks used to create split-phase interface– events can procede during bus transactions


Active Messages• Sending

– Declare buffer storage in a frame– Request Transmission– Naming a handler– Handle Completion signal

• Receiving– Declare a handler– Firing a handler

» automatic upon arrival of corresponding message» behaves like any other event

• Buffer management– strict ownership exchange– tx: done event => reuse– rx: must rtn a buffer– built-in wrapper

TOS_FRAME_BEGIN(INT_TO_RFM_frame) {

char pending;

TOS_Msg msg;

}

TOS_FRAME_END(INT_TO_RFM_frame);


Send Messagechar TOS_COMMAND(INT_TO_RFM_OUTPUT)(int val){

int_to_led_msg* message = (int_to_led_msg*)VAR(msg).data;

if (!VAR(pending)) {

message->val = val;

if (TOS_COMMAND(INT_TO_RFM_SUB_SEND_MSG)(TOS_MSG_BCAST, AM_MSG(INT_READING), &VAR(msg))) {

VAR(pending) = 1;

return 1;

}

}

return 0;

}

msg buffer

access appln msg buffer

cast to defined format

mark busy

application specific ready check

build msg

request transmission

destination identifier

get handler identifier


Completion Event

• Underlying message layer notifies all sending components of completion event

– may need to resume activity after other’s completion

– provides reference to sent buffer to identify action

• Here event propagated as output done

char TOS_EVENT(INT_TO_RFM_SUB_MSG_SEND_DONE)(TOS_MsgPtr sentBuffer){

if (VAR(pending) && sentBuffer == &VAR(data)) {

VAR(pending) = 0;

TOS_SIGNAL_EVENT(INT_TO_RFM_COMPLETE)(1);

return 1;

}

return 0;

}


Challenge Application Developmetn

• Specification of challenge application is a process

• layout how coordination and synthesis services plug in

• develop platform requirements

• Consider sequence of applications

– interactive spaces

– flock of model cars

– Multi-agent pursuit-evasion


Challenge App: pursuer/evader contest

obstacles

evader

UAVs

active markers

UAVs (pursuers) capable of:* flying between obstacles * seeing a limited region* placing active markers

Terrain: with obstacles* not accurately mapped

Evader capable of:* moving between obstacles (possibly

actively avoiding detection)

Active Markers:* form sensor field


obstacles

evader

UAVs

UAVs (pursuers) capable of:* flying between obstacles * seeing a region around them

(limited by the occlusions)

Terrain: * with fixed obstacles* not accurately mapped

The “rules” of the game

Evader capable of:* moving between obstacles

(possibly actively avoiding detection)

Objective:find the evader in minimum time


LaValle, Latombe, Guibas, et al. considered a similar problem but assume the map of the region is known, the pursuers have perfect sensors, and worst case trajectories for the evaders:

How many UAVs are needed to win the game in finite time?

1 agent is sufficient 2 agents are needed(no matter what strategy a single pursuer

chooses, there is a trajectory for the evader that avoids detection)

Strategies for pursuit-evasion games


Deng, Papadimitriou, et al., study the problem of building a map (seeing all points in the region) traversing the smallest possible distance.

standard “keep wall to the right” algorithm

algorithm that takes better advantage of the cameras capabilities

Exploring a region to build a map


A two step solution…

• exploration followed by pursuit is not efficient

• sensors are imprecise

• worst case assumptions the trajectories of the evaders leads to very conservative results

expl

orat

ion

purs

uit


A different approach…

Use a probabilistic framework to combine exploration and pursuit-evasion games.

Non determinism comes from:• poorly mapped terrain• noise and uncertainty in the sensors• probabilistic models for the motion of

the evader and the UAVs

expl

orat

ion

purs

uit


Markov Decision Processes

statestate xt := {1 ,2 ,…, 16}actionaction ut := {up, down, left, right}

timetime t {1, 2, 3,…}

transition probability functiontransition probability function p(x,x’,u) = P(xt+1=x’ | xt=x, ut=u)

control policycontrol policy (stochastic) : [0,1] P(ut= u| xt=x, ) = (u, x)

ux

uxxu tt )0

)1,|P

xu

control policycontrol policy (deterministic) : ut = (xt)

(almost surely)

.1|right

1 2 3

5 6

.7|right

.1|right

.1|right

…

4

xgoal21

…

16

4

5


Markov Decision Processescostcost J = E[Tgoal | ] (to be minimize)

optimal control policyoptimal control policy *

J* = min J

1

),(Et

ttlJ ux

x

xuxl

0

1,with 0

(additive)

where Tgoal := min {t : xt = xgoal}

one can also write

xgoal21

…

16

4

5

1 2 3

5 6

.7|right

.1|right

.1|right

…

4

Ø

1|-

1|-

.1|right


Sub-optimal policies

Q: How does one evaluate which control action will maximize the probability of finding the evader?

greedy policygreedy policy (+) pursuit policy that, at each instant, maximizes the probability of finding the evader at the next time instant


Sub-optimal policies

probabilistic map for the position of the evader

Q: How does one evaluate which control action will maximize the probability of finding the evader?

A: By keeping track of the probability of the evader being at each possible position

Ytt Y|P 1β

greedy policygreedy policy (+) pursuit policy that, at each instant, maximizes the probability of finding the evader at the next time instant


Problem:For given paths of several UAVs, how to fuse the data sensed by each of them (in real-time) to build a global map?

Map building


Probabilistic map building

Bayes’ rule

Problem:For given paths of several UAVs, how to fuse the data sensed by each of them (in real-time) to build a global map?


How each project will use the platform

• ...


What components will be contributed

• ...


What you’d like to see in the platform

• ...

Documents

Wireless OEP Breakout Session David Culler & Shankar Sastry University of California, Berkeley