RoboCup: An Application Domain for Distributed Planning and Sensoring in Multi-robot Systems

E. Pagello, RoboCup: Distributed Planning and Sensoring in MRS

RoboCup: An Application Domain for Distributed Planning and Sensoring

in Multi-robot Systems

Enrico PagelloPresident of the International IAS-Society

IAS-LabIntelligent Autonomous Systems

The University of PaduaThe University of Padua


Presentation Outline

• What a Cooperative Multi-Robot System should be• T. Arai, E. Pagello, L. Parker. Editorial: Advances in Multi-Robot Systems. IEEE/Trans. On R&A, Vol. 18, No. 5, pp 655-661, October 2002

• Scientific perspective in RoboCup with respect to Cooperation • Research on RoboCup at IAS-Lab, The University of Padua

• Distributed Sensoring: An Omnidirectional distributed vision sensor

• E. Menegatti, A. Scarpa, D. Massarin, E. Ros, E. Pagello: Omnidirectional Distributed Vision System for a Team of Heterogenueous Robots. Proc. of IEEE Workshop on Omnidirectional Vision (Omnivis’03), Praga June 2003

• E. Menegatti, A. Pretto, and E. Pagello Testing Omnidirectional Vision-based Monte-Carlo Localization under Occlusion. Proc. Of IROS-2004, Sendai (Japan), Sept 29 - Oct 2, 2004

• Cooperative Robotics: An Hybrid Architecture a MSL Team• A. D’Angelo, E. Menegatti, and E. Pagello: How a cooperative behavior can

emerge from a robot team. Proc. of DARS’04, Toulouse June 2004


Why Multi-Robot Systems (MRS) have been so successful ?

In challenging application domains, MRS can often deal with tasks that are difficult, if not impossible, to be accomplished by an individual robot.

A team of robots may provide redundancy and contribute cooperatively to solve the assigned task, or they may perform the assigned task in a more reliable, faster, or cheaper way beyond what is possible with

single robots.


What a Cooperative Multi-Robot System is ?

• Cooperative Robotics research field is so new that no topic can be considered mature

• Early research goes to

• Cellular Robotics by [Fukuda, IECON 1987] and Cyclic Swarm by [Beni, Intelligent Control 1988]

• Multi-Robot Motion Planning by [Arai, IROS 1989]• ACTRESS Architecture by [Asama, IROS 1989]

• [Dudek, Autonomous Robots 1996] and [Cao, Autonomous Robots 1997] gave a taxonomy

• In [Arai, Pagello, & Parker, IEEE/Trans. 2002] we identify several primary research areas


Research roots for Cooperative Multi-Robot Systems

Cooperative mobile robotics research began after the new behavior-based control paradigm

Brooks 1986, Arkin 1990 Since behavior-based paradigm is rooted in biological

inspirations, many researchers found it instructive to examine the social characteristics of insects and animals

The most common application is using simple local control rules of various biological societies, like ants, bees, and birds, for similar behaviors in MRS

MRS can flock, disperse, aggregate, forage, and follow trails, etc.


New and interesting research issues

The dynamics of ecosystems has been applied to MRS to demonstrate Emergent Cooperation

Cooperation in higher animals, such as wolf packs, has generated significant study in Predator-Prey Systems

Pursuit policies relay expected capture times to the speed and intelligence of the evaders and the sensing capabilties of the pursuers

Competition in MRS, such as in higher animals including humans, is being studied in domains such as multi-robot soccer.


Inherently cooperative tasks

A particular challenging domain for MRS is the one whose tasks are inherently cooperative, that is, tasks in which the utility of the action of one robot is dependent upon teammates’ current actions

Inherently cooperative tasks cannot decomposed into independent sub-tasks to be solved by a DARS Team success throughout task execution is measured by the by the combined actions of the robot team, rather than by individual actions

More recently identified biological topics of relevance are: Imitation in higher animals to learn new behaviors Physical Interconnectivity by insects such as ants, to enable collective navigation over challenging terrains How to maintain Communication in a distributed animal

