Contents
1 Introduction 1 1.1 Motivation . . . 1 1.2 Objectives . . . 2 1.3 Thesis Outline . . . 2 2 RoboCup 3 2.1 RoboCup Soccer . . . 32.1.1 Small Size League . . . 3
2.1.2 Middle Size League . . . 4
2.1.3 Standard Platform League . . . 5
2.1.4 Humanoid League . . . 5
2.1.5 Simulation League . . . 6
2.2 RoboCup Rescue . . . 6
2.2.1 Rescue Simulation League . . . 6
2.2.2 Real Rescue Robot League . . . 6
2.3 RoboCup Junior . . . 7 2.3.1 Soccer Challenge . . . 7 2.3.2 Dance Challenge . . . 7 2.3.3 Rescue Challenge . . . 7 2.4 RoboCup@Home . . . 8 2.5 Symposium . . . 8 2.6 Chapter Summary . . . 8 3 SimSpark 9 3.1 System Overview . . . 9 3.1.1 The Server . . . 10
3.1.2 The Monitor and Logplayer . . . 10
3.2 SimSpark . . . 11
3.2.1 Perceptors . . . 11
3.2.1.1 General message format . . . 11
3.2.1.2 General Perceptors . . . 11
3.2.2 Effectors/Actuators . . . 15
3.2.2.1 General Effectors . . . 15
3.2.2.2 Soccer Effectors . . . 16
3.2.3 Simulation Update Loop . . . 17
3.2.3.1 Single-threaded Timer . . . 18
3.2.3.2 Multi-threaded Timer . . . 19
3.3 MonitorSpark . . . 20
3.3.1 Internal Monitor . . . 20
3.3.2 External Monitor . . . 20
3.3.3 Playing Log files . . . 20
3.4 Other simulators . . . 20 3.5 Players . . . 21 3.5.1 Soccerbot . . . 21 3.5.2 NAO . . . 24 3.5.2.1 Parameters . . . 24 3.6 Faced problems . . . 27 4 FC Portugal 28 4.1 The team . . . 28
4.1.1 Competitions & Awards . . . 28
4.2 3D Humanoid Agent . . . 29 4.2.1 Agent structure . . . 30 4.2.2 Basic behavior . . . 32 4.2.3 Low-level skills . . . 33 4.2.4 High-level skills . . . 34 4.2.4.1 Goalkeeper . . . 34 4.2.4.2 Field Players . . . 35 4.2.5 Strategy . . . 37 5 Low-level development 38 5.1 Kinematics . . . 38 5.1.1 Forward Kinematics . . . 39
5.1.1.1 Transformation matrices relative to previous joint . . . . 41
5.1.1.2 Transformation matrices relative to the vision . . . 44
5.1.1.3 Implementation . . . 45
5.1.2 Inverse Kinematics . . . 45
5.1.2.1 Algebraic method . . . 46
5.1.2.2 Numeric method . . . 47
5.2 Vision . . . 49
5.2.1 The two basis . . . 49
CONTENTS CONTENTS
5.2.2.1 Trilateration . . . 56
5.2.2.2 Change of Basis . . . 59
5.2.3 Calculation of World Objects locations . . . 61
5.2.4 Software implementations . . . 62
5.3 Ball movement prediction . . . 63
5.3.1 The prediction procedure . . . 64
5.3.2 Getting DragFactor . . . 65
5.3.2.1 Improving the precision of velocity and acceleration values . . . 67 5.3.3 Final considerations . . . 75 5.3.4 Software implementations . . . 75 6 High-level development 77 6.1 Omnidirectional walk . . . 77 6.2 Goalkeeper behavior . . . 78
6.2.1 Position to defend the goal . . . 79
6.2.1.1 Problems . . . 80
6.2.2 Leaving the “defense point” . . . 81
6.2.3 Defend shots to goal . . . 82
6.2.3.1 Initial version . . . 82
6.2.3.2 Using ball movement prediction . . . 83
6.2.4 Conclusion . . . 85
6.3 Players behavior . . . 85
6.3.1 Decision-making structure . . . 85
6.3.2 Walk towards the ball . . . 86
6.3.2.1 Move to point . . . 86
6.3.2.2 Move to ball . . . 88
6.3.3 Walk with the ball . . . 93
6.3.4 Avoid obstacles . . . 94
6.3.5 Shot . . . 95
6.3.5.1 Aiming precision . . . 95
6.3.5.2 Best point to shoot to and its utility value . . . 99
6.3.6 Conclusion . . . 102 6.4 Players communication . . . 103 7 Conclusion 105 8 Future work 107 8.1 Behaviors . . . 107 8.1.1 Pass . . . 107
8.1.2 Intercept passes & shots . . . 109
8.1.4 Walk backwards to avoid rotating . . . 110
8.2 Planning the path . . . 110
8.3 Vision . . . 111
8.3.1 Noise and Restricted vision . . . 111
8.3.2 Players posture estimation . . . 112
8.4 Usage of Inverse Kinematics . . . 113
8.5 Integration with FC Portugal strategy . . . 113
Bibliography 115 A SimSpark Installation 123 A.1 By source-code . . . 123
A.2 Fedora . . . 126
A.3 On other systems . . . 126
B Real robots 127 B.1 Fujitsu HOAP . . . 127 B.2 Honda ASIMO . . . 129 B.3 RoboSapien . . . 132 B.4 Sony AIBO . . . 134 B.5 Sony QRIO . . . 135 B.6 Aldebaran NAO . . . 136
B.7 Non-commercial (RoboCup participants) . . . 137
C Homogeneous coordinates systems and Denavit-Hartenberg method 138 D Forward Kinematics 142 D.1 Transformation matrices relative to previous joint . . . 142
D.2 Transformation matrices relative to the vision . . . 149
E Some derivative concepts 153 E.1 Derivative of a scalar function . . . 153
E.2 Derivative of a vectorial function . . . 154
E.3 Gradient . . . 154
E.4 Jacobian . . . 155
List of Figures
2.1 Small Size robot. Origin: [27] . . . 4
2.2 Middle Size robot: CAMBADA team . . . 4
2.3 Standard Platform robot: NAO. Origin: [1] . . . 5
2.4 Humanoid League robot: Darmstadt Dribblers team . . . 5
3.1 Hinge Joint. Origin: [41] . . . 12
3.2 Universal Joint. Origin: [41] . . . 13
3.3 Polar coordinates as supplied by the 3D Soccer Server [92] . . . 14
3.4 Single-threaded loop UML sequence diagram. Origin: [41] . . . 18
3.5 Synchronization between SimSpark and agent. Origin: [41] . . . 19
3.6 Multi-threaded loop UML sequence diagram, note that each SimCon-trolNode runs in separated thread. Origin: [41] . . . 19
3.7 Frontal view of the Soccerbot in the simulation . . . 22
3.8 Side view of the Soccerbot in the simulation . . . 22
3.9 Overview of the joints of the Soccerbot . . . 22
3.10 An example message from the server to the Soccerbot including infor-mation from all the sensors . . . 24
3.11 The NAO humanoid robot . . . 24
3.12 The joints of NAO robot. Origin: [41] . . . 25
4.1 FC Portugal agent structure . . . 30
4.2 WorldState package . . . 30
4.3 Skills hierarchical organization . . . 31
4.4 FC Portugal agent basic code . . . 32
4.5 FC Portugal decision making process . . . 33
4.6 Goalkeepers acting. Origin: [8] . . . 34
4.7 Examples of body relative direction . . . 36
5.1 Types of joints. Origin: [9] . . . 39
5.2 Redundant and non-redundant robot . . . 39
5.3 Determination of point location without forward kinematics. Body has 1 link. . . 40
5.4 Determination of point location without forward kinematics. Body has
2 links. . . 40
5.5 Inverse kinematics with no solutions for the desired point . . . 45
5.6 Redundancy: two robot configurations to achieve the same point . . . . 46
5.7 Vision basis . . . 50
5.8 Field basis . . . 50
5.9 Field and vision basis with the same origin . . . 53
5.10 Field and vision basis with the same origin . . . 53
5.11 Vision basis, field basis and its projections along vision basis . . . 54
5.12 Field basis projected along vision basis . . . 54
5.13 Dimensions of the field . . . 55
5.14 Dimensions of the field . . . 56
5.15 Player distance to Flag 2 . . . 56
5.16 Player distance to Flag 1, Flag 2 and possible locations . . . 57
5.17 Player distance to Flags 1, 2 and 3 and his location . . . 57
5.18 Player distance to Flag 2 in 3D . . . 58
5.19 Player distance to Flag 1, Flag 2 and possible locations in 3D . . . 58
5.20 Player distance to Flags 1, 2 and 3 and his location in 3D . . . 59
5.21 Field dimensions . . . 59
5.22 Player orientation . . . 60
5.23 Player locations restricted to a line . . . 60
5.24 Player location found . . . 61
5.25 Intercepting an opponent’s pass . . . 63
5.26 Catch an uncontrolled ball . . . 63
5.27 Pass the ball to a teammate . . . 64
5.28 Rolling ball with representation of velocity and friction force . . . 64
5.29 Ball position after a shot . . . 66
5.30 Calculated ball velocity after a shot . . . 66
5.31 Calculated ball acceleration after a shot . . . 67
5.32 Filtered ball movement,α=1, Position . . . 68
5.33 Filtered ball movement,α=1, Velocity . . . 69
5.34 Filtered ball movement,α=1, Acceleration . . . 69
5.35 Filtered ball movement,α=0.5, Position . . . 70
5.36 Filtered ball movement,α=0.5, Velocity . . . 70
5.37 Filtered ball movement,α=0.5, Acceleration . . . 71
5.38 Unfiltered versus filtered ball movement,α=0.5, Position . . . 71
5.39 Unfiltered versus filtered ball movement,α=0.5, Velocity . . . 72
5.40 Unfiltered versus filtered ball movement,α=0.5, Acceleration . . . 72 5.41 Unfiltered versus filtered ball movement of another shot,α=0.5, Position 73 5.42 Unfiltered versus filtered ball movement of another shot,α=0.5, Velocity 73
LIST OF FIGURES LIST OF FIGURES
5.43 Unfiltered versus filtered ball movement of another shot, α = 0.5,
Ac-celeration . . . 74
5.44 Predicted and real movement of two shots, DragFactor=0.03 . . . 75
6.1 Omnidirectional walk examples . . . 78
6.2 Two possible points for the goalkeeper to stay . . . 79
6.3 Situation where is better for the goalkeeper to go and kick the ball . . . . 79
6.4 Goalkeeper position calculation . . . 80
6.5 Goalkeeper unable to reach the ball . . . 80
6.6 Goalkeeper leaving the “defense point” to intercept the ball . . . 81
6.7 Goalkeeper trying to defend using the legs . . . 82
6.8 Security circle used by the goalkeeper . . . 83
6.9 Predicted ball position after s simulation cycles . . . 84
6.10 Goalkeeper diving to defend the goal . . . 84
6.11 Move to point, omnidirectional walk, relative direction is 0º . . . 87
6.12 Move to point, omnidirectional walk, relative direction is 45º . . . 87
6.13 Position of the player to be able to walk with ball or kick it . . . 88
6.14 Problematic positions for the player to go to the ball . . . 88
6.15 Move to ball, initial version . . . 89
6.16 Move to ball initial version problems . . . 90
6.17 Move to ball, version 2, step 1 . . . 90
6.18 Move to ball, version 2, step 2 . . . 90
6.19 Move to ball, version 2, step 3 . . . 91
6.20 Positioning behind the ball. Origin: [87] . . . 92
6.21 Walk with the ball . . . 93
6.22 Walk with the ball adjustments . . . 94
6.23 Player shooting the ball. Origin: [3] . . . 95
6.24 Shots to goal from difficult locations . . . 96
6.25 Influence of the position relation in the shot precision . . . 96
6.26 Frontal speed . . . 97
6.27 Lateral speed . . . 97
6.28 Rotation speed . . . 98
6.29 Player kicking the ball . . . 98
6.30 Possible points the player can shoot the ball to, for it to hit the goal . . . 99
6.31 Best shoot point calculation, step 1 . . . 100
6.32 Best shoot point calculation, step 2 . . . 100
6.33 Best shoot point calculation, step 3 . . . 100
6.34 Best shoot point calculation, step 4 . . . 101
6.35 Best shoot point calculation, step 5 . . . 101
6.36 Best shoot point calculation, step 6 . . . 102
6.38 Saying a message . . . 103
6.39 Hearing messages . . . 104
8.1 Situation where it’s better to shoot than pass . . . 108
8.2 Situation where it’s better to shoot than pass . . . 109
8.3 Situation where it’s better to pass than shoot . . . 109
8.4 Situation where is not good to perform the actual “walk towards the ball”110 8.5 Restricted vision . . . 111 B.1 Fujitsu HOAP-1 . . . 128 B.2 Fujitsu HOAP-2 . . . 128 B.3 Honda E0 prototype . . . 129 B.4 Honda E1 to E5 prototypes . . . 130 B.5 Honda E6 prototype . . . 130 B.6 Honda P1 prototype . . . 131
B.7 Honda P2 and P3 prototypes . . . 131
B.8 Honda ASIMO . . . 132
B.9 RoboSapien . . . 133
B.10 NimbRo robots. Origin: [22] . . . 133
B.11 Sony AIBO playing soccer at RoboCup . . . 134
B.12 Sony QRIO. Origin: [25] . . . 135
B.13 NAO. Origin: [1] . . . 136
B.14 Darmstadt Dribblers robot . . . 137
C.1 Denavit-Hartenberg representation, step 1 . . . 140
C.2 Denavit-Hartenberg representation, step 2 . . . 140
C.3 Denavit-Hartenberg representation, step 3 . . . 140
C.4 Denavit-Hartenberg representation, step 4 . . . 141
C.5 Denavit-Hartenberg representation, step 5 . . . 141
E.1 Derivative of a function. Origin: [36] . . . 153
E.2 Gradient of a function. Origin: [36] . . . 155
List of Tables
3.1 Physical properties of the Soccerbot . . . 23
3.2 Perceptor and effector names . . . 23
3.3 Configuration of NAO, table 1 . . . 25
4.1 Goalkeeper’s behavior, initial version . . . 35 4.2 Goalkeeper’s behavior, initial version (Move to Default Point) . . . 35 4.3 Goalkeeper’s behavior, initial version (Turn to opponent’s goal) . . . 35 4.4 Field players’ behavior, initial version . . . 36 5.1 Numeric Inverse Kinematics . . . 48 5.2 setMyPosition() . . . 62 5.3 RelativeToAbsoluteCoordinates(RelativeCoordinates: Vector): Vector . . 62 5.4 AbsoluteToRelativeCoordinates(AbsoluteCoordinates: Vector): Vector . 62 5.5 positionInNCycles(currentPosition, currentVelocity, currentAcceleration:
Vector; nCycles: unsigned): Vector . . . 76 5.6 nCyclesToPosition(currentPosition, currentVelocity, currentAcceleration,
desiredPosition: Vector; tolerance: float; nMaxCycles: unsigned): int . . 76 6.1 Calculation of goalkeeper’s “defense point” . . . 80 6.2 Goalkeeper leaving the “defense point” to kick ball . . . 81 6.3 Goalkeeper defense method using legs . . . 82 6.4 Goalkeeper behavior using ball movement prediction . . . 84 6.5 Agent decision-making basic structure . . . 85 6.6 Field players’ walk, initial version . . . 86 6.7 Move to point, pre-omnidirectional walk . . . 87 6.8 Move to ball, initial version . . . 89 6.9 Move to ball, version 2 . . . 91 6.10 Avoid obstacles . . . 95
Chapter 1
Introduction
1.1
Motivation
Robotics is a domain in very fast expansion in the last years. The Robot World Cup Initiative (RoboCup) attempts to use a soccer game as a way of fostering research in the Artificial Intelligence and Robotics domains, by providing a standard problem where a wide range of technologies can be integrated and examined. This provides re-searchers a wide range of research topics such as design of autonomous agents, multi-agent collaboration, strategy and real-time reasoning.
RoboCup provides a wide range of platforms to study, from two-legged robotic simulation to wheeled robots in a real environment or disasters victims rescue, each one with specific challenges. Among the different leagues of RoboCup, there is the Simulation League, that is focused on strategic and multi-agent coordination-related issues.
FC Portugal is a team that has been participating in some of the simulation leagues, such as 2D Simulation League, Rescue Simulation, Coach competition, 3D Spheres Simulation League, among others. In 2007, FC Portugal has participated in a newly created league of RoboCup: 3D Humanoid Simulation League. This new league, that has replaced the 3D Spheres Simulation League, gives the simulation leagues the abil-ity to do research in the humanoid robots domain and simultaneously keep the re-search in the domains that already have been subject of rere-search by the simulation leagues teams.
In the 2008 edition of RoboCup, FC Portugal will participate again in the 3D Hu-manoid Simulation League. This is the base for the work developed in this project. This thesis will focus this league and its simulator, analyze 2007 FC Portugal agent and the improvement made to it.
1.2
Objectives
The objective of this project is to specify, implement, test and evaluate some of the main modules of the 3D humanoid FC Portugal agent. It must be considered the architecture of the humanoid agent, the integration of sensory and communication information in the knowledge database of the agent (world state). Also the high-level decision processes and the strategic coordination of the players must be considered.
In other words, the objective of this project is to improve the FC Portugal agent used in RoboCup 2007 by creating a flexible decision-making structure for the agent and improving and developing new behaviors for the player. The development done must also create a solid base in which future research can be done and integrated.
1.3
Thesis Outline
This thesis is organized as follows:
Chapter 2 introduces the RoboCup international initiative and the different competi-tion existent in it.
Chapter 3 presents the simulator used in this work, SimSpark. Are also detailed the two robot models used in this project and seen another real robots widely used in the same research areas as this project.
Chapter 4 introduces the FC Portugal team, its major research areas and awards, and its 3D Humanoid agent used in RoboCup07, which has been the base for this project.
Chapters 5 & 6: in these two chapters, the improvements done to the agent are de-scribed. The concepts, the procedures and the problems found during the project are highly detailed. In chapter 5 are discussed the parts of the work more lower-level related, such as kinematics and vision. In 6 we focus on high-lower-level behav-iors, like determine the best point of the goal to shoot the ball or avoidance of obstacles.
Chapters 7 & 8 present the conclusions of this project and the work and research areas the could be useful to do next in this team.
Chapter 2
RoboCup
RoboCup is an international robotics project that started in 1997. It aims to pro-mote intelligent robotics and artificial intelligence research, by providing a standard problem where a wide range of technologies can be integrated and examined. The goal of the RoboCup project is:
«By mid-21st century, a team of fully autonomous humanoid robot soccer players shall win the soccer game, comply with the official rule of the FIFA, against the winner of the most
recent World Cup.» [18]
Currently RoboCup has four major types of competitions, which are RoboCup Soc-cer, RoboCup Rescue, RoboCup Junior and RoboCup@Home, each with a number of leagues that focus on different aspects of this challenge.
This chapter is adapted from [74].
2.1
RoboCup Soccer
Why soccer? In order to a robot to play soccer reasonably well, there are a number of technologies that must be integrated, and a number of technical breakthroughs must be accomplished. These include design principles of autonomous agents, multi-agent collaboration, strategy acquisition, real-time reasoning, robotics, and sensor fusion [60]. Besides that, soccer is a well known sport around the world and it is loved all around the globe. This motivates people to do research in an area that involves their loved sport.
2.1.1 Small Size League
Small Size robot soccer focuses on the problem of intelligent multi-agent cooper-ation and control in a highly dynamic environment with a hybrid centralized/dis-tributed system.
The field of a Small Size League game has 4.9 by 3.4 meters of dimension and its ground is green. The robots can use two types of vision:
Figure 2.1: Small Size robot. Origin: [27]
Global The robots make use of a camera placed above the field and a computer to calculate its and others position. The recognition of which robot is which is made by using the colors that the robots have in its top (like noticed in Figure 2.1). This type of vision is the most commonly used.
Local Some teams prefer to have the vision sensor in the robots itself.
The robots have wheels to move around the field and to have dimensions following the rules of this league: its diameter must fit within 18 cm and they can be no higher than 15 mm (excluding the on-board vision, if used). The games are between teams of five players each [21].
2.1.2 Middle Size League
In the Middle Size League each team is composed of 4 to 6 robots with maximum size of 50x50cm base, 80cm height and a maximum weight of 40Kg, playing in a field of 18x12m. The rules of the game are similar to the official FIFA rules, with required changes to adapt for the playing robots.
Figure 2.2: Middle Size robot: CAMBADA team
Each robot is autonomous and has its own sensory means. They can communicate among them through a wireless network and with an external computer acting as a coach. This coach computer has no sensor of any kind, it only knows what is reported by the playing robots. The agents should be able to evaluate the state of the world and make decisions suitable to fulfill the cooperative team objective.
CHAPTER 2. ROBOCUP 2.1. ROBOCUP SOCCER
2.1.3 Standard Platform League
In the Standard Platform League, all teams use identical robots. The league has re-cently transitioned from the Sony AIBO four-legged robot and now uses the humanoid Aldebaran NAO (see section 3.5 for more details about these two robots).
Figure 2.3: Standard Platform robot: NAO. Origin: [1]
By using identical robots, the teams concentrate on software development only, while still using state-of-the-art robots. The robots operate fully autonomously, not using any external control, neither by humans nor by computers.
2.1.4 Humanoid League
In the Humanoid League, autonomous robots with a human-like body play soc-cer against each other. In addition to socsoc-cer games, penalty kick competitions and technical challenges take place. The robots are divided into two size classes: KidSize (30-60cm height) and TeenSize (80-130cm height).
Figure 2.4: Humanoid League robot: Darmstadt Dribblers team
Dynamic walking, running, and kicking the ball while maintaining balance, visual perception of the ball, other players, and the field, self-localization and team play are among the many research issues investigated in the Humanoid League.
2.1.5 Simulation League
There are no actual robots in the RoboCup Soccer Simulation League, all the action occurs within a computer simulation. Each simulated robot player is a computer pro-cess that interact with one common simulator that receives the orders from the players and gives them feedback.
The main advantage of the Simulation League is that it is a kind of Standard Plat-form League (with all the advantages of this league) with the additional advantage of the robots doesn’t suffer any kind of damage.
The 3D Humanoid Simulation League will be seen with more detail in this docu-ment, as this work is based on it.
2.2
RoboCup Rescue
Disaster rescue is a socially significant problem and has common features with game of soccer in various aspects, such as dynamic environment, incomplete and noisy information. It also has features that are missing in soccer, such as logistics, het-erogeneous agents, long-range planning, and emergent collaboration between teams of agents [18, 16].
RoboCup Soccer is defined as the landmark project, which has the goal of building a team of fully autonomous humanoid which beats human World Cup champion by 2050, and aims at spreading of technologies developed for the accomplishment of the goal. On the contrary, the RoboCup Rescue define itself to be the grand challenge project, where the accomplishment of its long range goal directly contribute to the society. Thus, RoboCup Rescue is a research and development initiative by itself, as well as being a domain of application of technologies developed through RoboCup Soccer [18].
RoboCup Rescue currently has two leagues: Simulation League and Real Robot League.
2.2.1 Rescue Simulation League
RoboCup Rescue Simulation main purpose is to provide emergency decision sup-port by integration of disaster information, prediction, planning, and human interface. A generic urban disaster simulation environment is constructed on network comput-ers. Heterogeneous intelligent agents such as fire fighters, commanders, victims, vol-unteers, etc. conduct search and rescue activities in this virtual disaster world.
2.2.2 Real Rescue Robot League
In the Real Robot Rescue League a real rescue scenario with victims spread around a building is used as the basis of the competition.
CHAPTER 2. ROBOCUP 2.3. ROBOCUP JUNIOR
2.3
RoboCup Junior
RoboCup Junior introduces the aims and goals of the RoboCup project to the pri-mary and secondary school age level. RoboCup Junior started in 1998 with a demon-stration held at the RoboCup international competition in Paris, France. In 2000, the first international RoboCup Junior competition was held in Melbourne, Australia.
RoboCup Junior offers several challenges, each emphasizing both cooperative and competitive aspects. For children, the Junior initiative provides an exciting introduc-tion to the field of robotics, a new way to develop technical abilities through hands-on experience with electronics, hardware and software, and a highly motivating oppor-tunity to learn about teamwork while sharing technology with friends. In contrast to the one-child-one-computer scenario typically seen today, RoboCup Junior provides a unique opportunity for participants with a variety of interests and strengths to work together as a team to achieve a common goal [18].
2.3.1 Soccer Challenge
In the RoboCup Junior Soccer Challenge, 1-on-1 or 2-on-2 teams of autonomous mobile robots play in a dynamic environment, tracking a special light-emitting ball in an enclosed, landmarked field. For the 1-on-1 League the robot must fit inside an upright 18cm diameter cylinder, while for the 2-on-2 League the robot must fit inside an upright 22cm diameter cylinder [15].
2.3.2 Dance Challenge
A team creates both one or more robots and a dance composition. The goal of the competition is to create a two minute dance choreographed to music, with particu-lar attention going to construction, programming and creativity. A panel of judges decides the winner based on a number of different criteria.
2.3.3 Rescue Challenge
In the RoboCup Junior Rescue Challenge, small autonomous robots must follow a black line on the floor. Along that line there are several “victims” (that can be identi-fied by being made of either green tape or aluminum foil that should be located by the robot. Besides the “victims”, the route may have ramps, obstacles or gaps on the black line. The final score is based on the total time, as well as the ability to locate victims, manage obstacles and gaps in the black line, and on penalties suffered along the route [14].
2.4
RoboCup@Home
RoboCup@Home focuses on real-world applications and human-machine interac-tion with autonomous robots. The aim is to foster the development of useful robotic applications that can assist humans in everyday life.
The competition of RoboCup@Home consists of tests which the robots have to solve. The tests will change over the years to become more advanced and function as an overall quality measurement in desired areas.
The tests should:
• include human machine interaction • be socially relevant
• be application directed/oriented • be scientifically challenging • be easy to set up and low in costs
• be simple and have self-explaining rules • be interesting to watch
• take a small amount of time
The ultimate scenario where the RoboCup@Home aims to work on is the real world itself. To build up the required technologies gradually a basic home environment is provided as a general scenario. In the first years it will consisted of a living room and a kitchen but it is also starting to involve other areas of daily life, such as a garden/park area, a shop, a street or other public places.
2.5
Symposium
The RoboCup events also hold a Symposium where the achieved goal in the dif-ferent research areas are presented and discussed.
2.6
Chapter Summary
This chapter presented the RoboCup international initiative, its goals and its most important leagues. One of them – 3D Humanoid Simulation League – will be analyzed with more detail following in this document since this work is based on that league.
Chapter 3
SimSpark
SimSpark is a multi-agent simulation system for agents in three-dimensional en-vironments. Its goal is to provide a high degree of flexibility for creating new types of simulations. It builds on a flexible application framework and exhausts the idea of replaceable components throughout its implementation.
In comparison to specialized simulators, users can create new simulations by using a scene description language. SimSpark is a powerful tool to state different multi-agent research questions and is used as the official simulator for the RoboCup 3D Simulation League competition.
Information about how to install SimSpark in your computer can be found in A. This chapter is based on [41].
3.1
System Overview
SimSpark is built upon an application framework called zeitgeist. This framework provides basic Operating System abstractions (like file and archive support, logging, shared libraries etc.), a scripting interface to Ruby and a powerful plugin mechanism coupled with an object hierarchy that provides a unified namespace. This library is the backbone of the system.
Zeitgeist allows to load new classes at runtime from plugins and install object in-stances in a hierarchy. It’s then possible to locate these inin-stances via path expression just like files in a file system. At various well known locations are objects called servers that provide services to other parts of the system. The script server that provides an interface to the Ruby it’s installed at .
Built as part of this object hierarchy is a scene graph used by the system to repre-sent the simulated world. This scene graph and related concepts are managed within the next layer of the system, called oxygen. It provides classes that encapsulate con-cepts like transformations, basic geometric primitives, physical bodies and collision primitives. It further provides access to a rigid body physical simulation.
man-agement and a monitor framework. It is responsible to keep track and to update con-nected agents and monitor processes. It also provides a customizable run loop service. This service is implemented as an abstract run loop that is extended with plugins as needed. In parts of the system can be replaced or left out easily as for example render-ing or monitor support.
The visualization of the scene and input event processing services are provided by the kerosin library. It implements the infrastructure for rendering and device man-agement. Concrete implementations are again provided by plugins. This allows the simulation to use different backends or graphic engines. A default set of plugins uti-lizes plain OpenGL and the SDL library.
3.1.1 The Server
The SimSpark server hosts the simulation process that manages the simulation. It is responsible to advance the simulation, i.e. modify the simulation state in a continu-ous run loop.
Objects in the scene change their state, i.e. one ore more of their properties like position, speed or angular velocity changes due to several influences. They are under the control of a rigid body physical simulation, that resolves collisions, applies drag, gravity etc. Agents that take part in the simulation also modify objects with the help of their effectors.
Another responsibility of the server is to keep track of connected agent processes. Each simulation cycle the server collects and reports sensor information for each of the sensors of all connected agents. It further carries out received action sequences that an agent triggers using its available effectors.
Depending on the setup of the server it renders the simulation itself, i.e. it imple-ments an internal monitor that omits the network overhead or it manages and updates remote monitor processes. In the latter configuration the rendering of the scene is de-ferred to remote processes.
3.1.2 The Monitor and Logplayer
The SimSpark monitor is responsible to render the current simulation. It connects to a running server instance from which it continuously receives a stream of update data that describes the simulation states either in full or as incremental updates rela-tive to the preceding state.
The format of the data stream that the server sends to the monitor is called . It is a customizable language used to describe the simulation state.
Apart from describing the pure simulation state each monitor format may provide a mechanism to transfer additional game specific state. For the soccer simulation this means for example current play mode and goals scored so far.
CHAPTER 3. SIMSPARK 3.2. SIMSPARK
The monitor client itself only renders the pure scene and defers the rendering of the game state to plugins. These plugins are intended to parse the game state and display it as an overlay, e.g. print out playmode and scores on screen.
The monitor can further be configured to read a protocol of scene updates from a file and act as a . In this mode it does not connect to a server instance but replays a recorded game. The format of the logfile is identical to the monitor protocol used on the network.
3.2
SimSpark
In this section will be presented information about the messages that are sent from the server to the agent (perceptors) and vice-versa (effectors).
3.2.1 Perceptors
Perceptors are used to sense the environment of the agent. They are sent from the server to each agent and contain agent specific and perceptor specific information about the environment and the agent itself. There are perceptors that are available to all kinds of simulations and soccer specific perceptors.
3.2.1.1 General message format
Messages from and to the server use S-expressions (short for symbolic expressions) as their basic data structure. The basic idea of S-expressions is very simple: they are either strings, or lists of simpler S-expressions. They are probably best known for their use in the Lisp family of programming languages where they are used for both code and data.
An advantage of using S-expressions over other data formats is that it provides an easy to parse and compact syntax that is to some extent still readable by humans for debug purposes. It is further easy to add new sensors to the messages as the parser on the client side can easily ignore unknown parts.
Messages exchanged between client and server use the default ASCII character set, i.e. one character is encoded in a single byte.
3.2.1.2 General Perceptors
The perceptors described next are available to all types of simulation. In other words they are not specific to the soccer environment.
GyroRate Perceptor The gyro rate perceptor delivers information about the orienta-tion of a body. Currently only the upper torso contains a gyro perceptor. The message contains the GYR identifier, the name of the body to which the gyro perceptor belongs
and three rotation angles. These angles describe the orientation of the body with re-spect to the global coordinate system.
• Message format:
HingeJoint Perceptor A hinge joint perceptor receives information about the angle of the corresponding single axis hinge joint. It contains the identifier HJ, the name of the perceptor (see Table 3.2) and the position angle of the axis. Zero degrees corre-sponds to straightly aligned bodies. A hinge joint is displayed in figure 3.1.
Figure 3.1: Hinge Joint. Origin: [41]
• Message format:
UniversalJoint Perceptor A universal joint perceptor receives information about the two angles of the corresponding two axis universal joint. It contains the identifier UJ, the name of the perceptor (see Table 3.2) and the position angles of the two axis. Zero degrees corresponds to straightly aligned bodies.
After the moment that Soccerbot was replaced by NAO as the robot used in the soccer simulation, this kind of joint is no longer used. When necessary to implement this kind of joint, two hinge joints placed in the same location will do just the same. A universal joint is displayed in figure 3.2.
• Message format:
Touch Perceptor This perceptor works like a bumper that is triggered if the agent part to which it is mounted collides with another simulation object. The perceptor always reports its own unique name. This allows the use of more than one touch-perceptor per agent. Further the value 0 meaning no collision detected or 1 meaning collision detected is given.
CHAPTER 3. SIMSPARK 3.2. SIMSPARK
Figure 3.2: Universal Joint. Origin: [41]
ForceResistance Perceptor This perceptor informs about the force that acts on a body. Currently, it is available for the left and the right foot (lf, rf). After FRP and the name of the body it contains two vectors that indicate the point on the body to which the force applies and the force vector itself.
• Message format:
3.2.1.3 Soccer Perceptors
The following perceptors are soccer specific and only available in the soccer simu-lation.
Vision Perceptor The robots possess a special omnicam as viewing system. If using the regular VisionPerceptor, robots have a 360 degrees view. With the RestrictedVi-sionPerceptor, the view field of the robot is restricted to 90 degrees (this is configurable in rcssserver3D.rb). The direction of the view (pan and tilt) can be changed with the pantilt effector. The camera can pan to any angle (the initial 0 degrees pan direction is the direction towards the opponent side), and tilt around the horizontal plane. The RestrictedVisionPerceptor still in development and is not used yet.
The VisionPerceptor delivers lists of seen objects, where objects are either others robots, the ball, or markers on the field. Currently there are 8 markers on the field: one at each corner point of the field and one at each goal post.
With each sensed object the agent gets (see Figure 3.3): • The distance between the player and the object.
• The angle in the horizontal plane. Zero degree means the object is in front of the player.
Figure 3.3: Polar coordinates as supplied by the 3D Soccer Server [92]
Contrary to 2D soccer simulation, the vision system does not deliver object veloci-ties. All distances and angles are given relative to the camera position. The camera is currently located at the center of the robot’s torso.
The Vision perceptor includes also the possibility to add some noise to the infor-mation sent to the players. This possibility is not being used yet.
A vision message is started with “See” followed by the visible objects. Possible objects are:
• Flags: The marker flags on the field corners F1L, F1R, F2L, F2R • Goalposts: The goal posts of both goals G1L, G1R, G2L, G2R • Ball: The ball B
• Players: Players P with additional information • Message format:
GameState Perceptor The GameStatePerceptor contains information of the current play time which starts from zero at kickoff of either half. It also contains the current game status. The first percept you get from this perceptor additionally tells you about some of the game variables, like ball weight and field size.
All other percepts start with GS and contain the current simulation time as a float value passed in seconds and the playmode. At the moment, the possible playmodes
are "BeforeKickOff", "KickOff_Left", "KickOff_Right", "PlayOn", "KickIn_Left", "KickIn_Right", "corner_kick_left", "corner_kick_right", "goal_kick_left", "goal_kick_right", "offside_left", "offside_right", "GameOver", "Goal_Left", "Goal_Right", "free_kick_left", "free_kick_right", "unknown".
• Message format:
AgentState Perceptor The AgentState perceptor gives information about the inter-nal state of the agent. It reports information about the current battery status and the temperature of the agent. This is not in use at the moment.
CHAPTER 3. SIMSPARK 3.2. SIMSPARK
• Message format:
Hear Perceptor Agent processes are not allowed to communicate with each other di-rectly, but agents may exchange messages via the simulation server. For this purpose agents are equipped with the so-called hear perceptor, which serves as an aural sen-sor and receives messages shouted by other players. Actually the underlying model stems from the 2D Soccer Simulation and has been integrated in the 3D simulator since server version 0.4. Percepts have the following format:
• Message format:
The value of time is a real number and reflects the time when the given message was heard. Source is either the relative direction in degrees where the sound was located, or if the player has a statement by his own. Message may consist of characters from the ASCII printing character subset[0x20, 0x7E], among which the alphanumer-ical symbols and mathematalphanumer-ical operators can be found for example. Three characters from this range are, however, excluded: the white space character () and the normal brackets and .
The hear perceptor comes up with some restrictions: 1. Messages are restricted to a maximal length.
2. Messages shouted from beyond a maximal distance cannot be heard.
3. The number of messages which can be heard at the same time is bounded: Each player has the maximal capacity of one heard message by a specific team ev-ery two sensor cycles (thus evev-ery 0.4 seconds per team). There are separately tracked capacities for both teams, because teams should not be able to block the hear perceptors of their opponents by shouting permanently. If more messages from players of one team arrive, they are processed in the order of arrival; the re-maining messages are simply not heard. Messages shouted by oneself, though, can always be noticed [92].
3.2.2 Effectors/Actuators
Effectors are used to act within the simulation. They are sent to the server to change the game state accordingly. There are effectors that are available to all kinds of simulations and soccer specific effectors.
3.2.2.1 General Effectors
The effectors described next are available to all types of simulation. In other words they are not specific to the soccer environment.
Create Effector When an agent initially connects to the server it is invisible and can-not take affect a simulation in any meaningful way. It only possesses a so called Cre-ateEffector.
An agent uses this effector to advice the server to construct it according to a scene description file it passes as a parameter. This file is used to construct the physical representation and all further effectors and perceptors.
• Message format:
After the agent representation is constructed in the server the agent should do further simulation specific setup. For example in the soccer simulation each agent is required to register to a team and acquire a unique player number. For these tasks usually a special effector like the SoccerInitEffector is used.
HingeJoint Effector Effector for all axis with a single degree of freedom. The first parameter is the name of the axis. The second parameter contains the change in angle of the joint.
• Message format:
UniversalJoint Effector Effector for all axis with a two degrees of freedom. The first parameter is the name of the axis. The second and third parameter contain the change in angle of the two joints. The order of the joints is the same as in the name.
• Message format:
Just like the UniversalJoint perceptor, this effector is not used since the NAO model has been adopted.
3.2.2.2 Soccer Effectors
The following effectors are soccer specific and only available in the soccer simula-tion.
Init Effector The init command is sent once for each agent after the create effector sent the scene command. It registers this agent as a member of the passed team with the passed number. All players of one team have to use the same teamname and different numbers. If an agent sends 0 as playernumber, the number is assigned au-tomatically by the server to the next free number. The side on which a team starts to play depends on which team connected first.
CHAPTER 3. SIMSPARK 3.2. SIMSPARK
Beam Effector The beam effector allows a player to position itself on the field before the game starts. The x and y coordinates define the position on the field with respect to the field coordinate system (see 5.2.1). The rot value allows to define the rotation angle of the player. Zero degrees points to positive x axis, 90 degrees to positive y axis.
• Message format:
Say Effector The say effector allows communication among agents by broadcasting messages. In order to say something, the following command has to be employed:
• Message format:
Message characters may be taken from the ASCII printing character subset[0x20, 0x7E]
except the white space character () and the normal brackets and . For details and restrictions please see Section 3.2.1.3, about the hear perceptor, the dual sensor to this actuator.
3.2.3 Simulation Update Loop
SimSpark implements a simple internal event model that immediately executes ev-ery action received from an agent. It does not try to compensate any network latency or compensate for different computing resources available to the connected agents.
A consequence is that SimSpark currently does not guarantee that events are re-producible. This means repeated simulations may have a different outcome, depend-ing on network delays or load variations on the machines hostdepend-ing the agents and the server.
A benefit of the simple structure however are speed gains that make it interesting for machine learning tasks as in these setups an often large number of different agent and simulation configurations are repeatedly tested.
Further the SimSpark main loop is highly customizable as it is entirely build upon plugins called simcontrol nodes. Simcontrol nodes are registered to the simulation server. They act in response to control events. The simulation server repeatedly gen-erates these as it executes an abstracted main loop.
The event types are an ‘init’ event once when the simulation server starts and a ‘done’ event on shutdown. The main then loop cycles repeatedly through the ‘start cycle’, ‘sense agent’, ‘act agent’ and ‘end cycle’ events.
Apart from generating control events the simulation server advances the simula-tion time passed in the last cycle. Depending on its configurasimula-tion it either does this in discrete time quanta or in one single step.
A simcontrol node further can take responsibility for the time measurement, for ex-ample to synchronize the simulation time with the real time used to render the scene. Otherwise the simulation is stepped a fixed time step as often as possible.
In this way all management tasks are implemented as plugins to the simulation server. This involves the agent management, monitor management, rendering, mouse and keyboard input and network code.
This setup allows us to configure the simulation at runtime as either a monolithic application that does both simulation and rendering or as a dedicated simulation server that defers rendering to a remote monitor application.
3.2.3.1 Single-threaded Timer
In the singled-threaded mode, the main loop cycles repeatedly through the ‘start cycle’, ‘sense agent’, ‘act agent’ and ‘end cycle’ events( see 3.4). There are two notice-able details:
• Each cycle duration is 20ms, if the simulation is fast than real time, it will wait; otherwise, if the simulation is very slow, it will run many physics updates once without interaction with agents. If the simulation is very slow, it will give up to catch up the real time and print warning. So you may have problem while the computer is not fast enough.
• The ‘act agent’ event is followed after ‘sense agent’, the action which the agent send according to nth cycle will be realized in the(n+1)thcycle, i.e. the action
has been delayed one cycle. See for 3.5 explanation.
CHAPTER 3. SIMSPARK 3.2. SIMSPARK
Figure 3.5: Synchronization between SimSpark and agent. Origin: [41]
3.2.3.2 Multi-threaded Timer
In modern time, computers have more than one CPU or dual cores in one CPU. This improve the performance greatly, but only multi-threaded programs can benefit. SimSpark has an experimental multi-threaded running loop, it can be switched on
simply by change the from to in
the b file.
The implementation of multi-threaded loop is based on two conditions.
First, every SimControlNode response for different parts of the simulation, they perform one by one in the singled-threaded mode but they can run in parallel.
Second, there is an active scene which stores the whole simulation data in a tree. The physics engine and SimControlNode interact through the active scene. The physics computation is the most time-consuming, and the physics engine does not need to ac-cess the active scene during physics computation. So the physics computation and SimControlNodes can run in parallel.
At last, we get the multi-threaded simulation loop as 3.6. Note that the agent’s action are also delayed one cycle in the multi-threaded loop.
Figure 3.6: Multi-threaded loop UML sequence diagram, note that each SimControlN-ode runs in separated thread. Origin: [41]
3.3
MonitorSpark
This section gives an overview about the available monitor and log player setups available in SimSpark, their configuration and usage.
3.3.1 Internal Monitor
The internal monitor implementation is part of the SimSpark server. It is enabled in the setup script by enabling the rendering and input plugins of the
server. To do so uncomment the lines and ,
i.e. remove the leading comment markers.
3.3.2 External Monitor
The external monitor implementation is called . It either connects to a running SimSpark instance or replays a simulation run from a log file.
3.3.3 Playing Log files
The monitor is able to replay a simulation that is recorded in a log file. It accepts a parameter on its command line that enables the log player mode.
3.4
Other simulators
SimSpark is chosen as the official simulator of the RoboCup Simulation 3D League, but there are other simulators.
Microsoft1has created its own robotics simulator. Like SimSpark, Microsoft Robotics Studio is a generic simulator that can be used to soccer simulations or any other kind of simulation related to the robotics area. Our own robots and environments can be built.
More information should be obtained in .
One very used simulation framework is “Player, Stage, Gazebo”2. This project is composed by three components (as the project name sujests). «Player is a network server for robot control. Running on a robot, Player provides a clean and simple inter-face to the robot’s sensors and actuators over the IP network. The client program talks to Player over a TCP socket, reading data from sensors, writing commmands to actu-ators, and configuring devices on the fly» [11]. Stage is a 2D simulator, while Gazebo is a 3D simulator.
Webots from Cyberbotics3is also becoming a very popular simulation engine.
1 2 3
CHAPTER 3. SIMSPARK 3.5. PLAYERS
URBI is a robotic platform built by Gostai4. It doesn’t have its own simulation
engine. Instead, it is focused on the programming language, specially designed for creation of parallel events. It has been integrated Webots, using its simulation en-gine. There is an interesting online competition based on the Webots simulator, NAO robot and URBI language. More detailed information can be found in
.
3.5
Players
As already discussed, the Simulation League (as all other RoboCup-related activi-ties) is in constant and fast progress. The 3D Humanoid Simulation League, as one of the youngest leagues in RoboCup is evolving a lot faster. This means a lot of options are taken, tried and discarded in a small amount of time. That’s what happened in consideration to the robots used in this competition.
During the time this work was being done the robot used has been discarded and a new one has been chosen. According to the discussion lists of the simulation league responsible people it occurred for two reasons: first to improve the realism of the 3D Humanoid Simulation; second to follow the RoboCup global strategy of using one robot in as many competitions as possible, excluding of course the leagues where building their own robots is part of the teams’ research work.
This player robot change implied some changes also in the simulator and in some parts of our agent.
3.5.1 Soccerbot
When this work began, the robot used was Soccerbot. This robot have been used in RoboCup07 competition [13].
This robot is based on a real robot: Fujitsu HOAP-2 [39, 40, 38] (more details in chapter B.1).
It is a humanoid robot with 20 degrees of freedom (DoF) as depicted in figure 3.9a. Its current dimensions are quite unrealistic for a real humanoid robot (see Table 3.1) which is due to instabilities in the physics simulation at the time the robot was first modeled. Another issue is that the joint ranges are not limited in this model. This allows for very unrealistic movements which can be fun to watch, but can lead to unfair behavior in a competition.
Figure 3.7: Frontal view of the Soccerbot in the simulation
Figure 3.8: Side view of the Soccerbot in the simulation LL5 LL6 RL5 RL6 LL4 RL4 LL2 LL3 RL2 RL3 LL1 RL1 LA1 LA2 RA1 RA2 LA3 RA3 LA4 RA4 lshoulder lupperarm llowerarm warm hhead htorso wleg lhip lthigh lshank wf oot lf oot (a) Overview of the degrees of freedom of the Soccerbot. Origin: [41]
(b) (c)
CHAPTER 3. SIMSPARK 3.5. PLAYERS
Name Width Depth Height Mass
head 0.39m (radius) 0.3kg torso 1.37m 0.96m 1.41m 1.8kg left_shoulder 0.445m 1.017m 0.536m 0.5kg right_shoulder 0.445m 1.017m 0.536m 0.5kg left_upper_arm 0.445m 0.398m 0.506m 0.2kg right_upper_arm 0.445m 0.398m 0.506m 0.2kg left_lower_arm 0.445m 0.316m 0.6m 0.2kg left_lower_arm 0.445m 0.316m 0.6m 0.2kg left_hip 0.273m 0.273m 0.2m 0.1kg right_hip 0.273m 0.273m 0.2m 0.1kg left_thigh 0.56m 0.56m 1.3m 0.25kg right_thigh 0.56m 0.56m 1.3m 0.25kg left_shank 0.56m 0.56m 0.964m 0.25kg right_shank 0.56m 0.56m 0.964m 0.25kg left_foot 0.6m 0.956m 0.095m 0.1kg right_foot 0.6m 0.956m 0.095m 0.1kg Table 3.1: Physical properties of the Soccerbot
The Soccerbot has several kinds of sensors available. It uses an omni-directional vision sensor (see section 3.2.1.3) to get information about objects in its environment5. In order to detect the contact with the ground and the resulting force at the feet, it is equipped with a Force Resistance Perceptor (see section 3.2.1.2) in each foot. It can sense the current simulation time with a GameState Perceptor (see section 3.2.1.3) and the change in orientation of its torso with a GyroRate Perceptor (see section 3.2.1.2). Furthermore, it has proprioceptive sensors that allow to sense the angle of each joint (see sections 3.2.1.2 and 3.2.1.2 for HingeJoint Perceptor and UniversalJoint Percep-tor descriptions, respectively). An overview over the joint percepPercep-tors and effecPercep-tors is given in Table 3.2.
Connection between Joint type Perceptor name Effector name Shoulder - body Universal joint laj1_2 raj1_2 lae1_2 rae1_2 Upper arm - shoulder Hinge joint laj3 raj3 lae3 rae3 Forearm - upper arm Hinge joint laj4 raj4 lae4 rae4
Hip - body Hinge joint llj1 rlj1 lle1 rle1
Upper leg - hip Universal joint llj2_3 rlj2_3 lle2_3 rle2_3 Lower leg - upper leg Hinge joint llj4 rlj4 lle4 rle4 foot - lower leg Universal joint llj5_6 rlj5_6 lle5_6 rle5_6
Table 3.2: Perceptor and effector names
Figure 3.10 shows an example message which the agent receives from the server in a single simulation cycle including sense information from all the perceptors of the agent.
Figure 3.10: An example message from the server to the Soccerbot including informa-tion from all the sensors
3.5.2 NAO
The NAO humanoid robot is manufactured by Aldebaran Robotics. Its height is about 57cm and its weight is around 4.5Kg. Its biped architecture with 22 degrees of freedom allows NAO to have great mobility. The rcssserver3D can simulate the NAO robot nicely, see 3.11. More details in section B.6.
(a) real robot (b) virtual robot
Figure 3.11: The NAO humanoid robot
3.5.2.1 Parameters
This section describes the model built, the configuration of the robot used by the simulator. Firstly, 3.12 is a picture that shows how the joints move. Second, Table 3.3 and Table 3.4 show the detailed parameters.
This section is very important for the implementation of Forward Kinematics (sec-tion 5.1.1).
CHAPTER 3. SIMSPARK 3.5. PLAYERS
Figure 3.12: The joints of NAO robot. Origin: [41]
Name Parent Translation Mass
Neck Torso 0, 0, 0.09 0.05 Head Neck 0, 0, 0.065 0.35 Shoulder Torso 0.098, 0, 0.075 (r) 0.07 -0.098, 0, 0.075 (l) Upperarm Shoulder 0.01, 0.02, 0 (r) 0.150 -0.01, 0.02, 0 (l) Elbow Upperarm -0.01, 0.07, 0.009 (r) 0.035 0.01, 0.07, 0.009 (l) Lowerarm Elbow 0, 0.05, 0 0.2 Hip1 Torso 0.055, -0.01, -0.115 (r) 0.09 -0.055, -0.01, -0.115 (r) Hip2 Hip1 0, 0, 0 0.125 Thigh Hip2 0, 0.01, -0.04 0.275 Shank Thigh 0, 0.005, -0.125 0.225 Ankle Shank 0, -0,01 -0.055 0.125 Foot Ankle 0, 0.03 -0.035 0.2 Torso 1.2171
Name Geometry Name Anchor Axis Min Max
Neck Cylinder HJ1 0, 0, 0 0, 0, 1 -120 120
L: 0.08 R:0.015
Head Sphere 0.065 HJ2 0, 0, -0.005 1, 0, 0 -45 45
Shoulder Sphere 0.01 AJ1 0, 0, 0 1, 0, 0 -120 120
Upperarm Box AJ2 -Translation 0, 0, 1 -95 (r) 1 (r)
0.07, 0.08, 0.06 0.02, -1 (l) 95 (l)
Elbow Sphere 0.01 AJ3 0, 0, 0 0, 1, 0 -120 120
Lowerarm Box AJ4 -Translation 0, 0, 1 -1 (r) 90 (r)
0.05, 0.11, 0.05 -90 (l) 1 (l)
Hip1 Sphere 0.01 LJ1 0, 0, 0 -0.7071, 0, 0.7071 -90 1
-0.7071, 0, -0.7071
Hip2 Sphere 0.01 LJ2 0, 0, 0 0, 1, 0 -45 (r) 25 (r)
-25 (l) 45 (l)
Thigh Box LJ3 -Translation 1, 0, 0 -25 100
0.07, 0.07, 0.14 Shank Box LJ4 0, -0.01, 0.045 1, 0, 0 -130 1 0.08, 0.07, 0.11 Ankle Sphere 0.01 LJ5 0, 0, 0 1, 0, 0 -45 75 Foot Box LJ6 0, -0.03, 0.035 0, 1, 0 -25 (r) 45 (r) 0.08, 0.07, 0.11 -45 (l) -25 (l) Torso Box 0.08, 0.07, 0.11
Table 3.4: Configuration of NAO, table 2
Meaning of each column from left to right in Table 3.3 and Table 3.4 are explained as follow:
Name the body part name of NAO Parent the parent of the body
Translation the offset relative to its parent Mass the mass of this body
Geometry the size of its geometry representation Name the joint name installed on this body
Anchor the offset of the joint anchor relative to the body that installed on Axis the joint axis relative to the body that installed on
Min the min angle that the joint can reach Max the max angle that the joint can reach
CHAPTER 3. SIMSPARK 3.6. FACED PROBLEMS
3.6
Faced problems
During this work two major issues have been presented to us: the constant evolu-tion of the simulator and the way players are seen by other players.
The first issue is easily understandable and expected. This simulator is in constant evolution. This leads to problems. For example, some work done based on a simulator version could have some problems or not run as expected in a new version. Also when the robot model changed from Soccerbot to NAO some problems have been faced like, for example, all the Forward Kinematics matrices have to be redone.
One of the major limitations of the actual SimSpark is that other players are simply represented by a single point. This doesn’t allow us to know if they are up or down on the ground, turned to our goal or theirs, etc. A possible solution to try to minimize this issue is discussed in 8.3.2.
FC Portugal
In this chapter will be briefly presented the FC Portugal team, its main research areas and some of the awards achieved.
It will be analysed the development state of the FC Portugal agent that participated in RoboCup 2007, the base for this project.
4.1
The team
FC Portugal is a joint project of Universidade de Aveiro and Universidade do Porto. The team participates in RoboCup competitions since 2000, including: 2D sim-ulation, 3D simsim-ulation, coach competition, rescue simsim-ulation, rescue infrastructure, legged and physical visualization.
The team research interests include [84]:
• Multi-Agent Systems (MAS) and Coordination in MAS;
• Intelligent Cooperative Robotics and Robotic Soccer (RoboCup); • Intelligent Simulation, Agent Based Simulation;
• Soccer, Game Analysis, Strategic Reasoning and Tactical Modelling; • Bridging the gap between simulated and real robotics.
4.1.1 Competitions & Awards
Thanks to its strong research-oriented strategy, FC Portugal has obtained very good results in several competitions, which lead to a full “trophy room”, from where some examples are:
• RoboCup 2000, Melbourne, Simulation League, Champions
• European RoboCup 2000, Amsterdam, Simulation League, Champions • RoboCup 2001, Seattle, Simulation League, 3rd Place
CHAPTER 4. FC PORTUGAL 4.2. 3D HUMANOID AGENT
• German Open 2001, Paderborn, Simulation League, Champions • RoboCup 2002, Fukuoka, Coach Competition League, Champions • RoboCup 2003, Padova, Coach Competition, 2th Place
• Portuguese Robotics Open 2004, Porto, Simulation league, Champions • RoboCup 2004, Lisbon, Coach Competition, 2th Place
• Portuguese Robotics Open 2005, Coimbra, Simulation league, Champions • European RoboCup 2006, Eindhoven, Rescue Sim. League, Champions • European RoboCup 2006, Eindhoven, Simulation League, 2nd Place • European RoboCup 2006, Eindhoven, Simulation 3D League, Champions • RoboCup 2006, Bremen, Simulation 3D League, Champions
• European RoboCup 2007, Hannover, Simulation 3D League, Champions • European RoboCup 2007, Hannover, Simulation League, 2nd Place • RoboCup 2007, Atlanta, Physical Visualization, 2nd Place
There is also a lot of publications related with work done for FC Portugal project [84].
4.2
3D Humanoid Agent
In this section we will see in detail the development state of the FC Portugal agent when this project started.
The FC Portugal Humanoid 3D team was built upon the team structure that has been used and improved along the last years in the different competitions FC Portugal has been present (see 4.1.1) [83].
Although the basic structure was taken from other competitions, this Humanoid 3D competition faces the teams with new problems. Problems that in other com-petitions didn’t exist, like basic moving around the field, for example. These new problems, which were easily solvable (or no problem at all) in other competitions, are some of the main research areas in the 3D Humanoid Simulation League. Things that seemed simple like walk in front and different directions, kick the ball and get up from the ground are now subject of intense research.
As the basic structure of the agent have been taken from older FC Portugal teams, some work was already done. Let’s see what was made, what can be useful and what needs improvement.
4.2.1 Agent structure
The agent structure is divided in five parts: four packages and the central module where the information is combined and the decisions are taken. The packages are all connected to the agent’s central module and are:
• World State • Utils • Geometry • Skills/Movs
Figure 4.1: FC Portugal agent structure
The World State package is the most complex of the packages. It provides all the information the agent needs to take decisions like conditions of the game (field length, goal width, etc), game state (current play mode, result, game time among others) and information about all the objects (own team players, opponent team players, land-marks and ball).
CHAPTER 4. FC PORTUGAL 4.2. 3D HUMANOID AGENT Utils package contain classes that are not directly related with the agent behavior
but help to make some tasks easier. Some examples are the creation of logs, commu-nication with the simulator, a message parser and a message composer to send the actions to the simulator.
The Geometry package is where the math and geometry related classes are located. Classes to operate with 2D and 3D vectors, circles and line segments are some exam-ples.
Skills/Movs package contains the basic skills the agent is able to perform, like walk,
kick, etc. This package contains only low-level skills, although there are different lev-els of skills. Skills can be considered in a hierarchical organization:
Figure 4.3: Skills hierarchical organization
As seen in Figure 4.3, generally we divide skills in two categories: low-level and high-level. More detailed information in 4.2.3 and 4.2.4.
These packages include some useful functions that were present in older FC Por-tugal teams and are also used in this agent.
This provides, among others, mechanisms of: • Communication with the simulator
• Parsing of the simulation messages • Mathematical and geometric operations • Identification of game state
• Knowledge of the field configuration (dimensions, existing elements – like flags – and its locations)
• Location of players from the opponent team • Location of the ball
• Self-location
4.2.2 Basic behavior
As already said, the FC Portugal 3D Humanoid agent is based on FC Portugal basic structure used in other leagues and competitions. Hence, some basic code was already done.
Figure 4.4: FC Portugal agent basic code
When a player is initialized his representation in memory is created (step 1). After that a message is sent to the simulator to communicate his own existence and readiness so the simulator can put him in the game (step 2). The steps 3 to 6 are executed in a loop that only stops when the simulation ends. Agent receives the message with game information from the simulator1 (step 3), processes the information and makes
decisions (steps 4 and 5) and sends his actions back to the simulator (step 6).
The decision making process (step 5) has also a behavior taken from older FC Por-tugal teams structure. This process is represented in Figure 4.5.
CHAPTER 4. FC PORTUGAL 4.2. 3D HUMANOID AGENT
Figure 4.5: FC Portugal decision making process
The decisions are based on the game state (see Section 3.2.1.3). Basically, when the player doesn’t have the right to touch the ball (according to regular soccer rules) he only positions himself on the game field according the strategy used (see 4.2.5) and waits the game state to change to one he can touch the ball. When he has the right to touch the ball his behavior is like described in 4.2.4.
4.2.3 Low-level skills
Low-level skills are the basis of the behavior of the agent. These low-level skills are also aliased as movs. These movs work like in a human being: combined in a sequence can produce more complex movs or a high-level skill. For example, a sequence of steps produce walk and a sequence of walk and turn can produce the skill go to a specific field
location.
At this initial point the agent possesses some low-level behaviors like • make a step
• lateral step (left and right) • walk
• rotate left • rotate right
• get up when player turned down
• get up when player turned down
These and other low-level actions have been studied and improved in [76].
4.2.4 High-level skills
High-level skills are more complex actions and are composed of low-level behav-iors. For example, we can consider go to ball a high-level action composed by walk and turn. Like the combination of several low-level skills compose high-level skills, several high-level skills compose more complex and strategic behaviors.
4.2.4.1 Goalkeeper
The goalkeeper is one of the most important players in the game field. He has special rules because he has a special mission: he can use the hands and his mission is to avoid the ball to hit his own goal.
Figure 4.6: Goalkeepers acting. Origin: [8]
When this project started, the goalkeeper behavior was very basic. It resumed to one simple action: the goalkeeper stands in front of the goal.
![Figure 3.12: The joints of NAO robot. Origin: [41]](https://thumb-eu.123doks.com/thumbv2/123dok_br/15977888.1102456/47.892.298.626.132.585/figure-joints-nao-robot-origin.webp)
![Figure 4.6: Goalkeepers acting. Origin: [8]](https://thumb-eu.123doks.com/thumbv2/123dok_br/15977888.1102456/56.892.262.617.682.1003/figure-goalkeepers-acting-origin.webp)
