Subsumption examples
Let us analyze
some subsumption
robots and systems
Squirt 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 Brooks
• First Subsumptive Robot
named after Allen Newell?
• 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.
Allen
• 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
Behavior Levels for Robot
Soccer
InteRRaps program for soccer (Jung,
RoboCup 98)
• Levelized architecture
– level of movements
– Level of local planning
– Level of social planning
Architecture EssexWizards for
soccer
simulation
Behavior Architecture Essex W.
High-Level
Behaviors
(tactical)
Low-Level
Behaviors
(primitive)
External
Threads
Advanced
communication
tactical
formational
Architecture
FC Portugal
situational
High
Level
Decisions
in FCP
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)
• 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
Labs in MIT
(Herbert Simon?)
• 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
• 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.
Advantageous; 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
Brooks‘ Walking
robot - 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.
Walking robot - Genghis
Brook‘s Hexapod with whiskers
Brooks 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 legs
Walk
Up leg
trigger
leg
down
S
beta position
Equilibrium of the legs
alpha
advance
alpha
balance
Alpha balance tries to make
the sum of the alpha angles zero
S
alpha position
Walking
Walk
Up leg
trigger
leg
down
S
beta pos
alpha
advance
alpha
balance
S
alpha pos
Walking in rough terrain
Walk
Up leg
trigger
leg
down
Alpha
collision
S
beta pos
alpha
advance
alpha
balance
S
alpha pos
From 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?
• 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
Architecture and
Map building using
Self-Organizing
Networks
Experiment
• Input Vector
– Sonar Measure in 8 directions
– Action
• Action Strategy
– Obstacle Avoiding
7
7

c

c

