PEG 2003 Design and Implementation Cory Sharp UC Berkeley NEST Retreat, June 2004, Santa Cruz, CA.

Post on 22-Dec-2015

212 views 0 download

transcript

PEG 2003Design and Implementation

Cory Sharp

UC Berkeley

NEST Retreat, June 2004, Santa Cruz, CA

PEG Goals

• Use a lot of sensors– 100 nodes

• In as large field as possible– 20m x 20m

• To help a pursuer– autonomous robot

• Intercept an evader– human controlled robot

• Demoed in July 2003

Platform

• Mica2Dot– 8-bit 4 MHz CPU, 128k program, 4k RAM– CC1000 Radio, abput 2 kB/s appl bw

• Magnetometer• Ultrasonic transceiver• Robust enclosure

• Pursuer– 266 MHz CPU, 20GB HD, 128MB RAM– 802.11 wireless radio

• All-terrain, GPS navigation

Software Design

• Self-localization– Ultrasonic ToF

• Vehicle detection– Calibrate, sense– Leader, position estimate– Route to pursuer

• Pursuer– Filter estimates– Intercept planning– Navigate

• Management services

PEG Approach

Approach of simplicity– Simple Sensor Network– Intelligent Processing

on Pursuer

• Core Services– Vehicle Detection– Routing– Navigation and Control

Vehicle Detection• Bandwidth driven design (most precious resrc)

– 40 packets per second• Half for local detection reports• Half for system wide behaviors

– Assume (design) that one object excites at most 9 nodes

• Calibration and Sensing– Use 8-bit digital pot with 10-bit ADC to recover a 16-

bit magnetic signal– Sample at 20 Hz– Moving average to calibrate static environment

• Determines a minimum detectible vehicle speed– Physical proximity of radio and magnetometer

caused interactions; invalidate readings while TX/RX

Vehicle Detection (2)• Local Detection Reports

– 1-norm magnetometer axes, threshold readings– Individual nodes report at 2 Hz– Put readings into a neighborhood

• Drove design of Hood

• Leader Election, Position Estimation– Leader election requires no additional communication– Leader if a node has the max in its neighborhood– A node can report as leader at most 2 Hz, weak

epoch of 0.5s– Leader reports immediately in its epoch

• Maximum detecticle vehicle speed only a fcn of the sensor– Disambiguation is deffered to outside the SN– Position report is 8.8 fixed point (x,y)

Routing

• Route from many sources to few mobile pursuers– Not many-to-one (base station) routing– Not any-to-any

• Landmark routing– Split problem into many-to-one and one-to-few– No geographic assumptions– Landmark is a rendezvous point– Spanning tree with crumb trails

• Many-to-one– Focus on building good trees

Routing (2)

• Building good trees– Flooding from a beacon

node– Select good routes

• Consider both link quality and hop count

• Precalibrate RSSI threshold for environment

• Filter then select lowest hop count parent

– Avoid broadcast storm (excess collisions)

• Adaptive time-delayed backoff

Routing (3)

• Pursuers build “crumb-trails”

• Selects a node in its proximity– By overhearing detection events

• Landmark relays msgs down crumb trail

• No coupling of pursuer to landmark– Allows for fail-over

Navigation and Control

• Classic control systems assume periodic readings with zero latency

• Cleanly separate control system from sensor network

• Assume reports from SN every few seconds

• Low-level navigate with GPS• Pursuer use of evader

position updates is robust to noise and latency

Some Results

• In the demo, the pursuer caught the evader every time

• A few noisy nodes• Quelled nodes at

(4,10) and (4,12)

Deployment Experiences

• Breakage, “Every touch breaks”– Disassembly, recharge, reprogram, reassembly

• Packaging– Requirements for deployment versus development– Wish we had external recharge and reprogram– Magnetometer interference

• Piano wire antenna, battery, metallic base spring

• Debugging– No logging services, used a big antenna– Ping-like tools to identify failed nodes

• Reprogram and Reconfig– Wireless reprogramming necessary– Minimize its use with liberal reparameterization

PEG ConsequencesSome Next Steps

• Extreme Scaling (ExScal)– 10,000 nodes monitoring a 10km long field

• NEST Final Demo (Capstone)– Berkeley’s baby for next summer

• Baseline system (Dialtone)– Everything that “proves to be pretty useful”

Dialtone• Everything that any deployed application needs, a wish list:

• Layered Application Retargetting– Config, VMLib, Reprogram

• Reset, on/off (sleep), ident/ping, scream• File system / log to flash• Bootloader• Service control• Self-test (flash, battery, profiling, duty cycle, event log, error log)• Health monitoring, watchdog• RAM/ROM query (jhill)• Multihop Routing• Epidemic dissemination (smart flood)• TimeSync• RAM buffers, message buffers• Security

Thanks!