Multiagent Soccer on Gaea. Itsuki Noda, Hideyuki Nakashima ETL. Umezono 1-1-4, Tsukuba 305, Japan Infons. arguments). 2.1.

Transcription

1 Multiagent Soccer on Gaea Itsuki Noda, Hideyuki Nakashima ETL Umezono 1-1-4, Tsukuba 305, Japan 3 1 Introduction We are developing a new software methodology for building large, complicated systems out of simple units[nak91]. The emphasis is on the architecture used to combine the units, rather than on the intelligence of individual units. We call the methodology \organic programming", referring to the characteristics of organic systems, context dependency and partial specication. Our approaches toward those characteristics are situatedness and re- ection. Situatedness corresponds to the former characteristic, and reection to the latter. In this paper we describe an application of organic programming language, Gaea, to the programming of players of a multi-agent game, soccer. Our approach to multiagent systems is recursive. Each agent is programmed in a multiagent way. In programing a complex agent like soccer player, we need various kinds of mechanisms of mode-change, interruption and emergency exit. We propose \dynamic subsumption architecture" as a exible methodology to realize such mechanisms. 2 Gaea Gaea[NNHF] is an instance of organic programming methodology, as Smalltalk is of object oriented programming. In the case of object oriented programming, there are combinations with procedural language (Smalltalk, C++), functional programming (LOOPS), and logic programming (ESP[Chi83]). The same variety of combinations are possible in organic programming. Gaea is a logic programming language. An organic program consists of the following: Processes: the execution of a program in a certain environment. Cells: the storage of program fragments. Environments for processes: The environment is formed by a collection of cells. 3 This work is supported by New Models for Software Architecture Project of MITI. 2.1 The Language Features of Gaea Infons An \infon"[dev91] is a unit of information. In Prolog, it corresponds to a single literal (a predicate plus its arguments) Clauses Constraints are relations among infons that always hold, or should always hold. By using these constraints, one can deduce a new infon from known infons. The inference rules are written as a form of clause. P : Q := R. The above clause is read as \To prove P where Q is true, prove R", or \To execute P where Q is true, execute R" Cells A cell is described by a set of clauses. Each cell has its identical name, by which process manipulate cells and environments described below Processes Each agent is associated with at least one process. Since processes normally share some part of their environment (cells), it is natural to implement them on shared memory architecture. A new process is invoked by calling fork(program,processid) where ProcessID is returned as the result of fork Environments By forming multiple cells into a specic structure, infons can interact with each other to yield new information. We refer to these structures as environments for processes. For each activation of programs in a process, its environment is searched for matching denitions (clauses). Each process can manipulate the environments of itself and other processes. In Gaea, the environment is a liner list of cells, and can be modied by any kinds 1

2 higher level subsume higher level subsume output subsume function lower level lower level Figure 1: Concept of Subsumption Architecture Figure 2: Implementation of Subsumption Architecture of list operations. For example, Gaea provides the following operations for cells: 1. push(cell [,PID]) pushes a Cell into the current environment. 2. remove cell(cell [,PID]) removes Cell from the current environment. 3. subst cell(cell1,cell2 [,PID]) swaps the Cell2 in the current environment with Cell1. 4. environment(env [,PID]) observes the current environment and returns a list of cells to ENV. 2.2 Subsumptive Programming Subsumption Architecture The basic concept of subsumption architecture[bro91] can be characterized as follows: 1. Each module is connected in parallel between the input and output. 2. Modules form layers in which higher layers can subsume lower. 3. Lower layers govern basic behaviors and higher layers provide sophisticated behavior. 4. The total behavior of the system can be changed by adding a new layer at the high without changing existing layers. When a new top layer is added, it is sometimes necessary to change the behavior of existing layers accordingly. It is ideal to perform this alternation of behavior without changing the internal structure of lower layers, as shown in Figure 1. However, actual implementation is something like Figure 2, in which higher layers send bias-signals to lower layers. An obvious shortcoming of this interconnection is that modularity is lost. There is yet another, more severe shortcoming in that the circuit is xed and cannot be easily rearranged to adapt to a new situation Subsumptive Programming in Gaea We can program an agent in a way similar to subsumption architecture: 1. We can program a system by functional layers. 2. Programs in higher functional layers can override programs in lower layers. The top-level process of an agent calls programs by their names. Those programs may exist in any layer. If more than one program of the same name exists, the program in an upper layer is given precedence over those in lower layers. If we use logic programming, as in Gaea, there is a further possibility to backtrack to lower levels when a higher level program fails to perform its function. One of the advantages of subsumptive programming is that we can easily modify the rules to accommodate a new condition. In the case of Brooks' subsumption, the whole system must be re-compiled to accommodate the new condition. As the result of re-compilation, the actual information ow is altered and higher layers give bias signals to lower layers. In organic programming, the same eect is achieved by re-dening the condition using the same name. The old denition still remains in the lower cell. Only the name for denition mapping is changed. 3 Soccer and Multi-Agent System 3.1 Soccer as a Multiagent System We selected soccer as our bench test because the game has many of the essential properties of multiagent systems: 1. Needless to say, soccer is played by teams of multiagents (a two-level multiagent system). 2. It is a real-time game. 3. Robustness against failure of tactics, loss of some agents, and so on, is required. 2