v  ( 2 cos( i ),  2 sin( i ))
4 i 0 d
4
i 0 d
– Wandering (or Wall following?)
Sensor data - SOM
70
65
60
55
50
45
40
35
30
Map: SOM 21-Jun-1999, Data: D, Size: 10 10
40
50
60
70
80
Student project on subsumption
Kickbot
Objectives 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
• 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 Kickbot
• Wander with no obstacle detection
MotorR
FF/FB
Wander
FF/FB
MotorL
Forward/backward of motors
Subsumption Architecture of Kickbot
• Wander with obstacle detection
S
Switch
Dir
S
MotorR
Wander
S
S
MotorL
FB
Forw. IR
I
SB
SF
Back IR
I
FF
S nodes
I nodes
WanderingArchitecture
behavior working
Subsumption
of Kickbot
– 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
Subsumption
Architecture
of Kickbot
• Wander and Tumble
S
S
I
MotorR
I
MotorL
Wander
S
Forw. IR
I
Back IR
Mercury
I
Tumble
S
Subsumption
Architecture
Subsumption
Architecture
of Kickbot
• Wander, Tumble, and Antagonize
Camera
Movement
Detector
Antagonize
S
S
S
I
I
MotorR
I
I
MotorL
Wander
S
Forw. IR
I
Back IR
Mercury
I
Tumble
S
S
Mechanical 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
Mechanical
Aspects
Aspects
of Kickbot
Sensors 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
Sensors
Sensors in Kickbot
Electrical 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 Aspects
Autonomous Robot Teams
in Dynamic and Uncertain
Environments
• Prof. Manuela Veloso, Dr. Tucker Balch, and Dr.
Brett Browning
Carnegie Mellon University
Robot Soccer
Ashley
Stroupe
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
Two agents observe one object. Observations are uncertain due to sensor noise.
1
Agents represent and communicate object locations
as 2-D Gaussian probability distributions.
Agents represent and communicate
object locations as 2-D Gaussian
probability distributions
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.
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
The mid-size team, CMU
Hammerheads, blue collars
Sony dogs, CMPack also competed
•Two teams of robots competed at RoboCup in the robotic midsize 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
CMPack robot soccer team attacks the difficult perceptual and
kinematics problems of legged motion in robot soccer
CMPark use
multi-fidelity
behaviors to
achieve realtime intelligent
motion
•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
Robust individual behaviors for an adversarial,
partially observable environment.
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
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
CMU Hammerheads Mid-size
robot soccer team provides a
testing ground for the MARS
software
•Team consists of three field robots and one goalie
CMU Hammerheads strategy uses fixed role assignment and combinations of robust
individual behaviors
•Sensor fusion used for cooperative localization of field
objects
•Multi-fidelity behaviors for efficient motion depending on
available sensor and localization accuracy
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
DVTBOt 1.d. Includes DSP board and
RF link
Holonomic design enables full
range of motions. Includes
custom DSP board and RF link
•New robot hardware for mid and
small size robot soccer
•Heterogeneous team structure now
possible
CveBot 2.D. Increased
reliability.Uses single laptop,
and USB camera
CyeBot 2.0: New compact design for increased
reliability. New design uses single laptop, the
Cye robot and a USB camera.
•Spectrum of mobility issues from
fully holonomic to non-holonomic with
a trailer through to high-speed
manoeuvrability
Development Life
Cycle
Evolutionary Model
Benefits:
Lends itself to testing and improvement
in several betas
Downfalls:
Difficult to apply to a timeline due to
iterations
Evolve mind together with body
Student Subsumption Project
Finite 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
Maze Racer
Percepts
Actions
Goals
Turn right or
Get through
Differences in
left, drive
maze, be the
light, touch,
straight,
rotation clicks internal u-turn, fastest, map
maze &
mapping of
successfully
maze, following
follow map
Of map
Environment
Maze
containing
directional
choices of
2 (no more, no
less)
Finite State Machine
Assess
Environment
Import
Behaviors to
Robot
Partition into
Situations
Run Robotic
Experiments
Create
Situational
Responses
Evaluate Results
Done
Enahance,
Expand,
Correct
Behavioral
Responses
Recall
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).
Subsumption Architecture
int map()
{
//multiple threads
openLeft();
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 Mindstorm RCX
3 Output or Motor Ports (A, B, C)
3 Input or Sensor Prots (1, 2, 3)
IR Transmitter/Reciever
•
The Handy Board is based on the 52pin Motorola MC68HC11 processor
•
It includes
•
The Handy Board
•
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:
Advantages:
Nearly C++ functionality
Simplistic
Open Source Kernel
Easy to learn
(adaptable to our needs)
Disadvantages:
Disadvantages:
Limited number of var.
Complexity of Program
Limited data types
Bugs in new language.
Functionality not
complex enough.
MOVAID: Decentralized
distributed architecture
Human Interface
Planning
Central Planning
System
Distribution Task
Module
(Reactive) 1
Module
(Reactive) 2
………
Module
(Reactive) N
System MOVAID: mobile assistive robot
System MOVAID: mobile robot talks to
fixed devices
Appliances
Typical apartment
room
Appliance
interfaces
kitchen
robot
Interface workstation
docking
System MOVAID: mobile unit
Arm + Hand
Tray
Bumper
Head:
auto-localisation
+ vision system
Mobile
base
+ low level
controls
Docking
system
Hardware Architecture of the mobile
robot
CPU
Controller of
wheels (3 axes)
A/D
converter
Controller
US
RACK 1
RS232
Radio
Link
Frame
Grabber
RACK 2
CPU
Arm
controller
(4 axis)
Arm
controller
(4
(4 axis)
Arm
controller
(2 axis)
Hardware of fixed station
Wireless link
module
ETHERNET
User
interface
CPU
(Supervisor)
Docking System
Power
Supply
Software
architecture
of fixed
station
Cooperation for localization and
movement
Click
interface
vision
(u,v)
human interface
Supervision module:
• 3D position localization (x,y,z)
• movement planning (x,y,z,,,)
(x,y,z,,,)
Human Interface to MOVAID
Human Interface to MOVAID
Beginner’s
level
Beginner level
Human Interface to MOVAID
advanced level
L’interfaccia
utenteto
diMOVAID
MOVAID
Human
Interface
System P3: distributed system
Embedded Systems
• Domains
• IP components
– telecommunications
– consumer electronics
– automotive electronics
– protocol stacks
– common algorithms
– devices w/ drivers
• Properties
– family/evolution of systems
– heterogeneous architectures
– non-trivial control
Design by Composition
• An example system - robot
– components:
•
•
•
•
bumper
bumper
sonar
sonar
joystick
joystick
wheels
wheels
AUTO
MANUAL
Outline
• New ways to package
– functionality
– control & coordination
• Software synthesis
– control
– communication
• Selective focus co-simulation
– functional
– timed
Observations on Current
Components
• 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
IPCHINOOK’s Component Packaging:
Adaptable modal processes
• Data interface contains ports
• Control interface contains modes
a
a
Change mode
-a
+b
x
{
}
y
z
b
c
{
}
d
{
}
{
}
{
}
{
}
{
}
b
Control & Coordination Protocol:
subsumption
• Must handle three cases:
y
– subsume, yield, idle
– hard-coded in each component
s
i
y
s
joystick
override
bumper
escape
sonar
avoid
y
s
s
s
wheels
sensors
actuators
i
i
y
decision
modules
decision
composition
s
i
Control Protocol Packaging:
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
Integrating components with ACTs
subsume
i s y
i s y
ACT
Mutual exclusion
Activate
adaptation
modal
processes
joystick
bumper
sonar
wheels
Component adaptation example
subsume
ACT
Subsumption adapter
idle
subsume
yield
adaptation
modal
processes
FI
B
joystick
W T
bumper
Bumper process
sonar
wheels
Component adaptation example
Subsumption adapter
idle
I
+B
subsume
B
W
Bumper+W
process
yield
T
+subsuming
System synthesis interaction
Designer:
Map functionality to architecture
IPChinook:
System synthesis interaction
Designer:
IPChinook:
Map functionality to architecture
Determine control communication
mode
manager
System synthesis interaction
Designer:
IPChinook:
Map communication
Determine Control Communication
to architecture
A
B
C
System synthesis interaction
Designer:
IPChinook:
Map communication Synthesize hop-processes
and rest of runtime support
to architecture
A
B
C
Inventory 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-simulation
•
•
•
•
•
Validate functionality
Validate timing aspects of behavior
Estimate utilization
Evaluate implementation decisions
Selective focus for efficiency
Selective Focus
Selective Focus
Modal Process
Modal Process
Protocol stack
Protocol stack
interface
interface
Tokens
Control Actions +a -x
Packets
Full Words
IPCHINOOK design flow summary
High-level simulation
Functionality mapping
Control synthesis
Communication mapping
Communication &
Runtime synthesis
Co-simulation
Synthesis
Designer & IDE
IP Component selection
Custom component authoring
System Composition
Systems designed with IPCHINOOK
• 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 Screenshot
Conclusion
• 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 work
• High level debugging leveraging modal process
abstractions
• Formal verification of control structures
• Extension to networked systems
• Commercialization via
Consystant Design Technologies
Literature
• (*) 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
Sources
•
•
•
•
•
•
•
•
•
•
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
IPCHINOOK
an integrated IP-based design framework for
distributed embedded systems
Pai Chou, Ken Hines, Ross Ortega,
Kurt Partridge, Gaetano Borriello
University of Washington
36th DAC - 22 June 1999