Wireless OEP Breakout Session

1
Wireless OEP Breakout Session

• David Culler Shankar Sastry
• University of California, Berkeley

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

3
NEST Program Structure
4
NEST Program Structure evolution
Composition Open Platform
initial low-power wireless Open Platform 100
tiny devices for alg. dev.
year
3
2
1
0
5
Platform Background

• material provided as reference
• coverage directed by discussion

6
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
• gt efficient modularity
• gt migration across HW/SW boundary
• Robust Operation
• numerous, unattended, critical
• gt narrow interfaces

7
HW Platforms

• Current SmartDust MacroMOTE gt Renes gt
• Phase 1 6 months gt algorithm studies
• Mote, MEMS sensors, TinyOS
• more microcontroller
• atmega163 gt 2x storage
• atmega103 gt 128K flash, 4k ram
• TIMSP430 gt 60k flash, 2k ram, HW , ...
• many subtle factors
• RFM with ASH
• too early for bluetooth
• 100 nodes for lt 20K
• Phase 2 30 months gt composition of algs
• ARM-power, Bluetooth physical
• integrated system
• OS??

8
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

9
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 gt signal strength
• Requires DC balanced signal an equal number of
  1s and 0s 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

10
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

11
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 27?gauss at 10Hz
• Bandwidth 5MHz

12
Basic Power Breakdown
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
LEDs 4 mA 0 0
Photo Diode 200 µA 0 0
Temperature 200 µA 0 0

• 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

10 uA for Dallas digital pot
13
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

14
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

Events
Commands
send_msg(addr, type, data)
power(mode)
init
Messaging Component
Internal State
internal thread
TX_packet(buf)
Power(mode)
TX_packet_done (success)
init
RX_packet_done (buffer)
15
Application Component Graph
Route map
router
sensor appln
application
Active Messages
Radio Packet
Serial Packet
packet
Temp
photo
SW
HW
UART
Radio byte
ADC
byte
Example ad hoc, multi-hop routing of photo
sensor readings
clocks
RFM
bit
16
Storage Breakdown (C Code)
3450 B code 226 B data
17
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!

18
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

data processing
application comp
message-event driven
active message
event-driven packet-pump
crc
event-driven byte-pump
encode/decode
event-driven bit-pump
19
Dynamics of Events and Threads
bit event gt end of byte gt end of packet gt
end of msg send
thread posted to start send next message
bit event filtered at byte layer
radio takes clock events to detect recv
20
Event-Driven Sensor Data
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 gtgt 2)
0x7)

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

21
Component Composition
include modules MAIN SENS_OUTPUT INT_TO_LEDS C
LOCK PHOTO MAINMAIN_SUB_INIT
SENS_OUTPUTSENS_OUTPUT_INIT MAINMAIN_SUB_START
SENS_OUTPUTSENS_OUTPUT_START SENS_OUTPUTSENS_OU
TPUT_CLOCK_EVENT CLOCKCLOCK_FIRE_EVENT SENS_OUTPU
TSENS_OUTPUT_SUB_CLOCK_INIT CLOCKCLOCK_INIT SEN
S_OUTPUTSENS_OUTPUT_SUB_OUTPUT_INIT
INT_TO_LEDSINT_TO_LEDS_INIT SENS_OUTPUTSENS_OUTP
UT_OUTPUT_COMPLETE INT_TO_LEDSINT_TO_LEDS_DONE SE
NS_OUTPUTSENS_OUTPUT_OUTPUT INT_TO_LEDSINT_TO_LE
DS_OUTPUT SENS_OUTPUTSENS_DATA_INIT
PHOTOPHOTO_INIT SENS_OUTPUTSENS_GET_DATA
PHOTOPHOTO_GET_DATA SENS_OUTPUTSENS_DATA_READY
PHOTOPHOTO_DATA_READY
INT_TO_LEDS
22
TinyOS Execution Contexts
Tasks
events
commands
Interrupts
Hardware
23
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
24
Filter Magnetometer Data Task
TOS_TASK(FILTER_DATA) int tmp VAR(first)
VAR(first) - (VAR(first) gtgt 5) VAR(first)
VAR(reading) VAR(second) VAR(second) -
(VAR(second) gtgt 5) VAR(second) VAR(first)
gtgt 5 VAR(diff) VAR(diff)-(VAR(diff) gtgt 5)
tmp VAR(first) - VAR(second) if(tmp lt 0) tmp
-tmp VAR(diff) tmp if((VAR(diff) gtgt 5)
gt 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)

25
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

26
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 gt 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_RF
M_frame)
27
Send Message
char TOS_COMMAND(INT_TO_RFM_OUTPUT)(int
val) int_to_led_msg message
(int_to_led_msg)VAR(msg).data if
(!VAR(pending)) message-gtval val if
(TOS_COMMAND(INT_TO_RFM_SUB_SEND_MSG)(TOS_MSG_BCAS
T, AM_MSG(INT_READING), VAR(msg)))
VAR(pending) 1 return 1 return
0
msg buffer
28
Completion Event
char TOS_EVENT(INT_TO_RFM_SUB_MSG_SEND_DONE)(TOS_M
sgPtr sentBuffer) if (VAR(pending)
sentBuffer VAR(data)) VAR(pending)
0 TOS_SIGNAL_EVENT(INT_TO_RFM_COMPLETE)(1)
return 1 return 0

• Underlying message layer notifies all sending
  components of completion event
• may need to resume activity after others
  completion
• provides reference to sent buffer to identify
  action
• Here event propagated as output done

29
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

30
Challenge App pursuer/evader contest
active markers

• Terrain with obstacles
• not accurately mapped

obstacles

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

UAVs

• Active Markers
• form sensor field

• Evader capable of
• moving between obstacles (possibly actively
  avoiding detection)

evader
31
The rules of the game

• Terrain
• with fixed obstacles
• not accurately mapped

• UAVs (pursuers) capable of
• flying between obstacles
• seeing a region around them (limited by the
  occlusions)

• Evader capable of
• moving between obstacles (possibly actively
  avoiding detection)

Objective find the evader in minimum time
32
Strategies for pursuit-evasion games
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)
33
Exploring a region to build a map
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
34
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

exploration
pursuit
35
A different approach
Use a probabilistic framework to combine
exploration and pursuit-evasion games.
exploration

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

pursuit
36
Markov Decision Processes
time t ? 1, 2, 3,
state xt? X 1 ,2 ,, 16
action ut ?U up, down, left, right
transition probability function p(x,x,u)
P(xt1x xtx, utu)
control policy (deterministic) ? X?U ut
? (xt)
(almost surely) ?
control policy (stochastic) ? U?X?0,1
P(ut u xtx, ? ) ? (u, x)
37
Markov Decision Processes
cost J? ETgoal ? (to be minimize)
where Tgoal min t xt xgoal ? ?
one can also write
(additive)
.1right
optimal control policy ? J? min? J?
38
Sub-optimal policies
greedy policy (?) ? pursuit policy that, at
each instant, maximizes the probability of
finding the evader at the next
time instant
Q How does one evaluate which control action
will maximize the probability of finding the
evader?
?
39
Sub-optimal policies
greedy policy (?) ? pursuit policy that, at
each instant, maximizes the probability of
finding the evader at the next
time instant
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 ?
probabilistic map for the position of the evader
40
Map building
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?
41
Probabilistic map building
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?
Bayes rule
42
How each project will use the platform

• ...

43
What components will be contributed

• ...

44
What youd like to see in the platform

• ...