subsumption examples let us analyze some subsumption robots and systems

Subsumption examplesSubsumption examples

Let us analyze Let us analyze some subsumption some subsumption robots and robots and systemssystems

Squirt of BrooksSquirt 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 BrooksAllen 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?

AllenAllen

• 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

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 Examples of Different Behavior Levels for Behavior Levels for Robot Robot

SoccerSoccer

InteRRaps program for soccer InteRRaps program for soccer (Jung, RoboCup 98)(Jung, RoboCup 98)

• Levelized architecture– level of movements– Level of local planning– Level of social planning

Architecture EssexWizards for Architecture EssexWizards for soccersoccer

simulation

Behavior Architecture Essex W.Behavior Architecture Essex W.

High-Level Behaviors (tactical)

Low-Level Behaviors (primitive)

External Threads

Architecture Architecture FC PortugalFC Portugal

tactical situational

formational

Advanced communication

High High Level Level

Decisions Decisions in FCPin FCP

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 Herbert robot from Brooks Labs in MITLabs 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?)

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

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.

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 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 - GenghisBrooks‘ Walking robot - Genghis

Walking robot - GenghisWalking robot - Genghis

Brook‘s Hexapod with whiskers

Brooks Robot Example: GenghisBrooks 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 legsWalking with six legs

Walk Up legtrigger

leg down

beta positionS

Equilibrium of the legsEquilibrium of the legs

alphaadvance

alpha balance

alpha positionS

Alpha balance tries to makethe sum of the alpha angles zero

WalkingWalking

WalkUp legtrigger

leg down

beta posS

alphaadvance

alpha balance

alpha posS

Walking in rough terrainWalking in rough terrain

WalkUp legtrigger

leg down

beta posS

alphaadvance

alpha balance

alpha posS

Alphacollision

From Genghis to AtillaFrom 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.

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 Subsumption Architecture and Architecture and

Map building using Map building using SSelf-elf-OOrganizing rganizing

NNetworksetworks

ExperimentExperiment• Input Vector

– Sonar Measure in 8 directions– Action

• Action Strategy– Obstacle Avoiding

– Wandering (or Wall following?)

))4

sin(),4