3 4. There is no single person giving directions during play (in contrast with American football). 5. All players must cooperate all the time (in contrast with baseball, especially with its oensive phase). 6. Verbal communication is very limited. 7. Simplication to a two-dimensional simulation does not abolish the essential properties of soccer. 3.2 Soccer Server Soccer Server [NOD95, NM96] enables a soccer match of two teams of player-programs written by dierent programing systems. A match using Soccer Server is carried out by a client-server system: Soccer Server provides a virtual soccer eld and simulates movements of players and a ball. Clients are brains of players and control their actions via a computer network. The protocol of the communication between a server and clients consists of control commands and sensor informations. Control commands are messages sent from a client to the server to control actions of the client's player. There are 4 kinds of commands: (turn Moment), (dash Power), (kick Power Direction), and (say Message). Sensor informations are messages sent from the server to a client to inform situation of the eld from the viewpoint of the player. Sensor informations consist of visual and auditory informations. Visual informations tell a client relative positions of objects in the view of its player. Auditory informations tell a client messages sent from the referee and other clients. 4 Programming Players in Gaea 4.1 Dynamic Subsumption Architecture In programming a complex agent like a soccer player, it is essential that the agent accepts many modes. The same agent may respond to the same input dierently according to the mode. For example, in soccer, a player may react dierently to a ball according to whether his team is on oense or defense. The mode of the agent must be changeable exibly. The mode changes as a result of agent's action and plan, and it also changes according to the change of situation. Moreover, modes will be divided into a couple of levels. For example, in soccer, \oensive mode" and \defensive mode" are relatively high-level modes. On the other hands, \chase-ball mode" and \dribble mode" are relatively low-level modes. In addition to it, we can consider a couple of types of changes of modes. For example, an agent may \goto" a new mode, or it may \enter" a new mode and \return" when it exits from the new mode. In order to realize such exible mode-change, we use an extension of subsumption architecture, called dynamic subsumption architecture. This architecture is the combination of subsumption architecture and dynamic environment change. Since subsumption architecture assumes xed layers of functions, it is either dicult or inecient to implement multiple modes on top of it. It is straightforward in organic programming, using context reection. We assume the following conditions for dynamic subsumption architecture: 1. Overriding is done by name 2. The same ontology (global name) is used by all cells. 4.2 Overview of the Architecture of a Soccer Player As described in Section 1, we program an agent in multi-agent way. A soccer player consists of the following processes(agents): Sensor Process: receives sensor informations sent from the Soccer Server, analyzes them, and puts the results into the common cell. Command Process: sends control commands to the Soccer Server. It is controlled to send one command per 100 milli-seconds, because Soccer Server accepts only one command per 100 milli-seconds. In other words, this process is a resource manager of sending control commands. Action Process: controls low-level modes of player's action by manipulating the environment of the command process. Object Detection Process: checks the way to the target of chasing or kicking, and changes the behavior by modifying the environment of the command process. if there are objects on the way, Communication Process: controls high-level modes of player's action according to the message from referee and teammates. The top level of each process is a loop that repeatedly calls \cycle(top)". It is dened in the \basic" cell, that is shared all processes, as follows: /* In \basic" cell */ toplevel() := repeat, cycle(top), fail. 4.3 Basic Action Modes A player is situated in certain action modes, such as chase-ball, dribble, shoot, pass, and so on, during the play. Each mode is dened in one or in a set of cells. The mode is changed by pushing cells into the environment of the command process of the player. For 3

