Subsumption examples Let us analyze some subsumption robots

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

Allen • In addition to sonars, odometry • Offboard Lisp machine for control by cable – 1 st layer: avoid obstacles – 2 nd layer: random wandering – 3 rd 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

Inte. RRaps program for soccer (Jung, Robo. Cup 98) • Levelized architecture – level of movements – Level of local planning – Level of social planning

Architecture Essex. Wizards 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: 3 D 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 behaviourgenerating modules. Modules include obstacle avoidance, wall following, and recognition of coke cans. Control of modules: Only suppression and inhibition between alternative modules - no other internal communication. Each module connected to sensors and to arbitration network which decides which competing action to take.

Description of Herbert in action: When following a wall, Herbert spots a coke can. The robot locates itself in front of the can. The arm motion is then begun - when can is detected with sensors local to the arm, it is picked up. Advantages; naturally opportunistic. If coke can put right in front of Herbert, can collect it and return to start, since no expectations about where coke cans will be found. Can find coke cans in a variety of locations, even if never found there before. But….

Genghis 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 • Level 1: standup – 2 modules per leg; – control alpha (advance) & beta (balance) motor • Level 2: simple walk – does not compenstate for rough terrain • Level 3: force balancing – Compensates for rough terrain • • Level 4: leg lifting Level 5: whiskers Level 6: pitch stabilization Level 7: 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 1 Kg 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 – Wandering (or Wall following? )

Sensor data - SOM

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 Motor. R FF/FB Wander FF/FB Motor. L Forward/backward of motors

Subsumption Architecture of Kickbot • Wander with obstacle detection S Switch Dir Back IR Motor. R Wander S Forw. IR S S Motor. L FB I SB SF I FF S nodes I nodes

Wandering. Architecture 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 of Kickbot • Wander and Tumble S S I Motor. R I Motor. L Wander S Forw. IR I Back IR Mercury I Tumble S

Subsumption Architecture of Kickbot • Wander, Tumble, and Antagonize Camera Movement Detector Antagonize S S S I I Motor. R I I Motor. L 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 Aspects of Kickbot

Sensors in Kickbot • Two Sharp GP 2 D 12 infrared sensors – Provides distance as an analog voltage up to 80 cm – 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 M 64283 FP) – Provides image as 128 x 128 analog pixel values – Can do edge detection in on-camera hardware – Used to detect interesting movement

Sensors in Kickbot

Electrical Aspects of Kickbot • Control board – PIC 16 F 877, display LEDs, dip switches, power regulator – Monitors IR sensors and mercury switches – Sends PWM to H-bridges for motor control • H-Bridges – National Semiconductor LMD 18201 T – Converts PWM input to 12 V to vary motor speed • Camera board – PIC 16 F 877, 32 KB SRAM, random TTL logic – Captures camera image and advises control board – Includes RS 232 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

or s Sen d te u b i tr usion Dis F 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. 1 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. 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 Robo. Cup 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

rob k c Pa CM team dog ot 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

ual d i v di Robust individual behaviors for an adversarial, partially observable environment. st In s u b Ro avior Beh 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 Team. Bots using Motor Schemas

a ads e h er mm UH CM CMU Hammerheads Mid-size robot soccer team provides a testing ground for the MARS software • Team consists of three field robots and one goalie • Sensor fusion used for cooperative localization of field objects CMU Hammerheads strategy uses fixed role assignment and combinations of robust individual behaviors • Multi-fidelity behaviors for efficient motion depending on available sensor and localization accuracy

e ativ v o Inn w Ne forms t Pla Our new hardware platforms designed for robot soccer small and mid size leagues Diff. Bot 1. 0: Compact high-speed design. Includes custom DSP board and RF link DVTBOt 1. d. Includes DSP board and RF link Cve. Bot 2. D. Increased reliability. Uses single laptop, and USB camera Cye. Bot 2. 0: New compact design for increased reliability. New design uses single laptop, the Cye robot and a USB camera. Holonomic design enables full range of motions. Includes custom DSP board and RF link • 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

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 open. Left(); open. Right(); dead. End(); arbitrate(); return; } int open. Left() { while(1) { if (opening on left) { Turn Left; Store 0 in map; } } return; }

int open. Right() { while(1) { if (open on right) { store 0 in map; } } return; } int dead. End() { while(1) { if (dead. End) { 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 52 -pin Motorola MC 68 HC 11 processor, and includes 32 K of battery-backed static RAM, four outputs for DC motors, a connector system that allows active sensors to be individually plugged into the board, an LCD screen, and an integrated, rechargable battery pack. This design is ideal for experimental robotics project, but the Handy Board can serve any number of embedded control applications.

Advantages: Nearly C++ functionality Simplistic Open Source Kernel Easy to learn (adaptable to our needs) 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 kitchen Appliance interfaces 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 RS 232 Radio Link Frame Grabber RACK 2 CPU Arm controller (4 axis) Arm controller (4 (4 axis) Arm controller (2 axis)

Hardware of fixed station

Software architecture of fixed station

Cooperation for localization and movement Click interface vision (u, v) human interface Supervision module: • 3 D position localization (x, y, z) • movement planning (x, y, z, , , )

Human Interface to MOVAID

Human Interface to MOVAID Beginner’s level Beginner level

Human Interface to MOVAID advanced level

L’interfaccia utentetodi. MOVAID Human Interface

System P 3: 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 sonar joystick 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 Change mode -a +b x { } y z b c { } d { } { } { } a b

Control & Coordination Protocol: subsumption • Must handle three cases: y – subsume, yield, idle – hard-coded in each component joystick override bumper escape sonar avoid s y i s y s s s i y wheels sensors actuators i 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 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 subsume idle I +B 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 Protocol stack 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 • Wubble. U 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 36 th DAC - 22 June 1999