An Elementary Communication Framework for Open

Co-operative RoboCup Soccer Teams

ıs Mota

1,2

and Lu

ıs Paulo Reis

DCTI-Instituto Superior de Ci

encias do Trabalho e da Empresa, Portugal

LIACC-Faculdade de Engenharia da Universidade do Porto, Portugal

Abstract. One of the present day challenges in RoboCup is the development of

Open Co-operative teams, where different research labs join efforts to build a

common team. Such teams bring together robots with heterogeneous hardware,

architectures and control software, which hinders straightforward co-operation.

The robots in these teams might co-operate through a-priori strategic knowledge

and structured communication during the game. This paper presents the kernel

of a communication framework, deﬁning a robotic soccer vocabulary, as well as

rules to manage communication.

1 Introduction

id[0..1]: String

team[0..1]: String

playerNumber[0..1]: PositiveInteger

colour[0..1]: Colour

width[0..1]: PositiveDecimal

depth[0..1]: PositiveDecimal

height[0..1]: PositiveDecimal

averageSpeed[0..1]: PositiveDecimal

kickingDevice[0..1]: Boolean

kickReach[0..1]: Decimal

kickAngleCSU[0..1]: Angle

Player

OwnTeamPlayer

OpponentTeamPlayer

Fig.1. Player deﬁnition.

RoboCup

has the goal of ”By the year 2050, develop a team of autonomous robots

that can win against the human world soccer champion team.” This team will surely be

formed by heterogeneous robots, a selection of the best players, which will outperform

http://www.robocup.org

Mota L. and Paulo Reis L. (2007).

An Elementary Communication Framework for Open Co-operative RoboCup Soccer Teams.

In Proceedings of the 3rd International Workshop on Multi-Agent Robotic Systems, pages 97-101

 SciTePress

any single-origin team. If this is to be the case, how will such a team be built and

managed, and how will it play?

This subject has recently been the subject of a prospective analysis[1]. In the present

paper, a Communication Framework that leads to implementing these scenarios is de-

ﬁned. To fulﬁl this scenario, there will be the need for a vocabulary relative to robotic

soccer, presented in section 2. The management of interactions between players during

the game must also be determined, and a proposal is made in section 3. Finally, we

present a summary and look into future work in section 4.

2 Robotic Soccer Domain Concepts

2.1 Physical Objects and Positioning

As pointed out in the scenario presented in [1], robots will have to share the world

state, having thus to use a proper vocabulary describing players. Information about

their colour and shape should also be expressable. They should be characterised by their

skills, like average motion speed and kicking device. This modelling can be seen as an

UML diagram in ﬁgure 1. Other relevant physical objects are the ball and the referee.

Positioning of objects should be shared among team-mates, to enhance the state of the

id[0..1]: String

height[0..1]: Decimal

trousersColour[0..1]: Colour

shirtColour[0..1]: Colour

Referee

id[0..1]: String

colour[0..1]: Colour

radius[0..1]: Decimal

Ball

id[0..1]: String

(...)

Player

PhysicalObject

Fig.2. Physical Objects.

world. The absolute pose of an object is based on a right-hand cartesian co-ordinate

system, with the origin placed at the centre of the ﬁeld, the x-axis pointing at the blue

goal and the z-axis up. The robot’s orientation, i.e., the direction it is facing, is modelled

as a yaw angle relative to the x-axis on the xy plane. The full deﬁnition can be found in

ﬁgure 3.

The uncertainty in positioning determination must be dealt with. In fact, no mea-

surement is entirely reliable and different sensors introduce different kinds of uncer-

tainty. We chose to use the Standard Uncertainty[2]. AbsolutePositioningWithSU ex-

tends ’AbsolutePositioning’. There can also be uncertainty about the identity of the ob-

served object (targetIdentiﬁcationConﬁdence). In the scenario in [1], most of the posi-

tioning exchanged are determined from the viewpoint of the robot, and are thus relative

to it. The class (RelativePositioning) represents relative positioning with respect to the

observer, useing polar co-ordinates. ’RelativePositioningWithSU’ extends the former.

Coach-Unilang[3] introduces a deﬁnition of ﬁeld regions, including predeﬁned areas

and freely deﬁnable areas like circles, which will be included in this framework.

x: Decimal

y: Decimal

z[0..1]: PositiveDecimal

yaw[0..1]: Angle

AbsolutePositioning

observerID: String

theta: Angle

distance: PositiveDecimal

altitude [0..1]: PositiveDecimal

yaw[0..1]: Angle

RelativePositioning

Positioning

targetIdentiﬁcationConﬁdence[0..1]: Decimal

thetaSU[0..1]: Angle

distanceSU[0..1]: PositiveDecimal

altitudeSU[0..1]: PositiveDecimal

yawSU[0..1]: Angle

RelativePositioningWithSU

targetIdentiﬁcationConﬁdence[0..1]: Decimal

xSU[0..1]: Angle

ySU[0..1]: PositiveDecimal

zSU[0..1]: PositiveDecimal

