subsumption examples l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Subsumption examples PowerPoint Presentation
Download Presentation
Subsumption examples

Loading in 2 Seconds...

play fullscreen
1 / 117

Subsumption examples - PowerPoint PPT Presentation


  • 579 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Subsumption examples' - Lucy


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
subsumption examples
Subsumption examples

Let us analyze some subsumption robots and systems

squirt of brooks
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
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 levelwhich attempted to head towards a goal.
  • Used the same type of architecturefor both types of behaviors.

named after Allen Newell?

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

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

interraps program for soccer jung robocup 98
InteRRaps program for soccer (Jung, RoboCup 98)
  • Levelized architecture
    • level of movements
    • Level of local planning
    • Level of social planning
behavior architecture essex w
Behavior Architecture Essex W.

High-Level Behaviors (tactical)

Low-Level Behaviors (primitive)

External Threads

architecture fc portugal
Architecture FC Portugal

Advanced communication

tactical

situational

formational

soccer behavior modes 1
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
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 robot from Brooks Labs in MIT

(Herbert Simon?)

  • Used a laser scanner to find soda can-like objectsvisually,
    • 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
Herbert
  • 248-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.
slide17
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.

slide18
Description of Herbert in action:

When following a wall, Herbert spots a coke can.

The robot locates itself in front of the can.

The arm motion is then begun - when can is detected with sensors local to the arm, it is picked up.

Advantageous; naturally opportunistic.

If coke can put right in front of Herbert, can collect it and return to start, since no expectations about where coke cans will be found.

Can find coke cans in a variety of locations, even if never found there before.

But….

genghis
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
Walking robot - Genghis

Brook‘s Hexapod with whiskers

brooks robot example genghis
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
walking with six legs
Walking with six legs

Walk

Up leg

trigger

leg

down

beta position

S

equilibrium of the legs
Equilibrium of the legs

alpha

advance

alpha

balance

alpha position

S

Alpha balance tries to make

the sum of the alpha angles zero

walking
Walking

Up leg

trigger

Walk

leg

down

beta pos

S

alpha

advance

alpha

balance

alpha pos

S

walking in rough terrain
Walking in rough terrain

Up leg

trigger

Alpha

collision

Walk

leg

down

beta pos

S

alpha

advance

alpha

balance

alpha pos

S

from genghis to atilla
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.
atilla killer application
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.
slide29

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.

experiment
Experiment
  • Input Vector
    • Sonar Measure in 8 directions
    • Action
  • Action Strategy
    • Obstacle Avoiding
    • Wandering (or Wall following?)
objectives of student project
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
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
Subsumption Architecture of Kickbot

MotorR

FF/FB

Wander

FF/FB

MotorL

  • Wander with no obstacle detection

Forward/backward of motors

subsumption architecture of kickbot39
Subsumption Architecture of Kickbot
  • Wander with obstacle detection

MotorR

S

S

Wander

Switch Dir

MotorL

S

S

FB

Forw. IR

I

SB

SF

Back IR

I

FF

S nodes

I nodes

wandering behavior working
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
subsumption architecture
Subsumption Architecture

Subsumption Architecture of Kickbot

  • Wander and Tumble

MotorR

S

S

I

Wander

MotorL

S

S

I

Forw. IR

I

Back IR

I

Mercury

Tumble

subsumption architecture42
Subsumption Architecture

Subsumption Architecture of Kickbot

  • Wander, Tumble, and Antagonize

Camera

MovementDetector

Antagonize

MotorR

S

S

S

I

I

Wander

MotorL

S

S

S

I

I

Forw. IR

I

Back IR

I

Mercury

Tumble

mechanical aspects of kickbot
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
Mechanical Aspects

Mechanical Aspects of Kickbot

sensors in kickbot
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
sensors
Sensors

Sensors in Kickbot

electrical aspects of kickbot
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
autonomous robot teams in dynamic and uncertain environments
Autonomous Robot Teams in Dynamic and Uncertain Environments
  • Prof. Manuela Veloso, Dr. Tucker Balch, and Dr. Brett BrowningCarnegie Mellon University

Robot Soccer

slide50

1

2

Distributed Sensor

Fusion

Ashley Stroupe

Agents can maintain a larger and more accurate view of the environment using communication.

Two agents observe one object. Observations are uncertain due to sensor noise

Agents represent and communicate object locations as 2-D Gaussian probability distributions

Agents represent and communicate object locations as 2-D Gaussian probability distributions.

Two agents observe one object. Observations are uncertain due to sensor noise.

The observations are fused to provide a more accurate estimate of the 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
slide51

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
slide52

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
slide53

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
slide54

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

slide55

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.

slide56

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

slide58

Student Subsumption Project

Finite State Machines

Behavior Based Robotics

slide62

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.

slide63

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

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

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)

slide67

Maze Racer...

Finite State Machine

slide69

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

slide70

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

Maze Racer...

Subsumption Architecture

slide72

int map()

{

//multiple threads

openLeft();

openRight();

deadEnd();

arbitrate();

return;

}

int openLeft()

{

while(1)

{

if (opening on left)

{

Turn Left;

Store 0 in map;

}

}

return;

}

slide73

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;

}

slide74

Decisions So Far...

Platforms:

The Lego Mindstorms RCX

+ Simplistic

- Limited Sensors and Motors

Handy Board

+ More Sensors and Motors

- Difficult to Program

lego mindstorm rcx
LEGO Mindstorm RCX

3 Output or Motor Ports (A, B, C)

