CERBERUS 2003 TEAM REPORT

CERBERUS 2003 TEAM REPORT Svetlozar Argirov, Boris Marinov Petya Pavlova, Nikola Shakev, Jordan Tombakov, Andon Topalov H. Levent Akın*, M. Kaan Baloğlu Hatice Köse Bağcı, Suzan Bayhan, Çetin Meriçli, Damla Poslu, Ömer Sever O. Taner Yıldız 1 Department of Computer Engineering, Boğaziçi University, 80815, Bebek, Istanbul, Turkey Department of Control Systems, Technical University Sofia, Plovdiv branch, 61, St. Petersburg Blvd, Plovdiv 4000, Bulgaria October 14, 2003 * Corresponding Author ii ACKNOWLEDGEMENTS The members of the Boğaziçi University team would like to thank Prof. Sabih Tansal, Rector of Boğaziçi University, Prof. Z. İlsen Önsan, Vice Rector and Chairperson of the Executive Committee of the Boğaziçi University Research Fund, and Candan Fetvacı, Coordinator of Boğaziçi University Foundation for their kind support throughout all the phases of the project . We would also like to thank Profs. Ethem Alpaydın, Fikret Gürgen and Lale Akarun and A.C. Cem Say for valuable discussions. We gratefully acknowledge the support of our work by the Boğaziçi University Research Fund through projects 01A101, 03A101D and Boğaziçi University Foundation. iii ABSTRACT Cerberus is a joint effort of Boğaziçi University (Turkey) and Technical University of Sofia, Plovdiv branch(Bulgaria). We have divided the robot software design into six major tasks, and worked on those tasks in parallel. Many modules were developed using several approaches and later integrated into the final system. In addition to using better algorithms, improvements in the code were also made. iv TABLE OF CONTENTS ACKNOWLEDGEMENTS....................................................................................................ii Abstract..................................................................................................................................iii TABLE OF CONTENTS ......................................................................................................iv I. INTRODUCTION .......................................................................................................... 1 II. THE DEVELOPMENT TEAM ..................................................................................... 2 II.1 The Turkish Team .................................................................................................. 2 II.2 The Bulgarian Team ............................................................................................... 2 III. THE ALGORITHMS ................................................................................................. 3 III.1 The Architecture ..................................................................................................... 3 III.2 Vision Module ........................................................................................................ 4 III.2.1 Vision Submodule .......................................................................................... 5 III.2.2 Image Processing Submodule......................................................................... 7 III.3 Localization Module............................................................................................. 10 III.3.1 Cases to consider .......................................................................................... 11 III.3.2 Approaches to The Problem ......................................................................... 11 III.3.3 Communication with Other Modules ........................................................... 13 III.3.4 Performance of the system ........................................................................... 14 III.4 Locomotion Module ............................................................................................. 15 III.5 Planner and Behavior Module .............................................................................. 15 III.5.1 Planner of the Goalkeeper ............................................................................ 16 III.5.2 Planner of the Attacker ................................................................................. 17 III.5.3 Planner of the Defender................................................................................ 18 III.5.4 Multi-Agent Behaviors ................................................................................. 18 III.6 Wireless Communication ..................................................................................... 20 III.6.1 Purpose of the system................................................................................... 20 III.6.2 Overview ...................................................................................................... 20 III.6.3 System Description....................................................................................... 20 IV. DISCUSSION AND CONCLUSIONS.................................................................... 22 V. RESOURCES ............................................................................................................... 23 REFERENCES ..................................................................................................................... 24 1 I. INTRODUCTION The Cerberus1 team made its debut in RoboCup 2001 competition. This was the first international team participating in the league as result of the joint research effort of a group of students and their professors from Boğaziçi University (BU), Istanbul, Turkey, and Technical University Sofia, Plovdiv branch (TUSP), Plovdiv, Bulgaria. Our general strategy was to divide the robot software into four major tasks, and assign one subteam for each task. Each subteam started out by developing some working code for the task, and by integrating it to produce a working system to begin with. Then, each subteam gradually improved the modules. Some modules were assigned to two teams at the same time. The groups were locomotion, localization, vision, behavior control. Taking into consideration the deficiencies of Cerberus 2002 team, mainly in vision and locomotion, special emphasis was given to these areas. Additionally, developing multi-agent behaviors that take into consideration the use of wireless network card was also carried out. Although some code from Cerberus 2002 team was used, the final implementation consisted of mainly new algorithms, implemented using OPEN-R SDK. 1 In Greek mythology, Cerberus was the most dangerous labor of Hercules. It was a vicious beast that guarded the entrance to Hades and kept the living from entering the world of the dead. It had three heads of wild dogs, a dragon or serpent for a tail, and heads of snakes all over his back. 2 II. THE DEVELOPMENT TEAM The team is a joint effort of Boğaziçi University (Turkey) and Technical University of Sofia, Branch Plovdiv (Bulgaria). II.1 The Turkish Team Assoc. Prof. H. Levent Akın, the head of the Artificial Intelligence Laboratory at the Department of Computer Engineering, leads the Turkish team. The Turkish team has five subteams: • • Vision and image processing: Olcay Taner Yıldız, and Ömer Sever. • Locomotion: Burak Turhan, Damla Poslu. • • Localization: Hatice Köse and Suzan Bayhan. Wireless Communication: Cetin Mericli. Planner and behaviors: M.Kaan Baloğlu. II.2 The Bulgarian Team The Bulgarian team is led by Assoc. Prof. Andon Topalov from the Technical University of Sofia, Plovdiv branch. The Bulgarian team has three subteams: • • • Vision and image processing: Dr. Petya Pavlova, Svetlozar Argirov Locomotion: Nikola Shakev, Svetlozar Argirov, Jordan Tombakov Behaviors: Assoc. Prof. Andon Topalov, Nikola Shakev, Boris Marinov 3 III. THE ALGORITHMS Considering the shortcomings of our team in Robocup 2002 we decided to improve mainly the locomotion, localization, vision components. Additionally, we decided to enhance our planner and behavior component both by using new learning algorithms and extending multiagent behaviors. In the development of the Cerberus 2003 team entry we tried to follow object-oriented software analysis and design techniques as closely as possible. For almost all modules many different approaches have been implemented and tested. These are described below. III.1 The Architecture The Cerberus team has developed a behavior-based architecture (Arkin 1998) for the robots and has been using this architecture since 2001. The main objective of our team was to build a research platform, which allows robust and efficient carriage of the robots playing football. A modular architecture has been adopted and implemented. This year the implementation was done using OPEN-R SDK. Figure III.1 The architecture of the control system The following are the main system components: Vision, Localization, Planner and 4 Behaviors, and Locomotion and Communication. The relationship between them can be seen in Figure III.1. The perception level of the control system consists of the Vision and Localization modules. The Vision module accepts images from the camera and identifies objects on the field that are visible. It delivers the identified objects as well as the distance to the object and its relative direction to the Planner and Localization modules. The Localization module receives the relative position of the landmarks around the play field from the Vision module. This information is used to approximate the position and heading of the robot on the field. The Planner and Communication modules form the logical level. They incorporate the memory of the robot, decision-making and inter-robot communication. The Planner module collects the information about the visible objects from the Vision module and stores it in the local map. The local map presents the objects around the robot in polar coordinates. The Planner also receives the position and heading of the robot from the Localization module. Using this information, it decides what have to be done and invokes the appropriate behavior. Communication module enables wireless communication between teammate the robots. Exchanging of information can be used to fill the local map or to facilitate the cooperative operations. In the previous years’s entries the number of logical modules was equal to the number of binary objects. But this year we have combined them into one binary as explained in subsubsection III.2.2.4 The components of the architecture are described briefly below. III.2 Vision Module The design goals of the Vision Module are to supply accurate information in a timely manner. The Vision Module is responsible for image acquisition, processing the image and providing useful and acceptable information in a timely manner to the other modules in the system. For example, the Localization Module gets the current beacon information, while the Locomotion Module gets the head orientation while searching the ball from the Vision Module. The Planner Module also needs the Vision Module to provide the local map information to decide on the next action (Figure III.2). The Vision Module can be considered as the core of the system. In order to make it work more efficiently the module is separated into two submodules as Vision submodule and Image Processing submodule. The two submodules will be explained in detail in later sections but mainly the Vision submodule is responsible for the inter-object communication and 5 preprocessing of the image and Image Processing submodule is responsible for more high level operations on the image such as region finding, region merging and object recognition. Figure III.2. Inter-object communication regarding Vision. The Vision Module of Cerberus 2002 was not so problematic. The algorithms seem to work well under most circumstances and provide acceptable information to the other modules in the system. The main problem in the system was the performance of the system. There were also some minor problems in the code that should be arranged in a way not to affect the other modules and also the Vision Module. We have also considered implementing new algorithms instead of existing ones to increase the performance or the accuracy of the Vision Module. III.2.1 Vision Submodule The main aim of this module is to acquire image, preprocess the image, send it to the Image Processing Module and after the processing send the information such as local map, beacons to other modules. In order to carry out these operations efficiently, Vision submodule has inter-object communications with other modules, namely, Localization, Locomotion and Planner Modules. As can be seen from the subject observer information given below, the Vision Module does not get information from other modules in the system except the system modules that are picture taking and the sensors. Subjects Vision.SendLocalMapInfo.TLocalMap.S Vision.SetCmdHC.Hc.S Vision.SendLocInfo.TBeaconArray.S Vision.SendLedInfo.TLedObjects.S 6 Observers Vision.GetSensor.OSensorFrameVectorData.O Vision.snapImage.OFbkImageVectorData.O The description of the information sent is given below: • SendLocalMapInfo is sent to Planner. It contains information about the current status of • the environment determined from the latest image taken. • orientation during the searching of the ball. SetCmdHC is sent to the Locomotion Module. This subject is responsible for the head SendLocInfo is sent to Localization Module. It contains the beacon information such as how many beacons can be seen, which beacons they are, the confidence levels etc. That information should be used by the Localization module to determine the current position • of the robot. • according to the information sent by Vision submodule. SendLedInfo is sent to the LED Module. This module turns the leds on and off GetSensor is an observer used by Vision submodule and its task is to control the sensors and sent the information that is not sent to the appropriate module. It is known that this • observer runs 32 times per second. snapImage is the other observer used by the system. This observer is responsible for getting the image taken by the robot. This observer is known to run 25 times per second. III.2.1.1 Color Classification Algorithms Mainly the algorithms developed for Cerberus 2002 were used with some speed improvements. The first approach depends on initially performing a preliminary color separation of the pixels in the color space described by a triple consisting of hue – H, saturation – S and achromatic parameter (Pavlova, Tombakov, and Shakev, 2002). The other approach is based on using machine learning techniques for classification. One of the algorithms used for color classification of the image is MLP which uses the neural networks and the other one is ClassifyC45 which uses decision trees for the same purpose. Currently our system uses ClassifyC45 for color classification in which there are 10 predefined colors. For the details of these algorithms please refer to Cerberus 2002 Team Report. 7 III.2.2 Image Processing Submodule This module does all the operations on the image to get the necessary information from the image. These operations include the region finding, region merging and image recognition. All of these are done after the color classification of the image. The region finding algorithm first preprocesses the first row and first column of the image to prepare it for the region merging algorithm. After the classification of the pixels, each pixel has a color assigned to it. There are 10 colors, namely, the colors of ball, goals, beacons and the pitch in the system. These pixels should be defined as a group to make a region. After preparing the regions the next operation is merging. Two or more rows can have regions that are of the same class of color, so they need to be merged in order to be registered as a big region rather than small regions. We need as big regions as possible because processing of bigger regions is easier and also conveys more information than small images. After these steps, the objects that are related to those regions are recognized. The merged regions are sorted according to the dimensions of those regions. Starting from the largest to the smallest, first the ball is tried to be recognized. Next it recognizes the beacons and then the goals. There were two main problems in the Cerberus 2002 code concernig these operations: One of them is the region merging mechanism which requires two pass through the image and as a result of this decreases the performance of the system. The other problem is the order of the object recognition. The Cerberus 2002 system assumes that if has found the beacons before finding the ball but it tries to find the beacons just after the ball recognition algorithm executes. So the possibility of conveying wrong information to the Vision submodule increases. These were solved as explained below. III.2.2.1 Labeler Software A separate tool called Labeler Software has been developed to handle data collection and the process of making decision trees and neural networks and has been in use in several versions since 2001. After some training phase, this is done by describing the correct colors on the image to the Labeler; the program is able to find the regions on the image. The pictures below show two images. One of them is before the classification and the other one is after the classification. 8 Figure III.3. Labeler and Images III.2.2.2 Run Length Encoding The performance problem in the vision module was solved in part by using run length encoding for the images. This algorithm consists of replacing horizontal runs of the same color with a run. A run stores the color it is associated with, the x, y location at which it starts, and the number of pixels included in the run. Run length encoding reduces the size of the image in the memory. This reduces the amount of time needed by the processor to scan over the entire image while performing some function. Only non-background pixels are encoded into runs, which is why the x, y location is needed. Generally, this increases the speed at which the robot can process data. An exception to this is the last background run on each scan line is stored. This allows for more regular code since each line has at least one run on it. The output of this stage is a run length encoded (RLE) image. The Run Length Encoding algorithm has given us the chance to store the image taken by the robot with much less memory. The structure used for run length encoding is 6 bytes long which consists of the y coordinate, begin and end of x coordinate, color and the region number. The average number of runs for an average image is around 1000. So the total number of bytes needed for an image is no more than 6 KB. The original image taken by the robot takes 76,4 KB. As it can be seen, the encoded image is about 8% of the original image. This greatly reduces the need for memory and also CPU time. Afterwards, the regions are merged using an algorithm that passes through the regions and merge them if possible. This process does not take considerable time since the number of 9 regions is not so high. The merging method employs a tree-based union with path compression. This offers not only a performance improvement that is only good in practice but also provides a hard algorithmic bound that is for all practical purposes linear. The merging is performed in place on the classified RLE image. This is because each run contains a field with all the necessary information; an identifier indicating a run's parent element (the upper leftmost member of the region). Initially, each run labels itself as its parent, resulting in a completely disjoint forest. The merging procedure scans adjacent rows and merges runs which are of the same color class and overlap under four-connectedness. This results in a disjoint forest where the each run's parent pointer points upward toward the region's global parent. Thus a second pass is needed to compress all of the paths so that each run is labeled with its actual parent. Now each set of runs pointing to a single parent uniquely identifies a connected region. The regions are then extracted by finding all of the runs that have the same parent. The runs for each region are linked together into a linked list to facilitate further processing. Summary statistics are gathered for all of the regions including: bounding box, centroid, and area. The regions are then separated based on color into linked lists and sorted in order of decreasing area. The linked lists of regions form the output of this last stage and the main input to the high level vision. III.2.2.3 Object Recognition One of the problems that affect the performance of the system is the order of object recognition. The ball recognition algorithm assumes that all beacon information is ready but beacon recognition is executed after the ball recognition algorithm. The accuracy of the system has also been increased by increasing the number of sanity checks to provide better information to the other modules in the system. III.2.2.4 Single Module Another work done for not only the Vision part but the whole system was to make the system work as a single module. The main aim for this was to decrease the overhead caused by the communications between modules and increase the performance. After the operation was complete, there was a small increase in the performance. This was not the most important result. The most important result was the serialization of the system. Namely, the operations are done in a predetermined order. First, image is taken by the AIBO, then Vision module processes the image and gets the object information, then Localization gets the information and processes it, then Planner decides on what action to do based on the local map provided 10 by the Vision module, then Locomotion Module does the action. This provides a better result and more control over the whole system. For the multiple module system, the order of operations is not predictable because the system is real time event-based system. The communication between modules is done via C++ structures instead of OPEN-R objects. III.3 Localization Module The Localization Module is used to find the robot position on the field. The position is in terms of x and y coordinates of the point the robot stands at that moment. The problem is very basic: specifying the coordinates and sending it to the Planner Module. PLANNER LOCALIZATION The robot Position LOCOMOTION Odometric data VISION Visual data Figure III.4.Data flow of Localization and other modules This module takes data from other two modules: Vision and Locomotion Modules (Figure III.4). So mainly there are two types of data: visual data from sensors of the robot by Vision Module and odometric data from Locomotion Module. Unfortunately the robot has a narrow sight of approximately 26.5 degrees from the center (in total 53 degrees). Therefore it is really difficult to get a very accurate localization using only the visual data. Most of the time the robot sees no beacon at all. So it is necessary to make use of the odometry information i.e. the knowledge of displacement of the robot at each step and to keep a list of past actions. There are many sub-problems to consider such as the noisy and oscillatory character of the data coming from visual sensors. For this reason the Localization Module aims to minimize the effects of noise on the localization process. 11 III.3.1 Cases to consider There are three cases to consider in localization process: • • • No beacon case One beacon case Two beacons case III.3.1.1 No-Beacon Case The most problematic situation is the case in which the robot does not see any beacons. In this case localization relies on the odometry information. Odometric data received from locomotion module is in the form of length moved from the previous time, and the angle of the move. According to this data, the position of the robot is updated. III.3.1.2 One Beacon Case One beacon is not sufficient for finding the robot position; it can only give an arc on which the robot may be at any point. If there is past information about the robot position or beacon data, this single beacon information may help to find the unique position of the robot. III.3.1.3 Two Beacons Case Cross points of circles is the name of the method used for determining the position of an object when only distances to other two objects are known. This is highly efficient method to find the position. However here again there may be two possible points. Choosing the one of the points may be done according to the later beacon data. III.3.2 Approaches to The Problem As explained above, the Vision Module processes the data provided by the camera of the robot and sends it to the Localization Module. This information can be translated into this form:”beacon x is seen at distance y ”. Localization module makes updates according to this information every time it is received. Other types of information also come when the robot makes a move. Since the data received from these two modules are in no special order, processing them is done according to the received information. It means that if beacon information arrives, visual update is done. Otherwise the “odometric” update is done (Köse, Bayhan and Akın, 2003). III.3.2.1 Methods Used The main idea of the localization process is based on the “grid world” model: The field is divided into equal sized squares. Each square represents an area of the field corresponding to 12 some points. There are 28 grid cells at the longer side and 18 grid cells at the shorter side of the field. There are also 2 columns representing the goal areas of each team so totally there are 540 grid cells. The robot position at each step is found in terms of grid coordinates. For example, it may be (7, 8) saying that the robot is at the point that is in the borders of the grid cell (7,8). Each update is done in the grid world. There are two techniques used in localization process: • • Classical Method Fuzzy Method III.3.2.2 Classical Method The “classical method” is also called triangulation. Here the main idea is to use beacon information to solve second degree equations. As it is known from mathematical terms, the points that are at the same distance from a center point in a plane forms a circle. Figure III.5. Classical Method Figure III.5 shows the cross-points of circles method. P0 and P1 are the positions of the landmarks and P3 is the position of the object whose coordinates are subject to be found. By solving the equations below and using the given data, cross points of the circles are calculated. a2 + h2 = r02 b2 + h2 = r12 a = (r02 - r12 + d2 ) / (2 d) P3= (x3,y3) P2 = P0 + a ( P1 - P0 ) / d x3 = x2 +- h ( y1 - y0 ) / d 13 y3 = y2 -+ h ( x1 - x0 ) / d Using this strategy, the possible structures representing the robot position may be an arc or some point(s). If there is no change in the robot position (no motion), the last seen two beacons are used for triangulation. If odometric data arrives then odometric update is done. III.3.2.3 Fuzzy Method This method can be accepted as an interpretation of describing the location information as a probabilistic distribution. For each grid, a weight is hold corresponding to the likelihood of the robot to be in that particular grid. After each visual and odometry data becomes available, the grid weights are updated according to the results of the fuzzy filter. This method was used developed and used in 2002. Figure III.6. Fuzzy Function In Figure III.6, d is the distance to some specific point, and the points that are at the distance d+x and d-x are also accepted as solutions. However they have smaller probability of happening. It means not an exact solution is given, instead a probabilistic solution is specified. The weight of each grid shows the probability of that grid to be the one that the robot stands at that moment. III.3.3 Communication with Other Modules As explained in subsubsection III.2.2.4, since the source code is adapted to the single module form, the communication is achieved by sharing of variables. In other words, the variable assigned by one module is used by the others. 14 III.3.3.1 Vision-Localization The Vision module sends an array of beacon information after processing each snapshot. This information includes the confidence of the information, distance to the beacon, expiration flag and the x-coordinate of the beacon. The centroid of the beacon is used to find the heading angle of the robot. Tbeacon Fields: float confidence: confidence level of visual information int distance: distance to that particular beacon int expire int centroidx: x-coordinate of the centroid in the picture TbeaconArray Fields: TBeacon beacons[6]: array of beacon information float panangle: angle between head and body III.3.3.2 Locomotion-Localization After each movement of the robot the locomotion module (commander -cmd) sends a motion object that is used to calculate the displacement of the robot. Motion Fields: double distance int angle III.3.3.3 Localization-Planner At each execution cycle localization sends its outputs to the planner module. The x and y coordinates of the grid cell the robot stands with the robot heading are sent. III.3.4 Performance of the system To measure the system performance, a simulator developed in C is used. Test files consist of data points that show the robot position and after the simulator is run, outputs that are sent to the Planner Module at each step are recorded. After all data are collected, a comparison of the actual data with the simulator outputs is done. 15 III.3.4.1 Results of tests The accuracy of the developed algorithms highly depends on the input data. If there is no noise in the input data, then the position calculations are exact. Thus as expected noise has a decreasing effect on accuracy. Tests were done on assuming several noise levels, to verify the effect of noise on the accuracy of the result. Localization is very crucial for robust the robot navigation, which is essential for the robot Soccer. However finding the real position of the robot is quite difficult due to the noisy data received from the other modules. The developed algorithms can be improved by increasing the amount of data collected considerably and thaking into consideration not only beacons but also using of goals and field lines, and usage of statistical methods nearby our current work would bring more accurate results. III.4 Locomotion Module The locomotion module generally deals with the movements of the head and the legs of the AIBO robots with respect to the commands taken from the planner module. This emphasizes the interaction of the locomotion module with the other modules. In the evaluation of Cerberus 2002 code the following deficiencies were noted. The existing code was not capable of making use of all the 12 degrees of freedom in legs. Consequently, we did not have smooth and consistent transitions between consecutive movements of the robot. We assigned discrete angles to joints for each type of movement directly without taking into consideration the current state of the robot. As a result when going from one state to another there inconsistencies between the joints of the robot occur that causes the robot to fall down although our code is able to handle all such cases reliably. However, this is a waste of time and unwanted event especially when going from walking style to turning style. Besides, this kind of attitude towards the movement makes the turns quite slow and not stable. The locomotion module was improved taking basically this into consideration. Among the notable improvements are in the turning, walking and kick behaviors regard to performance. III.5 Planner and Behavior Module The Planner module is responsible for the decision-making process. It receives data about the visible objects on the playground from the Vision module and in accordance with this information chooses the appropriate behavior. The Behaviors module consists of several basic reactive behaviors that can be switched by the Planner in order to achieve more complex behaviors of the robotic players on the field (attacker, and goalkeeper). The system of 2003 is 16 different from that of 2002 in many aspects. We tried to improve the finite state machine model as much as possible to reduce the problems we had identified. In the previous system, all the robots other than the goalkeeper were attackers. Their only aim was to find the position of the ball and shoot it. However, this did not work as expected, since while all the robots were heading towards the ball, they were obstructing each other. In our new system each the robot has roles associated with it, being the defender, the attacker and the goalie. These roles are predefined rather than being assigned during the match through the communication of the robots. III.5.1 Planner of the Goalkeeper As seen in Figure III.7 the goalie first checks to see if the ball is nearby, if it is near, then it checks the distance, if the distance is far then it just aligns itself with the ball, if it is close enough, it starts clearance which consists of dribbling and shooting. But at any state if the speed of the ball is larger than a predetermined value it tries to block the ball. While making a transition from the clear ball state to the “no threat” state, the goal keeper must perform GOBACKWARD behavior to position itself again in its goal. This is a difficult behavior to perform since it needs an excellent localization ability. 17 Figure III.7. Finite State Diagram for the goalkeeper III.5.2 Planner of the Attacker The planner of attacker given in Figure III.8 and it has been considerably simplified compared to the one in Cerberus 2002. In our previous version the robot keeps turning and turning if it cannot see the ball nearby, which is a waste of time. To solve this problem when the robot completes a turn of 360 degrees it moves four steps forward to search the ball at another place. At this state, if the robot moves towards the opponent goal, it can possibly support a team mate attacking that goal. Once the attacker possesses the ball, it dribbles to the opponent goal and when he is close enough he must shoot the ball. 18 Figure III.8. Finite state diagram of the attacker. III.5.3 Planner of the Defender The defender is the robot that is the closest to its own goal. The defender’s main requirement is positioning itself between the ball and its goal. This can be accomplished by computing the midpoint of the line segment between the middle of the goal and the ball, and positioning itself at that point. III.5.4 Multi-Agent Behaviors With the introduction of IEEE802.11 Wireless LAN card the robots are able to communicate effortlessly with each other by and OPEN-R SDK has enabled the communication to be carried in a simpler manner. The addition of the multi-agent behavior will increase the overall knowledge available to the individual the robotic agents, since they would be able to learn what their mates know. 19 Figure III.9. The finite state diagram for communicating players Multi-agent version of the attacker makes it easier for the players to find the ball. As players are able to communicate with each other, it will be sufficient for one player to find the ball. When a mate can’t see the ball, before beginning to search the ball, it will ask other mates whether they can see the ball. Only in the case that no player can see the ball, it will be necessary to perform a search operation. This does not mean that the other players would stay idle at this point. With communication, they can see the ball quicker than just blind search. Also communication of players will make it easier to attack. If an attacker gets the ball, dribbles it or shoots it, it can broadcast the updated latest information about the position of the ball and also of itself and that information can help other players a lot. Communication of players will make it possible that our team really plays collectively, like a real “team”. For example a player may not run to the ball if a mate is nearer to the ball than itself or a player can pass the ball to its “friend” if it is located in a more preferable position than itself. These and similar situations are needed to be considered for the effective working of a multi-agent behavior. 20 III.6 Wireless Communication III.6.1 Purpose of the system Wireless communication module is responsible of inter-robot communication for information change between the robots (i.e. positions of the robots and ball, tactical commands etc...), communication between game controller and transferring data from the robots to control center (log files, image data etc.) for debugging purposes. III.6.2 Overview The robots have IEEE 802.11 compliant wireless network adapter installed on them and each robot is associated with an IP address. Communication is done over TCP/IP. On the controller side, standard socket operations are used. On the robot side, there are some special objects (Endpoint) are required to establish a TCP connection. III.6.3 System Description We can decompose our system into three major subsystems: The robot-robot information exchange, Controller-robot communication, The robot-Controller information transfer for debugging and offline training purposes. III.6.3.1 The robot- robot information exchange Inter-robot communication is used to exchange data between teammates in the game to increase the knowledge of a player about the positions of the other the robots and ball. Tactical purposed commands can also be sent in the game for role assignment. We have developed a communication protocol for exchanging the world information but due to time limitations, the implementation of the inter-robot communication infrastructure could not be completed. As a result, we have competed in Padova as a team of single agents. III.6.3.2 Controller- robot communication This type of communication is used to send “Return to initial position” or “Start game” like signals to the robot during the game. This reduces the human interaction with the robots. The communication with game controller is completely implemented and was used during the competition. 21 III.6.3.3 The robot-Host information transfer The hardest part of making development on the robot is debugging. In order to have an idea about the state of the system and input data from sensors (image taken from the CCD camera, inputs from the odometer, etc...) we have decided to develop a software that allows us examine these information on the robot on a PC over the network. Implementation of the debugging software and image transfer utility for vision calibration is still ongoing and we are planning to use it in the next competition. 22 IV. DISCUSSION AND CONCLUSIONS Cerberus is an international team in the Sony Legged League. The cooperation between the Turkish and Bulgarian teams is mainly through the internet and only for a brief period just before Robocup the teams are generally able to work together in person. Even though internet provides good opportunities for communication, nevertheless distance hinders the pace for development. This year some of the modules were developed by both of the teams to be reviewed and then integrated into the final code. This year, the vision module is able to process images faster and with more accuracy. The locomotion capabilities of the robot have been improved vastly. The localization module is able to calculate the position of the robot with greater accuracy. The effects of these were seen in the Robocup 2003 games where the Cerberus team was more successful as compared to the previous years. Nevertheless the locomotion module still needs considerable improvement which will be one of the main focus of research for the team of Robocup 2004. The full implementation of the designed multi-agent behaviors together with relevant skills will also be carried out in 2004. 23 V. RESOURCES Our team agreed to make its code available to other teams. Our official website can be visited at http://the robot.cmpe.boun.edu.tr/aibo/home.php3. There exists also a local website of the Bulgarian group of the team: http://www.cerberus.dir.bg . 24 REFERENCES Arkin, R. C., 1998. Behavior-Based The robotics. The MIT Press, Cambridge, Mass. Köse, H. Bayhan S., and H. L. Akın, 2003." A Fuzzy Approach to Global Localization in the Robot Soccer Domain", TAINN 2003, The Tenth Turkish Symposium on Artificial Intelligence and Neural Networks. Pavlova, P. E., Tombakov, J. K., Shakev, N. G. (2002). “Fast Image Segmentation on the Basis of Color Hue and Saturation. International conference”, CompSysTech’2002, Sofia.