yawSU[0..1]: Angle

AbsolutePositioningWithSU

PhysicalObject

hasPosition

0..1

Fig.3. Positioning related concepts.

2.2 Game Events, Player Moves, Actions and Tactics

During the game, some events occur and may be reported to team-mates, since they are

relevant to the world state. Such events are related to temporarily absent players, which

may inﬂuence decisions or even strategy changes. These events are: sentOff(player),

returnedToGame(player), malfunctioning(player) and functioning(player).

Co-operation can be enhanced by the intentional exchange of messages to co-ordinate

robots’ behaviour. When a robot well positioned to score a goal decides to ask its

team-mate holding the ball to perform a pass. Coach-Unilang[3] deﬁnes a set of ac-

tions, which will be used. Some of these actions have added arguments. These ac-

tions and moves are: shoot(), pass(player), forward(ﬁeldRegion), dribble(direction),

run(direction), hold(), clear(), intercept(), tackle(player), mark( player), markPassLine

(player1, player2), gotoBall() and move(ﬁeldRegion).

Tactics deﬁne the players’ preferred positioning on the ﬁeld, as well as the team’s

pressure and mentality. These deﬁnitions will inﬂuence the players’ options. During a

game, a tactics change may have to be communicated to all the players. A set of classes

for this purpose can be seen in ﬁgure 4. Most of the attributes in the ’Tactics’ class have

a discrete set of possible values, e.g. from veryDefensive to veryOffensive or from 0 to

100. There are predeﬁned formations, like 442 and 433. There may be the need to use

arbitrary formations, using the ArbitraryFormation class, as represented in ﬁgure 4 by

FormationPosition. In this class, the positioning of each player is characterised by an

horizontal and vertical position. playerRole will deﬁne the attitude of the player.

3 Inter-robot Communicative Interactions

Since the information in the previous section is to be shared between heterogeneous

agents, one also needs to establish how this exchange will be managed. The autonomous

agents’ community has been dealing with these problems for several years, and one can

proﬁt from the results previously obtained.

The transmission of observed information needs only a simple interaction, where

one player (Sender) will inform some other players (Receivers). The acknowledgement

is optional. This interaction protocol is represented as an AUML diagram

. This proto-

http://www.auml.org

teamMentality[0..1]

gamePace[0..1]

teamPressure[0..1]

riskTaken[0..1]

Tactics

433 442 ...

ArbitraryFormation

verticalPosition

horizontalPosition

playerRole[0..*]

FormationPosition

Player

1..11

1 1

Fig.4. Tactics related concepts.

col will also be used to advertise choices. An example, where a robot informs others that

it intends to shoot at the opposite goal, uses the intends (I) operator[4], is as follows:

(inform :sender robot1 :receiver robot2 (...) :contents (I robot1 (shoot)))

Sender Receiver

inform(Contents)

acknowledge(Contents)

alternative

Sender: Player

alternative

Receiver: Player

request(Action)

accept(Action)

refuse(Action)

Fig.5. Inform and Request interaction protocols.

Other interactions are more complex: if a player wants a team-mate to perform a

speciﬁc action, it will have to request this action, and the requested player will have

to either accept or reject the request. Such an interaction resembles the FIPA Request

Protocol[5] (ﬁgure 3).

4 Summary, Conclusions and Future Work

A communication framework has been deﬁned, contributing to the development of

joint, multi-partner, heterogeneous, co-operative and open RoboCup soccer teams. This

framework introduces a vocabulary deﬁning a fundamental set of concepts needed by

robots during a match. Two kinds of interactions have been deﬁned. The ﬁrst kind al-

lows robots to share information about the game and their individual intentions. The

second enables momentary co-operation that will lead to more complex moves involv-

ing several robots.

This framework is therefore a fundamental set of concepts and protocols for robots

to communicate. In order to take co-operation to a higher level, it will need concepts

such as role changes and set plays. Further, there is also the need for game statistics,

which enable the modelling of the opponent team and could be the basis for a better

choice of tactics, prior to and during the game. All these concepts will be considered in

the future as possible extensions.

References

1. Mota, L., Reis, L.P., Burkhard, H.D.: Communication challenges raised by open co-operative

teams in robocup. In: Encontro Cient

ıﬁco do Festival Nacional de Rob

otica 2006. (2006)

2. ISO: Guide to the expression of uncertainty in measurement. International Organization for

Standardization (ISO). (1995)

3. Reis, L.P., Lau, N.: Coach unilang - a standard language for coaching a (robo) soccer team.

In Birk, A., Coradeschi, S., Tadokoro, S., eds.: RoboCup-2001: Robot Soccer World Cup V.

Volume 2377 of Lecture Notes in Artiﬁcial Intelligence., Berlin, Springer Verlag (2002) 183–

192

4. FIPA: FIPA SL Content Language Speciﬁcation. Foundation for Intelligent Physical Agents.

(2002)

5. FIPA: FIPA Request Interaction Protocol Speciﬁcation. Foundation for Intelligent Physical

Agents. (2002)