society


Communication versus Cooperation

Communication issue in MRS started since the inception of Distributed Autonomous Robots Systems (DARS) research.

Distinctions between Implicit and Explicit Communication are usually made:

Implicit communication occurs as a side-effect of other actions, or “through the world” Explicit communication is a specific act designed solely to convey information to other robots on the team.

Communication affects the performance of MRS in a variety of tasks

even a small amount of information can lead to great benefit The challenge is to maintain a reliable communication even

when connections between robots may change dynamically and unexpectedly

setting up and maintaining distributed network


Architecture and Task Planning

Research in DARS has focused on the development of architectures, task planning capabilities, and control addressing the issues of:

action selection heterogeneity versus homogeneity of robots achieving coherence amidst team actions resolving conflicts, etc.

Each architecture focuses on providing a specific type of DARS capability:

fault tolerance swarm control role assignment, etc.


Architecture and Task Planning, Localization and Mapping

Research in DARS has focused on the development of architectures and task planning capabilities, where each architecture focuses on providing a specific type of distributed capability

Initially, most of the research took an existing algorithm developed for single robot mapping, localization, or exploration, and extended it to MRS

[Fox et al., Autonomous Robots 2000] took advantage of a MRS to improve positioning accuracy beyond single robot to develop a colaborative multi-robot exploration

Only more recently, researchers have developed new algorithms that are fundamentally distributed, to take advantage from MRS


• Middle-size League• Building, maintaining, and

programming a team of fully autonomous robots

• High speed moving (>2m/s)

• Large field (12m X 8 m)

• Sensing the environment

• Cooperation abilities

RoboCup Soccer : The oldest RoboCup standard problem


• Middle-size League: progresses from 1997 to 2003 USC (USA) - Osaka Univ. (Japan) Nagoya 1997 Isfahan Univ (Iran) - AIS (Germany) Padua 2003

RoboCup Soccer : From simple moves towards complex actions

QuickTime™ and a decompressor

are needed to see this picture.

QuickTime™ and aPhoto - JPEG decompressor



Middle-size League: RoboCup2003 : Vision and Localization

• Vision is still a key research issue in MSL• All teams used color information • Half of teams use shape detection• Even less can make edge detection• Auto-color calibration is a hot topic,

especially to relax lightning condition

• Robot Self-Localization is mainly based on Visual Landmarks• Most teams detect corner posts• Half of teams detects also field lines• Several teams use statistical methods


Middle-size League: RoboCup2003 : Control Architectures

• One half of teams use reactive control architectures(behavior based robotics)

• One third of teams use theirown architectures like:Dual Dynamics, two-level FSMs,Fuzzy Approaches, etc.

• Several teams develops advanced robot skills using learning• Only a few teams extends reactive motion control with path

planners based mainly on potential field methods or similar


Research on RoboCup topics @ IAS-Lab, Dept. of Information Engineering, The University of Padua

• Soccer-robot design• ODVS (Omnidirectional

Distributed Vision System)• MonteCarlo Localization

using omni-vision • Coordinated behaviors


Evolving the Artisti Veneti Team

• First platform for MSL was designed on 1998 over a Pioneeer1 base

• Second and third platforms evolved from a Pioneer1 to a Pioneer2 base

• Third platform is a Golem robot

• We shifted from 2-wheeled robot, with a directional camera, towards omnidrive and omnivision platforms

• Fourth platform ehnance the circular movement of original goalkeeper


Omnidirectional Sensor Convex Mirror Perspective

camera Perspex Cylinder

(support)Camera

Mirror


How to design a mirror

Mirror profile constructionMirror profile construction

Pin Hole

Vertex

Y

X

Pin Hole

Vertex

DMin DMax

X

Y

dMax d1

D1

Pin Hole

Vertex

DMin DMax

X

Y

dMax d1

D1

Pin Hole

