Team Description of the GMD RoboCup-Team A. Kuth, A. Bredenfeld, H. Günther, H.U. Kobialka, B. Klaassen, U. Licht, K.L. Paap, P.G. Plöger, H. Streich, J. Vollmer, J. Wilberg, R. Worst, T. Christaller GMD Institute for System Design Technology D-53754 Sankt Augustin, Germany kuth, bredenfeld, guenther, kobialka, klaassen, licht, paap, ploeger, streich, vollmer, wilberg, worst,
[email protected]
Abstract In this paper, we describe the GMD-Robots. These robots will be presented at the RoboCup 1999. RoboCup is the robot world cup soccer games and conferences. It offers the opportunity to examine a wide range of technologies in different research areas. RoboCup is a task for a team of multiple moving robots in a dynamic environment. In order for a robot team to actually perform a soccer game various technologies must be incorporate: design principles of autonomous robots (hardware and software design), robotics, strategy acquisition and sensor and actor fusion. We present the design methodology for a team of middle size robots.
1. Introduction RoboCup [4], [8], [9] is a long-term effort of the academic and industrial research community to demonstrate scientific and engineering problems related to the development of a team of robotic football/soccer players. This is a major challenge because fast movement and team coordination must be achieved at the same time.
• the ability to develop and execute plays and strategies in real time (strategy acquisition, real-time reasoning and planning and reactive behavior) • pre- and post-game training (machine learning). The research challenge is to find good solutions and sophisticated design methodologies for nearly all the items listed above. Although RoboCup is a football competition with significant social impact it is also a benchmark project for the different research areas. In the following paper we introduce the GMD-robot for the RoboCup 99. The hardware of this robot consists of an aluminum chassis with differential drives. It has low level sensors (odometry, distance sensors etc.) and a newtonLab vision system. The software is organized in a layered structure using a uniform design pattern on each layer. A synchronous communication paradigm is adopted for the information exchange between the different layers.
Although RoboCup´s final target is a world cup with real robots, RoboCup intended to corporate innovations in a wide range of technologies and the integration of technologies in a fully functional team.
The next section contains a short overview of the RoboCup scenario. Section 3 gives a detailed description of the GMD-robot. The system is structured in four layers. Each layer uses a similar design pattern. Section 4 and 5 present the details of this structure. Our design methodology uses a structured topdown approach. It is shown in Section 6. Concluding the paper we present results of our robotic activities.
To build a world-class robot-team will require expert knowledge of different design areas[3].
2. RoboCup Scenario
Here are only a few items that must be performed: • capable single players (autonomous agents, robotics, vision and real-time sensor fusion)
For a better understanding we give a description of the RoboCup Scenario. RoboCup is a task for a team of multiple fast moving robots (figure 1)
• teamwork (multiagent collaboration, context recognition)
Currently (Paris 98) RoboCup has six different leagues[8]:
• understanding the competition (cognitive modeling)
• Simulator League
1. 2. 3. 4. 5.
VU HW P
P H WH UV
Figure 1. GMD-robots and opponents on the playground connected to an external PC.
• Small Robot League (Formula 180(F-180) Class robots are used) • Full Set Small robot League, which is 11 robots per team (Formula 180(F-180) Class Robots) • Middle Size Robot League (Formula 2000: F-2000 Class Robots are used) • Legged Robot League (Exhibition Games for 1998) • Expert Robot League Our goal is the participation in the middle size league. The regulations for medium-size robots in this league are listed below [7]: • Team: A team should consist of no more than five robots. • Field: The dimensions are 457.5 cm by 822 cm. • Robot: It should be within a 50 cm diameter. Square size 45 x 45 cm2 • Duration of Games: Each half is 5 minutes, break is 10 minutes. • Colorings: The colors of each part of the field are as follows: The field is green. The wall is white. The ball is red. The lines are drawn in white. • Ball: The ball is a soccer ball (FIFA size 4 ball). • Goal and defense zones: The size of the goal is 150 cm and the size of the defense zone is 67.5 cm from the goal line and it has a width of 300 cm. The border of the defense zone is painted white and is 3 cm wide. Only one defense robot can enter this area. A brief passing and accidental entry of other robots are permitted, but intentional entry and stay are prohibited. • Fouls: Five different fouls are defined
multiple defense ball holding court modification robot halting offsides
• Charging: Unless striving for a ball a player must not attack another. Such an act is regarded as a violent action. The umpire presents a red card to the responsible player, ordering it to leave the game. Throughout the game, if a player uses a device or an action that continuously causes serious damages to another robot´s functions, the umpire can present a yellow warning card to the responsible player and order it to go outside the field court and correct the problem. Once the correction is made, the robot can resume playing the game with the improval of the umpire. If the problem reoccurs the umpire presents a red card to the player, telling it to leave the game. Aside from these items, no regulations are placed against possible body contact, charging, dangerous plays, obstruction, and so on. As shown in Figure 1 each team can use an external PC for wireless communication and data transmission. The single robot has to perform a lot of tasks e.g. wireless communication, vision and sensor fusion, motor- and bus-control. A more detailed description of the GMD-robot is presented in the next section.
3. GMD Robots Each RoboCup player has to perform several behaviors to act as a soccer player. Therefore we need compact and powerful actuators with a wide dynamic range. The GMD-robots consist of the following components (figure 2): • PC and Wavelan: The PC on each robot is a small laptop and a wavelan ethernet card is used for the wireless communication. • Vision System: Our vision system is a camera together with a board from NewtonLab, which is used to detect and track the ball. • Sensors: 4 color detectors determine the color of the surrounding objects. For RoboCup each robot must distinguish the colors of the ball, goals, wall and other objects in the playground. After learning a very fast object recognition is possible. 16 gray scale sensors are placed around the robot´s body.
They are able to measure the light intensity in the immediate vicinity of the robot.
Server PC (extern)
Server PC Wireless LAN
Robot PC
Robot PC Ethernet
Master Micro-Controller
C 167 CAN
Figure 2. Important components of the GMD-robot
Slave Micro-Controller
C 167
C 167
Motor Sensor
• Touch sensors: Bumper, constructed at the GMD, detects a collision of the robot e.g. with opponents or the wall. Furthermore the robot uses infra-red distance sensors. • Motor: The motor speed is controlled by PWM (pulse width modulation). A special brake function is included. • Micro-Controller: The robot is equipped with three 16-Bit Micro-Controllers [1] which are connected via a CAN-bus. The total implementation of the robot was performed in different layers. The four major layers are described in the system structure.
4. System structure For a robot which has to play soccer a wide range of different components need to be integrated. Because of the complexity of the whole structure we devide it in four layers. On each layer a uniform software pattern design is used (figure 3). A synchronous communication scheme is used for communication among the layers (figure 4). The server PC is an external PC which is able to communicate via a non-real-time LAN (local area network) with the Robot PC. RoboCup players need the information about which behavior to select for which situation. The external PC can perform this complex tasks. In our approach we call it a decision making process and it offers a kind of global strategy. The external PC has an overview of the playground / world and can locate each robot position in the playground-scenario. The PC can transmit the robot coordinates to other robots on the playground.
Figure 3. The system structure with the different layers of implementation.
The Robot PC is installed on top of each robot. On this PC a subset of local strategies is implemented because this makes each robot able to act in a useful autonomous way even when the network is down and the connection to the server PC is not active. The master-controller and the slave-controllers define the real-time layers. They are three 16-Bit Micro-Controllers (C167). These controllers are connected via a CAN-bus. The master-controller performs the low level decision making. The first C167 slave-controller processes the motor-, odometry, colorcell-, bumper- and linedetector-data and is responsible for the obstacle avoidance. The second C167 slave-controller processes the data of the distanceand gray-scale-sensors. The three micro-controllers perform the real-time processing of the robot system and communicate via the CAN bus whereas the server-PC and the robot-PC communicate via ethernet. If real-time processes are necessary in the whole system it is also possible to connect the controllers via the CAN bus directly to the robot-PC (this involves a changing of the robot-PC operating-system). The whole communication and data transmission between the four layers is organized in a synchronization scheme with slot frames (figure 4). The master-controller acts like a synchronous time clock and is responsible for the synchronization task between the different layers. The schedulers of each layer operate at different synchronization rates. The master controller runs at the highest synchronization rate. The rates of all other layers are derived from
The software pattern is devided into three parts. idle
Each of these parts is again subdivided in different subtasks.
poll task sync sync
data exchange
PC-Server
• World: The world models the actual playground and robot state depending on the sensor- and netvalues. The sensor-values come from the drivers and the net-values by wireless lan from the external PC.
Robot-PC
Master Controller
Slave Controller slot n
slot n+1
slot n+2
slot n+3
slot n+4
Figure 4. Synchronization of the different layers with slots.
this rate. Schedulers on the layer in between are synchronized from the master-controller. The conditions of the server-PC, the robot-PC and the slave-controller changes between polling and task processing.
5. Software Design A uniform software design pattern is used on each of the system layers. The pattern is depicted in Figure 5.
Decision Making
Goals
• Drivers: A sensor preprocessing is performed and the motor controller is implemented. The sensor preprocessing maps real world events to an internal presentation.
Symbolic Sensors
Action Selection Obstacle Avoidance
World
Drivers
World State Net
Update Arbiter
Net update
Move Update
Sensor Update
Sensor Preprocessing
Motor Controller
Figure 5. The three most important parts of the software design.
• Decision Making: For the decision making part the values of the world state are reduced to symbolic sensors. Each robot can define an own goal e.g. defender, goal keeper, striker and so on. The symbolic sensors and the robot goal are the input for the decision making process. After an action is selected a check for a collision is made. If a possible collision is detected an obstacle avoidance command is generated. If there is no collision the selected action can be checked again in the world and if it is a useful decision the transmission to the motor controller was performed.
6. Design Flow One of the RoboCup challenges is the implementation of a sophisticated design methodology. We use a top down design flow, which starts with an abstract description of the system and ends with an assembler software on a microcontroller hardware. On each level we check the design against the more abstract level. For each level we use different programming languages. Figure 6 shows on the left side the different programming languages that we employ in each design phase and on the right side the respective design times. The complexity of the design corresponds to the level of abstraction. This means a specification of the design environment in Java/TCL is less costly than a description at the lower assembler level. The overall design flow begins with an ideal system sitting inside its normal environment. From this we extract an executable specification in Java [2],[5] or TCL [6] used for the implementation of the ideal system. Java offers the advantage that we can demonstrate the function of the ideal system via the internet. This is very useful when different design groups, which are not at the same place, coorporate. Thus the ideal system description defined by this en-
ognition, vision, strategic decision making and intelligent motor control. Java / TCL HTML
Environment
Design-Time x1
IN
C++
Assembler
OUT
System Implementation
HW
µC-Code
x10
The GMD-robots (figure 7) are developed for a spectrum of different missions. Of course for the RoboCup they will act as soccer players but we have implemented a flexible and changeable platform. Therefore it is possible to use the robots in relevant research lines like, remote configuration, auto-calibration or a network communication in unreliable environments.
x100
Figure 6. Top-down design flow approach.
vironment model is the start point of the specification. At each successive level of refinement we stimulate the system with an incoming trace produced by the preceding and more abstract level. The outgoing trace of the lower level system description is compared against the corresponding data on the more abstract level. The equivalence check is used to validate the description on each level.
Figure 7. GMD-robot with the soccer ball.
8. References
This structured top-down design flow allows an integrated development from abstract simulations to detailed controller implementations.
[1]
7. Results
[3]
Building a robot to play soccer is a big challenge in different fields. The range of technologies spans AI, robotic research and embedded system design. Therefore robots are ideal demonstrators for a number of research activities since they offer opportunities to evaluate various strategy-theories, softwarealgorithms, hardware-architectures and design techniques.
[2]
[4]
[5] [6]
RoboCup tournament is designed to handle realworld complexities, although in a limited world, while it maintains an affordable size and research cost.
[7]
Researchers from different fields can use the robot platform to tackle problems like real-time sensor fusion, reactive behavior, strategy acquisition, learning, real-time planning, multiagent systems, context rec-
[9]
[8]
“C167 Dirivatives”16-Bit CMOS Single-Chip Microcontrollers, Users´s Manual, Version 2.0 P. Chan, R. Lee: “The Java Class Libraries”, Addison Wesley, 1997 S.Hedberg: “Robots playing soccer? RoboCup poses a new set of AI research challenges”, IEEE Expert Intelligent Systems & Their Applications, Z1888, 1997 H. Kitano, M. Asada, Y. Kuniyoshi, I. Noda, E. Osawa, H. Matsubara: “RoboCup”, AI Magazine, vol.18, No.1, 1997 P. Niemeyer & J. Peck: ”Exploring Java”, O´Reilly, 1996 John K. Ousterhout: “TCL und Tk”, Addison Wesley, 1995 Regulations & Rules: http:// www.robocup.v.kinotrope.co.jp/regulations/4.html RoboCup: The Robot World Cup Initiative: http:// www.csl.sony.co.jp/person/kitano/RoboCup/ RoboCup-old.html RoboCup: The Robot World Cup Initiative: http:// www.robocup.v.kinotrope.co.jp/02.html (new RoboCup page)
