Presentation is loading. Please wait.

Presentation is loading. Please wait.

Let us analyze some subsumption robots and systems

Similar presentations

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

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

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

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

Download ppt "Let us analyze some subsumption robots and systems"

Similar presentations

Ads by Google