4 example, in chase-ball mode, the role process pushes the following \chase" cell into the environment of the action process. In each cell, \cycle(top)" for the command process is dened accordingly. /* In \chase" cell */ := target(target), cycle(turn(target)),/* turn to the target */ cycle(dash(target)). /* and dash */ cycle(turn(target)) ::= direction(target,dir), turn(dir). /* send turn command */ cycle(dash(target)) ::= distance(target,dist), dash(dist). /* send dash command */ target(ball). In Gaea, the environment of a process can be manipulated by the process itself and also by other processes. In out program, the action process manipulates the environment of the command process in order to control basic action mode. The followings are a sample of definition of \cycle(top)" for the action process. /* In \dribbler" cell */ distance(ball,bdist), BDist < 2, /* if ball is near */ distance(goal,gdist), GDist < 10 := /* and in front of goal */ change command env([shoot]). /* then shoot!! */ distance(ball,bdist), BDist < 2 := /* if ball is near */ change command env([dribble]). /* then start dribble */ = change command env([chase]). /* otherwise chase the ball */ /* Replacing new mode cells */ /* into the environment of */ /* the command process */ change command env(newmode) : command process(pid), environment(env,pid), include(newmode,env) :=. change command env(newmode) : command process(pid), environment(env,pid), remove mode cell(env,nenv), append(newmode,nenv,newenv), set environment(newenv,pid). In this program, the action process checks the situation of the eld, selects one \shoot", \dribble" and \chase" cells, and swaps it with the current mode cell in the environment of the command process. The merit of this architecture, in which the action process manipulate the environment of the command process, is that the command process can send commands constantly even if it take a lot of time for the action process to check the situation. Control of high-level mode is also realized in the same manner. In this case, communication process manipulate the environment of the action process in order to change higher-level of behavior like \dribbler" and \passer". 4.4 Modifying Basic Actions It is easy to realize small modication of behavior by manipulating environments. In order to avoid objects, the object detection process pushes the following \avoid" cell into the environment of the command process. /* In \avoid" cell */ target(target) : remove cell(avoid), /* remove this cell */ target(t1), /* nd original target */ Target = T1 + rel dir(60). /* shift relative angle in 60 degree */ This cell only override the denition of \target(target)" rather than \cycle(top)". Moreover, this denition is used only once, because the \avoid" cell is removed when \target(target)" is called. (See remove cell.) The program for the object detection process is as follows: /* In \check object" cell */ command process(pid), environment(env,pid), in(env,target(target)), /* get Target information */ /* in the command environment */ not clear to(target), /* check if the target direction */ /* is clear */ add action env([avoid]). /* add avoid into the */ /* command environment */ 4.5 Interruption Interruption is a kind of temporal change of modes. The feature of interruption is to suspend current job, execute another job, and return to execute the current job. For example, consider the case that the player must reply its position immediately when a teammate says \tell your position". This behavior can be realized 4

5 by pushing the following cell into the environment of the command process. /* In \tell pos" cell */ cycle( ) : estimate current pos(x,y), unum(unum), say([unum,position,x,y]), remove cell(tell pos), fail. This denition is used whenever \cycle/1" is called, and discarded after the execution in failure. Then original denition of \cycle/1" is called. We can control the level of interruption by specifying the argument of \cycle/1". For example, consider the case the player loses site of a ball when it is chasing the ball. In this case, the other process will interrupt the command process to search the ball. In the chase mode, the command process calls \cycle(turn)" and \cycle(dash)" sequentially. If the interruption is de- ned as \cycle( )" like the above example, the denition is executed when \cycle(dash)" is called. But the interruption of searching ball will change player's direction, so that the player may dash to the wrong direction. In order to avoid this, we can simply dene this interruption as \cycle(top)" as follows: /* In \search" cell */ target(target), cycle(look(target)), remove cell(search). cycle(look(target)) :- cycle(turn(target)), cycle(wait visual sensor), new info(target),cut. cycle(look(target)) :- cycle(search(target)). cycle(search(target)) :- turn(90), cycle(wait visual sensor), new info(target),cut. cycle(search(target)) :- cycle(search(target)). cycle(wait visual sensor) :- current time(ctime), repeat, usleep(100000), cycle(visual sensor newer(ctime)),cut. cycle(visual sensor newer(ctime)) : visual sensor time(vtime), VTime > CTime,cut. We can use any kinds of infon on the argument of \cycle/1", so that it is able to realize exible control of interruption. 4.6 Emergency Exit It is also possible to realize emergency exit of execution of plays. For example, consider the case that the player must go back to its own goal immediately because of the clutch. This behavior is realized by pushing emergency, guard goal and chase cells into the environment of the command process, where these cells have the following denitions. /* In \emergency" cell */ /* when cycle(top) is called, */ /* exit emergency */ remove cell(emergency) := fail. /* all other cycle( ) fails */ cycle( ) := fail. /* In \guard goal" cell */ target(owngoal). 5 Conclusion Thorough our experience of programming soccer players in Gaea, we are convinced that the language is suitable for complex multiagent programming. In programing complex agents, we need various kinds of mechanisms of mode-change, interruption and emergency exit. We proposed \dynamic subsumption architecture" as a exible methodology to realize such mechanisms. We could also program the system in layer-by-layer manner, from a simple behavior to more complex ones, taking full advantage of subsumption architecture design. References [Bro91] Rodney A. Brooks. Intelligence without representation. Articial Intelligence, 47:139{ 160, [Chi83] Takashi Chikayama. Esp { extended selfcontained prolog { as a preliminary kernel languages of fth generation computers. New Generation Computing, 1(1):11{24, [Dev91] [Nak91] [NM96] Keith Devlin. Logic and Information I: Infons and Situations. Cambridge Univ. Press, Hideyuki Nakashima. New models for software architecture project. New Generation Computing, 9(3,4):475{477, Itsuki NODA and Hitoshi MATSUBARA. Soccer server and researches on multi-agent 5

6 systems. In Hiroaki Kitano, editor, Proceedings of IROS-96 Workshop on RoboCup, pages 1{7, Nov [NNHF] Hideyuki Nakashima, Itsuki Noda, Kenichi Handa, and John Fry. GAEA programming manual. TR-96-11, ETL. Gaea system is available from year=1996. [NOD95] Itsuki NODA. Soccer server : a simulator of robocup. In Proc. of AI symposium '95, pages 29{34. Japanese Society for Articial Intelligence, Dec