Subsumption examples

1
Subsumption examples

• Let us analyze some subsumption robots and systems

2
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.

3
Allen 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.

7
Examples of Different Behavior Levels for Robot
Soccer
8
InteRRaps program for soccer (Jung, RoboCup 98)

• Levelized architecture
• level of movements
• Level of local planning
• Level of social planning

9
Architecture EssexWizards for soccer
simulation
10
Behavior Architecture Essex W.
High-Level Behaviors (tactical)
Low-Level Behaviors (primitive)
External Threads
11
Architecture FC Portugal
Advanced communication
tactical
situational
formational
12
High Level Decisions in FCP
13
Soccer 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.

14
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.

15
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.

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.
• 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.

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.

21
Walking robot - Genghis
Brooks Hexapod with whiskers
22
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

23
Walking with six legs
Walk
Up leg trigger
leg down
beta position
S
24
Equilibrium of the legs
alpha advance
alpha balance
alpha position
S
Alpha balance tries to make the sum of the alpha
angles zero
25
Walking
Up leg trigger
Walk
leg down
beta pos
S
alpha advance
alpha balance
alpha pos
S
26
Walking in rough terrain
Up leg trigger
Alpha collision
Walk
leg down
beta pos
S
alpha advance
alpha balance
alpha pos
S
27
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.

28
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.

29
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.
30
(No Transcript)
31
Subsumption Architecture and Map building using
Self-Organizing Networks
32
Experiment

• Input Vector
• Sonar Measure in 8 directions
• Action
• Action Strategy
• Obstacle Avoiding
• Wandering (or Wall following?)

33
Sensor data - SOM
34
(No Transcript)
35
Student project on subsumption

• Kickbot

36
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

37
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

38
Subsumption Architecture of Kickbot

• Wander with no obstacle detection

Forward/backward of motors
39
Subsumption 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
40
Wandering 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

41
Subsumption Architecture
Subsumption Architecture of Kickbot

• Wander and Tumble

MotorR
I
S
S
Wander
MotorL
I
S
S
Forw. IR
I
Back IR
I
Mercury
Tumble
42
Subsumption 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
43
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 130 gear ratio

44
Mechanical Aspects
Mechanical Aspects of Kickbot
45
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

46
Sensors
Sensors in Kickbot
47
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

48
Electrical Aspects
49
Autonomous Robot Teams in Dynamic and Uncertain
Environments

• Prof. Manuela Veloso, Dr. Tucker Balch, and Dr.
  Brett BrowningCarnegie Mellon University

Robot Soccer
50
Distributed 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

51
The 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

52
CMPack 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

53
Robust 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

54
CMU 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
55
Our 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.
56
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
57
Evolve mind together with body
58
Student Subsumption Project
Finite State Machines
Behavior Based Robotics
59
Robot
60
Finite State Machine
61
Subsumption Architecture
62
Maze 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.
63
The 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.

64
Limitations...

• 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)
66
Intelligent 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)
67
Maze Racer...
Finite State Machine
68
Spectrum of Robot Control
69
Activity 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
70
Recall
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).

71
Maze Racer...
Subsumption Architecture
72
int map() //multiple threads openLeft() ope
nRight() deadEnd() arbitrate() return
int openLeft() while(1) if
(opening on left) Turn Left Store
0 in map return
73
Pseudo-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
74
Decisions So Far...
Platforms The Lego Mindstorms RCX
Simplistic - Limited Sensors and Motors Handy
Board More Sensors and Motors - Difficult
to Program
75
LEGO Mindstorm RCX
3 Output or Motor Ports (A, B, C) 3 Input or
Sensor Prots (1, 2, 3) IR Transmitter/Reciever
76

• The Handy Board is based on the 52-pin Motorola
  MC68HC11 processor
• It 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.

The Handy Board
77
LegOS 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.
78
MOVAID Decentralized distributed architecture
Human Interface Planning Distribution Task
Central Planning System
Module(Reactive) 1
Module(Reactive) 2
Module(Reactive) N

79
System MOVAID mobile assistive robot
80
System MOVAID mobile robot talks to fixed devices
Appliances
Appliance interfaces
Typical apartment
kitchen
room
robot
docking
Interface workstation
81
System MOVAID mobile unit
Head auto-localisation vision system
Arm Hand Tray Bumper
Mobile base low level controls
Docking system
82
Hardware 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

83
Hardware of fixed station
84
Software architecture of fixed station
85
Cooperation 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,?,?,?)
86
Human Interface to MOVAID
87
Beginners level
Human Interface to MOVAID
Beginner level
88
advanced level
Human Interface to MOVAID
89
Linterfaccia utente di MOVAID
Human Interface to MOVAID
90
System 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

92
Design by Composition

• An example system - robot
• components
• bumper
• sonar
• joystick
• wheels

93
Outline

• New ways to package
• functionality
• control coordination
• Software synthesis
• control
• communication
• Selective focus co-simulation
• functional
• timed

94
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

95
IPCHINOOKs Component PackagingAdaptable modal
processes

• Data interface contains ports
• Control interface contains modes

x
Change mode -a b
y
z
96
Control 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
97
Control 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

98
Integrating components with ACTs
99
Component adaptation example
100
Component adaptation example
subsuming
Subsumption adapter
subsume
yield
idle
W
B
T
I
Bumper process
B
W
101
System synthesis interaction
Designer
IPChinook
Map functionality to architecture
102
System synthesis interaction
Designer
IPChinook
Map functionality to architecture
103
System synthesis interaction
Designer
IPChinook
Determine Control Communication
A
B
C
104
System synthesis interaction
Designer
IPChinook
Map communication to architecture
B
A
C
105
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

106
Co-simulation

• Validate functionality
• Validate timing aspects of behavior
• Estimate utilization
• Evaluate implementation decisions
• Selective focus for efficiency

107
Selective Focus
108
Selective Focus
Modal Process
Modal Process
Protocol stack
Protocol stack
interface
interface
a -x
Packets
Full Words
109
IPCHINOOK 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
110
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

111
IDE Screenshot
112
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

113
Ongoing Future work

• High level debugging leveraging modal process
  abstractions
• Formal verification of control structures
• Extension to networked systems
• Commercialization viaConsystant Design
  Technologies

114
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
115
Sources

• 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

116
Robbie CX 30
Team Members Dave Rudolph - Lead Web
Designer Lead Programmer Samara Secor -
Lead Analyst Documentation Specialist
117
IPCHINOOKan 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