1. Let us analyze some subsumption robots and systems
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 First Subsumptive Robot
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
Early robot.
Uses an offboard Lisp machine running the subsumption architecture, written in a precursor to the Behaviour Language.
First layer
Avoid static and dynamic obstacles.
Robot sits in middle of room but scurries away when approached.
Sonar sensor returns represent a repulsive force with inverse square dropoff in strength (like gravity).
Repulsive forces from all sensors are used to determine heading.
Additional reflex halts robot when something in front of it.
Second layer
Every 10 seconds (AFSM: timer), a random heading is generated.
If halted, this would help robot move away from obstacle.
Heading combined with layer 1 heading.
Third layer
Sonar is used to look for distant places and generate a new heading.
Again, heading is combined with layer 1’s.
Monitors progress in world via odometry.
[Brooks and Flynn 89]

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
Architecture FC Portugal

12. High Level Decisions in FCP

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

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.
Wanders offices following walls, avoiding obstacles, and collecting empty drink (soda) cans.
Subsumption architecture run by 24 loosely coupled 8-bit processors.
Has 30 IR proximity sensors for avoiding obstacles.
Has a grasping hand with a break sensor (IR).
Has a laser light striping system which produces one 256x32 pixel image per second out to 12 feet covering a 60 degree field.
4 processors expend ~30 instructions per pixel permitting high-performance vision algorithms.
A table-like object finder drives robot closer to tables where a drink-can-like object finder is more likely to trigger.
Once the latter triggers, the robot centers on the detected object - without communication with other layers
The arm controller notices robot is halted, so moves arm forward to line up the grasper on either side of can.
The arm and hand don’t communicate
The grasp reflex activates when the IR beam is broken. Makes it possible for a human to pass a can to the robot for collection.
[Brooks and Flynn 89]

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

20. 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.
Genghis walks over varied terrain.
Each leg “knows” what to do
If I’m a leg and I’m up, swing forward.
This causes other grounded legs to move back a little and the body to move forward.
If I’m a leg and I’m forward, put myself down.
The leg lifting sequence is the only part of the robot which is centrally controlled.
Additional layers suppress lower ones
e.g. If Genghis is climbing and one leg detects a high force before reaching the “down” position, that position is adjusted by suppressing the actuator command in the lowest layer.
The highest layer suppresses walking until a person is in the robot’s field, using pryoelectric sensors. Then “attacks”.
Some of the behaviours which correspond to layers are: Stand Up, Simple Walk, Force Balancing, Leg Lifting, Whiskers, Pitch Stabilising, Prowling.
57 FSMs, 48 of which are 6 copies of an 8-FSM control system for each leg.
The success of Genghis prompted the creation of Attila
Stronger and faster; can stand up from any position by leg rotation.
Periodic recharging of batteries required via solar cell.
[Brooks and Flynn 89], [Angle and Brooks 90]

21. Walking robot - Genghis
Brook‘s 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 Walk S S Up leg trigger leg beta pos down 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.
Brooks suggests the use of Attila (and other robots) as planetary rovers.
Small rovers provide immediate economic advantage in payload costs.
Redundancy reduces the need for 100% reliability, also reducing cost.
Legs can provide support for much richer sensation than wheels due to volume covered by sweep and step.
There’s little need for long term state, so
Frequent reboots are possible to limit effects of radiation.
Also means cheaper components can be used.
[Brooks and Flynn 89], [Angle and Brooks 90]
In line with NASA’s cheaper-faster-better strategy of recent years.

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.

31. Subsumption Architecture and Map building using Self-Organizing Networks

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

33. Sensor data - SOM

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 Tumble Antagonize
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
Wander
MotorR
MotorL
FF/FB
Forward/backward of motors

39. Subsumption Architecture of Kickbot
Wander with obstacle detection S S
MotorR
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 S S I
MotorR
Wander
MotorL S S I
Forw. IR I
Back IR I
Mercury
Tumble

42. Subsumption Architecture
Subsumption Architecture of Kickbot
Wander, Tumble, and Antagonize
Camera
MovementDetector
Antagonize S S S I I
MotorR
Wander
MotorL S S S I 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 1:30 gear ratio

44. 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 Browning Carnegie 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
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. 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.
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 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

54. Team consists of three field robots and one goalie
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. New robot hardware for mid and small size robot soccer
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
DVTBOt 1.d. Includes DSP board and RF link
DiffBot 1.0: Compact high-speed design. Includes custom 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 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.

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.

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. Subsumption Architecture
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();
openRight();
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
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.

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
Typical apartment
Appliance interfaces
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
Controller of
wheels (3 axes)
A/D converter
CPU
Controller 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
(u,v)
Supervision module:
3D position localization (x,y,z)
movement planning (x,y,z,,,)
(x,y,z,,,)

86. Human Interface to MOVAID

87. Human Interface to MOVAID
Beginner’s level
Beginner level

88. Human Interface to MOVAID
advanced level

89. L’interfaccia utente di MOVAID
Human Interface to MOVAID
L’interfaccia utente di MOVAID

90. System P3: distributed system

