Embed Size (px)
Citation preview
Multi-robot Coordination using Flexible Setplays:Applications in the RoboCup’s 2D/3D Simulation and
Middle-Size Leagues
Luıs MotaSupervisors: Prof. Doutor Luıs Paulo Reis and
Prof. Doutor Nuno Lau (Univ. of Aveiro)
March 17, 2010
Contents
1 Introduction 4
2 State of the Art 62.1 RoboCup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 2D Simulation League . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 3D Simulation League . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Small-size League . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Middle-Size League . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.5 Standard Platform league . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Agent Architectures in RoboCup . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Internal Agent Architecture . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Multi-agent System Architecture . . . . . . . . . . . . . . . . . . . . 9
2.3 Modelling Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Team level Co-ordination in RoboCup . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Positional Co-ordination . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Setplays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1 Setplay selection and activation . . . . . . . . . . . . . . . . . . . . . 132.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Objectives 15
4 Detailed Description 164.1 Motivating Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Framework Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.3 Inter-robot Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.4 Setplay Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.5 Example Setplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.6 Completed Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.6.1 Implementation of a C++ library . . . . . . . . . . . . . . . . . . . . 274.6.2 Implementation in the 3D Simulation League . . . . . . . . . . . . . . 304.6.3 Implementation in the 2D Simulation League . . . . . . . . . . . . . . 304.6.4 Implementation in the Middle Size League - Simulation . . . . . . . . 31
4.7 Uncompleted Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1
4.7.1 Testing in the Middle-Size League - Real robots . . . . . . . . . . . . 324.7.2 Mechanism for Setplay Evaluation and Selection . . . . . . . . . . . . 324.7.3 Graphical Design of Setplays . . . . . . . . . . . . . . . . . . . . . . . 324.7.4 Evaluation of the Setplay Framework . . . . . . . . . . . . . . . . . . 33
5 Planning 345.1 Literature Review and Initial Study . . . . . . . . . . . . . . . . . . . . . . . 345.2 Domain, Platforms and Base Code Study . . . . . . . . . . . . . . . . . . . 345.3 Definition of the Setplay Architecture . . . . . . . . . . . . . . . . . . . . . . 345.4 Design of Language for Setplays . . . . . . . . . . . . . . . . . . . . . . . . . 345.5 Implementation of C++ library . . . . . . . . . . . . . . . . . . . . . . . . . 365.6 Implementation in the 3D Simulation League . . . . . . . . . . . . . . . . . . 365.7 Implementation in the 2D Simulation League . . . . . . . . . . . . . . . . . . 365.8 Implementation in the Middle-Size League - Simulation . . . . . . . . . . . . 365.9 Testing in the Middle-Size League - Real robots . . . . . . . . . . . . . . . . 365.10 Mechanism for Setplay Evaluation and Selection . . . . . . . . . . . . . . . . 365.11 Graphical Design of Setplays . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.12 Experiments and Result Analysis . . . . . . . . . . . . . . . . . . . . . . . . 375.13 Ph.D. Thesis Writing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2
Abstract
Multi-agent coordination and strategic planning are two of the major research topics inthe context of RoboCup. However, innovations in these areas are often developed andapplied to only one domain and a single RoboCup league, without proper generalization.Also, although the importance of the concept of Setplay, to structure the team’s behaviour,has been recognized by many researchers, no general framework for the development andexecution of generic Setplays has been presented in the context of RoboCup. In the senseemployed in this thesis, a Setplay is a freely-definable, flexible and multi-step plan, whichallows alternative execution paths, involving a variable number of robots and having optionalarguments.
This project introduces such a framework for high-level Setplay definition and execution,applicable to any RoboCup cooperative league and similar domains. The framework is basedin a standard, league-independent and flexible language that defines Setplays which may beinterpreted and executed at run-time through the use of inter-robot communication.
The planning of the implementation of this framework in the 3D and 2D simulationleague, as well as in the Middle-Size League, is also described with concrete examples ofSetplay definition, management and execution. The first results achieved show the usefulnessof this approach and motivate us to use it as the main coordination of all teams participatingin the Simulation, Small-Size, Middle-Size and Legged leagues of RoboCup.
3
Chapter 1
Introduction
RoboCup is an international initiative to promote AI, robotics, and related fields. It fos-ters research by providing a standard problem, where a wide range of technologies can beintegrated and examined. RoboCup uses the soccer game as a central topic of research, aim-ing at innovations to be applied for socially significant problems and industries. Researchtopics include design principles of autonomous agents, multi-agent collaboration, strategyacquisition, real-time reasoning, robotics, and sensor-fusion.
The ultimate goal of the RoboCup initiative is ”By the year 2050, develop a team offully autonomous humanoid robots that can win against the human world soccer championteam.” This is certainly an ambitious goal, but research in co-operative robotics has beenaccumulating results that allow the community to continue believing in this challenge. Withthis goal in mind, some questions have to be asked: what kind of robotic team will play thisdecisive game when the time comes? What will the team’s high-level architecture be?
The RoboCup initiative has always believed that, to reach its intended goal, a wide arrayof scientific challenges will have to be solved. To better deal with this diversity of challenges,RoboCup has been split in different and heterogeneous leagues: Simulation, Mixed-Reality,Small and Middle-Size, Legged, Humanoid and Nanogram, all in the soccer domain, as well asleagues dealing with other domains, such as the Rescue league, both simulated and with realrobots, and RoboCup@Home, that researches the use of robots in domestic environments.
This diversity of applications has certainly allowed research teams to deal with a broadset of scientific issues. Nevertheless, it has also brought some drawbacks: the focussing onspecific leagues and problems, together with the competitive nature of the competitions,has frequently made teams overspecialise in specific issues, and simultaneously neglect thegeneralisation and wide application of results. This has had as consequence that the solu-tions developed in one league are not easily transferable to other leagues, lacking thereforegeneral purpose testing and applicability. This question has been discussed in more detailin [Mota and Reis, 2008].
Robot Soccer needs, as the research in the domain develops, co-ordination at team scope,which involves planning at many levels. This thesis deals with representing and executinghigh level, flexible plans for robots playing in different RoboCup leagues. A frameworkfor representing, executing and evaluating such plans is presented, relying on inter-robot
4
communication.Setplays are commonly used in many team sports such as soccer, rugby, handball, bas-
ketball and baseball. There are surely several important differences between robot soccerand human sports, but Setplays are nonetheless a useful tool for high-level co-ordination andcooperation.
One additional motivation for high level planning has been raised in the Middle-SizeLeague: the Technical Comittee has at one point decided that some of the teams would haveto join efforts to pairwise create common teams, in order to decrease the total number ofparticipating teams. This idea was not put forward, but anyway the challenge of buildingmulti-partner teams remains unsolved. One possible way to integrate heterogeneous playerswould be to present them a list of Setplays, understandable to all, and simply tell them whenand how each of these Setplays should be executed. A full scenario of such a mixed teamintegration has already been presented in [Mota et al., 2006].
From this analysis, one can conclude that there is the need for general purpose tools andframeworks, that can apply to several leagues, thus allowing the easy generalisation, testingand transfer of obtained results. Such tools and frameworks are the subject of the presentthesis.
5
Chapter 2
State of the Art
2.1 RoboCup
In the last ten years, the RoboCup competitions and symposia [Asada and Kitano, 1999,Veloso et al., 2000, Stone et al., 2001, Birk et al., 2002, Kaminka et al., 2003][Polani et al., 2004, Nardi et al., 2005, Bredenfeld et al., 2006, Lakemeyer et al., 2007][Visser et al., 2008, Iocchi et al., 2009, Baltes et al., 2010] have increasingly become a testbed for co-operative robotic approaches. Teams from all around the world compete in ninemajor leagues including six co-operative soccer main leagues: Simulation 2D; Simulation 3D;Small-Size; Middle-Size; Standard Platform and Humanoid.
2.1.1 2D Simulation League
The 2D simulation league is based on the publicly available soccer server system. It simu-lates the players and the field for a 2D soccer match. The server accepts low-level commandsfrom the players, executes them in an imperfect way and sends (imperfect) perception in-formation to the players [Noda et al., 1998]. One of the objectives of the simulation leagueconsists in testing high-level multi-agent research issues while waiting for the hardware tokeep up. Advances in the simulation league include the use of learning to optimise in-dividual and team skills [Stone, 1998, Riedmiller et al., 2000, Riedmiller and Merke, 2003],co-operative techniques like formations and roles [Stone and Veloso, 1999], complex teamstrategies [Reis and Lau, , Kok et al., 2003], new agent architectures and agents debuggingtools [Stone and Veloso, 1999, Reis and Lau, 2001].
2.1.2 3D Simulation League
The 3D simulation league was introduced as a new competition in 2004. This competitionis based on a completely new simulator [Kogler and Obst, 2004] with a 3D environment andestablished a new set of research problems that had to be tackled. New problems includethe physics dynamics model which is much more precise and realistic than the one of the 2Dsimulator [Smith, 2004], new agent actions that are closer to the ones of real robots when
6
compared with the 2D simulator and the synchronisation between agent and simulator thatis completely different, making the thinking time of the agents one of the parameters thatmust be tackled (the world evolves while agents are thinking) [Riedmiller and Merke, 2003].The 3D simulation league has drawn a lot of interest in the community.
Since RoboCup 2007, the original server, where players were modelled as spheres, was con-tinuously replaced by versions where players were different kinds of humanoids [Boedecker and Asada, 2008].Presently, players are modelled as NAO robots, used in the Standard Platform League, de-scribed below.
2.1.3 Small-size League
Small-size teams consist of 5 robots that play in a 6.1x4.7m green-carpeted field. The rules ofthis league permit the use of global vision and robots’ centralised control. During the gamethe off-field software controller receives global vision information and sends out commandsto the robots using wireless communication. The need for high speed and precise controlhas given the small-size league the reputation of the ’engineering league’. Developmentsin subjects like electromechanical design, control theory and digital electronics, have beencrucial in this league [Stone et al., 2001, Birk et al., 2002]. However teamwork characteristicslike explicit passing abilities are increasingly turning more important due to the advances inhardware and the steadiness of the rules.
2.1.4 Middle-Size League
RoboCup Middle-Size League poses a unique combination of research challenges, com-bining most of the challenges encountered in the simulation and small-size leagues. Thegame is played by teams including up to 5 robots, in a 18x12m field, with a normal ball.Robots must be totally autonomous and thus carry all sensors and actuators on boardbut communication is permitted. In past RoboCup editions, most teams were mainlyconcerned with hardware design and complex solutions have been developed like omni-directional cameras [Iocchi and Nardi, 2000, Marques and Lima, 2001], laser range-finders[Weigel et al., 2001] or omni- directional drive designs, also self-calibrating vision systems[Lange and Riedmiller, 2005, Heinemann et al., 2007b] and robot self-localisation [Lauer et al., 2006,Heinemann et al., 2007a] have concentrated a lot of attention. Only a few teams introducedhigh-level approaches derived from previous simulation league approaches [Weigel et al., 2001,Hafner and Riedmiller, 2003]. Past directions in this league included the participation ofmixed teams, composed by the joint efforts of initially distinct teams, introducing severalresearch challenges, directly concerned with the objectives of this project.
2.1.5 Standard Platform league
The Standard Platform league had its debut on the 2008 edition of RoboCup. It is areplacement for the 4-legged league, described in the next paragraph of this section. All
7
teams must use the same robot, NAO1, a humanoid model which is available since early2008, thus the league’s name. The field is 6x4m and the teams can have a maximum of threerobots.
The Legged league, which has ceased to be maintained and was last present in RoboCup2007, was a predecessor to the Standard Platform League, since the robotic platform wascommon to all team and locomotion was made using legs. Teams consisted of 4 quadrupedrobot AIBO platforms from Sony. Objects have different colours, and special markers existin the field to enable self-localisation. Research in this league has been mainly focused onvision, self-localisation and robot locomotion. However, some teams like the previous cham-pions UNSW and German Team, have implemented teamwork algorithms like formationsand the use of roles. The case of the German Team is particularly interesting because theyare voluntarily organised as a mixed team. Several teams compete separately inside Germanybut joint efforts when at the World Championship mixing the software modules, using a com-mon architecture, developed by the four participant universities [Lotzsch et al., 2004]. Thisapproach, though successful, requires that all partners commit to a common architecture,leaving much place for innovation on this research subject.
2.2 Agent Architectures in RoboCup
2.2.1 Internal Agent Architecture
Traditionally, architectures employed in RoboCup tend to be hybrid, mixing reactive com-ponents with deliberative reasoning. This choice is made because players must be able torapidly change their behaviour when there is a sudden change in the environment (e.g. ballpossession is lost), while there is certainly the need for mid to long term planning.
[Berger et al., 2004, Berger et al., 2006] describe the Double-Pass Architecture, that aimsat de-coupling the sense-think-act cycle, by using a long-term planner that organises inten-tions and an executor that chooses short-term actions to execute. This architecture presents abalance between deliberative long-term planning and reactive response to unexpected events.
An already cited successful example is the German Team [Rofer et al., 2006], which is aco-operative project between several German teams. Each team develops an independent 4-legged team, that join efforts to build up a national team. In order to integrate the best com-ponents developed by every team, a general control architecture was defined [Rofer, 2003],where behaviours are defined using an XML-based language [Lotzsch et al., 2004]. The sys-tem provides development tools like a debugger and a simulator.
[Ramos et al., 2007] proposed a middleware for soccer robots, with three components:state-of-the-world, decision and low-level skills. The decision component can be set upusing either Petri Nets, State Machines or Fuzzy decision. Surprisingly, the interface to themiddleware is not fixed and can therefore change between different applications.
[Kleiner and Buchheim, 2004] introduces a plug-in based architecture, where each com-ponent is developed independently and then connected to the system. This allows a certain
1http://www.aldebaran-robotics.com/eng/Nao.php
8
degree of hardware independence, since components can be easily replaced. To allow thisflexibility, the system’s interface is fixed, and all components must comply to it.
[Farinelli et al., 2004] present a development and control architecture for robotic plat-forms. This architecture has a hardware-abstraction layer that allows high-level controlcomponents to be applied to different platforms. To help the development, components arebuilt modularly and there are tools for remote inspection. A perceptual model is used forcommunication between robots.
One less common approach is presented in [Ferrein et al., 2006]. This framework, basedon situation calculus, uses Golog as the implementation language. This way, the frameworkallows the declarative description of behaviours.
2.2.2 Multi-agent System Architecture
The co-operation between the different players in a team has been the subject of research inmany teams, specially in the simulated leagues. This is certainly a broad field of development,and many different approaches have been proposed. This section looks at some relevantexamples of these.
[Yokota et al., 1999] present a co-operation mechanism based on communication, usingconcepts common in the Multi-agent system domain, like communication protocols andspeech acts. [Shiota et al., 2006], also a Japanese team, also aim at using communication,but keeping the bandwidth as low as possible. Agents exchange simple, limited messageswith clear semantics.
[Lafrenz et al., 2006] uses a graphical language to define distributed behaviours. Thesebehaviours are executed by the robots, namely by following synchronisation and role-distri-bution phases. The behaviour’s progress is decided using state-of-the-world information ineach robot, thus needing little communication resources.
In [Beaudry et al., 2006], heterogeneous robots are used on the same team, with ball andown positions being communicated to other players. Decision making is done independentlyby each robot. These decisions are though communicated to a supervisor, which has thepower to change them in case it considers they are not in the best interest of the wholeteam.
A general overview of role allocation in RoboCup is presented in [Gerkey and Mataric, 2004].The authors analyse this question from an Operational Research point of view, and arguethat some of the currently employed strategies can be enhanced.
A classical approach for co-ordination in multi-robot teams is presented in [Parker, 1998].This architecture aims at efficient role distribution and relies on communication for coordi-nation. It is not well suited for dependant tasks, since their outcome is not predictable withcertainty.
A simple role distribution mechanism is described in [Moreira et al., 2006]: a centralsupervisor allocates roles to robots and communicates this to the other players. This kindof choice requires no negotiation, thus being very simple and straightforward.
Another role distribution architecture is presented in [Kose et al., 2005], where roles areallocated through auctions among the team members. Costs for fulfilling a role are estimated
9
through reinforcement learning.For role assignment in the middle-size CAMBADA team, a dynamic algorithm that
adapts the formation to a possible varying number of active robots is used, which will assigneach role/robot to the strategic positionings according to priorities and number of activerobots [Lau et al., 2009].
In [Castelpietra et al., 2001], formations are chosen through a voting process. Subse-quently, roles in the chosen formation are distributed according to each robot’s evaluationof capacity to fulfil the role. This is possible because all robots are able to play any role,whose characteristics are public, in order to allow adequacy evaluation.
[Utz et al., 2004] argue that a team of heterogeneous robots can co-operate simply bythe exchange of messages about the world state. The communication protocol is CORBAbased. The messages’ content is the estimated position and velocity of the player and theobserved objects. The communication architecture could also be used to convey informationother than the perceived world state.
While planning the present thesis, a proposal was made for an adhoc framework to struc-ture the communication and cooperation of heterogeneous agents. This proposal [Mota and Reis, 2007a]was not further developed but will be considered as future work.
2.3 Modelling Languages
Several authors research on hardware-independent languages to carry high-level information.These languages can have different purposes. [Lovell and Estivill-Castro, 2005] define a po-tentially hardware independent, XML based language to describe physical objects like theball. [Stanton and Williams, 2004] go in the same direction, also covering the most basicconcepts.
The soccer server [Noda et al., 1998] used in the RoboSoccer Simulation competitionsalso introduces perception and action languages. These languages convey information aboutthe different objects on the field, originally modelled in 2D. The abstraction level is, though,quite low, only allowing primitive actions (dash, turn, kick, etc.) and basic state-of-the-worldconcepts (distances to objects).
Coach Unilang [Reis and Lau, 2002] is a coaching language that defines concepts essentialto coach robot soccer teams, including high-level topics like tactics and formations, and lowlevel concepts like time periods and field positions. There are several options to expressthe recommended playing options: team mentality, team pressure, field use, formations, etc.Real-time communication of game statistics is also possible. The language allows expressingobserved situations like players and ball position, enabling it to be used as a communicationlanguage. Based on this language, RoboCup community developed Clang [Chen et al., 2003].
[Davin et al., 2005] present a language for players to communicate in the Simulation 2Dlanguage. Since there are severe bandwidth restrictions, the main challenge is to produceconcise content. It deals mainly with state-of-the-world information. The only exception is amessage type that can be used to ask for a pass if the player is in an advantageous position.
10
2.4 Team level Co-ordination in RoboCup
2.4.1 Positional Co-ordination
A method to achieve coordination based on repulsions and attractions called Strategic Po-sitioning by Attraction and Repulsion (SPAR) was introduced by [Stone, 1998]. When anagent is positioning itself using SPAR, the agent maximizes the distance to other players andminimizes the distance to ball and to goal. This is achieved evaluating several forces: repul-sion from opponents and team mates, attraction to active team mate, ball and opponents’goal. It also uses other constraints that have influence in agent’s positioning: stay in an areanear home position, stay within the field boundaries, avoid being at an offside position andstay in a position where is possible to receive a pass.
Later the Situation Based Strategic Positioning (SBSP) was introduced by [Reis et al., 2001][Lau and Reis, 2007]. If an agent is not involved, and will not be soon, in an active situa-tion, it will try to occupy its strategic position relative to the actual situation of the game.Through the analysis of the tactic, formation, self positioning in the formation and playertype, a player is able to define its base strategic positioning. This position is then adjustedaccordingly to ball’s position and velocity and situation (i.e. attack, defence, etc...). Theplayer type defines the player’s strategic characteristics like ball attraction, admissible re-gions in the field, specific positional characteristics for some regions in the field, tendency tostay behind the ball, alignment in the offside line, and attraction by specific points in thefield in some situations. Using a strategic positioning like SBSP the players will be morewell distributed over the field than using a active one like SPAR, which is the reason whyother teams adopted SBSP as the standard positioning method.
The CAMBADA coordination [Lau et al., 2008] is based in SBSP (Situation Based Strate-gic Positioning) [Reis et al., 2001, Lau and Reis, 2002] strategies used in RoboCup 2D Sim-ulation League, adapted to the MSL specifications.
2.5 Setplays
Setplays are to be understood as multi-agent small plans that need the commitment of severalplayers in order to reach a common goal. Setplays are very common in most sports, e.g.,soccer, rugby, handball, etc, which can make one believe that such constructs can also playa useful role in robotic soccer.
The concept of Setplay is present in a teamwork and communication strategy for the2D simulation league, presented by [Stone and Veloso, 1999]. These Setplays, however, lacksome of the most relevant features now presented. Namely, they are meant to be used onlyin very specific situations, like corner kicks and throw-ins, which are decided by the referee,and are unique for each of these situations. Thus, the question of Setplay activation andchoice is not considered. Further, there is no mention to Parameters, though Player Roles areproposed. Most important, a Setplay is limited to a sequence of Steps, without alternatives,which excludes the need of choice announcing, and therefore the use of communication with
11
this purpose.[McMillen and Veloso, 2006] introduced a strategy for role assignment in the four-legged
league. This strategy implies the communication of the currently chosen Play, which providesa set of Roles to be assigned to all the available players in the team. The strategy assuresco-ordination by the existence of a leader that selects the best momentary Play and instructsthe other robots on what Roles to take. Each Role fully determines the player’s behaviour.The strategy does not, however, define a concept of Setplay with intermediary states, andPlays do not have Parameters. Plays are a more limited concept than Setplays, since theymerely aim at distributing roles among all the teams players. It is therefore more of acoordination methodology than cooperation with actual plans, as is the case with Setplays.
The RFC Stuttgart/CoPS team uses Special Interaction Nets [Zweigle et al., 2006], asimplified version of Interaction Nets adapted to cooperation in multi-agent environments.These diagrams include states, representing actions, transitions, which model conditions,eventually global, and sub-nets, with the former components. Certain conditions can modeltime-dependent issues, and can be used to synchronise multi-agent behaviour. Messages canalso be used to synchronise multiple networks. The model does not present a standard setof concepts, which does not enforce generalisation and may lead to the developing of veryspecific cooperative strategies. This team uses dynamic role assignment[Zweigle et al., 2008],with sub-roles, e.g., role Defender and sub-role Left or Right. The role allocation is donelocally by every robot, based on the shared world model, that integrates information fromall robots. This being the case, inconsistencies are minimised, since all robots decide basedon the same information. Role allocation will be potentially wrong only when the sharedworld model is inconsistent.
XABSL is a language to describe behaviors for autonomous agents based on hierarchicalfinite state machines, and has been used by different teams in RoboCup, namely the GermanTeam [Rofer et al., 2006]. Recent developments [Risler and von Stryk, 2008] have allowedthe use of the language to develop cooperative multi agent behaviour, through synchronisa-tion elements, that allow the specification of minimum or maximum number of robots is agiven state.
An interesting approach is presented in [Castelpietra et al., 2002], where Setplays arerepresented as transition graphs. These plans, which are formally defined, have a high levelof abstraction, and can be applied to different robotic platforms, as it has been the case withmiddle-size and 4-legged robots. The actual execution of plans and how the robots deal withsynchronisation issues are unclear topics. In a related research effort [Iocchi et al., 2007],Petri Nets have been used to structure the development of a joint team with robots fromtwo distinct institutions.
A formal proposal for the usage of UML Statecharts to specify single and multi-agentbehaviour was introduced in [Murray, 2004]. This approach is developed and refined in[Furbach et al., 2008], but lacks practical implementation and is not sufficiently clear aboutsynchronisation mechanisms. Further, the underlying statecharts are considerably dense,and therefore difficult to read. This approach could not easily be used by non-IT specialists.
[Rad et al., 2004] use a tree of plan sequences to choose the best suited plan in each
12
situation. This tree must permanently be re-evaluated. The mechanism for synchronisation,a vital issue, is not clearly described.
TechUnited [Aangenent et al., 2009] team has recently switched from static to dynamicassignment of roles, which is done centrally by a dedicated module, based on world-state,namely player and ball positions.
The Brainstormers Tribots [Lange et al., 2008] have their roles, and the team formation,decided centrally by a dedicated, high-level module. The closest robot to the ball acts as amaster and decides which play to use.
2.5.1 Setplay selection and activation
One relevant task for the successful application of the framework is the selection of Setplaysduring the game, and therefore possible tools with this purpose must be considered.
Case-based reasoning (CBR) is a technique to solve new problems based on the solutionto known, similar situations in the past [Aamodt and Plaza, 1994]. Typically, a CBR systemhas a large case base, with knowledge about past situation. When a new problem is presented,the case base is searched for a similar case (case retrieval). The solution to the retrievedcase is then adapted to the new problem at hand, and applied. This application can at thispoint be evaluated and also inserted in the case base, for later usage, generating new casesfor future selection and adaptation. Case-based Reasoning has had several applications inRoboCup, but is not yet a very popular research topic. The most significant results will belooked at in the next paragraphs.
[Karol et al., 2004] present a formal approach to classification and evaluation of plans.Unfortunately, this approach remains purely theoretical, since it has never been implementedin a real system.
An application of Case-based Reasoning techniques to the legged league has been pre-sented in [Ros et al., 2006, Ros et al., 2007, Ros and Veloso, 2007]. A single agent is respon-sible for retrieving the most suited case and advertising its choice to the team-mates, whowill perform the sequence of actions in the plan. This approach still lacks testing in realgame situations.
A different usage of CBR is presented in [Wendler and Bach, 2004], where behaviourswhen manipulating the ball are analysed and predicted. In this case, the results can be usedto better predict the opponent’s behaviour. [Lattner et al., 2006] aim at extracting smallinteraction between players from game logs. The extracted interactions are, though, notevaluated nor used in real situations.
[Berger and Lammel, 2007] try to use CBR to activate co-operative behaviours, in thiscase involving two players. The experimental results showed that this application was rea-sonably unsuccessful.
In the approach presented in [Bowling et al., 2004], the success of Plays is recorded, inorder to help the choice of these Plays in future execution opportunities. This evaluationcan rapidly change, even during one game, to cope with Plays that ceased to be effectivedue to practical reasons like not being adapted to a specific team, or opponent adaptationto the Play.
13
2.6 Summary
Although many approaches to co-operative robotics exist in the context of RoboCup, only afew teams include high-level concepts general enough to be useful for more than one league.
There has been no general, abstract proposal for Setplay-based cooperation that wouldbe applied to the domain as a whole, which is the main scientific contribution of the presentwork. This thesis’ project approach differs from all the known approaches, since it has thelong term intention of being used in all RoboCup leagues with the same agent-based software.Furthermore, it also aims at integrating robots with different origins in its teams.
14
Chapter 3
Objectives
The main objective of this thesis is to develop a general-purpose framework for the appli-cation of Setplays, small multi-player plans in the robotic soccer domain, to any league inRoboCup.
Setplays should be high-level, reusable plans, defined in a league-independent languageand with a text-based syntax that allows the quick and easy creation or modification of aSetplay.
This framework should be as modular as possible, offering tools that allows its easyapplication to any league without any change in the framework. Such tools include:
Setplay parser a parser to read the text syntax of Setplays;
Selection of players algorithms to select the participating players in a Setplay combiningSetplay positionings and actual player positions;
Setplay evaluation and selection algorithms to evaluate and record the performance ofindividual Setplays, as a basis for real-time selection of Setplays in actual situations;
Graphical editor an editing tool to configure Setplays in a graphical environment, whichshould allow general users and field specialists to provide Setplay-definitions to theFramework;
Setplay execution engine an easy-to-use mechanism to manage the execution of Setplays;
Communication management Setplay execution makes use of the communication be-tween players and the framework must provide tools for its management.
To test the application of the framework and prove the validity of the underlying concepts,the framework will be applied to several teams: in 2D and 3D simulated soccer, and to theMiddle-Size League, in a simulated environment and with actual robots.
15
Chapter 4
Detailed Description
This section makes a thorough description of the content of the thesis and the related work.In section 4.1, a scenario that inspired the design of the Setplay framework is described, high-lighting the most relevant challenges. Section 4.2 describes the data model of the framework,while the communication protocol is described in section 4.3. The language underlying theframework is presented in section 4.4. Section 4.5 presents a complete example of the usageof the Setplay framework. Finally, section 4.6 presents the already developed components,while in 4.7 one can find a description of the tasks to be done to complete the thesis.
4.1 Motivating Scenario
The 5dpo1 middle-size team has its’ collective behaviour organised around so-called Setplays[Moreira et al., 2006]. Such Setplays are dynamically used in particular situations duringthe game. An example is used for the execution of free-kicks near the opposite goal: threeplayers are involved. The Initiator is responsible to start the Setplay by passing the ballto the Kicker, which is located half a meter to the right of the ball. A third player, theSupporter, will be located behind the ball, in order to deal with lost or stray balls. TheSetplay starts when the Initiator passes the ball to the Kicker, which tries to shoot at goal.This Setplay was fine-tuned and became a very successful collective move.
The concept of Setplay, as described, is used to structure the team’s behaviour. Butwhat if this kind of collective move could be described and shared in a standard, league-independent and flexible way, which would be interpreted and executed at run-time? Thefirst benefit would be the possibility of writing arbitrary Setplays, which would dynamicallybe used during the game, opening horizons to new plays which could, for instance, differ fromgame to game, to better deal with each opponents’ characteristics. In that case, the Setplayscould also be used in different leagues. Furthermore, since any player could have access tothe definition of Setplays and interpret their content, Setplays could also be a means forthe creation of mixed teams, where heterogeneous robots would play together: when the
1URI: http://paginas.fe.up.pt/∼robosoc/
16
name: StringSetPlay
order: NonNegIntwaitTime: MilisecondsabortTime: Miliseconds
Step
name: StringParameter
*1
*
1
PlayerReference
players
*
1
Condition
priority: DecimalTransition
Action
* 1
*1
Variable
roleName: StringPlayerRole
team: Stringnumber: PosInt
Player
*10..1
1
participants
11 next
Decimal
VarRegion
Participation1 *1 player
*
1 at
Region
*
0..1
Finish Abort
NextStep
Integer
abortCond
Directive
*1
Do Dont
Figure 4.1: Setplay definition
Setplays are being executed, players simply have to follow the steps in the Setplay in orderto co-operate.
To fulfil these requirements, one needs a standard language, where Setplays could bedefined and interpreted by any player in any league. The basic concepts of soccer (moves,conditions, skills) need a clear and concrete definition. Also, the transitions between in-termediary steps have to be expressed, as well as termination conditions. Such a languageis thus the scientific subject being tackled in this thesis. The framework that models thislanguage is presented in detail in this section.
Another motivating scenario, describing the interaction of heterogeneous players fromtwo different teams, can be found in [Mota et al., 2006].
4.2 Framework Description
The Setplay framework[Mota and Reis, 2007b], inspired by the motivating scenario and thechallenges it creates, was designed with the goal of being general, flexible, parameterizeableand applicable to any robotic soccer league. Its’ general structure is shown schematically inFigure 4.1.
At the top level, a Setplay is identified by a name, and has parameters, which can besimple data types like integers and decimals, or more sophisticated concepts as points andregions. Setplays also have Player References, which identify players taking part in the Set-
17
play. The Player References can point to specific players, or be Player Roles, i.e., abstractrepresentations of a particular role in the Setplay, identified by a name (e.g., attacker, sup-porter). Parameters and Player Roles will be instantiated at run-time, allowing a flexibleuse of the Setplay. There is also an Abort Condition which, when met at any moment duringexecution, implies the Setplay should be aborted.
Steps are the main building blocks of a Setplay, which contains an arbitrary numberof these, gathered in a list. A Step can be seen as a state in the execution of a Setplay.By convention, the first Step in a Setplay is always labelled with 0 as its’ id. The playersparticipating in a Setplay will follow some, or all, of these Steps in order to accomplish thesuccessful execution of the Setplay.
A Step has an id, which is a non-negative integer. In order to control the Step’s execution,the concepts of wait time and abort time are introduced. Wait time is the amount of timethe player should wait, after entering the Step, before starting the transition to another Step,or simply finishing the Setplay. The abort time is the threshold after which the players willabandon the Setplay, if it was not possible to progress from this Step to another one. A Stepalso has a Condition, which must be satisfied before entering the Step. A list of Participations,identifies the players taking part in the Step, with an optional location, which indicates thedesired positioning of the player in this Step.
There are several possible ways out of a Step, which are defined as Transitions. AllTransitions can have a Condition, which must be satisfied for the Transition to be followed.An Abort Transition represents a situation where the Setplay must be abandoned, eitherbecause it is no longer judged useful, or it is thought that it will not reach its’ goal. TheFinish Transition represents that the Setplay has reached its’ intended goal and should stopat this point. The main Transition, that is used to link between the different Steps is definedas NextStep. It includes the id of the next Step to be reached, and contains a list of Directivesthat will be applied in order to accomplish the Transition.
Directives include Actions and can be of two kinds: Do and Don’t, meaning respectivelythat the contained Actions should, or should not, be executed. In this context, Actions,depicted in Figure 4.2, are high-level concepts that represent skills and moves, both simpleand complex, that can be executed by a player. Examples of such Actions are passingthe ball to a player or region, shooting at goal, intercepting the ball, or dribbling. Inthis Setplay framework, the Action concepts were inspired by the ones defined by Clang[Chen et al., 2003], the coaching language used in the simulation league. There is, however,one added Action which is absent from this language: the concept of Action Sequence, whereseveral actions are to be executed following a particular order.
The concept of Condition, already mentioned before, plays also a central role, and isdepicted as an UML diagram in fig. 4.3. Such Conditions have a wide field of application,and deal with the whole domain of robotic soccer. Similarly to the Actions, the majority ofthe Conditions in this framework were inspired in Clang. Examples of such Conditions areplayers and ball being in particular positions or regions, ball ownership and play mode. Inthis case, however, several new Conditions had to be introduced, in order to model comple-mentary situations. Particularly, some Conditions refer to the possibility of accomplishing
18
Pass
Shoot
Forward
Position
Dribble
Region
1
1
1
1
1
1
PlayerReference
1..*
1
MarkRegion
1
1
MarkPlayer
1
1
Clear 11
InterceptHold
MarkLineTo1..*1
Tackle
1..*
1
to
to
to
ActionSequence
2..*
1
Action
WithBallWithoutBall
AttentionTo
AttentionTo
1
to
Object
1to
Stop
MarkGoal
ReceiveBall
Figure 4.2: Action definition
passes and shots, i.e., modelling the success of passes to players and regions, and shots atgoal. One should pay special attention to this kind of Conditions : they are not based on averifiable state-of-the world, but instead are an estimation of a success rate. This could beconsidered as intrinsically different from Conditions like player position, which are tangibleand verifiable. Even these Conditions are, in the scope of robotic soccer, also somehowan estimation: the players do not know the real state-of-the-world, they simply have theirown view, built from own observation and information shared by other team-mates. There-fore, for the sake of simplicity and expressiveness, all these concepts are indistinguishablyconsidered Conditions.
Regions are another concept in the core of the definition of Setplay, and are depicted inthe diagram in Figure 4.4. Once again, these concepts originate from Clang, including spatialentities like points, Triangles, Arcs and Rectangles. Similarly, the concept of Dynamic Point,referring to the location of a player or of the ball, is also introduced. Named regions areintroduced to model intuitive locations like ’our mid-field’ or ’their penalty box’, as definedin [Reis and Lau, 2002].
19
PlayerReference
confirmable: BooleanCondition
min:PosIntmax:PosInt
Position
player1
1..*
Region1
1
BallPossession
player
1
1
ClearPass
from
1
1
ClearPassToRegion
to
1
1..*
ClearPassToPlayer
to
1
1..*
And
Or
*
1
Not
1
1
*
1
PlayMode
ClearShotAtGoal
Figure 4.3: Condition definition
4.3 Inter-robot Communication
The major issue in this framework was how to achieve co-ordination between the robotswhen executing a Setplay. Naturally, a complex Setplay must follow several steps, and allparticipating players must be tightly synchronised in order to achieve fruitful co-operation.The first step towards this objective was to define a communication and synchronisationpolicy, which should be as straightforward as possible, and can be seen in Figure 4.5.
Each step will be led by the so-called lead player, which takes the most important de-cisions. This player, which is eventually not fixed throughout the Setplay, and can changefrom step to step, will monitor the execution of the Setplay, instructing the other players onSetplay begin, step entry and transition choice. The entry into a new step, which is decidedby the lead player in charge of the previous step, possibly implies the change of the leadplayer.
20
Figure 4.4: Region definition
4.4 Setplay Language
The sintax of the Setplay definition language, written as a set of BNF statements, is includedbellow.
# Some highlights
# - All references to players are done by PLAYER_REFERENCE
# - A new region type was added: NAMED_REGION
# - New conditions: canPassPl, canPassReg, canShoot
# - New actions: receiveBall, attentionTo(object or region), seq
# - All operators (+, -, *, /, ==, !=, <, <=, >, >=) are prefix
# - Arguments have added labels (like :label)
21
LeadPlayer: Player
alternative
participant1: Player
startSetplay(parameters)
abort
participantN: Player
startSetplay(parameters)
abort
finish
finish
nextStep(ID)
nextStep(ID)
stepChange(ID)
stepChange(ID)
Figure 4.5: Setplay interaction scheme
# - All lists are built through the s-expression (list <args>)
# Syntax:
# ?: 0 or 1
# *: any amount
# +: 1 or more
<SETPLAY>: (setplay <PARAMETER_DEFINITION_LIST>?
<PLAYER_REFERENCE_DEFINITION_LIST>
:abortCond <CONDITION> <STEP_LIST>)
<PARAMETER_DEFINITION_LIST>: :parameters (list <PARAMETER_DEFINITION>+)
<PARAMETER_DEFINITION>: (parameter :name <VAR> :type <TYPE>)
<TYPE>: integer | decimal | region | point
<PLAYER_REFERENCE_DEFINITION_LIST>:
22
:players (list <PLAYER_REFERENCE_DEFINITION>+)
<PLAYER_REFERENCE_DEFINITION>: (playerRole :name <VAR>)
| (player :team <TEAM> :number <PLAYER_NUM>)
<TEAM>: our | opp
<PLAYER_NUM>: [0-9] | 10 | 11
<STEP>: (step :order <NON_NEG_INTEGER>
:waitTime <NON_NEG_INTEGER>
:abortTime <NON_NEG_INTEGER>
:participants <PARTICIPATION_LIST>
:condition <CONDITION>
:transitions <TRANSITION_LIST>)
<PARTICIPATION_LIST>: (list <PARTICIPATION>+)
<PARTICIPATION>: <PLAYER_REFERENCE_DEFINITION>
| (at <PLAYER_REFERENCE> <REGION>)
<STEP_LIST>: (list <STEP>+ )
<TRANSITION_LIST>: (list <TRANSITION>+ )
| <TRANSITION>
<TRANSITION>: <NEXT_STEP> | <FINISH> | <ABORT>
<NEXT_STEP>: (nextStep :nextStepNumber <NON_NEG_INTEGER>
:condition <CONDITION>
:directives <DIRECTIVE_LIST>)
< FINISH >: (finish :condition <CONDITION>
:directives <DIRECTIVE_LIST>)
< ABORT >: (abort :condition <CONDITION>
:directives <DIRECTIVE_LIST>)
<ACTION> : (pos :region <REGION>)
| (bto :region <REGION>)
| (bto :players <PLAYER_REFERENCE_LIST>)
| (mark :players <PLAYER_REFERENCE_LIST>)
23
| (markl :players <PLAYER_REFERENCE_LIST>)
| (markl :region <REGION>)
| (markGoal)
| (oline :region <REGION>)
| (clear :region <REGION>)
| (hold)
| (dribble :region <REGION>)
| (shoot)
| (tackle :players <PLAYER_REFERENCE_LIST>)
| (intercept)
| (receiveBall)
| (stop)
| (attentionTo :region <REGION>)
| (attentionTo :object <OBJECT_LIST>)
| (htype <INTEGER>)
| (seq <ACTION>+)
<ACTION_LIST> : (list <ACTION>+ ) | <ACTION>
<OBJECT_LIST>: (list <OBJECT>+) | <OBJECT>
<OBJECT>: <STATIC_OBJECT> | <MOBILE_OBJECT>
<STATIC_OBJECT>: <POST> | <FLAG> | ...
<MOBILE_OBJECT>: <BALL> | <PLAYER_REFERENCE>
<CONDITION> : (true)
| (false)
| (ppos :players <PLAYER_REFERENCE_LIST> :min <INTEGER>
:max <INTEGER> :region <REGION>)
| (bpos :region <REGION>)
| (bowner :players <PLAYER_REFERENCE_LIST>)
| (playm <PLAY_MODE>)
| (canShoot :players <PLAYER_REFERENCE_LIST>)
| (canPassPl :from <PLAYER_REFERENCE_LIST>
:to <PLAYER_REFERENCE_LIST>)
| (canPassReg :from <PLAYER_REFERENCE_LIST>
:to <REGION>)
| (and <CONDITION_LIST>)
| (or <CONDITION_LIST>)
24
| (not <CONDITION>)
| (<COND_COMP>)
<COND_COMP> : <TIME_COMP>
| <OPP_GOAL_COMP>
| <OUR_GOAL_COMP>
| <GOAL_DIFF_COMP>
<TIME_COMP> : (time <COMP> <INTEGER>)
<OPP_GOAL_COMP> : (opp_goals <COMP> <INTEGER>)
<OUR_GOAL_COMP> : (our_goals <COMP> <INTEGER>)
| <COMP> <INTEGER> our_goals
<GOAL_DIFF_COMP> : (goal_diff <COMP> <INTEGER>)
<COMP> : < | <= | == | != | >= | >
<PLAY_MODE> : bko | time_over | play_on | ko_our | ko_opp
| ki_our | ki_opp | fk_our | fk_opp
| ck_our | ck_opp | gk_opp | gk_our
| gc_our | gc_opp | ag_opp | ag_our
<CONDITION_LIST> : (list <CONDITION>+ )
<DIRECTIVE> :
(do|dont :players <PLAYER_REFERENCE_LIST>
:actions <ACTION_LIST>)
<DIRECTIVE_LIST> : (list <DIRECTIVE>+)
<REGION> : <VAR>
| (regVar :name <CLANG_STR> )
| (regVar :name <CLANG_STR> :value <REGION>)
| <POINT>
| (regNamed :name <REGION_NAME>)
| (arc :center <POINT> :radius_small <REAL> :radius_large <REAL>
:angle_begin <REAL> :angle_span <REAL>)
| (triang :points (list <POINT> <POINT> <POINT>))
| (rec :points (list <POINT> <POINT>))
25
<REGION_NAME>: field | outside | our_middle_field | their_middle_field |
our_leftwing | our_middle | our_rightwing | our_penalty_box |
our_leftwing_back | our_leftwing_middle | our_leftwing_front |
our_rightwing_back | our_rightwing_middle | our_rightwing_front |
our_middle_back | our_middle_front | our_middle_back_right |
our_middle_back_left | our_middle_front_right |
our_middle_front_left | our_left_box | our_center_box |
our_goalie_area | our_right_box | our_goal_left | our_goal_center |
our_goal_right | defensive_third | middle_third | attacking_third |
their_leftwing | their_middle | their_rightwing |
their_penalty_box | their_leftwing_back | their_leftwing_middle |
their_leftwing_front | their_rightwing_back | their_rightwing_middle |
their_rightwing_front | their_middle_back | their_middle_front |
their_middle_back_right | their_middle_back_left |
their_middle_front_right | their_middle_front_left | their_left_box |
their_center_box | their_goalie_area | their_right_box |
their_goal_left | their_goal_center | their_goal_right
<POINT> : <VAR>
| (ptVar :name <CLANG_STR> )
| (ptVar :name <CLANG_STR> :value <POINT> )
| (pt :x <REAL> :y <REAL>)
| (pt ball)
| (pt :player <PLAYER_REFERENCE>)
| (ptRel :x <REAL> :y <REAL> :pt <POINT>)
| (<POINT_ARITH>)
<POINT_ARITH> : (<OP> <POINT> <POINT>)
<OP> : + | - | * | /
<REGION_LIST> : (list <REGION>+)
<PLAYER_REFERENCE_LIST> : (list < PLAYER_REFERENCE>+ )
<PLAYER_REFERENCE>: <VAR>
| (player :team <TEAM> :number <PLAYER_NUM>)
<CLANG_STR> : "[0-9A-Za-z\(\)\.\+\-\*\/\?\<\>\_ ]+"
<VAR> : [A-Z]+[a-zA-Z0-9_]*
26
4.5 Example Setplay
In this section, a simple example is presented, to illustrate the actual definition of Setplays,how the players in the 2D simulation league deal with it, and how inter-robot communicationis deployed.
A situation where a Setplay can be properly used is the corner-kick: it is an offensivesituation close to the opponent goal and holes in the defense can be exploited. To keep thisexample clear, a simple situation, with only three participants and no opponents, will bedescribed. The Setplay initiator triggers execution, after choosing the participating playersfrom their distance to the positions in the setplay, by sending a instantiation message, whereS0 identifies the chosen Setplay with number 0, representing its position in the Setplayconfiguration file. In this case, the lead player is nr. 10 (taking role cornerP), and the twoother participants nrs. 7 and 11 (roles receiver and shooter), thus the message sent is asfollows:
<S0 10 7 11>
In step 0 of the Setplay, the participating players reach their positions, after which thecornerP tries to reach step 1, passing the ball to the receiver, as depicted in fig. 4.6(a).Upon gaining possession of the ball, receiver starts being the new lead player and thereforesends a message to the other players, informing them that the Setplay is currently in step 1,and that the receiver will try to reach step 2, as follows:
<1 2>
When the receiver verifies that it can make a pass to the shooter, it will do so, as depictedin fig. 4.6(b). In this figure, the receiver is looking at the shooter in order to accomplish agood pass, as it was the case in the precedent image.
Finally, as soon as it considers that shooting at goal is possible, the shooter executes theshot (see fig. 4.6(c)) and moves to step 3, which simply finishes the Setplay. At this moment,the shooter will send a message stating that it reached step 3, and that there is no furtherstep in the Setplay:
<3 -1>
The described Setplay was defined in a configuration file, read upon player startup, asseen in fig. 4.7.
4.6 Completed Development
4.6.1 Implementation of a C++ library
The Setplay framework was, from the beginning, intended to be applicable to different teamsand leagues: it should be possible to mix players from different originating teams in onesingle, mixed team, while executing Setplays, and, further, the framework should be appliedin different leagues.
27
(a) (b) (c)
Figure 4.6: Corner Setplay execution steps.
Since the initial implementation and testing were planned to be conducted on top ofthe FCPortugal and CAMBADA teams, both implemented using C++, it was decided todevelop a C++ library, with two goals: ease the implementation in these teams, or any otherimplemented in C++; and maintain a common, stable framework that would be applied toany team.
This implementation intended to provide as much tools as possible, and therefore thefollowing three features were developed:
Setplay definition parser Since setplays can freely be defined using the model describedin the last section, or edited using a separate graphical tool, it was obviously necessaryto develop a parser to load files and convert them to C++ objects. This parser wasdeveloped using the Spirit library included in the latest Boost 2 distributions.
Setplay participants selection An algorithm to select the players participants, accordingto their distance to the Setplay initial positions, has been developed.
Setplay execution engine A Setplay execution is almost trivially determined by its def-inition and real-time instantiation. Therefore, the framework provides an executionengine to be easily used, out-of-the-box.
With these tools, and the Setplay evaluation and selection mechanism described in section4.7.2, a team using the framework does not have to worry about the execution of a Setplay:
2http://www.boost.org/
28
(setplay :name simpleCorner
:players (list (playerRole :roleName cornerP)
(playerRole :roleName receiver) (playerRole :roleName shooter))
:steps
(seq (step :id 0 :waitTime 15 :abortTime 70
:participants (list (at cornerP (pt :x 52 :y 34))
(at receiver (pt :x 40 :y 25))(at shooter (pt :x 36 :y 2)))
:condition (playm ck_our) :leadPlayer cornerP
:transitions (list
(nextStep :id 1
:condition (canPassPl :from cornerP :to receiver)
:directives (list
(do :players cornerP :actions (bto :players receiver))
(do :players receiver :actions (intercept))))))
(step :id 1 :waitTime 5 :abortTime 70
:participants (list (at cornerP (pt :x 52 :y 34))
(at receiver (pt :x 40 :y 25))(at shooter (pt :x 36 :y 2)))
:condition (and (bowner :players receiver) (playm play_on))
:leadPlayer receiver
:transitions (list
(nextStep :id 2
:condition (canPassPl :from receiver :to shooter)
:directives (list
(do :players receiver :actions (bto :players shooter))
(do :players shooter:actions (intercept))))))
(step :id 2 :abortTime 70
:participants (list (at cornerP (pt :x 52 :y 34))
(at receiver (pt :x 40 :y 25)) (at shooter (pt :x 36 :y 2)))
:condition (and (bowner :players shooter) (playm play_on) )
:leadPlayer shooter
:transitions (list
(finish :condition (canShoot :players shooter)
:directives (do :players shooter :actions (shoot)))))))
Figure 4.7: Corner Setplay definition
it has to define the domain specific actions and conditions (see next section), and create thenecessary Setplays, eventually using the graphical editor PlayMaker.
In order to be able to implement all the necessary actions and conditions, a team will haveto be able to do the following, which can be considered a check-list before implementation:
Implement actions The team must be able to execute skills like kicks, passes to regions
29
and shots, as well as movements to points and marking of opponents and regions, andball reception and interceptions.
Implement conditions Concepts like ball and player positions, game state (mode, scoreand time) and evaluation of pass and shot success must be modelled by the team.
Communication The lead player, that can be set to be a fixed player like the coach, mustbe able to send simple text messages to the other players. This communication can beuni-directional.
4.6.2 Implementation in the 3D Simulation League
As a primary testbed for the Setplays, the code of the 2006 champion in the 3D simulationleague, FC Portugal [Lau and Reis, 2006], was used. This code already had the main buildingblocks for the implementation of Setplays.
Conditions and Actions were implemented based on the existing code dealing with world-state, skills and actions.
The rules and organisation for this competition were largely changed from RoboCup 2007on. Since the new robots were initially investigating low-level questions like movement andkicking, there was temporarily no place for high-level concepts like Setplays. The develop-ment in this league was thus suspended and will be picked up again when these skills arebetter developed, which will happen in the near future.
4.6.3 Implementation in the 2D Simulation League
The 2D simulation league is the most developed, in terms of game flow and high-level coop-eration. FCPortugal has been participating in this league since 2000, with very competitiveresults, including several titles, namely World Champions. This code had several featuresavailable: a mature state-of-the-world, which considers both own observations and infor-mation shared by other players, and which includes prediction of actions’ and interactions’effects; and a set of actions and skills that allows the mapping of actions as defined in theSetplay framework to concrete executions in the 2D simulator. This implementation will bepresented in [Mota et al., 2010].
This implementation was achieved after following several steps. First, the Setplay usagescenario was chosen: in the current level of play, it was considered interesting to use Setplaysmainly in situations like corners, kick-ins and free-kicks, since these situations are clearlyannounced by the server, and thus all players can prepare to participate in the Setplay.
Secondly, Conditions and Actions as defined in the framework were implemented basedon the existing code dealing with world-state, skills and action.
Finally, the message exchange needed for the execution of Setplays was implemented, asdiscussed in section 4.6.3.
30
Inter-robot Communication
The major challenge in this implementation was how to deal with the limited communicationmeans allowed by the server. To cope with the restrained, single-channel communication, thelead player, in this case the player with ball possession, will be the only player allowed to sendmessages. The content of communication must be as concise as possible, in order to followthe 2D simulator’s limitations (messages under 10 bytes in length, only one message per teamand cycle) and to leave enough place for the sharing of world-state information, necessaryfor the maintenance of a satisfactory and up-to-date world model by all players. In orderto comply with these limitations, it was chosen to only use Setplays without arguments,since these would use much space in the startup messages (as explained in section 4.3).The Setplay startup message does therefore only have the participating player numbers asarguments.
4.6.4 Implementation in the Middle Size League - Simulation
After successfully having implemented the framework’s usage in the 2D Simulation league,it was decided to use it in a real-world environment, the Middle-Size League. This league’sdevelopment in recent years has seen the leading teams’ effort to enhance the high-levelperformance, through team level coordination and cooperation schemes, as seen in section 2.Namely, team CAMBADA has developed configurable team-play for set pieces. It was thusconsidered timely to take this kind of team-play one level higher: fully integrate the Setplayframework.
Development was, in a first moment, conducted in a simulated environment: CAMBADAhas developed a full-blown simulator to ease the development process and avoid the constantuse of the robots. The simulator fully emulates the robots’ low-level functions (perceptorsand actuators), and hence the high-level software can be directly applied to the robots, withonly minor inconsistencies. Development in the simulated environment is quite straight-forward, and, after implementing the abstract Conditions and Actions, the robots werequickly executing Setplays. Special attention was given to passes between players: thecanPassPl Condition has to assure that both players involved are well aligned, or else thepass will frequently fail, since the ball catching capabilities of the robots are very limited.
Setplay instantiation and startup is taken care of by the team coach, which has access tothe team’s shared State-of-the-World (see further down for details). This intangible agent,that does not have to deal with low-level activities, has plenty computing power to managethe Setplay execution.
The integration of the framework in the CAMBADA team was perhaps more challengingthan in the 2D Simulation team, since the low-level perception and action mechanisms arefar more complex, and have to be more finely tuned, specially in the forthcoming testingwith the real robots.
31
Inter-robot Communication
Communication in the Middle-Size League is not subject to strict limitations: although therobots are fully autonomous, they can freely communicate through a wireless network usingstandard protocol 802.11. In championship settings, it is common that the network has hightraffic and is consequently over-loaded, but this situation is normally under control.
The CAMBADA team uses a black-board approach with a shared State-of-the-World.This architecture, called RTDB (Real Time Database) [Lau et al., 2008] has been used bothfor posting perception information and coordination flags in previous tackles at team-levelcoordination. The RTDB was therefore used for the posting of the Setplay messages by thecoach, since these can be read by all the team robots.
4.7 Uncompleted Objectives
4.7.1 Testing in the Middle-Size League - Real robots
After the full implementation in the simulated environment, that fully resembles the real-world setting, tests will be conducted with the real robots, to ascertain the quality of theimplementation. These tests, if successful, will lead to the integration of the Setplay frame-work in the CAMBADA team, in real competitions.
4.7.2 Mechanism for Setplay Evaluation and Selection
For the Setplay Framework to be as self-sufficient as possible, it should provide a way toconstantly evaluate and select Setplays at run-time. Such a mechanism can be very usefulfor the Framework’s deployment in teams with no or little expertise in this domain.
This mechanism should record the performance of each execution of every Setplay, inorder to collect data to evaluate this performance and, consequently, the usefulness of theSetplay. Such data should be examined and consolidated in order to better estimate theperformance if a Setplay in particular situations, and thus choose the most appropriate.
This mechanism will tentatively be implemented as a Case Based Reasoning (CBR)system. Each prior execution of a Setplay will be considered a case, building a case-base thatwill be searched, using typical techniques in the CBR domain, to choose the most appropriatesolution for the problem at hand. As variables for the evaluation of cases, the localisationof the case, the opponent and the success rate will surely be considered. Upon gaining someexperience with the initial implementation of the CBR system, new development lines canbe sought and applied.
4.7.3 Graphical Design of Setplays
As Setplays become more complex, involving more players and going through more steps,their textual representation will be more verbose and difficult to read and edit. On topof this, the edition of s-expressions can be confusing for users not acquainted with this
32
formalism. It would therefore be useful to graphically edit the Setplays with some graphicaltool, where players, actions and conditions could spatially be put in connection, with thetextual content as output.
In a co-operative effort involving the author of this thesis, such a tool has been developed:PlayMaker [Lopes, 2009]. This editors allows the accomplishment of the aforementionedtasks, outputting regular, textual Setplay-definition files, that can be directly read by theFramework. Several tests have already been performed to define Setplays for the 2D Sim-ulation implementation of the framework. Further, more complex tests will be performedwith other implementations of the Framework, in order to test the adaptation, suitabilityand performance of this graphical editor. Such test will result in an evaluation and, possibly,enhancements of the tool.
PlayMaker will ultimately be used as a interface of the Framework to potential users, whowill be asked to create new Setplays and evaluate them, and the Framework, upon observationof executions of the designed Setplays in actual, practical situations. This exposure of theFramework to actual users will provide very useful data for the general evaluation of theperformance of the Setplay system.
4.7.4 Evaluation of the Setplay Framework
The graphical editor will be presented as an interface to field experts in the domains ofrobotic and human soccer. These will be asked to design Setplays that will later be testedin the different implementations of the framework.
Experiments will focus on the comparison of the team behaviour in specific situations,where alternative executions with use of Setplays will be compared to situations with theSetplays framework inactive.
33
Chapter 5
Planning
The planning for the present thesis can be seen as a Gantt chart in fig. 5.1, and is describedin the remainder of this chapter.
5.1 Literature Review and Initial Study
Focussed on multi-agent systems, cooperative robotics, robotic platforms, communicationlanguages, co-ordination, agent architectures and hardware independent implementations.
5.2 Domain, Platforms and Base Code Study
Study of the robotic soccer domain and similar cooperative domains. Study of the roboticplatforms available at the two Universities and of the base code developed by the Universities.Design and selection of the application domains and selection of the source code to use as abasis for the framework.
5.3 Definition of the Setplay Architecture
Design of the framework architecture and related language. Definition of all inherent conceptsthrough textual description and UML diagrams.
5.4 Design of Language for Setplays
The Setplays were designed with the goal of being definable outside the scope of a singleteam or implementation. Therefore, there has to be a language to independently expressSetplays, compatible with the previously defined architecture.
34
Figure 5.1: Gantt Chart
35
5.5 Implementation of C++ library
To ease the integration of the Setplay framework in arbitrary teams, the framework wasmade available as an independent library, including tools for Setplay parsing and execution,namely to manage communication.
5.6 Implementation in the 3D Simulation League
Pilot implementation in the FCPortugal3D simulation team, 2006 world champion.
5.7 Implementation in the 2D Simulation League
Implementation in the FCPortugal2D simulation team.
5.8 Implementation in the Middle-Size League - Sim-
ulation
Implementation in the CAMBADA MSL team. As a starting point, the implementation wasdone on top of a recently developed simulator, that completely emulates the robot low-levelfunctions, allowing the use of the exact same high-level code.
5.9 Testing in the Middle-Size League - Real robots
Testing of the above mentioned implementation in the real robots.
5.10 Mechanism for Setplay Evaluation and Selection
A Case Based Reasoning based mechanism will be developed for the evaluation of Setplayexecution, and consequent selection in run-time.
5.11 Graphical Design of Setplays
Testing of the graphical editor of Setplays, PlayMaker, which will be presented to differentusers as an interface to the Setplay Framework.
36
5.12 Experiments and Result Analysis
Design and execution of controlled experiments using teams of agents performing complexcooperative tasks in the selected application domains, namely using the graphical editor asan interface to field experts in the domains of robotic and human soccer.
Experiments will focus on the comparison of the team behaviour in specific situations,where alternative executions with use of Setplays will be compared to situations with theSetplays framework inactive.
5.13 Ph.D. Thesis Writing
Writing of the Ph.D. thesis and preparation of the thesis presentation, finishing the workplan.
37
Bibliography
[Aamodt and Plaza, 1994] Aamodt, A. and Plaza, E. (1994). Case-based reasoning: Foun-dational issues, methodological variations, and system approaches. AI Communications,7(1):39–59.
[Aangenent et al., 2009] Aangenent, W., de Best, J., Bukkems, B., Kanters, F., Meessen,K., Willems, J., Merry, R., and v.d. Molengraft, M. (2009). TechUnited Eindhoven TeamDescription 2009. In Baltes, J., Lagoudakis, M. G., Naruse, T., and Shiry, S., editors,RoboCup 2009: Robot Soccer World Cup XIII - CD proceedings.
[Asada and Kitano, 1999] Asada, M. and Kitano, H., editors (1999). RoboCup-98: RobotSoccer World Cup II, volume 1604 of Lecture Notes in Artificial Intelligence. Springer.
[Baltes et al., 2010] Baltes, J., Lagoudakis, M. G., Naruse, T., and Shiry, S., editors (2010).RoboCup 2009: Robot Soccer World Cup XIII, volume 5949 of Lecture Notes in ComputerScience. Springer.
[Beaudry et al., 2006] Beaudry, J., Choquette, J., Fournier, P.-M., Larouche, L.-A., andSavard, F. (2006). Robofoot EPM team description – RoboCup2006 MiddleSize League.Technical report, Ecole Polytechnique de Montreal, Canada.
[Berger et al., 2004] Berger, R., Gollin, M., and Burkhard, H.-D. (2004). AT Humboldt 2004& AT Humboldt 3D team description. Technical report, Humboldt Universitat Berlin.
[Berger et al., 2006] Berger, R., Hein, D., and Burkhard, H.-D. (2006). AT Humboldt &AT Humboldt 3d team description 2006. In Lakemeyer, G., Sklar, E., Sorrenti, D., andTakahashi, T., editors, RoboCup-2006: Robot Soccer World Cup X - CD proceedings.Humboldt University of Berlin.
[Berger and Lammel, 2007] Berger, R. and Lammel, G. (2007). Exploiting past experience– case-based decision support for soccer agents. In KI 2007: Advances in Artificial Intel-ligence.
[Birk et al., 2002] Birk, A., Coradeschi, S., and S.Tadokoro, editors (2002). RoboCup-2001: Robot Soccer World Cup V, volume 2377 of Lecture Notes in Artificial Intelligence.Springer.
38
[Boedecker and Asada, 2008] Boedecker, J. and Asada, M. (2008). Simspark - concepts andapplication in the RoboCup 3D Soccer Simulation League. In SIMPAR-2008 Workshopon The Universe of RoboCup Simulators, Venice, Italy.
[Bowling et al., 2004] Bowling, M., Browning, B., and Veloso, M. (2004). Plays as effectivemultiagent plans enabling opponent-adaptive play selection. In Fourteenth InternationalConference on Automated Planning and Scheduling (ICAPS), pages 376–383.
[Bredenfeld et al., 2006] Bredenfeld, A., Jacoff, A., Noda, I., and Takahashi, Y., editors(2006). RoboCup-2005: Robot Soccer World Cup IX, volume 4020 of Lecture Notes inArtificial Intelligence. Springer.
[Castelpietra et al., 2002] Castelpietra, C., Guidotti, A., Iocchi, L., Nardi, D., and Rosati,R. (2002). Design and implementation of cognitive soccer robots. In Birk, A., Coradeschi,S., and S.Tadokoro, editors, RoboCup-2001: Robot Soccer World Cup V, volume 2377 ofLecture Notes in Artificial Intelligence. Springer.
[Castelpietra et al., 2001] Castelpietra, C., Iocchi, L., Nardi, D., Piaggio, M., Scalzo, A.,and Sgorbissa, A. (2001). Communication and coordination among heterogeneous mid-size players: Art99. In Stone, P., Balch, T., and Kraetzschmar, G., editors, RoboCup 2000:Robot Soccer World Cup IV, volume 2019. Springer.
[Chen et al., 2003] Chen, M., Foroughi, E., Heintz, F., Kapetanakis, S., Kostiadis, K.,Kummeneje, J., Noda, I., Obst, O., Riley, P., Steffens, T., Wang, Y., and Yin, X. (2003).Users manual: RoboCup soccer server manual for soccer server version 7.07 and later.
[Davin et al., 2005] Davin, J., Riley, P., and Veloso, M. (2005). CommLang: Communicationfor coachabe agents. In Nardi, D., Riedmiller, M., Sammut, C., and Santos-Victor, J.,editors, RoboCup-2004: Robot Soccer World Cup VIII, volume 3276.
[Farinelli et al., 2004] Farinelli, A., Grisetti, G., and Iocchi, L. (2004). SPQR-RDK: a mod-ular framework for programming mobile robots. In Nardi, D., Riedmiller, M., Sammut,C., and Santos-Victor, J., editors, RoboCup-2004 Symposium, volume 3276. Springer.
[Ferrein et al., 2006] Ferrein, A., Lakemeyer, G., and Schiffer, S. (2006). Allemaniacs 2006team description. Technical report, Knowledge-based Systems Group, Computer ScienceDepartment, RWTH Aachen University.
[Furbach et al., 2008] Furbach, U., Murray, J., Schmidsberger, F., and Stolzenburg, F.(2008). Model checking hybrid multiagent-systems for the robocup. In Visser, U., F.,R., Ohashi, T., and Dellaert, F., editors, RoboCup-2007: Robot Soccer World Cup XI,volume 5001. Springer.
[Gerkey and Mataric, 2004] Gerkey, B. P. and Mataric, M. J. (2004). On role allocation inrobocup. In Polani, D., Browning, B., Bonarini, A., and Yoshida, K., editors, RoboCup-2003: Robot Soccer World Cup VII, volume 3020. Springer Verlag.
39
[Hafner and Riedmiller, 2003] Hafner, R. and Riedmiller, M. (2003). Reinforcement learningon an omnidirectional mobile robot. In IEEE/RSJ IROS 2003 Workshop on Robotics forNanosciences and Nanotechnology.
[Heinemann et al., 2007a] Heinemann, P., Haase, J., , and Zell, A. (2007a). A novel approachto efficient monte-carlo localization in robocup. In Lakemeyer, G., Sklar, E., Sorrenti, D.,and Takahashi, T., editors, RoboCup-2006: Robot Soccer World Cup X, volume 4434.Springer.
[Heinemann et al., 2007b] Heinemann, P., Sehnke, F., Streichert, F., and Zell, A. (2007b).Towards a calibration-free robot: The act algorithm for automatic online color training. InLakemeyer, G., Sklar, E., Sorrenti, D., and Takahashi, T., editors, RoboCup-2006: RobotSoccer World Cup X, volume 4434. Springer.
[Iocchi et al., 2007] Iocchi, L., Marchetti, L., Nardi, D., Lima, P. U., Barbosa, M., Pereira,H., and Lopes, N. (2007). Spqr + isocrob robocup 2007 qualification report. Technicalreport, Sapienza Universita di Roma, Italy; Instituto Superior Tecnico.
[Iocchi et al., 2009] Iocchi, L., Matsubara, H., Weitzenfeld, A., and Zhou, C., editors (2009).RoboCup 2008: Robot Soccer World Cup XII, volume 5399 of Lecture Notes in ArtificialIntelligence. Springer.
[Iocchi and Nardi, 2000] Iocchi, L. and Nardi, D. (2000). Self-localization in the robocupenvironment. In Veloso, M., Pagello, E., and Kitano, H., editors, RoboCup-99: RobotSoccer World Cup III, volume 1856. Springer.
[Kaminka et al., 2003] Kaminka, G., Lima, P., and Rojas, R., editors (2003). RoboCup-2002: Robot Soccer World Cup VI, volume 2752 of Lecture Notes in Artificial Intelligence.Springer.
[Karol et al., 2004] Karol, A., Nebel, B., Stanton, C., and Williams, M.-A. (2004). Casebased game play in the RoboCup four-legged league part i the theoretical model. InPolani, D., Browning, B., Bonarini, A., and Yoshida, K., editors, RoboCup 2003: RobotSoccer World Cup VII, volume 3020. Springer.
[Kleiner and Buchheim, 2004] Kleiner, A. and Buchheim, T. (2004). A plugin-based archi-tecture for simulation in the F2000 league. In Polani, D., Browning, B., Bonarini, A., andYoshida, K., editors, RoboCup-2003: Robot Soccer World Cup VII, volume 3020. Springer.
[Kogler and Obst, 2004] Kogler, M. and Obst, O. (2004). Simulation league: The nextgeneration. In Polani, D., Browning, B., Bonarini, A., and Yoshida, K., editors, RoboCup2003: Robot Soccer World Cup VII, volume 3020 of Lecture Notes in Artificial Intelligence,pages 458–469. Springer.
[Kok et al., 2003] Kok, J., Spaan, M., and N.Vlassis (2003). Multi-robot decision makingusing coordination graphs. In 11th International Conference on Advanced Robotics (ICAR2003), pages 1124–1129.
40
[Kose et al., 2005] Kose, H., Kaplan, K., Tatlidede, C. M. U., and Akin, L. (2005). Market-driven multi-agent collaboration in robot soccer domain. In Cutting Edge Robotics, pages407–416. pIV pro literatur Verlag.
[Lafrenz et al., 2006] Lafrenz, R., Zweigle, O., Kappeler, U.-P., Rajaie, H., Tamke, A., Ruhr,T., Oubbati, M., Schanz, M., Schreiber, F., and Lev, P. (2006). Major scientific achieve-ments 2006 - cops stuttgart registering for world championships in bremen. Technicalreport, University of Stuttgart.
[Lakemeyer et al., 2007] Lakemeyer, G., Sklar, E., Sorrenti, D., and Takahashi, T., editors(2007). RoboCup-2006: Robot Soccer World Cup X, volume 4434 of Lecture Notes inArtificial Intelligence. Springer.
[Lange et al., 2008] Lange, S., Muller, C., and Welker, S. (2008). Tribots: Soccer Strategy.RoboCup Workshop Kassel 2008,http://www.ni.uos.de/fileadmin/user upload/tribots/Research/Kooperation.pdf. Lastvisited: 21 of July 2009.
[Lange and Riedmiller, 2005] Lange, S. and Riedmiller, M. (2005). Evolution of computervision subsystems in robot navigation and image classification tasks. In Nardi, D., Ried-miller, M., Sammut, C., and Santos-Victor, J., editors, RoboCup-2004: Robot Soccer WorldCup VIII, volume 3276. Springer.
[Lattner et al., 2006] Lattner, A. D., Miene, A., Visser, U., and Herzog, O. (2006). Sequen-tial pattern mining for situation and behavior prediction in simulated robotic soccer. InBredenfeld, A., Jacoff, A., Noda, I., and Takahashi, Y., editors, RoboCup 2005: RobotSoccer World Cup IX, volume 4020 of Lecture Notes in Artificial Intelligence. Springer.
[Lau et al., 2008] Lau, N., Lopes, L. S., and Corrente, G. (2008). CAMBADA: Informationsharing and team coordination. In Eighth Conference on Autonomous Robot Systems andCompetitions, pages 27–32, Aveiro, Portugal. Universidade de Aveiro.
[Lau et al., 2009] Lau, N., Lopes, L. S., Corrente, G., and Filipe, N. (2009). Multi-robotteam coordination through roles, positionings and coordinated procedures. In 2009IEEE/RSJ International Conference on Intelligent Robots and Systems - IROS 2009,,St. Louis, USA.
[Lau and Reis, 2002] Lau, N. and Reis, L. P. (2002). FC Portugal 2001 team description:Configurable strategy and flexible teamwork. In Birk, A., Coradeschi, S., and Tadokoro,S., editors, RoboCup-2001: Robot Soccer World Cup V, LNAI, Berlin. Springer Verlag.
[Lau and Reis, 2006] Lau, N. and Reis, L. P. (2006). Coordination methodologies devel-oped for FC Portugal 3D 2006 team. In RoboCup-2006: Robot Soccer World Cup X CDproceedings, Bremen, Germany.
41
[Lau and Reis, 2007] Lau, N. and Reis, L. P. (2007). FC Portugal - High-level Coordina-tionMethodologies in Soccer Robotics, page 598. ItechEducationandPublishing, Vienna,Austria.
[Lauer et al., 2006] Lauer, M., Lange, S., and Riedmiller, M. (2006). Calculating the perfectmatch: An efficient and accurate approach for robot self-localisation. In Bredenfeld, A.,Jacoff, A., Noda, I., and Takahashi, Y., editors, RoboCup-2005: Robot Soccer World CupIX, volume 4020 of Lecture Notes in Artificial Intelligence. Springer.
[Lopes, 2009] Lopes, R. (2009). Coordination methodologies applied to robocup: a graphicaldefinition of setplays. Master’s thesis, Faculdade de Engenharia da Universidade do Porto.
[Lotzsch et al., 2004] Lotzsch, M., Bach, J., Burkhard, H.-D., and Juengel, M. (2004). De-signing agent behavior with the extensible agent behavior specification language xabsl. InPolani, D., Browning, B., Bonarini, A., and Yoshida, K., editors, RoboCup 2003: RobotSoccer World Cup VII, volume 3020 of Lecture Notes in Artificial Intelligence, pages 114–124. Springer.
[Lovell and Estivill-Castro, 2005] Lovell, N. and Estivill-Castro, V. (2005). A descriptivelanguage for flexible and robust object recognition. In Nardi, D., Riedmiller, M., Sammut,C., and Santos-Victor, J., editors, RoboCup-2004: Robot Soccer World Cup VIII, volume3276 of Lecture Notes in Artificial Intelligence. Springer.
[Marques and Lima, 2001] Marques, C. and Lima, P. (2001). A localization method for asoccer robot using a vision-based omni-directional sensor. In Stone, P., Balch, T., andKraetzschmar, G., editors, RoboCup-2000: Robot Soccer World Cup IV, volume 2019 ofLecture Notes in Artificial Intelligence. Springer.
[McMillen and Veloso, 2006] McMillen, C. and Veloso, M. (2006). Distributed, play-basedrole assignment for robot teams in dynamic environments. In 8th International Symposiumon Distributed Autonomous Robotic Systems (DARS 2006), Minnesota, USA.
[Moreira et al., 2006] Moreira, A. P., Costa, P., Scolari, A., Sousa, A., and Marques, P.(2006). 5dpo-2000 team description for robocup 2006. Technical report, University ofPorto (UP).
[Mota and Reis, 2007a] Mota, L. and Reis, L. P. (2007a). An elementary communicationframework for open co-operative RoboCup soccer teams. In The Third InternationalWorkshop on Multi-Agent Robotic Systems (MARS 2007), at the 4th International Con-ference on Informatics in Control, Automation and Robotics - ICINCO 2007.
[Mota and Reis, 2007b] Mota, L. and Reis, L. P. (2007b). Setplays: Achieving coordinationby the appropriate use of arbitrary pre-defined flexible plans and inter-robot communica-tion. In Winfield, A. F. T. and Redi, J., editors, First International Conference on RobotCommunication and Coordination (ROBOCOMM 2007), volume 318 of ACM Interna-tional Conference Proceeding Series. IEEE.
42
[Mota and Reis, 2008] Mota, L. and Reis, L. P. (2008). A Common Framework for co-operative robotics: an open, fault tolerant architecture for multi-league RoboCup teams.In Carpin, S., Noda, I., Pagello, E., Reggiani, M., and von Stryk, O., editors, InternationalConference on Simulation, Modeling and Programming for Autonomous Robots (SIMPAR2008), volume 5325 of LNCS, pages 171–182. Springer.
[Mota et al., 2006] Mota, L., Reis, L. P., and Burkhard, H.-D. (2006). Communicationchallenges raised by open co-operative teams in RoboCup. In Encontro Cientıfico doFestival Nacional de Robotica.
[Mota et al., 2010] Mota, L., Reis, L. P., and Lau, N. (2010). Co-ordination in RoboCup’s2D Simulation League: Setplays as flexible, multi-robot plans. In IEEE InternationalConference on Robotics, Automation and Mechatronics (RAM 2010), to apperar.
[Murray, 2004] Murray, J. (2004). Specifying agent behaviors with uml statecharts andstatedit. In Polani, D., Browning, B., Bonarini, A., and Yoshida, K., editors, Robocup2003: Robot Soccer World Cup VII, volume 3010 of Lecture Notes in Artificial Intelligence.Springer.
[Nardi et al., 2005] Nardi, D., Riedmiller, M., Sammut, C., and Santos-Victor, J., editors(2005). RoboCup-2004: Robot Soccer World Cup VIII, volume 3276 of Lecture Notes inArtificial Intelligence. Springer.
[Noda et al., 1998] Noda, I., Matsubara, H., Hiraki, K., and Frank, I. (1998). Soccer server:A tool for research on multiagent systems. Applied Artificial Intelligence, 12(2–3):233–250.
[Parker, 1998] Parker, L. E. (1998). Alliance: an architecture for fault tolerant multirobotcooperation. IEEE Transactions on Robotics and Automation, 14(2):220–240.
[Polani et al., 2004] Polani, D., Browning, B., Bonarini, A., and Yoshida, K., editors (2004).RoboCup-2003: Robot Soccer World Cup VII, volume 3020 of Lecture Notes in ArtificialIntelligence. Springer.
[Rad et al., 2004] Rad, A. A., Qaragozlou, N., and Zaheri, M. (2004). Scenario-based team-working, how to learn, create, and teach complex plans? In Polani, D., Browning, B.,Bonarini, A., and Yoshida, K., editors, RoboCup 2003: Robot Soccer World Cup VII,volume 3020 of Lecture Notes in Artificial Intelligence. Springer.
[Ramos et al., 2007] Ramos, N., Barbosa, M., and Lima, P. (2007). Multi-robot systemsmiddleware applied to soccer robots. In ROBOTICA 2007 - 7th Portuguese RoboticsFestival.
[Reis and Lau, ] Reis, L. P. and Lau, N. FCPortugal home page,http://www.ieeta.pt/robocup.
43
[Reis and Lau, 2001] Reis, L. P. and Lau, N. (2001). FC Portugal team description: Robocup2000 simulation league champion. In Stone, P., Balch, T., and Kraetzschmar, G., editors,RoboCup-2000: Robot Soccer World Cup IV, volume 2019 of Lecture Notes in ArtificialIntelligence, pages 29–40. Springer.
[Reis and Lau, 2002] Reis, L. P. and Lau, N. (2002). Coach unilang - a standard languagefor coaching a (robo) soccer team. In RoboCup-2001: Robot Soccer World Cup V, volume2377 of Lecture Notes in Artificial Intelligence, pages 183–192. Springer.
[Reis et al., 2001] Reis, L. P., Lau, N., and Oliveira., E. (2001). Situation based strategicpositioning for coordinating a simulated robosoccer team. In Hannebauer, M., Wendler,J., and Pagello, E., editors, Balancing React. and Social Deliberation in MAS, volume2103 of Lecture Notes in Artificial Intelligence, pages 175–197. Springer.
[Riedmiller and Merke, 2003] Riedmiller, M. and Merke, A. (2003). Using machine learningtechniques in complex multi-agent domains. In Adaptivity and Learning.
[Riedmiller et al., 2000] Riedmiller, M., Merke, A., Meier, D., Sinner, A., Thate, O., andEhrmann, R. (2000). Karlsruhe brainstormers - a reinforcement learning way to roboticsoccer. In Veloso, M., Pagello, E., and Kitano, H., editors, RoboCup-99: Robot SoccerWorld Cup III, volume 1856 of Lecture Notes in Artificial Intelligence. Springer.
[Risler and von Stryk, 2008] Risler, M. and von Stryk, O. (2008). Formal behavior specifi-cation of multi-robot systems using hierarchical state machines in XABSL. In AAMAS08-Workshop on Formal Models and Methods for Multi-Robot Systems, Estoril, Portugal.
[Rofer, 2003] Rofer, T. (2003). An architecture for a national robocup team. In Kaminka,G., Lima, P., and Rojas, R., editors, RoboCup 2002: Robot Soccer World Cup VI, volume2752 of Lecture Notes in Artificial Intelligence, pages 417–425. Springer.
[Rofer et al., 2006] Rofer, T., Brose, J., Carls, E., Carstens, J., Goehring, D., Juengel, M.,Laue, T., Oberlies, T., Oesau, S., Risler, M., Spranger, M., Werner, C., and Zimmer, J.(2006). Germanteam 2006 the german national robocup team. In Robocup 2006 Sympo-sium. Deutsches Forschungszentrum fuer Kuenstliche Intelligenz, Universitaet Darmstadt,Universitaet Bremen and Humboldt-Universitaet zu Berlin.
[Ros et al., 2007] Ros, R., de Mantaras, R. L., Arcos, J. L., , and Veloso, M. (2007). Case-Based Reasoning Research and Development, volume 4626 of LNCS, chapter Team PlayingBehavior in Robot Soccer: A Case-Based Reasoning Approach, pages 46–60. Springer.
[Ros and Veloso, 2007] Ros, R. and Veloso, M. (2007). Executing multi-robot cases througha single coordinator. In AAMAS ’07: Proceedings of the 6th international joint conferenceon Autonomous agents and multiagent systems. ACM.
[Ros et al., 2006] Ros, R., Veloso, M., de Mantaras, R. L., Sierra, C., , and Arcos, J. L.(2006). Advances in Case-Based Reasoning, volume 4106 of LNCS, chapter Retrievingand Reusing Game Plays for Robot Soccer, pages 47–61. Springer.
44
[Shiota et al., 2006] Shiota, S., Yamazaki, Y., Takahashi, S., Taniguchi, Y., and Takeuchi,I. (2006). Yowai2006 team description. In Robocup 2006 Symposium. University of Tokyo,Japan.
[Smith, 2004] Smith, R. (2004). Open Dynamics Engine v0.5 User Guide,http://www.ode.org/.
[Stanton and Williams, 2004] Stanton, C. and Williams, M.-A. (2004). Grounding robotsensory and symbolic information using the semantic web. In Polani, D., Browning, B.,Bonarini, A., and Yoshida, K., editors, RoboCup-2003: Robot Soccer World Cup VII,volume 3020 of Lecture Notes in Artificial Intelligence. Springer.
[Stone, 1998] Stone, P. (1998). Layered Learning in Multi-Agent Systems. PhD thesis, CMU.
[Stone et al., 2001] Stone, P., Balch, T., and Kraetzschmar, G., editors (2001). RoboCup-2000: Robot Soccer World Cup IV, volume 2019 of Lecture Notes in Artificial Intelligence.Springer.
[Stone and Veloso, 1999] Stone, P. and Veloso, M. (1999). Task decomposition, dynamic roleassignment, and low-bandwidth communication for real-time strategic teamwork. ArtificialIntelligence, 110(2):241–273.
[Utz et al., 2004] Utz, H., Stulp, F., and Muehlenfeld, A. (2004). Sharing belief in teams ofheterogenous robots. In Nardi, D., Riedmiller, M., and Sammut, C., editors, RoboCup-2004: The Eighth RoboCup Competitions and Conferences, volume 3020 of Lecture Notesin Artificial Intelligence. Springer.
[Veloso et al., 2000] Veloso, M., Pagello, E., and Kitano, H., editors (2000). RoboCup-99: Robot Soccer World Cup III, volume 1856 of Lecture Notes in Artificial Intelligence.Springer.
[Visser et al., 2008] Visser, U., F., R., Ohashi, T., and Dellaert, F., editors (2008). RoboCup-2007: Robot Soccer World Cup XI, volume 5001 of Lecture Notes in Artificial Intelligence.Springer.
[Weigel et al., 2001] Weigel, T., Auerbach, W., Dietl, M., Dumler, B., Gutmann, J.-S.,Marko, K., Muller, K., Nebel, B., Szerbakowski, B., and Thiel, M. (2001). Cs freiburg:Doing the right thing in a group. In Stone, P., Balch, T., and Kraetzschmar, G., editors,RoboCup-2000: Robot Soccer World Cup IV, volume 2019 of Lecture Notes in ComputerScience. Springer.
[Wendler and Bach, 2004] Wendler, J. and Bach, J. (2004). Recognizing and predictingagent behavior with case based reasoning. In Polani, D., Browning, B., Bonarini, A., andYoshida, K., editors, RoboCup 2003: Robot Soccer World Cup VII, volume 3020 of LectureNotes in Artificial Intelligence. Springer.
45
[Yokota et al., 1999] Yokota, K., Ozaki, K., Watanabe, N., Matsumoto, A., Koyama, D.,Ishikawa, T., Kawabata, K., Kaetsu, H., and Asama, H. (1999). Uttori united: Coopera-tive team play based on communication. In Asada, M. and Kitano, H., editors, RoboCup-98: Robot Soccer World Cup II, volume 1604 of Lecture Notes in Artificial Intelligence,pages 479 – 484. Springer.
[Zweigle et al., 2008] Zweigle, O., Kappeler, U.-P., Rajaie, H., Hussermann, K., Lafrenz, R.,Tamke, A., Schreiber, F., Hoferlin, M., Schanz, M., and Levi, P. (2008). CoPS Stuttgartteam description 2008. In Visser, U., F., R., Ohashi, T., and Dellaert, F., editors, RoboCup2008: Robot Soccer World Cup XII CD proceedings.
[Zweigle et al., 2006] Zweigle, O., Lafrenz, R., Buchheim, T., Kappeler, U.-P., Rajaie, H.,Schreiber, F., and Levi, P. (2006). Cooperative agent behavior based on special interactionnets. In Intelligent Autonomous Systems 9: IAS-9.
46
![C:/andreia/Doutorado/ Tese/tese latex/tese latex/tese · 2018-01-31 · [Sampaio & de Souza, 2008] SAMPAIO, A.; DE SOUZA, C.. Usu´arios podem escrever especificac¸˜oes de sistemas?](https://img.pdfslide.us/doc/110x75/5ec8d4569e681779b87efd18/candreiadoutorado-tesetese-latextese-latex-2018-01-31-sampaio-de.jpg)