3 Input or Sensor Prots (1, 2, 3)

IR Transmitter/Reciever

slide76

The Handy Board is based on the 52-pin Motorola MC68HC11 processor

  • It includes
    • 32K of battery-backed static RAM,
    • four outputs for DC motors,
    • a connector system that allows active sensors to be individually plugged into the board,
    • an LCD screen,
    • and an integrated, rechargable battery pack.
  • This design is ideal for experimental robotics project, but the Handy Board can serve any number of embedded control applications.

The Handy Board

slide77

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.

movaid decentralized distributed architecture
MOVAID: Decentralized distributed architecture

Human Interface

Planning

Distribution Task

Central Planning System

Module(Reactive) 1

Module(Reactive) 2

Module(Reactive) N

………

system movaid mobile robot talks to fixed devices
System MOVAID: mobile robot talks to fixed devices

Appliances

Typical apartment

Appliance interfaces

kitchen

room

robot

docking

Interface workstation

system movaid mobile unit
System MOVAID: mobile unit

Head:

auto-localisation

+ vision system

Arm + Hand

Tray

Bumper

Mobile base

+ low level

controls

Docking system

hardware architecture of the mobile robot
Hardware Architecture of the mobile robot

A/D converter

Controller of

wheels (3 axes)

Controller

CPU

US

RACK 1

RS232

Radio

Frame

Link

Grabber

RACK 2

Arm controller (4 axis)

Arm controller (4 axis)

Arm controller (2 axis)

CPU

(4

cooperation for localization and movement
Cooperation for localization and movement

Click interface

vision

human interface

  • Supervision module:
  • 3D position localization (x,y,z)
  • movement planning (x,y,z,,,)

(u,v)

(x,y,z,,,)

advanced level
advanced level

Human Interface to MOVAID

l interfaccia utente di movaid
L’interfaccia utente di MOVAID

Human Interface to MOVAID

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
design by composition
Design by Composition

AUTO

MANUAL

bumper

sonar

joystick

wheels

  • An example system - robot
    • components:
      • bumper
      • sonar
      • joystick
      • wheels
outline
Outline
  • New ways to package
    • functionality
    • control & coordination
  • Software synthesis
    • control
    • communication
  • Selective focus co-simulation
    • functional
    • timed
observations on current components
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
ipc hinook s component packaging adaptable modal processes
IPCHINOOK’s Component Packaging:Adaptable modal processes

{}

{}

{}

{}

{}

{}

a

a

b

b

{}

b

{}

{}

{}

{}

c

{}

{}

d

a

{}

{}

{}

  • Data interface contains ports
  • Control interface contains modes

x

Change mode

-a

+b

y

z

control coordination protocol subsumption
Control & Coordination Protocol: subsumption

s

i

i

y

i

i

y

s

s

i

i

y

i

i

  • Must handle three cases:
    • subsume, yield, idle
    • hard-coded in each component

y

s

i

y

s

i

joystick

override

y

bumper

escape

s

s

i

sonar

avoid

s

y

wheels

s

i

sensors

actuators

decision

modules

decision

composition

control protocol packaging abstract control types acts
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
Integrating components with ACTs

subsume

ACT

i

y

s

i

y

s

adaptation

Mutual exclusion

Activate

modal

processes

bumper

sonar

wheels

joystick

component adaptation example
Component adaptation example

subsume

ACT

Subsumption adapter

idle

idle

subsume

yield

adaptation

modal

processes

F

I

B

B

B

W

T

bumper

sonar

wheels

joystick

Bumper process

component adaptation example100
Component adaptation example

subsume

yield

idle

subsume

W

I

B

B

W

+subsuming

Subsumption adapter

idle

subsume

yield

I

B

W

T

Bumper process

+B

+W

system synthesis interaction
System synthesis interaction

Designer:

IPChinook:

Map functionality to architecture

system synthesis interaction102
System synthesis interaction

Determine control communication

mode

manager

Designer:

IPChinook:

Map functionality to architecture

system synthesis interaction103
System synthesis interaction

Map communication

to architecture

Designer:

IPChinook:

Determine Control Communication

A

B

C

system synthesis interaction104
System synthesis interaction

Synthesize hop-processes

and rest of runtime support

Designer:

IPChinook:

Map communication

to architecture

B

A

C

inventory of runtime support
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
Co-simulation
  • Validate functionality
  • Validate timing aspects of behavior
  • Estimate utilization
  • Evaluate implementation decisions
  • Selective focus for efficiency
selective focus108
Selective Focus

+a -x

Tokens

Control Actions

Tokens

Control Actions

Packets

Full Words

Modal Process

Modal Process

Protocol stack

Protocol stack

interface

interface

+a -x

Packets

Full Words

ipc hinook design flow summary
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

systems designed with ipc hinook
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
conclusion
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
Ongoing & Future work
  • High level debugging leveraging modal process abstractions
  • Formal verification of control structures
  • Extension to networked systems
  • Commercialization viaConsystant Design Technologies
literature
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
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
slide116

Robbie CX 30

Team Members:

Dave Rudolph - Lead Web Designer

Lead Programmer

Samara Secor - Lead Analyst

Documentation Specialist

ipc hinook an integrated ip based design framework for distributed embedded systems

IPCHINOOKan integrated IP-based design framework for distributed embedded systems

Pai Chou, Ken Hines, Ross Ortega,

Kurt Partridge, Gaetano Borriello

University of Washington

36th DAC - 22 June 1999