Vertex

DMin DMax

X

Y

dMax d1

D1

Pin Hole

Vertex

DMin DMax

X

Y

dMax d1

D1

x

y P

Pin Hole

Vertex

DMin DMax

X

Y

dMax d1

D1

Pin Hole

Vertex

DMin DMax

X

Y

dMax d1

D1

Pin Hole

Vertex

DMin DMax

X

Y

dMax d1

D1

Pin Hole

Vertex

DMin DMax

X

Y

dMax d1

D1

Pin Hole

Vertex

DMin DMax

X

Y

dMax d1

D1

Made by F. Nori Made by F. Nori at IAS-Labat IAS-Lab


Our robot mirrors

Mirror’s three parts: Measurement Mirror Marker Mirror Proximity Mirror

Mirror ProfileMirror ProfileThe task determines The task determines the mirror profilethe mirror profile


A mirror designed for AIS – Fraunhofer Institut (Germany)

Three-parts mirrorThree-parts mirror Tailored on their mobile Tailored on their mobile

robotrobot Satisfing customer Satisfing customer

requirementsrequirements


In the case of Soccer Robots Requirements and profileRequirements and profile

For Goalie: Locate the ball Identify the markers See the defended

goal

For Attacker: Locate the ball Identify the markers See both goals Lighter mirror


Heterogeneous Robots

Characteristics: Chassis shaped for omnidirectional vision Mirror profile designed for the robot’s task

Mirror

Camera


Heterogeneous Vision Systems

Peripheral vision

Foveal vision


Heterogeneous Vision Systems

OVA’s viewOVA’s view PVA’s viewPVA’s view


Features and Events for Omnivision

Events: A new edge A disapearing edge Two edges 180° apart180° apart Two pairs od edges 180° apartTwo pairs od edges 180° apart

Features: Vertical edges


Omnidirectional Vision and Mapping

P2P2

P4P4 P3P3

P5P5

P1P1

It simplifies data interpretationIt simplifies data interpretation::– Discriminate b/t “Discriminate b/t “turns”turns” and and ““travels”travels”– Simplify “Simplify “Exploring around the Exploring around the blockblock””


Experimental Results

Correct tracking of edges Recognition of actions Calculation of the turn angle

The path The path segmentationsegmentation


Single Robot Mapping Strategy

Use an omnidirectional vision sensor Detect topologically meaningful features in the

environment Use Spatial Semantic Hierarchy of Kuipers (SSH) Build a topological map Use the map to explore the environment

E. Menegatti, E. Pagello, M. Write E. Menegatti, E. Pagello, M. Write Using Omnidirectional Vision within the Spatial Semantic Hierarchy Using Omnidirectional Vision within the Spatial Semantic Hierarchy

IEEE/ICRA2002, IEEE/ICRA2002, WashingtonWashington, , May 2002 May 2002


Multi-robot mapping strategy

Every robot builds its own local map When two robots can see each other, they share their local

maps by matching their current views: Identifying the objects seen by both robots Estimating their relative distance and orientation

If the match is successful, they transmit their own local map to the teammate

Each robot connects this new local map to its local map


Some hints

Every robot carries on an independent exploration by using use a misanthropy robot strategy i.e.

Follow a direction of exploration that increases the distance

from the visible teammates Use redundacy of the observers and observation to

improve the map Exploit the heterogeneity of the robots more deeply in

tasks too expensive (or not achievable) for homogeneous robots

Use maps of non previoulsy met robots to navigate. The bridge is the common starting location.


ODVS for Navigation

We realised a network of smart uncalibrated sensors able to learn how to navigate a blind service robot in an office like environment

The sensors learn by observing the robot motion.

The first stage is supervised, then the knowledge is propagated autonomously exploiting the overlapping field of view of the sensors

VA1

VA2

