Title: Subsumption examples
1Subsumption examples
- Let us analyze some subsumption robots and systems
2Squirt 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.
3Allen of Brooks
named after Allen Newell?
- 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.
4 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
5- 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.
6- 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.
7Examples of Different Behavior Levels for Robot
Soccer
8InteRRaps program for soccer (Jung, RoboCup 98)
- Levelized architecture
- level of movements
- Level of local planning
- Level of social planning
9Architecture EssexWizards for soccer
simulation
10Behavior Architecture Essex W.
High-Level Behaviors (tactical)
Low-Level Behaviors (primitive)
External Threads
11Architecture FC Portugal
Advanced communication
tactical
situational
formational
12High Level Decisions in FCP
13Soccer Behavior Modes (1)
- Localize Find own field location if its
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.
14Soccer 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.
15Herbert 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.
16 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.
17-
- 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.
18- 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.
19(No Transcript)
20 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.
21Walking robot - Genghis
Brooks Hexapod with whiskers
22Brooks 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
23Walking with six legs
Walk
Up leg trigger
leg down
beta position
S
24Equilibrium of the legs
alpha advance
alpha balance
alpha position
S
Alpha balance tries to make the sum of the alpha
angles zero
25Walking
Up leg trigger
Walk
leg down
beta pos
S
alpha advance
alpha balance
alpha pos
S
26Walking in rough terrain
Up leg trigger
Alpha collision
Walk
leg down
beta pos
S
alpha advance
alpha balance
alpha pos
S
27From 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.
28Atilla 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.
29Daedalus 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.
30(No Transcript)
31Subsumption Architecture and Map building using
Self-Organizing Networks
32Experiment
- Input Vector
- Sonar Measure in 8 directions
- Action
- Action Strategy
- Obstacle Avoiding
- Wandering (or Wall following?)
33Sensor data - SOM
34(No Transcript)
35Student project on subsumption
36Objectives 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
37Kickbot 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
38Subsumption Architecture of Kickbot
- Wander with no obstacle detection
Forward/backward of motors
39Subsumption Architecture of Kickbot
- Wander with obstacle detection
MotorR
S
S
Wander
Switch Dir
MotorL
S
S
FB
Forw. IR
I
SB
SF
Back IR
I
FF
S nodes
I nodes
40Wandering behavior working
Subsumption Architecture 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
41Subsumption Architecture
Subsumption Architecture of Kickbot
MotorR
I
S
S
Wander
MotorL
I
S
S
Forw. IR
I
Back IR
I
Mercury
Tumble
42Subsumption Architecture
Subsumption Architecture of Kickbot
- Wander, Tumble, and Antagonize
Camera
MovementDetector
Antagonize
MotorR
I
S
S
S
I
Wander
MotorL
S
I
S
S
I
Forw. IR
I
Back IR
I
Mercury
Tumble
43Mechanical 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 130 gear ratio
44Mechanical Aspects
Mechanical Aspects of Kickbot
45Sensors 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
46Sensors
Sensors in Kickbot
47Electrical 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
48Electrical Aspects
49Autonomous Robot Teams in Dynamic and Uncertain
Environments
- Prof. Manuela Veloso, Dr. Tucker Balch, and Dr.
Brett BrowningCarnegie Mellon University
Robot Soccer
50Distributed Sensor Fusion
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
Agents represent and communicate object locations
as 2-D Gaussian probability distributions.
Agents represent and communicate object locations
as 2-D Gaussian probability distributions
Two agents observe one object. Observations are
uncertain due to sensor noise.
The observations are fused to provide a more
accurate estimate of the objects location
The observations are fused to provide a more
accurate estimate of the objects 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
51The mid-size team, CMU Hammerheads, blue
collars Sony dogs, CMPack also competed
- 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
52CMPack robot soccer team attacks the difficult
perceptual and kinematics problems of legged
motion in robot soccer
CMPack robot dog team
CMPark use multi-fidelity behaviors to achieve
real-time 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
53Robust individual behaviors for an adversarial,
partially observable environment.
Robust Individual Behaviors
Basic behaviors allow for robust navigation even
with limited sensor range and noise
Simple individual behaviors combine to produce
complex motions to achieve the robots 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
54CMU Hammerheads Mid-size robot soccer team
provides a testing ground for the MARS software
CMU Hammerheads
- 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
CMU Hammerheads strategy uses fixed role
assignment and combinations of robust individual
behaviors
55Our new hardware platforms designed for robot
soccer small and mid size leagues
New Innovative Platforms
Holonomic design enables full range of motions.
Includes custom DSP board and RF link
DiffBot 1.0 Compact high-speed design. Includes
custom DSP board and RF link
DVTBOt 1.d. Includes DSP board and RF link
- 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
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.
56Development Life Cycle
Evolutionary Model
Benefits
Lends itself to testing and improvement in
several betas
Downfalls
Difficult to apply to a timeline due to iterations
57Evolve mind together with body
58Student Subsumption Project
Finite State Machines
Behavior Based Robotics
59Robot
60Finite State Machine
61Subsumption Architecture
62Maze Racer Competition
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.
63The Problem at Hand...
- Robbie must find its 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.
64Limitations...
- 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.
65(No Transcript)
66Intelligent Agents cont.
PAGE descriptions List the agent type, its
percepts, actions, goals, and environment.
Agent Type
Percepts
Actions
Goals
Environment
Maze Racer
Differences in light, touch, rotation clicks
Turn right or left, drive straight, internal
u-turn, mapping of maze, following Of map
Get through maze, be the fastest, map maze
successfully follow map
Maze containing directional choices of 2 (no
more, no less)
67Maze Racer...
Finite State Machine
68Spectrum of Robot Control
69Activity Design Methodology
Assess Environment
Import Behaviors to Robot
Partition into Situations
Run Robotic Experiments
Enahance, Expand, Correct Behavioral Responses
Create Situational Responses
Evaluate Results
Done
70Recall
Subsumption Architecture
- 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).
71Maze Racer...
Subsumption Architecture
72int map() //multiple threads openLeft() ope
nRight() deadEnd() arbitrate() return
int openLeft() while(1) if
(opening on left) Turn Left Store
0 in map return
73Pseudo-Code
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
74Decisions So Far...
Platforms The Lego Mindstorms RCX
Simplistic - Limited Sensors and Motors Handy
Board More Sensors and Motors - Difficult
to Program
75LEGO Mindstorm RCX
3 Output or Motor Ports (A, B, C) 3 Input or
Sensor Prots (1, 2, 3) IR Transmitter/Reciever
76The 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.
77LegOS vs NQC
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.
78MOVAID Decentralized distributed architecture
Human Interface Planning Distribution Task
Central Planning System
Module(Reactive) 1
Module(Reactive) 2
Module(Reactive) N
79System MOVAID mobile assistive robot
80System MOVAID mobile robot talks to fixed devices
Appliances
Appliance interfaces
Typical apartment
kitchen
room
robot
docking
Interface workstation
81System MOVAID mobile unit
Head auto-localisation vision system
Arm Hand Tray Bumper
Mobile base low level controls
Docking system
82Hardware Architecture of the mobile robot
A/D converter
Controller of wheels (3 axes)
Controller
CPU
US
RACK 1
RS232
Radio
Frame
Link
Grabber
RACK 2
Arm controller (4 axis)
Arm controller (4 axis)
Arm controller (2 axis)
CPU
(4
83Hardware of fixed station
84Software architecture of fixed station
85Cooperation for localization and movement
Click interface
vision
human interface
- Supervision module
- 3D position localization (x,y,z)
- movement planning (x,y,z,?,?,?)
(u,v)
(x,y,z,?,?,?)
86Human Interface to MOVAID
87Beginners level
Human Interface to MOVAID
Beginner level
88advanced level
Human Interface to MOVAID
89Linterfaccia utente di MOVAID
Human Interface to MOVAID
90System P3 distributed system
91 Embedded 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
92Design by Composition
- An example system - robot
- components
- bumper
- sonar
- joystick
- wheels
93Outline
- New ways to package
- functionality
- control coordination
- Software synthesis
- control
- communication
- Selective focus co-simulation
- functional
- timed
94Observations 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
95IPCHINOOKs Component PackagingAdaptable modal
processes
- Data interface contains ports
- Control interface contains modes
x
Change mode -a b
y
z
96Control Coordination Protocol subsumption
- Must handle three cases
- subsume, yield, idle
- hard-coded in each component
y
i
s
y
i
s
joystick
override
y
bumper
escape
s
s
i
sonar
avoid
s
y
wheels
i
s
sensors actuators
decision modules
decision composition
97Control Protocol PackagingAbstract 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
98Integrating components with ACTs
99Component adaptation example
100Component adaptation example
subsuming
Subsumption adapter
subsume
yield
idle
W
B
T
I
Bumper process
B
W
101System synthesis interaction
Designer
IPChinook
Map functionality to architecture
102System synthesis interaction
Designer
IPChinook
Map functionality to architecture
103System synthesis interaction
Designer
IPChinook
Determine Control Communication
A
B
C
104System synthesis interaction
Designer
IPChinook
Map communication to architecture
B
A
C
105Inventory 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
106Co-simulation
- Validate functionality
- Validate timing aspects of behavior
- Estimate utilization
- Evaluate implementation decisions
- Selective focus for efficiency
107Selective Focus
108Selective Focus
Modal Process
Modal Process
Protocol stack
Protocol stack
interface
interface
a -x
Packets
Full Words
109IPCHINOOK design flow summary
IP Component selection Custom component
authoring System Composition
High-level simulation
Functionality mapping
Designer IDE
Control synthesis
Communication mapping
Synthesis
Communication Runtime synthesis
Co-simulation
110Systems 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
111IDE Screenshot
112Conclusion
- 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
113Ongoing Future work
- High level debugging leveraging modal process
abstractions - Formal verification of control structures
- Extension to networked systems
- Commercialization viaConsystant Design
Technologies
114Literature
- () 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
115Sources
- Brooks
- Ceylon TCS, MIT
- Maja Mataric
- Nilsson book
- Jeremy Elson
- Norvigs 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
116Robbie CX 30
Team Members Dave Rudolph - Lead Web
Designer Lead Programmer Samara Secor -
Lead Analyst Documentation Specialist
117IPCHINOOKan 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