cos((7

02

7

02

id

ci

d

cv

ii

Sensor data - SOMSensor data - SOM

Map: SOM 21-Jun-1999, Data: D, Size: 10 1030 40 50 60 70 80

35

40

45

50

55

60

65

70

Student project on subsumptionStudent project on subsumption

KickbotKickbot

Objectives of student projectObjectives 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 KickbotSubsumption Architecture of Kickbot

• Wander with no obstacle detection

Wander

MotorR

MotorL

FF/FB

FF/FB

Forward/backward of motors

Subsumption Architecture of KickbotSubsumption 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

Wandering behavior workingWandering 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 KickbotSubsumption Architecture of Kickbot

Subsumption ArchitectureSubsumption Architecture

• Wander and Tumble

Wander

MotorR

MotorL

IS

IS

S

S

Forw. IR

Back IR

Mercury Tumble

I

I

Subsumption Architecture of KickbotSubsumption Architecture of Kickbot

Subsumption ArchitectureSubsumption Architecture

• Wander, Tumble, and Antagonize

Wander

MotorR

MotorL

ISS

S IS

S

S

Forw. IR

Back IR

Mercury Tumble

CameraMovementDetector Antagonize

I

I

I

I

Subsumption Architecture of KickbotSubsumption Architecture of Kickbot

Mechanical Aspects of KickbotMechanical 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 AspectsMechanical AspectsMechanical Aspects of KickbotMechanical Aspects of Kickbot

Sensors in KickbotSensors 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

SensorsSensorsSensors in KickbotSensors in Kickbot

Electrical Aspects of KickbotElectrical 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

Electrical AspectsElectrical Aspects

Autonomous Robot Teams Autonomous Robot Teams in Dynamic and Uncertain in Dynamic and Uncertain

EnvironmentsEnvironments

• Prof. Manuela Veloso, Dr. Tucker Balch, and Dr. Brett BrowningCarnegie Mellon University

Robot Soccer

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 object’s location.

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

•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

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

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 robot’s objectives

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

New Innovativ

e

Platform

s

•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

Development Life Development Life CycleCycle

Evolutionary Model

Benefits:

Downfalls:

Lends itself to testing and improvement in several betas

Difficult to apply to a timeline due to iterations

Evolve mind together with bodyEvolve mind together with body

Student Subsumption ProjectStudent Subsumption ProjectFinite 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 Percepts Actions Goals Environment

Maze Racer Differences inlight, touch,

rotation clicks

Turn right orleft, drivestraight,

internal u-turn,mapping of

maze, followingOf map

Get throughmaze, be thefastest, map

maze &successfullyfollow map

Mazecontainingdirectionalchoices of

2 (no more, noless)

Finite State Machine

Assess Environment

Partition into Situations

Create Situational Responses

Import Behaviors to Robot

Run Robotic Experiments

Evaluate Results

Enahance, Expand, Correct Behavioral Responses

Done

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

Subsumption Architecture

int map() {

//multiple threadsopenLeft();openRight();deadEnd();arbitrate();return;

}

int openLeft() { while(1) {

if (opening on left){ Turn Left; Store 0 in map;}

} return;}

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;}

Platforms:

The Lego Mindstorms RCX

+ Simplistic

- Limited Sensors and Motors

Handy Board

+ More Sensors and Motors

- Difficult to Program

LEGO LEGO MindstormMindstorm RCX RCX

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

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

IR Transmitter/Reciever

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.

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 MOVAID: Decentralized distributed architecturedistributed architecture

Human Interface

Planning

Distribution Task

Module(Reactive)

1

Module(Reactive)

2

Module(Reactive)

N

………

Central Planning System

System MOVAID: mobile assistive robotSystem MOVAID: mobile assistive robot

System MOVAID: mobile robot talks to System MOVAID: mobile robot talks to fixed devicesfixed devices

robot

Interface workstation

Appliances

Appliance interfaces

Typical apartment

room kitchen

docking

System MOVAID: mobile unitSystem MOVAID: mobile unit

Head:auto-localisation+ vision system

Arm + Hand

Tray

Bumper

Mobile base+ low level

controls

Docking system

RS232

RACK 1

RACK 2

Radio Link

Frame Grabber

CPU

Controller

US

Controller of wheels (3 axes)

CPU

(4

Hardware Architecture of the mobile Hardware Architecture of the mobile robotrobot

Arm controller (4 axis)

Arm controller (4 axis)

Arm controller (2 axis)

A/D converter

ETHERNET

Docking System

User interface

Power Supply

CPU (Supervisor)

Wireless link module

Hardware Hardware of fixed stationof fixed station

Software Software architecture architecture

of fixed of fixed stationstation

Cooperation for localization and Cooperation for localization and movementmovement

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

human interface

(u,v)

visionClick

interface

(x,y,z,,,)

Human Interface to MOVAIDHuman Interface to MOVAID

Human Interface to MOVAIDHuman Interface to MOVAIDBeginner levelBeginner’s levelBeginner’s level

advanced leveladvanced levelHuman Interface to MOVAIDHuman Interface to MOVAID

L’interfaccia utente di MOVAIDL’interfaccia utente di MOVAIDHuman Interface to MOVAIDHuman Interface to MOVAID

System P3: distributed system System P3: distributed system

Embedded SystemsEmbedded 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 CompositionDesign by Composition

• An example system - robot– components:

• bumper

• sonar

• joystick

• wheels

AUTOMANUAL

sonar

bumper

wheelsjoystick

OutlineOutline

• New ways to package– functionality– control & coordination

• Software synthesis– control – communication

• Selective focus co-simulation– functional– timed

Observations on Current Observations on Current ComponentsComponents

• 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

IPCIPCHINOOK’HINOOK’s Component Packaging:s Component Packaging:Adaptable modal processesAdaptable modal processes

• Data interface contains ports

• Control interface contains modes

{}

{}

{}

{}

{}

a b c d

{}

{}

{}{}

{}{}

{}

{}

{}

{}

a b

{}

Change mode-a+b

a b

x

y

z

Control & Coordination Protocol: Control & Coordination Protocol:

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

joystick

bumper

sonar

wheels

escape

avoid

override

s

s

sensorsactuators

decisionmodules

decisioncomposition

isy

isy

sy

isy

i

i

i

i

i

s i

s i

yi

ys

yi

Control Protocol Packaging:Control Protocol Packaging:Abstract control types (ACTs)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

i s y i s y

Mutual exclusion Activate

Integrating components with ACTsIntegrating components with ACTs

ACT

subsume

modalprocesses

joystick bumper sonar wheels

adaptation

modalprocesses

ACT

adaptation

joystick bumper sonar wheels

subsume

Component adaptation exampleComponent adaptation example

BF

idle

BI

idle

B W T

subsume yield

Bumper process

Subsumption adapter

Component adaptation exampleComponent adaptation example

subsume

WB TI

yieldidle

+B

BI

subsumeidle

WB

+subsuming

yieldsubsume

W

Bumper process

Subsumption adapter

+W

System synthesis interactionSystem synthesis interaction

Map functionality to architecture

Designer: IPChinook:

Map functionality to architecture

modemanager

Determine control communication

System synthesis interactionSystem synthesis interaction

Designer: IPChinook:

Map communication to architecture

System synthesis interactionSystem synthesis interaction

Designer: IPChinook:

Determine Control Communication

A B C

System synthesis interactionSystem synthesis interaction

Designer: IPChinook:

Map communication to architecture

Synthesize hop-processes and rest of runtime support

A B C

Inventory of runtime supportInventory 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-simulationCo-simulation

• Validate functionality

• Validate timing aspects of behavior

• Estimate utilization

• Evaluate implementation decisions

• Selective focus for efficiency

Selective FocusSelective Focus

Selective FocusSelective Focus

Modal Process

interface

Modal Process

interface

Protocol stack Protocol stack

Full Words

Packets

Tokens Control Actions +a -x

Full Words

Packets

Tokens Control Actions +a -x

IPCIPCHINOOKHINOOK design flow summary design flow summary

Functionality mapping

Communication mapping

IP Component selectionCustom component authoring

System Composition

Control synthesis

Communication & Runtime synthesis

High-level simulation

Co-simulation

Des

ign

er &

ID

E

Syn

thesis

Systems designed with IPCSystems designed with IPCHINOOKHINOOK

• 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

IDE ScreenshotIDE Screenshot

ConclusionConclusion

• 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 workOngoing & Future work

• High level debugging leveraging modal process abstractions

• Formal verification of control structures

• Extension to networked systems

• Commercialization viaConsystant Design Technologies

LiteratureLiterature

• (*) 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

SourcesSources• 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

IPCIPCHINOOKHINOOKan integrated IP-based design framework for an integrated IP-based design framework for

distributed embedded systemsdistributed embedded systems

Pai Chou, Ken Hines, Ross Ortega,

Kurt Partridge, Gaetano Borriello

University of Washington

36th DAC - 22 June 1999