Presentation is loading. Please wait.

Presentation is loading. Please wait.

Subsumption examples Let us analyze some subsumption robots and systems.

Similar presentations

Presentation on theme: "Subsumption examples Let us analyze some subsumption robots and systems."— Presentation transcript:

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 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. named after Allen Newell?

4 Allen 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 tactical situational formational Advanced communication

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 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 Simon?)

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


20 Genghis 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. Brooks Walking robot - Genghis

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 Walk Up leg trigger leg down beta pos S alpha advance alpha balance alpha pos S

26 Walking in rough terrain Walk Up leg trigger leg down beta pos S alpha advance alpha balance alpha pos S Alpha collision

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.


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


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

39 Subsumption Architecture of Kickbot Wander with obstacle detection Wander MotorR MotorL S S S S Forw. IR Back IR I I FB SB SF FF Switch Dir S nodes I nodes

40 Wandering behavior working –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

41 Subsumption Architecture Wander and Tumble Wander MotorR MotorL IS IS S S Forw. IR Back IR MercuryTumble I I Subsumption Architecture of Kickbot

42 Subsumption Architecture Wander, Tumble, and Antagonize Wander MotorR MotorL ISS SIS S S Forw. IR Back IR MercuryTumble Camera Movement Detector Antagonize I I I I Subsumption Architecture of Kickbot

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 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 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. 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 Agents represent and communicate object locations as 2-D Gaussian probability distributions. Ashley Stroupe 1 2 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 Two agents observe one object. Observations are uncertain due to sensor noise Agents represent and communicate object locations as 2-D Gaussian probability distributions

51 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 The mid-size team, CMU Hammerheads, blue collars Sony dogs, CMPack also competed

52 CMPack robot dog team CMPack robot soccer team attacks the difficult perceptual and kinematics problems of legged motion in robot soccer 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 CMPark use multi-fidelity behaviors to achieve real- time intelligent motion

53 Robust Individual Behaviors Robust individual behaviors for an adversarial, partially observable environment. 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 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

54 CMU Hammerheads CMU Hammerheads Mid-size robot soccer team provides a testing ground for the MARS software CMU Hammerheads strategy uses fixed role assignment and combinations of robust individual behaviors 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

55 New Innovative Platforms 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 Our new hardware platforms designed for robot soccer small and mid size leagues DiffBot 1.0: Compact high-speed design. Includes custom DSP board and RF link CyeBot 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 DVTBOt 1.d. Includes DSP board and RF link CveBot 2.D. Increased reliability.Uses single laptop, and USB camera

56 Development Life Cycle Evolutionary Model Benefits: Downfalls: Lends itself to testing and improvement in several betas 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 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 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 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 PAGE descriptions – List the agent type, its percepts, actions, goals, and environment. Agent TypePerceptsActionsGoalsEnvironment 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 Finite State Machine


69 Assess Environment Partition into Situations Create Situational Responses Import Behaviors to Robot Run Robotic Experiments Evaluate Results Enahance, Expand, Correct Behavioral Responses Done

70 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). Recall

71 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 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 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 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 Module (Reactive) 1 Module (Reactive) 2 Module (Reactive) N ……… Central Planning System

79 System MOVAID: mobile assistive robot

80 System MOVAID: mobile robot talks to fixed devices robot Interface workstation Appliances Appliance interfaces Typical apartment room kitchen docking

81 System MOVAID: mobile unit Head: auto-localisation + vision system Arm + Hand Tray Bumper Mobile base + low level controls Docking system

82 RS232 RACK 1 RACK 2 Radio Link Frame Grabber CPU Controller US Controller of wheels (3 axes) CPU (4 Hardware Architecture of the mobile robot Arm controller (4 axis) Arm controller (2 axis) A/D converter

83 Hardware of fixed station

84 Software architecture of fixed station

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

86 Human Interface to MOVAID

87 Beginner level Beginners 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 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 AUTO MANUAL sonar bumper wheels joystick

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 IPC HINOOK s Component Packaging: Adaptable modal processes Data interface contains ports Control interface contains modes {}{} {}{} {}{} {}{} {}{} abcd {}{} {}{} {}{} {}{} {}{} {}{} {}{} {}{} {}{} {}{} ab {}{} Change mode -a +b ab x y z

96 Control & Coordination Protocol: subsumption Must handle three cases: –subsume, yield, idle –hard-coded in each component joystick bumper sonar wheels escape avoid override s s sensors actuators decision modules decision composition is y is y s y is y i i i i i sisiy i y s y i

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

98 i s y i s y Mutual exclusionActivate Integrating components with ACTs ACT subsume modal processes joystick bumpersonarwheelsadaptation

99 modal processes ACT adaptation joystick bumpersonarwheels subsume Component adaptation example BF idle BI BWT subsumeyield Bumper process Subsumption adapter

100 Component adaptation example subsume WBTI yieldidle +B BI subsumeidleWB +subsuming yieldsubsume W Bumper process Subsumption adapter +W

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

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

103 Map communication to architecture System synthesis interaction Designer:IPChinook: Determine Control Communication ABC

104 System synthesis interaction Designer:IPChinook: Map communication to architecture Synthesize hop-processes and rest of runtime support 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 Modal Process interface Modal Process interface Protocol stack Full Words Packets TokensControl Actions +a -x Full Words Packets TokensControl Actions +a -x

109 IPC HINOOK design flow summary Functionality mapping Communication mapping IP Component selection Custom component authoring System Composition Control synthesis Communication & Runtime synthesis High-level simulation Co-simulation Designer & IDE Synthesis

110 Systems designed with IPC HINOOK 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 IPC HINOOK 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 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 Team Members: Dave Rudolph - Lead Web Designer Lead Programmer Samara Secor - Lead Analyst Documentation Specialist

117 IPC HINOOK 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

Download ppt "Subsumption examples Let us analyze some subsumption robots and systems."

Similar presentations

Ads by Google