E. Menegatti, E. Pagello, T. Minato, T. Nakamura, H. Ishiguro E. Menegatti, E. Pagello, T. Minato, T. Nakamura, H. Ishiguro ““Toward knowledge propagation in an omnidirectional distributed vision system” Toward knowledge propagation in an omnidirectional distributed vision system”

Proc. of 1st Int. Workshop on Advances in Service Robotics (ASER'03), Proc. of 1st Int. Workshop on Advances in Service Robotics (ASER'03), Bardolino (Italy), March 2003Bardolino (Italy), March 2003


Implicit Communication VA1 learns its own mapping VA1 moves the robot in the

field of view of VA2 VA2 observes the robot VA2 receives from VA1 the

motor commands sent to the robot

VA2 trains its own neural nets to build its own mapping

VA1

VA2


Monte Carlo Localisation (MCL) as a very successful approach Applying MCL to omnidirectional vision used as a range finder An experimentally generated sensor model The fusion of sensor data for pose likelyhood calculation A global localization experiment in a RoboCup Environment Robustness to occlusion An application to a non-roboCup Environment

E. Menegatti, A. Pretto, E. Pagello A New Omnidirectional Vision Sensor for Monte-Carlo Localization Proc. of 8th RoboCup Int. Symposium, Lisbon (Portugal), July 2004

Why Monte-Carlo Localization


MCL (Monte Carlo Localisation) in one page

MCL is a probabilistic technique to estimate the robot’s positions

from the odometric and sensor data We calculate the probability density of robot positions (the belief)

by a set of weighted samples The samples are localisation hypothesis When the robot moves, everytime a new image is processed,

the samples are moved in accordance with the motion model To every sample is associated a weight proportional to the probablity

that the robot is occuying that position When the robot grasps new data, the sample weights are updated

according to the sensor model At every step a resampling eliminates the less probable positions


Our approach to MCL

Starting from the work of [Kröse, IVC 2001] and [Burgard, ICRA 2002] , we realised an omnidirectional image-based Monte Carlo Localisation system for a large office environment [Menegatti, RAS 2004]

We decided to port a similar approach in RoboCup, but image-based localisation is not suited due to:

(i) many occlusions (ii) an high dynamical environment(iii) high computational costs for processing the whole image

Previous works in RoboCup implemented MCL using complex method for landmark or feature detection, and need to cope with dynamic occlusions

[Utz, RoboCup-IV 2001], [Enderle, IAS2000] We fell back on range-scanner, like [Fox, JAIR 1999][Thrun, AI 2000]


Our omnidirectional enhanced range finder

• We detect colour transitions of interest: G- W, G -Y, G - Blue

• We detect occlusion: G - Black


Probability distribution of the robot’s pose

• The scan of every colour transition of interest (here Green-White) gives a probability distribution in the whole field.

• Black dots = high probability , White dots = low probability

• Note the symmetry in the environment


Sensor Model.1 - Calculating p(o|l)

• p(o|l) is the probability to have a the scan o at the location l

• oi is the measurement along the single ray i of the scan

Omni-Scan:• One scan per colour transition of

interest• Every scan has 60 rays (one

every 6°)• Every ray has one receptor every

4 cm from 10 cm to 4 meters• When a transition is found the

ray is not searched anymore

{i = 1:60}


Expected and Real Scans


Sensor Model.2 – estimating p(oi|l)

• Taking 2000 images in different positions in the field

• For every ray of the 2000 scans

• Computing the actual distance of

the colour transition (here Green-White)

• Estimating the distance of the colour transition with the vision software

• Running the Expectation

Maximisation (EM) to fit the experimental data separately for every colour transition

Expected Distance


Sensor Model.3 –Results

The resulting probability density calculated for every colour transition is the sum of three components:

1. Erlang distribution (accounting for image noise and imperfect colour quantization)

2. Gaussian distribution centered around the expected distance

3. Discrete density (accounting for missing the transition)

Erlang

Gaussian

Discrete


Combining the three probability distributions

Probability distribution for the green-white ToI

Probability distribution for the green-blueToI