91. Embedded Systems Domains IP components Properties telecommunications
consumer electronics
automotive electronics
IP components
protocol stacks
common algorithms
devices w/ drivers
We’ve been looking at better ways to design systems that fall into some very broad domains and have these properties. With various types of intellectual property.We are interested in sytsems that fall in tese domains, use IP of this sort and have these properties.
There are several domains to which our technology can be applied --- in telecomunications it can be applied to the design of switching centers and infrastructure components, base stations and cellular phones. For consumer electronics it can be applied to PDAs, and so forth, smart appliences. In the automotive field IPChinook can be applied to smart cars, advanced antilock brake systems, online navigation systems.
The types of IP we consider includes protocol stacks such as IrDA, TCP/IP, common algorithms such as Compression/decompression, Cellular power management etcetera and for devices we consider actuators, sensors, protocol hardware, chips and standard cells that perform certain functionality.
And we are concerned
We’re looking at system design at a higher
An example system that we commonly use is an autonomous robot
Properties
family/evolution of systems
heterogeneous architectures
non-trivial control

92. Design by Composition An example system - robot components: bumper
sonar
joystick
wheels
AUTO
MANUAL
joystick
bumper
sonar
wheels
This robot solves a maze by following the wall to the left of it until it finds its way out.
The crucial idea here is that we want to design this through composition. This constructs a system from modular components, so it is an ideal way to introduce intellectual property into it. Some examples of components are:
and any one of these can be IP. So --- now that I’ve introduced the example, let me tell you what we’re going to do with it.

93. Outline New ways to package Software synthesis
functionality
control & coordination
Software synthesis
control
communication
Selective focus co-simulation
functional
timed
First, I’m going to describe new ways of packaging functionality and control,
Then I’ll describe the software synthesis performed by the IPChinook tools---specifically control and communication software. Finally, I will describe how simulation is employed in this, and some novel features of the co-simulator.
The way functionality is packaged is through components

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
Traditionally components have some nice features, such as a separation between the compoenent’s functionality and the way it communicates with other compoennts in the system --- however, this is through a data and event based interface, and this in itself is already limiting, since it leaves out control
Control is a global concept that doesn’t apply directly to any particular component, but it is a singificant aspect in the design of systems. Current approaches tend to hardwire aspects of this control into components, making it difficult to change---and such changes often require intrusive modification of many compoentns. This breaks modularity.

95. IPCHINOOK’s Component Packaging: Adaptable modal processes
Data interface contains ports
Control interface contains modes a b
{ } a b a b c d
{ }
We feel we have a better way of packaging functionality --- through something we call “modal processses”. A modal process has several parts---handlesr, ports and modes. The communication occurs through tokens on the data ports, the handlers are small pieces of code that execute when data tokens arrive, and they can generate data tokens on their output during execution. Handlers are guarded by modes. Lets step through the operation of this: 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 s i s i i y y i s i
joystick
override y s y
bumper
escape s
To better explain what we mean by common control patterns, consider this example common in simple autonomous robots, called “subsumption”.
The way this works is s i s i
sonar
avoid s y i y
wheels s i
sensors
actuators
decision
modules
decision
composition

97. 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
Since control is a global concept, it makes no sense to embed it into components. We’ve found that, nevertheless, the control for components follows certain common patterns. To encapsulate these patterns we introduce a concept called abstract control types. These are basically control structures that can be used in a variety of ways:

98. Integrating components with ACTs
subsume
modal
processes
joystick
bumper
sonar
wheels i s y
Mutual exclusion
Activate
adaptation
So: In ipchinook, the control protocol is packaged into an ACT--- here we show a subsumption act --- and the components are packaged into adaptable modal processes with control interfaces --- but the pieces don’t match.
Here we use ACTs to perform adaptation, to perform the matching.

99. Component adaptation exampleB F
idle I W T
subsume
yield
Bumper process
Subsumption adapter
modal
processes
ACT
adaptation
joystick
bumper
sonar
wheels
subsume

100. Component adaptation example
+subsuming
Subsumption adapter B I
subsume
idle
idle
yield
subsume W
subsume
yield I W B B W T
Bumper process +B +W

101. System synthesis interaction
Designer:
IPChinook:
Map functionality to architecture

102. System synthesis interaction
Designer:
IPChinook:
mode
manager
Determine control communication
Map functionality to architecture

103. System synthesis interaction
Designer:
IPChinook:
Map communication
to architecture
Determine Control Communication A B C

104. System synthesis interaction
Designer:
IPChinook:
Synthesize hop-processes
and rest of runtime support
Map communication
to architecture A B 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 Tokens Control Actions
+a -x
Protocol stack
Protocol stack
Packets
interface
interface
Full Words
+a -x
Tokens
Control Actions
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 via Consystant 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 Cecilia Laschi 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

116. Robbie CX 30 Team Members: Dave Rudolph - Lead Web Designer
Lead Programmer
Samara Secor - Lead Analyst
Documentation Specialist

117. 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
Good Morning! I’ve been chosen by the rest of the authors to give you this talk on some interesting research we are doing at the University of Washington, and to give you some intuition as to how this applies to IP based design.
Unfortunately, I only have time to give you a whirlwind tour of some of the more relevant aspects.