Subsumption examples Let us analyze some subsumption robots and systems.
-
Upload
lydia-bishop -
Category
Documents
-
view
228 -
download
4
Transcript of Subsumption examples Let us analyze some subsumption robots and systems.
Subsumption examplesSubsumption examples
Let us analyze Let us analyze some subsumption some subsumption robots and robots and systemssystems
Squirt of BrooksSquirt of Brooks• Incorporates an 8-bit computer, an on-board
power supply, three sensors and a propulsion system.
• Normal mode of operation is to act as a "bug", hiding in dark corners and venturing out in the direction of noises, only after the noises are long gone.
• The entire compiled control system for Squirt fits in 1300 bytes of code on an on-board computer.
Allen of BrooksAllen of Brooks• First Subsumptive Robot• Almost entirely reactive, using sonar
readings to keep away from people and other moving obstacles, while not colliding with static obstacles.
• Also had a non-reactive higher level which attempted to head towards a goal.
• Used the same type of architecture for both types of behaviors.
named after Allen Newell?
AllenAllen
• In addition to sonars, odometry• Offboard Lisp machine for
control by cable– 1st layer: avoid obstacles
– 2nd layer: random wandering
– 3rd layer: head toward distant places
Lowest level reactive layer; used sonar readings to keep away from moving and static obstacles. - if an obstacle is close, instead of bumping into it, stop.
Second level; random wandering. Every 10 seconds, generate a movement in a random direction.
Third level: Look for a distant place, and move towards it. Odometry can be used to monitor progress.
Three layers made it possible for robot to approach goal, whilst avoiding obstacles.
Goal subsumption: switching control between the modules is driven by the environment, not by a central locus of control.
Robot heads for goal until sensors pick up information that there is an obstacle in the way.
The obstacle avoidance module cuts in.
Once the obstacle has been avoided the goal-finding module takes control again.
Robot can move around in the environment although it does not build, or use, any map of that environment, and is only driven by simple environmental cues.
Examples of Different Examples of Different Behavior Levels for Behavior Levels for Robot Robot
SoccerSoccer
InteRRaps program for soccer InteRRaps program for soccer (Jung, RoboCup 98)(Jung, RoboCup 98)
• Levelized architecture– level of movements– Level of local planning– Level of social planning
Architecture EssexWizards for Architecture EssexWizards for soccersoccer
simulation
Behavior Architecture Essex W.Behavior Architecture Essex W.
High-Level Behaviors (tactical)
Low-Level Behaviors (primitive)
External Threads
Architecture Architecture FC PortugalFC Portugal
tactical situational
formational
Advanced communication
High High Level Level
Decisions Decisions in FCPin FCP
Soccer Behavior Modes (1)Soccer Behavior Modes (1)• Localize: Find own field location if it’s unknown.• Face Ball: Find the ball and look at it.• Handle Ball: Behavior is used when the ball is
kickable.• Active Offense: Go to the ball as quickly as possible.
Behavior is used when no teammate could get there more quickly.
• Auxiliary Offense: Get open for a pass. Behavior is used when a nearby teammate has the ball.
Soccer Behavior Modes (2)Soccer Behavior Modes (2)• Passive Offense: Move to a position likely to be useful
offensively in the future.• Active Defense: Go to the ball even though another
teammate is already going. Behavior is used in the defensive end of the field.
• Auxiliary Defense: Mark an opponent.• Passive Defense: Track an opponent or go to a position
likely to be useful defensively in the future.
Herbert robot from Brooks Herbert robot from Brooks Labs in MITLabs in MIT
• Used a laser scanner to find soda can-like objects visually, – infrared proximity sensors to navigate by following walls and going
through doors.
• A magnetic compass was used to maintain a global sense of orientation.
• A host of sensors on an arm were used to reliably pick up a soda can.
• Herbert's task was to wander around looking for soda cans, pick one up and bring it back to where Herbert had started from.
(Herbert Simon?)
HerbertHerbert• 24 8-bit processors, loosely coupled
via slow interfaces.• 30 IR sensors for obstacle avoidance.• Manipulator with grasping hand.• Laser striping system: 3D depth data.• Wanders office, follows walls.• Finds table, triggering can finder,
which robot centers on.• Robot stationary: drives arm forward.• Hand grasps when IR beam broken.
Subsumption architecture: several behaviour-
generating modules.Modules include obstacle avoidance, wall
following, and recognition of coke cans.Control of modules: Only suppression and inhibition between
alternative modules - no other internal communication.
Each module connected to sensors and to arbitration network which decides which competing action to take.
Description of Herbert in action:
When following a wall, Herbert spots a coke can. The robot locates itself in front of the can. The arm motion is then begun - when can is detected with sensors local to the arm, it is picked up.
Advantages; naturally opportunistic. If coke can put right in front of Herbert, can collect it and return to start, since no expectations about where coke cans will be found. Can find coke cans in a variety of locations, even if never found there before.
But….
Genghis Genghis
• Walk under subsumption control over varied terrain.
• Each leg “knows” what to do.• Leg lifting sequence centrally
controlled.• Additional layers suppress
original layers when triggered.
• Highest layer suppresses walking until person in field.
• Then Attacks.
Brooks‘ Walking robot - GenghisBrooks‘ Walking robot - Genghis
Walking robot - GenghisWalking robot - Genghis
Brook‘s Hexapod with whiskers
Brooks Robot Example: GenghisBrooks Robot Example: Genghis
• Level1: standup– 2 modules per leg;– control alpha (advance) & beta (balance) motor
• Level2: simple walk– does not compenstate for rough terrain
• Level3: force balancing– Compensates for rough terrain
• Level4: leg lifting• Level5: whiskers• Level6: pitch stabilization• Level7: steered prowling
Walking with six legsWalking with six legs
Walk Up legtrigger
leg down
beta positionS
Equilibrium of the legsEquilibrium of the legs
alphaadvance
alpha balance
alpha positionS
Alpha balance tries to makethe sum of the alpha angles zero
WalkingWalking
WalkUp legtrigger
leg down
beta posS
alphaadvance
alpha balance
alpha posS
Walking in rough terrainWalking in rough terrain
WalkUp legtrigger
leg down
beta posS
alphaadvance
alpha balance
alpha posS
Alphacollision
From Genghis to AtillaFrom Genghis to Atilla• Genghis is a 1Kg six legged robot which walks
under subsumption control and has an extremely distributed control system
• It can walk over rough terraine using 12 motors, 12 force sensors, 6 pyroelectric sensors, one inclinometer and 2 whiskers.
• They built a follow-up, Attila--Stronger climber, and faster: able to scramble at around 3 KPH. Periodic recharging of batteries.
Atilla = Killer Application?Atilla = Killer Application?• Brooks suggested using Attila
as planetary rover.• Small rovers provide economic
advantage.• Reduces need for 100%
reliability.• Legs are much richer sensors
than wheels.• Little need for long term state.• NASA's cheaper-faster-better
strategy.
Daedalus is a six-legged frame-walker with efficient redundant drive systems. Daedalus was designed for extreme terrain missions as part of CMU's Lunar Rover Initiative
The Ambler is a six-legged walking machine for extreme terrains. Key attributes include orthogonal legs, body level motions and a circulating gait. Ambler was a mainstay of our planetary rover work for several years.
Subsumption Subsumption Architecture and Architecture and
Map building using Map building using SSelf-elf-OOrganizing rganizing
NNetworksetworks
ExperimentExperiment• Input Vector
– Sonar Measure in 8 directions– Action
• Action Strategy– Obstacle Avoiding
– Wandering (or Wall following?)
))4
sin(),4
cos((7
02
7
02
id
ci
d
cv
ii
Sensor data - SOMSensor data - SOM
Map: SOM 21-Jun-1999, Data: D, Size: 10 1030 40 50 60 70 80
35
40
45
50
55
60
65
70
Student project on subsumptionStudent project on subsumption
KickbotKickbot
Objectives of student projectObjectives of student project• Build an autonomous
robot from scratch
• Design a robot such that falling over is not a failure mode
• Investigate interesting embodied behaviors with a real robot
Kickbot Behaviors Kickbot Behaviors
• Wander– Kickbot wanders around avoiding obstacles
• Tumble– If kicked, Kickbot tumbles and resumes wandering
when stable
• Antagonize– Kickbot periodically stops to look for interesting
movement– If found, then it antagonizes the interesting object
until it is kicked
Subsumption Architecture of KickbotSubsumption Architecture of Kickbot
• Wander with no obstacle detection
Wander
MotorR
MotorL
FF/FB
FF/FB
Forward/backward of motors
Subsumption Architecture of KickbotSubsumption Architecture of Kickbot
• Wander with obstacle detection
Wander
MotorR
MotorL
S
S
S
S
Forw. IR
Back IR
I
I
FB
SB
SF
FF
Switch Dir
S nodes
I nodes
Wandering behavior workingWandering behavior working
– First version included no turning yet – Kickbot illustrated an embodied behavior by
successfully wandering around– Current version has two turning modes
• Reverse with slight motor differential when obstacle detected
• Spin for specific amount of time when obstacle detected
Subsumption Architecture of KickbotSubsumption Architecture of Kickbot
Subsumption ArchitectureSubsumption Architecture
• Wander and Tumble
Wander
MotorR
MotorL
IS
IS
S
S
Forw. IR
Back IR
Mercury Tumble
I
I
Subsumption Architecture of KickbotSubsumption Architecture of Kickbot
Subsumption ArchitectureSubsumption Architecture
• Wander, Tumble, and Antagonize
Wander
MotorR
MotorL
ISS
S IS
S
S
Forw. IR
Back IR
Mercury Tumble
CameraMovementDetector Antagonize
I
I
I
I
Subsumption Architecture of KickbotSubsumption Architecture of Kickbot
Mechanical Aspects of KickbotMechanical Aspects of Kickbot
• Two independently rotating half-spheres – Allows for differential drive
– Attached to motor axels using custom aluminum hub and six spokes
– Set screws allow for easy removal
• Central disk– Counter-weight (batteries and lead weights) keeps central disk upright
and helps stabilize robot after tumbling
– Provides space for mounting electronics and sensors
• Two gear top motors– Mounted in middle of central disk
– 4,500 rpm geared through a 1:30 gear ratio
Mechanical AspectsMechanical AspectsMechanical Aspects of KickbotMechanical Aspects of Kickbot
Sensors in KickbotSensors in Kickbot• Two Sharp GP2D12 infrared sensors
– Provides distance as an analog voltage up to 80cm
– Used for obstacle avoidance
• Two mercury switches– Aligned such that they are both on when central disk is upright
– Used to detect tumbling
• Gameboy camera (Mitsubishi M64283FP)– Provides image as 128x128 analog pixel values
– Can do edge detection in on-camera hardware
– Used to detect interesting movement
SensorsSensorsSensors in KickbotSensors in Kickbot
Electrical Aspects of KickbotElectrical Aspects of Kickbot
• Control board– PIC16F877, display LEDs, dip switches, power regulator
– Monitors IR sensors and mercury switches
– Sends PWM to H-bridges for motor control
• H-Bridges– National Semiconductor LMD18201T
– Converts PWM input to 12V to vary motor speed
• Camera board– PIC16F877, 32KB SRAM, random TTL logic
– Captures camera image and advises control board
– Includes RS232 interface to dump image data to host computer
Electrical AspectsElectrical Aspects
Autonomous Robot Teams Autonomous Robot Teams in Dynamic and Uncertain in Dynamic and Uncertain
EnvironmentsEnvironments
• Prof. Manuela Veloso, Dr. Tucker Balch, and Dr. Brett BrowningCarnegie Mellon University
Robot Soccer
Distributed Sensor
Fusion
Agents can maintain a larger and more accurate view of the environment using
communication.
Two agents observe one object. Observations are uncertain due to sensor noise.
Communication enables
•Building a world model through merging own sensing and observations transmitted by team members•Team tracking of objects that only one agent sees•More accurate location of objects simultaneously observed by multiple agents
Agents represent and communicate object locations as 2-D Gaussian probability distributions.
Ashley Stroupe
1
2
The observations are fused to provide a more accurate estimate of the object’s location.
The observations are fused to provide a more accurate estimate of the object’s location
Two agents observe one object. Observations are uncertain due to sensor noise
Agents represent and communicate object locations as 2-D Gaussian probability distributions
•Two teams of robots competed at RoboCup in the robotic mid-size soccer games and Sony dog legged league•Robot soccer provides a highly dynamic, adversarial environment ideal for developing robust control architectures•Successful teams require diverse range of individual and team skills in the partially observable environment
The mid-size team, CMU Hammerheads, blue collars
Sony dogs, CMPack also competed
CMPack robot
dog team
CMPack robot soccer team attacks the difficult perceptual and kinematics problems of legged motion in robot soccer
•Robust low-level behaviors for different kicking modes, walking, crash recovery and game play•CMVision for reliable color blob detection and tracking•Sensor Resetting Localization for reliable field positioning
CMPark use multi-fidelity behaviors to achieve real-time intelligent motion
Robust Individual
Behaviors
Robust individual behaviors for an adversarial, partially observable environment.
•Individual behaviors combine to produce complex intelligent behavior as a whole•Robust to typical sensor limitations and noise•Behaviors implemented in TeamBots using Motor Schemas
Basic behaviors allow for robust navigation even with limited sensor range and noise
Simple individual behaviors combine to produce complex motions to achieve the robot’s objectives
CMU Hammerheads
CMU Hammerheads Mid-size robot soccer team provides a testing ground for the MARS
software
CMU Hammerheads strategy uses fixed role assignment and combinations of robust individual behaviors
•Team consists of three field robots and one goalie•Sensor fusion used for cooperative localization of field objects
•Multi-fidelity behaviors for efficient motion depending on available sensor and localization accuracy
New Innovativ
e
Platform
s
•New robot hardware for mid and small size robot soccer•Heterogeneous team structure now possible•Spectrum of mobility issues from fully holonomic to non-holonomic with a trailer through to high-speed manoeuvrability
Our new hardware platforms designed for robot soccer small and mid size leagues
DiffBot 1.0: Compact high-speed design. Includes custom DSP board and RF link
CyeBot 2.0: New compact design for increased reliability. New design uses single laptop, the Cye
robot and a USB camera.
Holonomic design enables full range of motions. Includes custom DSP board and RF link
DVTBOt 1.d. Includes DSP board and RF link
CveBot 2.D. Increased reliability.Uses single laptop, and USB camera
Development Life Development Life CycleCycle
Evolutionary Model
Benefits:
Downfalls:
Lends itself to testing and improvement in several betas
Difficult to apply to a timeline due to iterations
Evolve mind together with bodyEvolve mind together with body
Student Subsumption ProjectStudent Subsumption ProjectFinite State Machines
Behavior Based Robotics
Robot
Finite State Machine
Subsumption Architecture
This year is the second year of this competition. The objective is to build a robot which will compete in the following challenge:
Qualification Round:
The robot must navigate through a maze in less that 20 minutes.
Competition Round:
The robot must navigate and map a maze and then race through the maze as quickly as possible.
• Robbie must find it’s way from entrance to exit within 20 minutes.
• Robbie must remember the path to get through the maze.
• Robbie must then run the race again using his memory and get to the exit as fast as possible.
• Must fit between walls 8 inches apart.
• Must be no taller that 12”.
• May not mark the track in any way.
• May not be connected to any external devices.
PAGE descriptions – List the agent type, its percepts, actions, goals, and environment.
Agent Type Percepts Actions Goals Environment
Maze Racer Differences inlight, touch,
rotation clicks
Turn right orleft, drivestraight,
internal u-turn,mapping of
maze, followingOf map
Get throughmaze, be thefastest, map
maze &successfullyfollow map
Mazecontainingdirectionalchoices of
2 (no more, noless)
Finite State Machine
Assess Environment
Partition into Situations
Create Situational Responses
Import Behaviors to Robot
Run Robotic Experiments
Evaluate Results
Enahance, Expand, Correct Behavioral Responses
Done
Subsumption Architecture
•Also known as reactive planning.
•It can be implemented with either a table or set of condition-action rules.
•It is hierarchical in nature. The default behavior can be overridden by behaviors that have higher priority (those that would score more ‘points’ or bring it closer to the goal state).
Recall
Subsumption Architecture
int map() {
//multiple threadsopenLeft();openRight();deadEnd();arbitrate();return;
}
int openLeft() { while(1) {
if (opening on left){ Turn Left; Store 0 in map;}
} return;}
int openRight() { while(1) {
if (open on right){ store 0 in map;}
} return;}
int deadEnd() { while(1) {
if (deadEnd){ Virtual U-turn; Replace 0 w/ 1; !map next turn; turn left next;}
} return;}
Platforms:
The Lego Mindstorms RCX
+ Simplistic
- Limited Sensors and Motors
Handy Board
+ More Sensors and Motors
- Difficult to Program
LEGO LEGO MindstormMindstorm RCX RCX
3 Output or Motor Ports (A, B, C)
3 Input or Sensor Prots (1, 2, 3)
IR Transmitter/Reciever
The Handy Board
The Handy Board is based on the 52-pin Motorola MC68HC11 processor, and includes 32K of battery-backed static RAM, four outputs for DC motors, a connector system that allows active sensors to be individually plugged into the board, an LCD screen, and an integrated, rechargable battery pack. This design is ideal for experimental robotics project, but the Handy Board can serve any number of embedded control applications.
Advantages:
Nearly C++ functionality
Open Source Kernel
(adaptable to our needs)
Disadvantages:
Complexity of Program
Bugs in new language.
Advantages:
Simplistic
Easy to learn
Disadvantages:
Limited number of var.
Limited data types
Functionality not complex enough.
MOVAID: Decentralized MOVAID: Decentralized distributed architecturedistributed architecture
Human Interface
Planning
Distribution Task
Module(Reactive)
1
Module(Reactive)
2
Module(Reactive)
N
………
Central Planning System
System MOVAID: mobile assistive robotSystem MOVAID: mobile assistive robot
System MOVAID: mobile robot talks to System MOVAID: mobile robot talks to fixed devicesfixed devices
robot
Interface workstation
Appliances
Appliance interfaces
Typical apartment
room kitchen
docking
System MOVAID: mobile unitSystem MOVAID: mobile unit
Head:auto-localisation+ vision system
Arm + Hand
Tray
Bumper
Mobile base+ low level
controls
Docking system
RS232
RACK 1
RACK 2
Radio Link
Frame Grabber
CPU
Controller
US
Controller of wheels (3 axes)
CPU
(4
Hardware Architecture of the mobile Hardware Architecture of the mobile robotrobot
Arm controller (4 axis)
Arm controller (4 axis)
Arm controller (2 axis)
A/D converter
ETHERNET
Docking System
User interface
Power Supply
CPU (Supervisor)
Wireless link module
Hardware Hardware of fixed stationof fixed station
Software Software architecture architecture
of fixed of fixed stationstation
Cooperation for localization and Cooperation for localization and movementmovement
Supervision module:• 3D position localization (x,y,z)• movement planning (x,y,z,,,)
human interface
(u,v)
visionClick
interface
(x,y,z,,,)
Human Interface to MOVAIDHuman Interface to MOVAID
Human Interface to MOVAIDHuman Interface to MOVAIDBeginner levelBeginner’s levelBeginner’s level
advanced leveladvanced levelHuman Interface to MOVAIDHuman Interface to MOVAID
L’interfaccia utente di MOVAIDL’interfaccia utente di MOVAIDHuman Interface to MOVAIDHuman Interface to MOVAID
System P3: distributed system System P3: distributed system
Embedded SystemsEmbedded Systems
• Domains– telecommunications
– consumer electronics
– automotive electronics
• IP components– protocol stacks
– common algorithms
– devices w/ drivers
• Properties– family/evolution of systems
– heterogeneous architectures
– non-trivial control
Design by CompositionDesign by Composition
• An example system - robot– components:
• bumper
• sonar
• joystick
• wheels
AUTOMANUAL
sonar
bumper
wheelsjoystick
OutlineOutline
• New ways to package– functionality– control & coordination
• Software synthesis– control – communication
• Selective focus co-simulation– functional– timed
Observations on Current Observations on Current ComponentsComponents
• Functionality separate from interfaces
• Data and event based interfaces– each component contains ports– ports connected to form a system
• What about control? – control is a system concept– but traditionally hardwired in components– changes require intrusive modification
IPCIPCHINOOK’HINOOK’s Component Packaging:s Component Packaging:Adaptable modal processesAdaptable modal processes
• Data interface contains ports
• Control interface contains modes
{}
{}
{}
{}
{}
a b c d
{}
{}
{}{}
{}{}
{}
{}
{}
{}
a b
{}
Change mode-a+b
a b
x
y
z
Control & Coordination Protocol: Control & Coordination Protocol:
subsumptionsubsumption• Must handle three cases:– subsume, yield, idle– hard-coded in each component
joystick
bumper
sonar
wheels
escape
avoid
override
s
s
sensorsactuators
decisionmodules
decisioncomposition
isy
isy
sy
isy
i
i
i
i
i
s i
s i
yi
ys
yi
Control Protocol Packaging:Control Protocol Packaging:Abstract control types (ACTs)Abstract control types (ACTs)
• Sets of constraints between modes– one mode change implies other mode changes– constrain the state space spanned by modes
• Usage– inter-component coordination – adaptation
• ACTs can be layered
i s y i s y
Mutual exclusion Activate
Integrating components with ACTsIntegrating components with ACTs
ACT
subsume
modalprocesses
joystick bumper sonar wheels
adaptation
modalprocesses
ACT
adaptation
joystick bumper sonar wheels
subsume
Component adaptation exampleComponent adaptation example
BF
idle
BI
idle
B W T
subsume yield
Bumper process
Subsumption adapter
Component adaptation exampleComponent adaptation example
subsume
WB TI
yieldidle
+B
BI
subsumeidle
WB
+subsuming
yieldsubsume
W
Bumper process
Subsumption adapter
+W
System synthesis interactionSystem synthesis interaction
Map functionality to architecture
Designer: IPChinook:
Map functionality to architecture
modemanager
Determine control communication
System synthesis interactionSystem synthesis interaction
Designer: IPChinook:
Map communication to architecture
System synthesis interactionSystem synthesis interaction
Designer: IPChinook:
Determine Control Communication
A B C
System synthesis interactionSystem synthesis interaction
Designer: IPChinook:
Map communication to architecture
Synthesize hop-processes and rest of runtime support
A B C
Inventory of runtime supportInventory of runtime support
• For each processing element:– Mode managers – Hop processes for communication– Customized versions of processes– Message routers– Execution schedules to meet real-time constraints
Co-simulationCo-simulation
• Validate functionality
• Validate timing aspects of behavior
• Estimate utilization
• Evaluate implementation decisions
• Selective focus for efficiency
Selective FocusSelective Focus
Selective FocusSelective Focus
Modal Process
interface
Modal Process
interface
Protocol stack Protocol stack
Full Words
Packets
Tokens Control Actions +a -x
Full Words
Packets
Tokens Control Actions +a -x
IPCIPCHINOOKHINOOK design flow summary design flow summary
Functionality mapping
Communication mapping
IP Component selectionCustom component authoring
System Composition
Control synthesis
Communication & Runtime synthesis
High-level simulation
Co-simulation
Des
ign
er &
ID
E
Syn
thesis
Systems designed with IPCSystems designed with IPCHINOOKHINOOK
• Maze solving robot– Similar to robot shown here– Follows left wall to get out of maze
• WubbleU PDA– Handheld web browser– proposed codesign benchmark
• Watch – from examples used by Berry & Harel
IDE ScreenshotIDE Screenshot
ConclusionConclusion
• Facilitates IP-based design through control and data interface abstractions
• Automatic synthesis enables re-mapping of specification to multiple architectures
• Integrated co-simulation with synthesis shortens design flow feedback loops
• IPCHINOOK is a complete environment for rapid prototyping
Ongoing & Future workOngoing & Future work
• High level debugging leveraging modal process abstractions
• Formal verification of control structures
• Extension to networked systems
• Commercialization viaConsystant Design Technologies
LiteratureLiterature
• (*) R. A. Brooks, “A Robust Layered Control System for a Mobile Robot”, Cambrian Intelligence, The MIT Press
J. O. Gray, D. G. Caldweel, “Advanced Robotics & Intelligent Machines” R. A. Brooks, “Cambrian Intelligence”, The MIT Press
SourcesSources• Brooks
• Ceylon TCS, MIT
• Maja Mataric
• Nilsson book
• Jeremy Elson
• Norvig’s book
• Dave Rudolph
• English PH.D thesis, recent
• Chris Batten• David Wentzlaff • Cecilia Laschi• Pai Chou, Ken Hines, Ross Ortega, Kurt Partridge, Gaetano Borriello,
University of Washington
Team Members:
Dave Rudolph - Lead Web Designer
Lead Programmer
Samara Secor - Lead Analyst
Documentation Specialist
IPCIPCHINOOKHINOOKan integrated IP-based design framework for an integrated IP-based design framework for
distributed embedded systemsdistributed embedded systems
Pai Chou, Ken Hines, Ross Ortega,
Kurt Partridge, Gaetano Borriello
University of Washington
36th DAC - 22 June 1999