Probability distribution for the green-yellow ToI

Resulting Probability distribution for the

robot’s pose


Global Localisation

Step 0 Step 4

Step 6 Step 18


Sensor Occlusion.1


Sensor Occlusion.2

Our system is able to recognise occlusion by other robots as a Green-Black ToI along a ray

These rays are labeled as FAKE_RAY (

and discarded from the calculation of p(o|l)

We called this process ray discriminationOur system scans with less rays (so less information), but keeps the usable information and avoids using expensive algorithm as distance filters.


•We need uniformly colored surfaces, clear color gaps, and uniform light

•Red floor, white walls, and gray furnitures

•New color transitions: Red - White, Red - Gray

•The omnidirectional image is scanned with 60 rays, one every 6 degrees

Sperimentation at University Building


The ideal scan was different from the real one:• Robot shadow• Mirror deformation• Error in color detection near the door

In the probability map of the environment, there are dark zones everywhere the probability to have the observation is higher:• All cornered zones are darker•The samples closer to the real pose have a higher weight

Ideal scans and probabilities in real environments


Extending the limits of the sensorial horizon of the single agent

• The first step: using omnidirectional vision (RoboCup is an example of this)

• But, RoboCup proved omnidirectional vision is not enough for highly dynamic

environments:• cannot see occluded objects • cannot see very distant objects

• To realise a Distributed Vision System we need to share information between the agents of a team


Omnidirectional Distributed Vision System (ODVS)

Requirements:Requirements:

• Robots’ only sensor: omnidirectional Robots’ only sensor: omnidirectional visionvision

• No use of external computerNo use of external computer

• Every robot shares its measuresEvery robot shares its measures• Every robot fuses all measures Every robot fuses all measures received received

by teammatesby teammates• Measures can refer to different Measures can refer to different instants instants

in time in time

Tracking multiple moving objects in highly dynamic Tracking multiple moving objects in highly dynamic environments environments by sharing the information gathered by every single robotby sharing the information gathered by every single robot


Enhancing the ODVS by fusing multiple observations

E. Menegatti, A. Scarpa, D. Massarin, E. Ros, E. PagelloOmnidirectional Distributed Vision System for a Team of Heterogenueous RobotsProc. of IEEE Workshop on Omnidirectional Vision (Omnivis’03), Praga June 2003

• Fusing Multiple Observations from Single Measurements


Inspiring Works

• Stroupe et al. [ICRA 2001]• Perspective cameras• They fused measurements made at the same instant in time• No tracking, just recognition

• Gutmann et al. [IROS 2001]• Laser Range Finders + Perspective cameras• External Global Sensor Integrator• Robot uses external information only for unseen objects


Problems for ODVS

• Our Robots are heterogeneous: • Omni-sensors are different• On-board processing power is different• Robots’ platforms are different

• The robot need to share: • the same spatial frame of reference• the same temporal frame of reference

• The system must be robust to failure of single robots


Single Sensor

Architecture of the Perception Module


Single Measures

• A 2D Gaussian is associated to every measure

• The Gaussian represents the The Gaussian represents the

probability that probability that

the object is actually located at that the object is actually located at that

pointpoint• Gaussian widths are determined Gaussian widths are determined

experimentally for every single robotexperimentally for every single robotTo share the measurements with other robots: To share the measurements with other robots: • Measure is transformed in the absolute reference frame of play Measure is transformed in the absolute reference frame of play

field field • A time stamp is associated to every measureA time stamp is associated to every measure


Fusing Multiple Observations (1)

• Measures come from:• the vision system of the single robot • the vision system of the teammates

• Measures can refer to:• Different objects• The same object

(this is the most frequent case because of omnidirectional vision)

• They are processed in the same way:• They are fused using a Kalman filter• They are stored in ‘tracks’• Multiple tracks allowed for single object (Multi-modal

distribution)


Mean Object Position

Associated Variance

Fusing Multiple Observations (2)

• Two measurements (i.e. two Gaussians) are fused with a Kalman filter:


Tracks management• Every new measure is compared with existing tracks:

• If compatible the measure is added to the track• If NOT compatible a new track is created

• When a track is not updated the associated variance increase• Over certain threshold the track is deleted• We allows more tracks for the same object• Real position assumed to be the one of smallest variance


Measures from Different Robots

Problems:1. sharing the same spatial frame of reference2. sharing the same temporal frame of reference3. Trusting teammates4. Managing ‘old’’ measurements

Adopted solutions:1. Robust self-localisation thanks to omni-vision2. Internal clock synchronised via Network Time

Protocol (NTP)3. Variance of measures from teammates are

doubled4. The state of the object is recalculated


Old Measurements• Old measurements cannot be thrown away For example: Very slow vision system reporting very accurate measurements

Image processing time


Experiment (1)

Ball moving between steady robots Ball moving between steady robots


Experiment (2)

Moving ball and ‘blind robot’


Experiment (3)

Kidnapped ball


Discussion

• We implemented an Omnidirectional Distributed Vision System

• The system is robust to failure of the single robots

• The system exploits:• the heterogenity of the sensors

• The redundancy of the observations

• We presented experiments in real game scenarios

• The system requires fine tuning of the parameters:

• Variance associate to every measure

• Rate of growth of variance when track not updated

• Variance of teammates’ observations


A Hybrid Architecture for MRS

We suggest to use an Hybrid architecture where the Deliberative part and the Reactive part can take mutual advantages. We introduced Robot Schemas at the low level, as building blocks to grow-up complex behaviors from simple ones, according to Arbib and Arkin :

Behaviors are chunks of basic knowledge of how to act and perceive.

Each behavior is implemented with a schema composed by a motor schema, representing the physical activities a perceptual schema which includes the sensing


The Perceptual/Motor Schema

At each level, the primitive control component is a behavior built by perceptual and motor schemas only.• The lower reactive level uses only information coming

from sensors, and feeds the motors with appropriate commands.

• It can elaborate on some perceptual patterns generated by other individual robots, both opponents and temmates.


An Abstract Architecture

• Compound behaviors appear only at higher level, when they may receive more structured information about the environment.

• Only the higher deliberative levels refer to cooperative capabilities that any robot could exhibit as a teammate, while a cooperative behavior is going to emerge.


The Layered Levels of Control

By releasing a behavior, we fire an activation-inhibition mechanism, built on some given evaluation condition rule, at some level of abstraction.

Simple Behaviors like defendArea, or carryBall, are implemented as motor schemas accessing directly the robot effectors.

Basic Behaviors, like playDefensive, and chaseBall, are obtained by simply appending two perceptual schemas seeBall and haveBall.

playDefensive : seeBall --> defendArea chaseBall : haveBall --> carryBall

Since a primitive behavior results in appending just one perceptual schema to one motor schema, at the reactive level we obtain sensori-motor coordinations


Software architecture:ArtiFACT (Artisti Fuzzy Agents Control Toolkit)

• We designed a new hybrid deliberative reactive architecture.• The classic deliberative paradigm (Sense-Reason-Act) has been

evolved reinforcing reactive behaviors.• A direct link between sense and act has been introduced to speed-up

the reactive response of the robot• Thus, deliberative conditions can be bypassed for certain inputs

which need more reactive behaviors


A Functional Architecture

• The architecture of each single robot shows • An inner loop, for close feedback, • An outer looop, for high level reasoning.

• To allow cooperation with teammates, two sensorial sources can input asynchronously both

• Environment constraints (the “Ruler”) • Information about teammates (the “Teamplay”)


On Role Allocation in RoboCup

Inspired by Stone and Veloso’s pioneering work, many teams employ role-based coordination, in which robots can take on different static roles within the team

Although it would be possible to statically assign roles once forever, most teams switched to dynamic role allocation, by solving an iterated assignement problem, where the current allocation is re-evaluated periodically 10 times for each second

Given n robots, n prioritized (weighted) single-robot roles, and some estimates of how well each robot can be expected to play each role, assign robots to roles so as to maximize the overall expected performance

Gerkey and Mataric [Springer Book on RoboCup2004] showed that this technique is an instance of the canonical Greedy algorithm for Optimization theory


RoboCup Team solutions adopted

RoboCup role allocation problem is similar to task allocation problem for MRS in order to cooperatively achieve the goal, where a time-extended role concept replace that of a transient task

CS Friburg Team used a distributed role allocation mechanism in which two robots may exchange roles only if both want to do it, both moving to a higher-utility role for themselves.

ART Team, as well as early, Artisti Veneti Team, ordered the roles in a descending priority, and then assigned each to the available robot with the highest utility.


Utility Functions

Multi-robot role allocation is a dynamic decision problem, that varies in time, according to the environmental

changes, Utility concept rely on the fact that each individual robot

can somehow internally estimate the value (i.e. the cost) of executing an action

In RoboCup it is common to compute utility as the weighted sum of factors like distance to target, distance to ball, defence-offense coonfigurations, etc.

The computation is affected by sensor noise, general uncertainties, and environmental changes

Given the utility value Uij of each robot i for each role j, find the highest utility Uij, assign robot i to role j, and iterate


Dynamic role assignment in practice

• We developed an enhanced reactive approach starting from behavior-based hand-coded software• Dynamic role assignments among attacker, supporter and defender, were managed by considering collision avoidance issues and competitive behaviors

QuickTime™ and aYUV420 codec decompressor


QuickTime™ and aH.263 decompressor



Coordinating the Master/Supporter Roles

• Consider the coordination between two robots carrying the ball towards the opponent’s goal:

• We may indentify a Master Role and a Supporter Role• Roles can be played at different responsibility levels:

• Can be >>> Assume >>> Acquire >>> Advocate• Ball assignments depend on Ball Possesses

• HaveBall condition allows to discriminate

which robot is really carrying the ball• It is an Environment constraint acting as a kind of

Macroparameter, evaluated by different teammates

• It allows to synchronize the activation of a new cooperation pattern


Notifying Roles

• Roles can be switched provided a notification is exchanged between teammates

• A notification implies a communication between teammates based on a

first-notified/first-advocated basis• A notify(Role) rule is:

Supporter (mate) -->> reply (role, mate)

Master (mate) --> request (role, mate)• Environment Rules require that a Master role must be

advocated, whereas a Supporter role should be acquired.

• haveBall and notify (Role) are the two allowed asynchronous communication from outside for a single robot


Constructing Clamping Behaviors

A role is switched from acquire to advocate, or from assume to acquire, provided a notification is made to its teammate Two complex Clamping Behaviors for Master and Supporter can be constructed from notify (x) and haveBall (z)

The Master robot shows a chase_ball behavior haveBall (me) & not haveBall (mate) -->> acquire (Master) Acquire (Master) & Notify (Master) -->> advocate (Master)

The Supporter robot shows an approach_ball behavior Not acquire (Master) & canBe (Supporter) -->> assume (Supporter) Assume (Supporter) & Notify (Supporter) -->> acquire (Supporter)

The robot chasing the ball suggests a teammate to become supporter by advocating a master role, and forcing the other robot to acquire a supporter role by approaching the ball.


Single Robot Architectureand effect on coordination

• Conditions are defined as fuzzy functions. A value is returned depending on how strongly the condition is met

• Team coordination is obtained by incorporating some conditions depending on messages coming from other robots, when the condition is evaluated

QuickTime™ and aMotion JPEG OpenDML decompressor



The Artisti Veneti TeamThe Artisti Veneti Team

www.dei.unipd.it/~robocupwww.dei.unipd.it/~robocup

Documents

RoboCup: An Application Domain for Distributed Planning and Sensoring in Multi-robot Systems