Contents
1 Introduction 1 1.1 Motivation ...... 1 1.2 Objectives ...... 2 1.3 Thesis Outline ...... 2
2 RoboCup 3 2.1 RoboCup Soccer ...... 3 2.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.1.3 Soccer Perceptors ...... 13
I CONTENTS CONTENTS
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 5.2.2 Calculation of agent location ...... 55
II 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.3 Covering ...... 110
III CONTENTS CONTENTS
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 E.5 Approximated derivative ...... 155
IV 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
V LIST OF FIGURES LIST OF FIGURES
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 in3D...... 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
VI 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.37 Shot to the best point ...... 102
VII LIST OF FIGURES LIST OF FIGURES
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 E.3 Approximated value of the derivative. Origin: [36] ...... 156
VIII 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 3.4 Configuration of NAO, table 2 ...... 26
IX List of Algorithms
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
X 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 research 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 1.2. OBJECTIVES CHAPTER 1. INTRODUCTION
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-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.
2 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:
3 2.1. ROBOCUP SOCCER CHAPTER 2. ROBOCUP
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.
4 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 soccer 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.
5 2.2. ROBOCUP RESCUE CHAPTER 2. ROBOCUP
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.
6 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].
7 2.4. ROBOCUP@HOME CHAPTER 2. ROBOCUP
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.
8 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 instances 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. The oxygen library further implements basic simulation services like agent man-
9 3.1. SYSTEM OVERVIEW CHAPTER 3. SIMSPARK 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.
10 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
11 3.2. SIMSPARK CHAPTER 3. SIMSPARK 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.
• Message format:
12 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.
• The latitudinal angle. Zero degree means horizontal.
13 3.2. SIMSPARK CHAPTER 3. SIMSPARK
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.
14 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 mathematical 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 every 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.
15 3.2. SIMSPARK CHAPTER 3. SIMSPARK
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.
• Message format:
16 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 hosting 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 configuration 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.
17 3.2. SIMSPARK CHAPTER 3. SIMSPARK
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)th cycle, i.e. the action has been delayed one cycle. See for 3.5 explanation.
Figure 3.4: Single-threaded loop UML sequence diagram. Origin: [41]
18 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]
19 3.3. MONITORSPARK CHAPTER 3. SIMSPARK
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. Microsoft1 has 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 Cyberbotics3 is also becoming a very popular simulation engine.
1 2 3
20 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.
4
21 3.5. PLAYERS CHAPTER 3. SIMSPARK
Figure 3.7: Frontal view of the Soccerbot in Figure 3.8: Side view of the Soccerbot in the the simulation simulation
h RA1 head
w RA2 arm RA3 LA1
LA2 l RA4 shoulder h LA3 torso w leg l RL1 LA4 upperarm LL1 RL2 l LL2 lowerarm RL3 l hip LL3
l RL4 thigh LL4
l RL5 shank LL5 RL6 LL6 l w foot foot (a) Overview of the (b) (c) degrees of freedom of the Soccerbot. Origin: [41]
Figure 3.9: Overview of the joints of the Soccerbot
22 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 perceptors and effectors 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.
5It is currently located in the center of the torso.
23 3.5. PLAYERS CHAPTER 3. SIMSPARK
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).
24 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
Table 3.3: Configuration of NAO, table 1
25 3.5. PLAYERS CHAPTER 3. SIMSPARK
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
26 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.
27 Chapter 4
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 simulation, coach competition, rescue simulation, 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
28 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.
29 4.2. 3D HUMANOID AGENT CHAPTER 4. FC PORTUGAL
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).
Figure 4.2: WorldState package
30 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 same team
31 4.2. 3D HUMANOID AGENT CHAPTER 4. FC PORTUGAL
• 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.
1More detailed information in 3.2.1
32 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
33 4.2. 3D HUMANOID AGENT CHAPTER 4. FC PORTUGAL
• 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.
34 CHAPTER 4. FC PORTUGAL 4.2. 3D HUMANOID AGENT
Algorithm 4.1 Goalkeeper’s behavior, initial version Default Point ⇐ (−22.0, 2.8); // position in front of the goal; Distance Tolerance ⇐ 1; if my distance to Default Point > Distance Tolerance then Move to Defaul Point; else Turn to opponent’s goal; end if
Where:
Algorithm 4.2 Goalkeeper’s behavior, initial version (Move to Default Point) Rotation Tolerance ⇐ 10; // tolerance equals 10 degrees if absolute value of Default Point direction relative to the player < Rotation Toler- ance then Walk Front; else if Default Point direction < 0 then Turn Left; else Turn Right; end if
And:
Algorithm 4.3 Goalkeeper’s behavior, initial version (Turn to opponent’s goal) Rotation Tolerance ⇐ 10; // tolerance equals 10 degrees if absolute value of my rotation relative to the field < Rotation Tolerance then // is the player looking ahead to the opponent’s field? Stay; else if my direction relative to the field > 0 then // looking right? Turn Left; else Turn Right; end if
The position of the goalkeeper was defined statically. Remember the values in Algorithm 4.1 are relative to the simulation at the moment this work began which means the robot used was Soccerbot and the field have other dimensions. This behavior was obviously too simple and has been improved, as analyzed in Section 6.2.
4.2.4.2 Field Players
The field players have a mission different from the goalkeeper: they cannot use their hands and their mission is not only defend their goal avoiding the ball to hit it but also to score goals making the ball enter the opponent’s goal.
35 4.2. 3D HUMANOID AGENT CHAPTER 4. FC PORTUGAL
(a) 0º (b) 45º (c) -90º
Figure 4.7: Examples of body relative direction
Initially, the field players of the team also had a quite basic behavior. This behavior was like detailed in Algorithm 4.4.
Algorithm 4.4 Field players’ behavior, initial version if on the ground then Get Up; else if ball kickable then if facing opponent’s goal then Kick; else // Rotate until facing opponent’s goal; if ball to the right side of the player then Rotate to the right; else Rotate to the left; end if end if else // Move to ball; if absolute value of ball relative direction < 30º then Walk in front; else if ball to the right side of the player then Rotate to the right; else Rotate to the left; end if end if end if end if
36 CHAPTER 4. FC PORTUGAL 4.2. 3D HUMANOID AGENT
These actions were all very simple. The kick, for example, didn’t include any aim- ing preparation. The field players behavior has also been discussed and improved (Section 6.3).
4.2.5 Strategy
The FC Portugal team has, in the last few years, made several research and ad- vances in strategy related areas. One of the main research areas of FC Portugal is related with strategic positioning of the players [82]. Their position changes according the needs and actions of the team. The players can even temporarily switch roles if that brings benefit for the team. Although that research advanced state in this area and the structure of our agent is based on previous developed teams that use SBSP, this is not in use by the agent. Because this league is recent and is evolving very fast, some issues (such as the fact that the team has only two players) lead FC Portugal to partially deactivate SBSP in this initial version of the 3D Humanoid agent. So the strategy in this version of the agent is simply a system to position players on the field before the game starts and during game interruptions (corner kicks, free kicks, etc). No during the match dynamic positioning is used. As the games are 2 versus 2 players, FC Portugal chose to have one goalkeeper and one field player.
37 Chapter 5
Low-level development
In this chapter will be described the improvements made to the original FC Portu- gal 3D Humanoid agent. There has been improvements in several areas. From kinematics to help to repre- sent the robots used, to the vision of the agent, to a ball prediction module, to a com- munication system. The decision-making structure of the agent has also been changed and several other behaviors have been studied, discussed and improved.
5.1 Kinematics
«Branch of physics concerned with the geometrically possible motion of a body or system of bodies, without consideration of the forces involved. It describes the spatial position of bodies or systems, their velocities, and their acceleration.»[49]. In robotics a rigid body is commonly represented as a group of links connected by joints. This is like a human skeleton, being links the human bones and joints the human articulations. This kinematic model and forward and inverse kinematics discussed below are very useful to build better movements, like walk, shoot, get up and others. This subject have been analyzed in [76]. Six basic types of joints have been defined:
• Revolute joints
• Prismatic joints
• Helical joints
• Cylindrical joints
• Spherical joints
• Planar joints
38 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.1. KINEMATICS
Figure 5.1: Types of joints. Origin: [9]
Although this can be reduced to only two because all the others can be obtained by the combination of:
• Revolute joints
• Prismatic joints
It is possible to represent robots of any kind of configuration, but in our case we will only talk about non-redundant robots. In a non-redundant robot there is only one way to go from one joint to another. In a redundant robot the can be not true.
(a) Redundant robot (b) Non-redundant robot
Figure 5.2: Redundant and non-redundant robot
5.1.1 Forward Kinematics
Forward kinematics allows to determine the location of any robot’s body part knowing the dimensions of all body parts, relation between them and angles of the joints connecting them.
39 5.1. KINEMATICS CHAPTER 5. LOW-LEVEL DEVELOPMENT
Let’s see an example where the location of a point is calculated by the usual method.
= × (θ ) x r1 cos 1 = × (θ ) y r1 sin 1
Figure 5.3: Determination of point location without forward kinematics. Body has 1 link.
= × (θ ) + × (θ + θ ) x r1 cos 1 r2 cos 1 2 = × (θ ) + × (θ + θ ) y r1 sin 1 r2 sin 1 2
Figure 5.4: Determination of point location without forward kinematics. Body has 2 links.
This method is not systematic, what implies that if the body keeps growing the for- mulas will keep growing as well and if one body part’s change occurs, all the formulas have to be redone. To avoid the recalculation of all the formulas and to help the representation of robot’s configuration we’ll use Denavit-Hartenberg representation [57]. This method uses transformation matrices of homogeneous coordinates to calculate the difference of location and position between two points. Detailed information about Denavit- Hartenberg method and homogeneous matrices can be consulted in Chapter C. If we call χ the position of a link and θ the joints’ angular values, we can consider call T the forward kinematics application so:
χ = T (θ) (5.1)
40 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.1. KINEMATICS
5.1.1.1 Transformation matrices relative to previous joint
In our case, this method is useful in this way: if we consider a fixed body point, let’s say the vision perceptor, as the origin point, applying transformations representing the body parts of the robot we know the location of any of that body parts relatively to the vision during the simulation, just knowing the angle values of the joints. In this case we’ll calculate the transformation matrices of all the joints, but the matrices relative to other body parts are also simple to obtain following the method. As already discussed we consider: ⎡ ⎤ Δ ⎢ 100 x ⎥ ⎢ ⎥ ⎢ 010Δy ⎥ • ⎢ ⎥ a translation of (Δx, Δy, Δz) ⎣ 001Δz ⎦ 000 1 ⎡ ⎤ ⎢ 10 0 0⎥ ⎢ ⎥ ⎢ 0 cos(α) − sin(α) 0 ⎥ • ⎢ ⎥ a rotation of α in counter-clockwise direction ⎣ 0 sin(α) cos(α) 0 ⎦ 00 0 1 around x axis ⎡ ⎤ (α) (α) ⎢ cos 0 sin 0 ⎥ ⎢ ⎥ ⎢ 0 100⎥ • ⎢ ⎥ a rotation of α in clockwise direction around y ⎣ − sin(α) 0 cos(α) 0 ⎦ 0 001 axis ⎡ ⎤ (α) − (α) ⎢ cos sin 00⎥ ⎢ ⎥ ⎢ sin(α) cos(α) 00⎥ • ⎢ ⎥ a rotation of α in counter-clockwise direction ⎣ 0010⎦ 0001 around z axis
Following the robot model configuration in Section 3.5.2, we get the transformation matrices for all the joints. Next we present the transformations of a joint relative to the previous joint. The calculated matrices os transformation can be consulted in Section D.1.
• Neck Relative to torso:
£ Translation of (0, 0, 0.09) £ Rotation of NeckAngle around z
• Head Relative to neck:
41 5.1. KINEMATICS CHAPTER 5. LOW-LEVEL DEVELOPMENT
£ Translation of (0, 0, 0.06) £ Rotation of HeadAngle around x
• Right Shoulder Relative to torso:
£ Translation of (0.098, 0, 0.075) £ Rotation of RightShoulderAngle around x
• Left Shoulder Relative to torso:
£ Translation of (−0.098, 0, 0.075) £ Rotation of Lef tShoulderAngle around x
• Right Upper Arm Relative to right shoulder:
£ Rotation of RightUpperArmAngle around z
• Left Upper Arm Relative to left shoulder:
£ Rotation of Le f tUpperArmAngle around z
• Right Elbow Relative to right upper arm:
£ Translation of (0, 0.09, 0.009) £ Rotation of RightElbowAngle around y
• Left Elbow Relative to left upper arm:
£ Translation of (0, 0.09, 0.009) £ Rotation of Le f tElbowAngle around y
• Right Lower Arm Relative to right elbow:
£ Rotation of RightLowerArmAngle around z
• Left Lower Arm Relative to left elbow:
42 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.1. KINEMATICS
£ Rotation of Le f tLowerArmAngle around z
• Right Hip 1 Relative to torso:
£ Translation of (0.05, 0, −0.115) £ Rotation of RightHip1Angle around special axis1
• Left Hip 1 Relative to torso:
£ Translation of (−0.05, 0, −0.115) £ Rotation of Le f tHip1Angle around special axis
• Right Hip 2 Relative to right hip 1:
£ Rotation of RightHip2Angle around y
• Left Hip 2 Relative to left hip 1:
£ Rotation of Le f tHip2Angle around y
• Right Thigh Relative to right hip 2:
£ Rotation of RightThighAngle around x
• Left Thigh Relative to left hip 2:
£ Rotation of LeftThighAngle around x
• Right Shank Relative to right thigh:
£ Translation of (0, 0.005, −0.12) £ Rotation of RightShankAngle around x
• Left Shank Relative to left thigh:
£ Translation of (0, 0.005, −0.12)
1As seen in Figure 3.12 on page 25, right and left Hip1 rotate around a special axis that is not one of the three basis generators
43 5.1. KINEMATICS CHAPTER 5. LOW-LEVEL DEVELOPMENT
£ Rotation of Lef tShankAngle around x
• Right Ankle
Relative to right shank:
£ Translation of (0, 0, −0.1)
£ Rotation of RightAnkleAngle around x
• Left Ankle
Relative to left shank:
£ Translation of (0, 0, −0.1)
£ Rotation of Lef tAnkleAngle around x
• Right Foot
Relative to right ankle:
£ Rotation of RightFootAngle around y
• Left Foot
Relative to left ankle:
£ Rotation of LeftFootAngle around y
5.1.1.2 Transformation matrices relative to the vision
The transformation matrices of all robot joints relative to the vision can be con- sulted in Section D.2. Using these matrices it’s possible to know the location of any of these joints. Previous matrices gives us the transformation between vision and joints. If we consider the vision point the origin of the basis, vision will be at point p = (0, 0, 0).To know the position of a joint, let’s say right elbow, all that’s needed to do is: ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎢ 0 ⎥ ⎢ x ⎥ Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ 0 ⎥ ⎢ y ⎥ ⎣ Vision → Right Elbow ⎦ × ⎢ ⎥ = ⎢ ⎥ ⎣ 0 ⎦ ⎣ z ⎦ (D.29) 1 1
Where (x, y, z) is the location of the right elbow. The matrices that allow the calculation of the all robot joints location can be con- sulted in the CD provided with this thesis.
44 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.1. KINEMATICS
5.1.1.3 Implementation
A forward kinematics software module has been implemented in the agent, allow- ing to know in any moment the position of any body part. The implementation has been as simple as writing the transformation matrices al- ready described. When we want to know some body part location, the correspondent matrix is calculated.
5.1.2 Inverse Kinematics
We already know that using forward kinematics (and Denavit-Hartenberg method) it is possible to build a model of our robot and calculate the location of any body part at anytime, just knowing the joints angles. This is useful, but another thing that would be very useful is the opposite. We want some body part to be at a specific location, which are the necessary joints angles values? As already seen (Formula 5.1), forward kinematics consists in calculating χ know- ing θ. Considering (as earlier) that χ is the position and θ are the joints’ angular values, − we want find T 1 so that: − θ = T 1 (χ) (5.2)
In forward kinematics, for every T (θ) there is always one and only one solution χ. − In inverse kinematics this could be false. For every T 1 (χ) there could be one, none or several solutions θ. The case when there are no solutions is easy to understand. Like in Figure 5.5 whatever the values of θ are, the desired point χ will never be reached.
Figure 5.5: Inverse kinematics with no solutions for the desired point
There could be also several valid solutions. This happens because we could be dealing with a redundant system: we have several different ways to achieve the same point.
45 5.1. KINEMATICS CHAPTER 5. LOW-LEVEL DEVELOPMENT
(a) (b)
Figure 5.6: Redundancy: two robot configurations to achieve the same point
− Generically, if a body has n joints, there are 2n 1 ways to achieve a solution, ex- cepting unique solutions (body fully stretched) and impossible solutions. There are two ways to determine the solution of inverse kinematics of a system: an algebraic way and a numeric way.
5.1.2.1 Algebraic method
The algebraic method is more intuitive to understand than the numeric. The prob- lem is that, for some body parts, we have a redundant system, as already discussed. In those cases we need to eliminate some DoF2 so that we have only the number of DoF that match the number of dimensions of the space in which we are working. In our case, as long as we are working on a 3D space, we must have 3 DoF. After calculating T of a body part, as we are working on a three-dimensional space, T will have three equations. Assuming that χ = (x, y, z) and θ = (α, β, γ): ⎧ ⎪ = (α β γ) ⎨ x T1 , , T = y = T (α, β, γ) ⎩⎪ 2 = α β γ z T3 ( , , )
− We just have to solve the equation system in order to (α, β, γ). T 1 will also have three equations: ⎧ ⎪ α = −1 ( ) ⎨ T1 x, y, z − − T 1 = β = T 1 (x, y, z) ⎩⎪ 2 γ = −1 ( ) T3 x, y, z So this method is not difficult to implement, although it has the DoF problems already referred. − Since some of the T 1 results are too complex to be presented in this document, − the T 1 matrices of the inverse kinematics of all the robot joints are included in the CD provided with this thesis.
2Degrees of Freedom
46 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.1. KINEMATICS
5.1.2.2 Numeric method
As already seen, the algebraic method have some restrictions, like the number of DoF of the system must be the same as the number of dimensions of our space. It also can can lead in very complex solutions that are confusing and take very long to calculate. To try to solve those issues there is a numeric method. When using the numeric method, the solution is build incrementally, as this method is iterative. We can run this method as many times as we want. Every time it is exe- cuted, a solution better than the previous one is calculated. Every time it is executed, the method calculates the better way to change the angles (θ) so the end-effector has the best approaching to the desired position (χ). Due the existing sines and cosines in the forward kinematics equations T is not − linear in θ, so its inverse (T 1) could not exist. The idea behind numeric methods is to use the differential of the joints movements. In order to better understand the concepts of this method, some useful derivative concepts can be read in Chapter E.
Algorithm of the calculation Let’s consider that:
• θ represents the actual state of the joints angles
• χ represents the actual position of the actuator
χ • GOAL represents the desired position to be achieved by the actuator
J (χ, θ) shows how χ changes based on θ changes, which means how the position of the actuator changes based on how the joints angles are changed. If we have a change of Δθ, the change of χ can be approximated by:
Δχ ≈ J (χ, θ) · Δθ = J · Δθ (5.3)
If we desire a change of Δχ in the actuator position how much we need to change θ? Since we have: Δχ ≈ J · Δθ
We just need to calculate:
− Δθ ≈ J 1 · Δχ (5.4) χ χ Since we want to be GOAL:
Δχ = χ − χ GOAL
47 5.1. KINEMATICS CHAPTER 5. LOW-LEVEL DEVELOPMENT
Due the non-linearity of the equations, we should choose smaller steps in the de- sired direction:
Δχ = β (χ − χ) ≤ β ≤ GOAL , where 0 1 (5.5)
So, the algorithm of the the numeric inverse kinematics is:
Algorithm 5.1 Numeric Inverse Kinematics χ χ while too far from GOAL do Compute J (χ, θ); − Compute J 1; // Inverte the jacobian matrix Δχ = β (χ − χ) GOAL ; // Choose the apppropriate step − Δθ = J 1 · Δχ; // Compute the changes to the joints θ = θ + Δθ; // Apply the changes to the joints Compute the new χ; // Use forward kinematics to know the location of the actuator end while
Calculating the jacobian Since we’re working on a three-dimensional space χ have three components and the jacobian is a matrix with dimension 3 x N, where N is the number of joints. For every joint we must analyze how χ changes based on θ changes. ⎡ ⎤ ∂x ∂x ∂x ⎢ ∂θ ∂θ ... ∂θ ⎥ ⎢ 1 2 N ⎥ ⎢ ∂ ∂ ∂ ⎥ (χ θ) = ⎢ y y y ⎥ J , ⎢ ∂θ ∂θ ... ∂θ ⎥ ⎣ 1 2 N ⎦ ∂z ∂z ∂z ∂θ ∂θ ... ∂θ 1 2 N If the number of columns of the jacobian is bigger than rows, the system is redun- dant and called underconstrained. If the number of rows is bigger than columns, could not exist a solution and the system is called overconstrained. If the jacobian is a squared matrix, the system is called well-behaved. The calculated jacobian matrices of the joints where the forward kinematics matri- ces have been calculated, can be consulted in the CD provided with this thesis.
− Inverting the jacobian If the jacobian is a squared matrix, J 1 is obtained by simply inverting the matrix with a normal matrix inversion operation. In matrices algebra, − the inverse of a (squared) matrix is another matrix called A 1, as:
− − A 1 A = AA 1 = I where I is the identity matrix
When the system is overconstrained or underconstrained there is no inverse of the jacobian, so a generalized inverse B must be used.
48 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.2. VISION
One of the most used is the pseudo-inverse:
− ∗ 1 J = JT J JT (5.6)
Another “false inverse” very used is the transpose of the jacobian. It is very fast to compute and has good results. So the calculation of Δθ would be:
Δθ = JT · Δχ (5.7)
Another advantage of this “false inverse” is that, if we don’t want to, it is not needed to calculate all the jacobian matrix. If we just want to change a specific DoF we just have to calculate it. With jacobian inverse or pseudo-inverse it’s needed to calculate the all the jacobian matrix and after that invert it.
When to stop? Since this method is iterative, when will it stop? Basically there are tree situations where the algorithm should stop:
• The desired position was achieved (within defined tolerance)
• The system is stopped in a local minimum
• It took too long (the maximum number of iterations was reached)
It is important for the system to obey the previous rules or it could run indefinitely without stop.
Results The numeric inverse kinematics system hasn’t been yet implemented in the agent.
5.2 Vision
5.2.1 The two basis
It’s easy to understand that, when talking about vision we are dealing with two basis: the one of the field and the one of vision of the player. They aren’t the same because two reasons:
• Location: obviously the player is moving around the field, so his location is dynamic and the origin of the vision basis is not coincident to origin of the field basis.
• Positioning: besides moving around the field, the player has other movements. He can turn his orientation left or right and can fall back or front. So even if the two basis have the same origin, the basis weren’t the same because the vectors generators of those basis wouldn’t be coincident.
49 5.2. VISION CHAPTER 5. LOW-LEVEL DEVELOPMENT
The two basis have been defined as follows:
• Vision basis
£ x is the transversal axis, positive to the right side £ y is the longitudinal axis, positive to the front £ z is the vertical axis, positive to up
Figure 5.7: Vision basis
• Field basis
£ x is the axis along the field length, positive to the opponent’s midfield £ y is the axis along the field width, positive to the right side if we’re looking to positive x axis side £ z is the vertical axis, positive to up
Figure 5.8: Field basis
50 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.2. VISION
A little introduction
When a vector v in 2 is represented as v = (α, β) this is a shorter form to v = α × + β × = ( ) = ( ) e1 e2, being e1 1, 0 and e2 0, 1 the vectors of the canonical basis of 2. Generically, any vector v of the vectorial space n can be written as a linear com- bination of the basis vectors.
= × + × + × + + × { } v v1 e1 v2 e2 v3 e3 ... vn en, being e1, e2, e3,...,en the basis vectors.
{ } In its vectorial form and as e1, e2,...,en are vectors of dimension n: ⎡ ⎤ ⎡ ⎤ e e ··· e v ⎢ 11 21 n1 ⎥ ⎢ 1 ⎥ ⎢ e e ··· e ⎥ ⎢ v ⎥ = ⎢ 12 22 n2 ⎥ ⎢ 2 ⎥ v ⎢ . . . . ⎥ ⎢ . ⎥ ⎣ . . .. . ⎦ ⎣ . ⎦ ··· e1n e2n enn vn α = { } β = { } Without loss of generalization, let v1, v2 and w1, w2 be two basis of 2. Given u ∈2, it is a linear combination of the vectors of basis α and β. = × + × [ ] = x1 u x1 v1 x2 v2 or u α (5.8) x2
and = × + × [ ] = y1 u y1 w1 y2 w2 or u β (5.9) y2
Being β a basis of 2 any vector of α can bee written as a linear combination of the vectors of β. v = α × w + α × w 1 11 1 21 2 (5.10) = α × + α × v2 12 w1 22 w2
Replacing 5.9 in 5.8 one gets:
= (α × + α × ) + (α × + α × ) u x1 11 w1 21 w2 x2 12 w1 22 w2 = (α × + α × ) + (α × + α × ) 11 x1 12 x2 w1 21 x1 22 x2 w2 (5.11)
By 5.9 and 5.11 we obtain: y = α × x + α × x y α α x 1 11 1 12 2 ⇔ 1 = 11 12 1 (5.12) = α × + α × α α y2 21 x1 22 x2 y2 21 22 x2
51 5.2. VISION CHAPTER 5. LOW-LEVEL DEVELOPMENT
α α α If we consider [T] = 11 12 we can say: β α α 21 22
α [u]β = [T]β [u]α (5.13)
α [T]β is the matrix that allows to convert a vector v in basis α to the same vector in basis β. α α If we analyze [T]β we can see that the columns of [T]β are the vectors of basis α in β basis . ⎡ ⎤ || ⎢ ⎥ [ ]α = [ ] [ ] T β ⎣ v1 β v2 β ⎦ (5.14) ||
Knowing 5.14, if we want the opposite:
− β α 1 [u]α = [T]α [u]β ⇔ [u]α = [T]β [u]β (5.15)
α 3 As [T]β is an orthogonal matrix , its inverse and transpose are the same.
− β α 1 α T [T]α = [T]β = [T]β (5.16)
The transpose is preferred because it requires less computation time. What we need to know to build the matrix that allows the conversion between vision and field basis is 5.14. Let’s consider the origin of both basis the same and{ x, y, z} the vectors of vision basis, {u, v, w} the field basis and ux, uy, uz, vx, vy, vz, wx, wy, wz the projections of u along x, u along y, and so on. Following 5.14 the matrix HeadToFieldTransf of conversion between vision basis and field basis is: = [ ] [ ] [ ] HeadToFieldTransf x field y field z field
That is: ⎡ ⎤ u u u ⎢ x y z ⎥ = HeadToFieldTransf ⎣ vx vy vz ⎦ wx wy wz
What does this means graphically? Let us imagine those two basis with the same origin point.
3Rows and columns are linearly independent: none of the vectors can be written as a linear combina- tion of the others.
52 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.2. VISION
Figure 5.9: Field and vision basis with the same origin
Let’s give vectors different colors to distinguish them better from each other:
Figure 5.10: Field and vision basis with the same origin
We get projection of field basis’ vectors along vision basis:
53 5.2. VISION CHAPTER 5. LOW-LEVEL DEVELOPMENT
Figure 5.11: Vision basis, field basis and its projections along vision basis
Where we can see only the projections:
Figure 5.12: Field basis projected along vision basis
How do we get field basis?
As the dimensions of the field are known, the absolute location of some objects is also known: the flags, for example.
54 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.2. VISION
Figure 5.13: Dimensions of the field
(Flag2 − Flag1) gives us a vector collinear with u and length 12 meters. We reduce its length to 1 meter and get our u . (Flag3 − Flag1) gives us a vector collinear with v and length 8 meters. We reduce its length to 1 meter and get v .
The cross-product u × v gives us a vector orthogonal to those two, our w .
The vectors { u , v , w } are coincident with { u, v, w } so we can work with { u , v , w }. After getting HeadToFieldTransf and FieldToHeadTransf it’s easy convert a point between the two basis. If we have a point p with coordinates (x, y, z) in vision basis and want to convert it to field basis:
= × p field HeadToFieldTransf pvision (5.17)
This is true if the two basis have the same origin point. Since the player moves around the field its location is not (0, 0, 0) most of the time. Then a translation is necessary to “reposition” the basis so the origin points are the same.
5.2.2 Calculation of agent location
As seen in section 3.2.1.3, the simulator doesn’t give the player his location. It only gives the location of other objects relatively to the player, what the player “sees”. The player location must be calculated.
55 5.2. VISION CHAPTER 5. LOW-LEVEL DEVELOPMENT
5.2.2.1 Trilateration
Using this method it’s possible to calculate the relative positions between objects knowing the distance between them. Knowing the relative positions between three objects and the absolute position of two of them, the position of the other one is easily determined. As already said, the dimensions of the field are well known.
Figure 5.14: Dimensions of the field
Knowing the absolute and relative locations of at least 3 non-collinear objects it’s possible to calculate the player location. Let’s imagine (in 2D): the player knows he is 5 meters distant from Flag 2.
Figure 5.15: Player distance to Flag 2
56 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.2. VISION
The player location can be any point of the red circumference. The player also knows that he is 9.5 meters away from Flag 1.
Figure 5.16: Player distance to Flag 1, Flag 2 and possible locations
Now the player can only be in two locations: the yellow dots (intersection points of the two circumferences). To calculate the exact location it’s necessary the location of another non-collinear object.
Figure 5.17: Player distance to Flags 1, 2 and 3 and his location
57 5.2. VISION CHAPTER 5. LOW-LEVEL DEVELOPMENT
The player location is the yellow dot where the 3 circumferences intersect each other.
This method the same way in 3D.
Figure 5.18: Player distance to Flag 2 in 3D
Knowing the distance to Flag 2 the location of the player can be any point of the sphere surface.
Figure 5.19: Player distance to Flag 1, Flag 2 and possible locations in 3D
Knowing also the distance to Flag 1, the player can be located in a point of the yellow circumference.
58 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.2. VISION
Figure 5.20: Player distance to Flags 1, 2 and 3 and his location in 3D
The player is located at the point where the three spheres intersect each other.
5.2.2.2 Change of Basis
As seen, to know the player positioning it’s necessary to determine the matrices of transformation between the two basis (field and vision). Since this is necessary, these matrices can be used to calculate the location of the player. Let’s see an example in 2D (where the only positioning parameter is the horizontal orientation). The player knows the field dimensions but have no idea of his location.
Figure 5.21: Field dimensions
By using HeadToFieldTransf and FieldToHeadTransf, the player knows he is ori- entated 30º clockwise.
59 5.2. VISION CHAPTER 5. LOW-LEVEL DEVELOPMENT
Figure 5.22: Player orientation
The player sees Flag 4 right in front of him. So his location is now restricted to a line.
Figure 5.23: Player locations restricted to a line
As he sees Flag 4 at the distance of 3 meters, his location is now defined.
60 CHAPTER 5. LOW-LEVEL DEVELOPMENT 5.2. VISION
Figure 5.24: Player location found
This method requires less computation than Trilateration so it is used instead of the other one.
5.2.3 Calculation of World Objects locations
During the game the player needs to know the location other objects (ball) and players. The information the gets from the simulator is the relative position of the other ob- jects. Applying 5.17 one gets p field. But this isn’t the location of the object — remember the two basis have to have the same origin so we can use this method — it’s just the converted coordinates from one basis to another. To get the location of the object we must add the player location.
= + ObjectLocation p field PlayerLocation = × + HeadToFieldTransf pvision PlayerLocation
One major problem of the actual vision is that players are seen as a single point. This doesn’t allow to know their positioning. This increases the uncertainty of some actions: Is the opponent goalkeeper on the ground? Will the shot be succeeded? As the vision is not vertically centered in the players, even if we estimate if the player is on the ground, we don’t know which side is the head and which side are the legs, so our shot may or may not be intercepted by the player’s legs. One attempt to minimize this issue is discussed in Future Work Section (8.3.2).
61 5.2. VISION CHAPTER 5. LOW-LEVEL DEVELOPMENT
5.2.4 Software implementations
There are several functions related to vision. There’s one that builds the transformation matrices between the two basis and calculates player location.
Algorithm 5.2 setMyPosition() // Get field basis u ⇐ Normalized (RelativePosition (RightFrontFlag) − RelativePosition (RightBackFlag));
v ⇐ Normalized (RelativePosition (Le f tFrontFlag) − RelativePosition (RightFrontFlag));
w ⇐ CrossProduct (u, v); // Build tranformation matrices HeadToFieldTransf (1, 1) ⇐ Projection of u along x; HeadToFieldTransf (1, 2) ⇐ Projection of u along y; HeadToFieldTransf (1, 3) ⇐ Projection of u along z; HeadToFieldTransf (2, 1) ⇐ Projection of v along x; HeadToFieldTransf (2, 2) ⇐ Projection of v along y; HeadToFieldTransf (2, 3) ⇐ Projection of v along z; HeadToFieldTransf (3, 1) ⇐ Projection of w along x; HeadToFieldTransf (3, 2) ⇐ Projection of w along y; HeadToFieldTransf (3, 3) ⇐ Projection of w along z; FieldToHeadTransf ⇐ Transpose (HeadToFieldTransf ); // Calculate player location PlayerLocation ⇐ AbsoluteLocation (Le f tFrontFlag) − HeadToFieldTransf × RelativePosition (Le f tFrontFlag); PlayerOrientation ⇐ Direction of Vector (FieldToHeadTransf (1, 1), FieldToHeadTransf (1, 2));
PlayerVerticalInclination ⇐ Direction of Vector (FieldToHeadTransf (3, 1), FieldToHeadTransf (3, 3));
One function converts relative coordinates in vision basis into absolute coordinates in field basis.
Algorithm 5.3 RelativeToAbsoluteCoordinates(RelativeCoordinates: Vector): Vector RelativeCoordinatesInFieldBasis ⇐ HeadToFieldTransf × RelativeCoordinates; AbsoluteCoordinatesInFieldBasis ⇐ PlayerLocation + RelativeCoordinatesInFieldBasis; return AbsoluteCoordinatesInFieldBasis;
And one that does the opposite.
Algorithm 5.4 AbsoluteToRelativeCoordinates(AbsoluteCoordinates: Vector): Vector RelativeCoordinatesInFieldBasis ⇐ AbsoluteCoordinates − PlayerLocation; RelativeCoordinatesInVisionBasis ⇐ FieldToHeadTransf × RelativeCoordinatesInFieldBasis; return RelativeCoordinatesInVisionBasis;
62 CHAPTER 5. LOW-LEVEL DEVELOPMENT5.3. BALL MOVEMENT PREDICTION
5.3 Ball movement prediction
Like humans intuitively do, it is extremely useful for a soccer player to be able to predict the movement of the ball. Knowing the past of the ball, its position and velocity in the near future can be estimated.
Using that information the goalkeeper, for example, knows if a shot is going to hit the goal and where: to his left? To his right? Near the ground? Knowing that he can take the necessary actions to avoid the ball entering the goal.
Also the field players can use that prediction do improve their behavior.
Let’s look at some situations where the ball movement prediction is useful:
• Intercept an opponent’s pass
Figure 5.25: Intercepting an opponent’s pass
• Catch an uncontrolled ball moving in the field
Figure 5.26: Catch an uncontrolled ball
• Pass to a teammate
63 5.3. BALL MOVEMENT PREDICTIONCHAPTER 5. LOW-LEVEL DEVELOPMENT
Figure 5.27: Pass the ball to a teammate
Since at this moment it’s very difficult to control the ball in the air (none of the teams participating in the RoboCup08 has this ability), during the games the ball is almost all the time at the ground level. So, to avoid improving the complexity of this module too much, it will be only considered the 2D movement.
5.3.1 The prediction procedure
After a shot, when the ball is running free, only one force is applied: the force that decelerates the ball.4
Figure 5.28: Rolling ball with representation of velocity and friction force
By Newton’s Second Law of Motion [72] we know that:
F = m × a (5.18) Where F is the sum of all forces applied to a body, m is its mass and a its accelera- tion. We want to discover the value of that deceleration (negative acceleration) so we can predict the ball movement.
4In fact, the simulator takes in consideration the rolling movement of the ball but these forces will be neglected.
64 CHAPTER 5. LOW-LEVEL DEVELOPMENT5.3. BALL MOVEMENT PREDICTION
Analyzing the simulator source-code5 we conclude that:
F = −DragFactor × v (5.19)
Replacing (5.19) in (5.18) we get:
DragFactor − DragFactor × v = m × a ⇔ a = − × v (5.20) m We also know that: ∂ x ∂ v v = ∧ a = ∂t ∂t In a discrete (non-continuous) space we can say:
Δ = × Δ x v t ⇒ Δ = × Δ 2 + × Δ x a ( t) v0 t Δ v = a × Δt
Hence, if in a specific moment the ball is at position x0 with velocity v0 and accel- eration a0, after a simulation cycle (0.02 s), it will be in position x1 with velocity v1 and acceleration a1 where:
⎧ ⎧ ⎪ Δ = × (Δ )2 + × Δ ⎪ = × 2 + × + ⎨ x a t v0 t ⎨ x1 a0 0.02 v0 0.02 x0 Δ v = a × Δt ⇔ v = a × 0.02 + v (5.21) ⎩⎪ ⎩⎪ 1 0 0 = − DragFactor × = − DragFactor × a m v a1 m v0
Knowing (by analyzing the simulator source-code6) that m = 0.026, we only need to find DragFactor.
5.3.2 Getting DragFactor
To get DragFactor we’ll capture several shots of the ball. Then we will consider only the first few moments of the shot and try to predict the rest of the movement of the ball by applying the procedure already seen. We will do that with several different values of DragFactor and see with which of these values the prediction is closer to the real movement. A player shoots the ball and its position during the movement is captured.
5File lib/oxygen/physicsserver/dragcontroller.cpp 6File app/simspark/naosoccersim.rb
65 5.3. BALL MOVEMENT PREDICTIONCHAPTER 5. LOW-LEVEL DEVELOPMENT
Figure 5.29: Ball position after a shot
We can now calculate the velocity of the ball for any moment of the movement (in fact, it’s not the instantaneous velocity for any moment, it’s the average velocity for any 20 ms. interval). Assuming that p is the position of the ball, his velocity v in the simulator iteration i is calculated this way:
Δp p (i) − p (i − 1) v = ⇔ v (i) = (5.22) Δt 0.02
Figure 5.30: Calculated ball velocity after a shot
It’s clear that these results are not very good. This happens because the deter- mination of an object (in this case, the ball) position is not (obviously) perfect, as is discussed in Section 5.2.3. There are some imprecisions and this affects the values of
66 CHAPTER 5. LOW-LEVEL DEVELOPMENT5.3. BALL MOVEMENT PREDICTION the velocity.
The same way, the first derivative of the velocity (or the second derivative of the position) gives us the acceleration of the ball.
Δv v (i) − v (i − 1) a = ⇔ a (i) = Δt 0.02
Figure 5.31: Calculated ball acceleration after a shot
If the velocity results where affected by error, acceleration results are quite unread- able. This is because we are calculating the derivative of values with a lot of noise, as we already saw. We need to find a way to improve the precision of the velocity and acceleration values.
5.3.2.1 Improving the precision of velocity and acceleration values
To make velocity and acceleration values more precise, that is, to get rid of those errors let’s use a Low-Pass Filter. «A Low-Pass Filter is a circuit offering easy passage to low-frequency signals and difficult passage to high-frequency signals»[44]. This way we hope to get rid of the biggest part of the noise that is making impos- sible to properly use these values. There are two simple kinds of digital filter simple to implement in software: Finite Impulse Response and Infinite Impulse Response [79].
Assuming that x are the original values and x f are the filtered values:
Infinite Impulse Response
67 5.3. BALL MOVEMENT PREDICTIONCHAPTER 5. LOW-LEVEL DEVELOPMENT
( ) = α · ( ) + ( − α) · ( − ) x f t x t 1 x f t 1 (5.23)
Where α is a value between 0 and 1 meaning the percentage of the new value that we want in the filtered value.
Finite Impulse Response
x (t) + x (t − 1) + ...+ x (t − n) x (t) = (5.24) f n + 1 Where n is the number of previous simulation values we want to use.
The low-pass filter will make the graphs values smoother but also less responsive7. We’ll have to find a middle point maximizing the smooth and minimizing the lack of responsiveness. Using the method (5.23) of the low-pass filter a bigger α means better responsive- ness and less smooth. To the method (5.24) a bigger n means a smoother but less responsive graph. Let’s try the method (5.23) to filter the position graph. Then, calculating its deriva- tive, we get the velocity and filter that result. Finally we calculate the derivative of that to get the ball acceleration and filter the result too.
Figure 5.32: Filtered ball movement, α = 1, Position
7How much time the filter needs to reflect changes in the original data
68 CHAPTER 5. LOW-LEVEL DEVELOPMENT5.3. BALL MOVEMENT PREDICTION
Figure 5.33: Filtered ball movement, α = 1, Velocity
Figure 5.34: Filtered ball movement, α = 1, Acceleration
Of course, if α = 1 there aren’t any changes in the graphs because, since the result is 100% the read values, we are not actually filtering the results.
69 5.3. BALL MOVEMENT PREDICTIONCHAPTER 5. LOW-LEVEL DEVELOPMENT
Let’s try α = 0.5. This way, any value of the graph is a half the read value and another half the previous filtered value.
Figure 5.35: Filtered ball movement, α = 0.5, Position
Figure 5.36: Filtered ball movement, α = 0.5, Velocity
70 CHAPTER 5. LOW-LEVEL DEVELOPMENT5.3. BALL MOVEMENT PREDICTION
Figure 5.37: Filtered ball movement, α = 0.5, Acceleration
Now the results are quite readable. But are they responsive enough?
Figure 5.38: Unfiltered versus filtered ball movement, α = 0.5, Position
71 5.3. BALL MOVEMENT PREDICTIONCHAPTER 5. LOW-LEVEL DEVELOPMENT
Figure 5.39: Unfiltered versus filtered ball movement, α = 0.5, Velocity
Figure 5.40: Unfiltered versus filtered ball movement, α = 0.5, Acceleration
As already said, different shots have been captured. Let’s see if α = 0.5 is a good value for a different shot.
72 CHAPTER 5. LOW-LEVEL DEVELOPMENT5.3. BALL MOVEMENT PREDICTION
Figure 5.41: Unfiltered versus filtered ball movement of another shot, α = 0.5, Position
Figure 5.42: Unfiltered versus filtered ball movement of another shot, α = 0.5, Velocity
73 5.3. BALL MOVEMENT PREDICTIONCHAPTER 5. LOW-LEVEL DEVELOPMENT
Figure 5.43: Unfiltered versus filtered ball movement of another shot, α = 0.5, Accel- eration
As the unfiltered acceleration values are full of noise that graph is useless for us to compare. Looking at the position and velocity graphs, comparing the original and filtered values, although there is a tiny delay, we can assume the values are ok so α = 0.5 is a good value and we don’t need to try other α values or low-pass filter method (5.24).
Let’s try to get DragFactor value.
We have the original filtered position data (let’s call it xorig and yorig) and our pre- diction using dF as DragFactor (xpred and ypred). We can quantify the error of our prediction by: = − 2 + − 2 error ∑ xpred xorig ∑ ypred yorig
Using a tool like Solver of Microsoft Excel we can minimize the error value by changing dF. Doing so, Solver gives us an ideal dF value of 0.0299980906079769. We can then consider DragFactor = 0.03.
74 CHAPTER 5. LOW-LEVEL DEVELOPMENT5.3. BALL MOVEMENT PREDICTION
(a) Shot 1, Position (b) Shot 1, Velocity
(c) Shot 2, Position (d) Shot 2, Velocity
Figure 5.44: Predicted and real movement of two shots, DragFactor = 0.03
5.3.3 Final considerations
Replacing DragFactor and m values in 5.20 we get:
0.03 a = − × v 0.026
We’re now able to predict a ball movement during a game. An important point is that this prediction is only valid for a free running ball. So we need to know when the prediction valid and not. To do this we calculate the accel- eration of the ball and apply the low-pass filter in run-time. When the acceleration is negative means the ball is decelerating and our prediction method will work.
5.3.4 Software implementations
Two functions have been implemented. One that allows to know what’s the location of the ball n simulation cycles from now.
75 5.3. BALL MOVEMENT PREDICTIONCHAPTER 5. LOW-LEVEL DEVELOPMENT
Algorithm 5.5 positionInNCycles(currentPosition, currentVelocity, currentAccelera- tion: Vector; nCycles: unsigned): Vector // Initialize values positionPrediction[0] ⇐ currentPosition; velocityPrediction[0] ⇐ currentVelocity; accelerationPrediction[0] ⇐ currentAcceleration; for cycle = 1tonCycles do accelerationPrediction[cycle] ⇐ accelerationPrediction[cycle − 1] × DragFactor; velocityPrediction[cycle] ⇐ velocityPrediction[cycle − 1]+ accelerationPrediction[cycle − 1] × CYCLE_DURATION; positionPrediction[cycle] ⇐ positionPrediction[cycle − 1]+ velocityPrediction[cycle − 1] × CYCLE_DURATION; end for return positionPrediction[nCycles];
The other one is used to estimate how many cycles until the ball reach a specific location. As this can never occur, a maximum number of simulation cycles to be tested must be given. This function will exhaustively test the location of the ball for every cycle until one satisfying the tolerance or the maximum number of tests is reached.
Algorithm 5.6 nCyclesToPosition(currentPosition, currentVelocity, currentAccelera- tion, desiredPosition: Vector; tolerance: float; nMaxCycles: unsigned): int for cycle = 0tonMaxCycles do if positionInNCycles(currentPosition, currentVelocity, currentAcceleration, cycle) distance to desiredPosition ≤ tolerance then return cycle; end if end for return −1;
76 Chapter 6
High-level development
In this chapter will be presented and detailed the work done on high-level behav- iors.
6.1 Omnidirectional walk
As already seen, when this work began the agent have the ability to walk in front and to rotate. After that the ability to side-stepping was introduced. But all this low- level skills are independent from each other and one can only begin after the previous one have stopped. This make our players to have a bit slow walking because they walk in front, stop, rotate, walk in front, rotate, ... The non-existent connection between the low-level skills lead to a slow walk. As already said, this work occurred simultaneously with another one also related with FC Portugal 3D Humanoid. This other work ([76]) is intended to study and improve, among others, low-level skills to the players. The omnidirectional walk is result of that work and was applied to the agent. This omnidirectional walk allows to join the previous three skills (walk in front, rotate and side walk) in one low-level skill. This way is possible to rotate and simul- taneously walk in front – for example – without need to stop between the two. The omnidirectional step takes three parameters: front walk speed, rotation speed and side walk speed. This allows all kind of human-like walking. Considering f the front walk speed, r the rotation speed, s the side walk speed and (α, β, γ) positive decimal values, we can see some examples in Figure 6.1. These are just some examples of what is possible using the omnidirectional walk- ing. More detailed information about this omnidirectional walk can be consulted in [76].
77 6.2. GOALKEEPER BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
(a) ( f , r, s) = (α,0,0) (b) ( f , r, s) = (0, β,0)
(c) ( f , r, s) = (0, 0, −γ) (d) ( f , r, s) = (α, β,0) (e) ( f , r, s) = (−α,0,γ)
Figure 6.1: Omnidirectional walk examples
6.2 Goalkeeper behavior
The main mission of the goalkeeper is to block shots that could go to goal. To do that the goalkeeper needs to be well located in relation to the goal and when the ball is going to the goal stop it, usually by diving to the ground.
The original goalkeeper (Section 4.2.4.1) has a very simple behavior. We can almost consider he has no behavior because he only stands still in front of the goal. This obviously needed to be improved.
The improvement have been focused on three main areas:
• Choose the best location to stay
• Run to the ball and kick it when necessary
• Block shots to goal
The first one means the goalkeeper to choose the best point to stay during the game to defend the goal.
78 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.2. GOALKEEPER BEHAVIOR
(a) (b)
Figure 6.2: Two possible points for the goalkeeper to stay
It’s clear that, in general, the point represented in Figure 6.2a is better than the one in Figure 6.2b for the goalkeeper to stay. If some opponent shots the ball to the goal, it’s much likely to block it if in the situation 6.2a than in situation 6.2b. Let’s imagine this one-on-one situation:
Figure 6.3: Situation where is better for the goalkeeper to go and kick the ball
In this situation, where the goalkeeper is a lot closer to the ball than the opponent is better to go and kick the ball away than wait the opponent to came and shoot the ball. The second area of improvement is related with these situations. The third and last area improved refers to when some opponent shoots the ball and it is going to enter the goal. The mission of the goalkeeper is to block it. That’s what this area is related to. The basic behavior of the goalkeeper has been improved.
6.2.1 Position to defend the goal
The method to choose the point where the goalkeeper should stay during the game, ready to block the goal attempts is taken from other FC Portugal teams. It consists in:
79 6.2. GOALKEEPER BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
Algorithm 6.1 Calculation of goalkeeper’s “defense point” L ⇐ line passing in the goal center and the ball location; C ⇐ circumference; C center ⇐ middle of the goal; C diameter ⇐ goal width; {P1; P2} ⇐ intersection points between C and L if P1 inside field then Def ense Point ⇐ P1; else Def ense Point ⇐ P2; end if
(a) Step nr. 1 (b) Step nr. 2
Figure 6.4: Goalkeeper position calculation
This method, although simple, gives us a point where the goalkeeper covers the goal front shots. Most of the shots are blocked just by the body of the goalkeeper thanks to his location.
6.2.1.1 Problems
The problem with this method is when the ball is near the goal. If we consider the goal width equals the circumference diameter equals d. When d the ball distance to the goal center is less than 2 the goalkeeper is unable to reach it.
Figure 6.5: Goalkeeper unable to reach the ball
80 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.2. GOALKEEPER BEHAVIOR
6.2.2 Leaving the “defense point”
To solve the problem previously reported, this exception needs to be taken in con- d sideration. When the ball distance to the goal center is less than 2 the goalkeeper can leave his “defense location” and walk to the ball to intercept it or kick it or someway defend his own goal.
Figure 6.6: Goalkeeper leaving the “defense point” to intercept the ball
This is one of the situations when is better the goalkeeper not to stay in the “de- fense point”. Another one is the one discussed in Section 6.2: when the goalkeeper is closer than anyone else to the ball and can avoid the opponent to shoot. The first situation is solved by making the goalkeeper leave the “defense point” when the ball is closer the goal center than him. The second is not so simple. The solution chosen (again based on older FC Portugal choices) was:
Algorithm 6.2 Goalkeeper leaving the “defense point” to kick ball 1 if ball distance < 3 of the field length then // is the ball close enough for the GK to go? if I am the closest player to the ball then // it’s not reasonable to go if I’m not the closest player if ball stoping then // evaluate ball speed < threshold if ball kickable then if my body turned to my field side then return Turn myself to opponent’s goal; else return Kick the ball; end if end if end if end if end if return Stay in "Defense point";
81 6.2. GOALKEEPER BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
6.2.3 Defend shots to goal
In real soccer we see goalkeepers avoid goals with some awesome defenses. The experts say that agility is one of the most important qualities of a good goalkeeper. They can block shots with an impressive quickness and dive to the ground to avoid an almost certain goal when the ball was going to hit the goal. Unfortunately , our robot don’t possesses that kind of agility yet (the movements are being improved; see, for example [76]) and that is a challenge to be solved. The mission of the goalkeeper is to avoid the opponent’s to score goals. To do that he must intercept the ball when somebody shoots it. One thing that help a lot is a good location, already discussed in Section 6.2.1. Another thing is actively trying to block the shots.
6.2.3.1 Initial version
An initial method of trying to defend the goal was implemented. This method to stop shots is very simple:
Algorithm 6.3 Goalkeeper defense method using legs if ball in our midfield and ball velocity in direction to the goal bigger than a thresh- old then Open both legs; else Stay in Defense Point; end if
Figure 6.7: Goalkeeper trying to defend using the legs
This action, as the robot legs are big, cover almost the whole goal width.
82 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.2. GOALKEEPER BEHAVIOR
Although very easy to implement, this method isn’t very effective because only evaluating the ball velocity it’s not easy to determine if the ball is going to the goal, when, which side, at what velocity, ... Too many indeterminations for the defense to be effective.
Other situation that force this method to be abandoned was the robot model change. In opposition to Soccerbot, NAO isn’t able to open the legs that way so this method has to be abandoned.
6.2.3.2 Using ball movement prediction
After implementing the Ball Movement Prediction module (Section 5.3) the way the goalkeeper defends the goal can be improved. Now we know with very good detail where the ball is going to be a time interval from now.
A security circle around the goal is considered.
Figure 6.8: Security circle used by the goalkeeper
The goalkeeper is permanently evaluating the ball location in every of the the next t simulation cycles.
If the doesn’t enter the security circle in any of these cycles, the goalkeeper keeps his other defending procedures (stay in “defense point” and leaving it when necessary to kick the ball away).
If the goalkeeper detects that the ball will enter the security circle in the simulation cycle s (with s ≤ t) he will try to avoid it to hit the goal.
83 6.2. GOALKEEPER BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
Figure 6.9: Predicted ball position after s simulation cycles
Knowing the ball location in cycle s, goalkeeper decides to dive to the left or to the right side (the one where the ball is going to) to try to defend the shot.
Figure 6.10: Goalkeeper diving to defend the goal
Algorithm 6.4 Goalkeeper behavior using ball movement prediction SC ⇐ circle; SC center ⇐ middle of the goal; SC diameter ⇐ goal width; for cycle s = 0toMaxCycles do PredBallPos ⇐ predicted ball location in cycle s; if PredBallPos inside SC then DiveSide ⇐ decide which side (left or right) to dive based on PredBallPos; return dive to DiveSide to defend the goal; end if end for return other defense procedures;
84 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.3. PLAYERS BEHAVIOR
This method proved a lot better than the previous one, although the movement of diving still very slow.
6.2.4 Conclusion
After the improvements already discussed we passed from a goalkeeper that only stands in front of the goal to a goalkeeper that chooses the best position to stay to defend the goal, that runs and kicks the ball away when needed, that estimates if the ball is going to enter the goal, which side of the goal this is going to happen and tries to avoid it.
6.3 Players behavior
Besides the goalkeeper there are the field players. Their mission is to, globally as a team1, score goals and help the goalkeeper to keep the own goal safe.
6.3.1 Decision-making structure
The decision-making structure of the agent has also been modified. The basic idea is to attribute to all possible actions an utility value. As higher the utility value is, best for the team is to take the correspondent action. For example, when a player is near the opponent’s goal with no one obstructing him it’s more useful to kick the ball to goal than pass it behind. The utility value of shooting to goal is higher than passing behind. The structure allows to evaluate all the possible actions of the player and then choose the best one. The team strategy state (attacking, defending or any other defined) is taken in consideration. After that, the utility value is calculated for the possible actions and a choice is made.
Algorithm 6.5 Agent decision-making basic structure switch TeamState for all PossibleActions do Calculate action Utility Value; end for Execute action with highest Utility Value; end switch
The choice of the set of actions to be evaluated and the utility values calculation formulas are very complex questions. The considered possible states of the team at the moment are enumerated:
1Depends on the number of players; at the moment this work began games were 2 versus 2 and FC Portugal has one goalkeeper and one field player
85 6.3. PLAYERS BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
• Attacking
• Defending
It is evaluated if the player possesses the ball or not:
• Player with ball possession
• Player without ball possession
6.3.2 Walk towards the ball
Walking is important to all animals, humans as well. A soccer player also needs to move himself around the field so he can be where is most useful: run to receive a pass from a teammate, to intercept a lost ball, to be in the best position to shoot... One ability that was already implemented when this work began was the ability of the player to walk to a specific point on the field (see 4.2.4.2). This ability used two low-level skills available at the time: walk in front and rotate.
Algorithm 6.6 Field players’ walk, initial version if absolute value of desired point relative direction < 30º then Walk in front; else if desired point to the right side of the player then Rotate to the right; else Rotate to the left; end if end if
But the initial agent only walked in direction to the ball and a player needs to walk to other field locations to intercept opponent’s passes, catch lost balls, receive passes from teammates, run with the ball, etc. Being so, the walk procedure has been divided int two: “move to point” and “move to ball”.
6.3.2.1 Move to point
Before omnidirectional walk Walk to point is intended for the player to go to any location of the game field. As original walking method (Algorithm 6.6) was simple but effective, its basic strategy has been maintained. After the introduction of the omnidirectional walk, this method suffered an im- provement.
86 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.3. PLAYERS BEHAVIOR
After omnidirectional walk After the introduction of the omnidirectional walk in our agent, it’s not necessary anymore to use the two separate skills: walk in front and rotate. The same effect with more stability and faster is achieved with the omnidirectional walk. The strategy used is to maintain side walk speed at zero2 and relate frontal walk and rotation speeds with the relative direction of the desired point.
Desired point relative direction = 0º Frontal walk speed = maximum Rotation speed = 0
Figure 6.11: Move to point, omnidirectional walk, relative direction is 0º
When the relative direction of the desired point is 0, the frontal walk speed is max- imum and rotation speed is 0.
Desired point relative direction = 45º Frontal walk speed = 0 Rotation speed = maximum
Figure 6.12: Move to point, omnidirectional walk, relative direction is 45º
When the relative direction of the desired point is 45º or higher, the frontal walk speed is 0 and rotation speed is maximum. The value of 45º is chosen because it is not useful to keep walking in front if the desired point is in a high (positive or negative, right or left) relative direction. If we consider that maximum front walk speed and maximum rotation speed have the same value3, the skill “Move to point” became:
Algorithm 6.7 Move to point, pre-omnidirectional walk RelDirectionLimit ⇐ 45; if DesiredPointRelDirection > RelDirectionLimit then DesiredPointRelDirection ⇐ RelDirectionLimit; else if DesiredPointRelDirection < −RelDirectionLimit then DesiredPointRelDirection ⇐−RelDirectionLimit; end if OmnidirectionalWalkParams ⇐ (RelDirectionLimit − DesiredPointRelDirection, DesiredPointRelDirection,0);
2In fact it will not be always 0, but “move to point” will not be responsible for this. See 6.3.2.2. 3This could be false and is used only to demonstrate how the “move to point” procedure works. Informations about maximums and units of the several parameters should be consulted in [76].
87 6.3. PLAYERS BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
This improved walking allows the player to move around the field without faster and smoother (without need to stop between low-level skills).
6.3.2.2 Move to ball
Approaching the ball by the right side When a player is going to the ball, almost all the times the next action will be to walk with the ball to near the opponent’s goal or kick it (more details in 6.3.3 and 6.3.5, respectively). Both these actions require the player to be turned to the opponent’s goal and behind the ball.
Figure 6.13: Position of the player to be able to walk with ball or kick it
Then what happens if the player is in a position like the ones in Figure 6.14?
(a) (b)
Figure 6.14: Problematic positions for the player to go to the ball
The player cannot simply go to the desired point behind the ball because in this case he will jostle the ball.
88 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.3. PLAYERS BEHAVIOR
To try to minimize this issue the initial FC Portugal 3D Humanoid agent already has a solution: evaluates if his absolute x coordinate is bigger than the absolute x coordinate of the ball (see 5.2.1). In this case he cannot walk in direction of the ball because of the problem already discussed. Then, to choose where to go, he evaluates his and ball’s y coordinate and if the ball is at his left (ball’s y lower than player’s y coordinate) he will “move to point” to BallPosition + (−3, 2). If the opposite occurs (the ball is to the right) he will go to BallPosition + (−3, −2).
Algorithm 6.8 Move to ball, initial version if PlayerPos.x > BallPos.x then if PlayerPos.y < BallPos.y then MoveToPoint (BallPos + (−3, −2)); else MoveToPoint (BallPos + (−3, 2)); end if else MoveToPoint (BallPos); end if
The next figures show the point where the player is walking to, considering his position in relation to the ball.
(a) (b) (c)
Figure 6.15: Move to ball, initial version
This solution is obviously too simple and has some problems. In a situation like the one in Figure 6.16, this solution is clearly bad.
89 6.3. PLAYERS BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
Figure 6.16: Move to ball initial version problems
In this situation the better movement is to just kick the ball to the goal.
Improving the solution To improve the way this issue was solved another method has been implemented. This solution is based on a principle that solves the problem of Figure 6.16: the player must go to the point where it is best to shoot, a point in the line opponent’s goal–ball.
Figure 6.17: Move to ball, version 2, step 1
To choose where is the best point to go, the player draws the opponent’s goal–ball line. Also a circumference with ray r4 is drawn around the ball.
Figure 6.18: Move to ball, version 2, step 2
The result is two possible points. Obviously the only one that is useful for the player is the one far from the goal (t0). Let’s call this point t.
4The best value of r is what fits best the needs of a good shot; see 6.3.5.1
90 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.3. PLAYERS BEHAVIOR
The next step is to determine if it is useful to go to the point or it is best to go to the ball and then the shot adjustments (chapter 6.3.5.1) will be enough. If the player distance to the ball is lower than to point t or is lower than r, that is the case. If not, it needs to be determined the point to where the player goes. A line between the player and the ball is drawn and also another line perpendicular to the first one.
Figure 6.19: Move to ball, version 2, step 3
The two points of the second line that intersect the circumference are p0 and p1. The player will “move to point” that has a lower distance to point t. In this case p0.
Algorithm 6.9 Move to ball, version 2 BallGoal ⇐ line between the ball and opponent’s goal; BallCirc ⇐ circumference with ray r around the ball; { } ⇐ t1, t2 points of intersection between BallGoal and BallCirc; ⇐ { } t point from t1, t2 with higher distance to the goal; // t is the best point to kick or start walking with the ball DistToBall ⇐ distance between the player and the ball; if DistToBall < r or DistToBall < distance between player and t then MoveToPoint (BallPosition); else BallPlayer ⇐ line between the ball and the player; PerpLine ⇐ line perpendicular to BallPlayer; { } ⇐ p1, p2 points of intersection between BallPlayer and BallCirc; ⇐ { } p point from p1, p2 with lowest distance to t; MoveToPoint (p); end if
This method makes the player not to jostle with ball and, being in any place of the field, go to the point to kick the ball or start walking with it controlled. However, this method causes the player to always go to a point that always has the same distance r to the ball. This causes a problem: r cannot be very high or else when the player is near the ball it will not adjust his walking and go straight towards it, nor can be very low or the player will simply go straight towards the ball all the time, not adjusting his walk.
91 6.3. PLAYERS BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
Hence this method was changed so r is not a fixed value. It changes according to the relation between ball and target directions relative to the player. This method is based on one from NimbRo [87].
Figure 6.20: Positioning behind the ball. Origin: [87]
The player will now move to the point behind the ball in the “ball→target” that is at distance r from the ball.
r = Reduction Factor × abs (Ball direction − Target direction) (6.1)
Where Ball direction and Target direction are directions relative to the player. Re- duction Factor = 0.01 was found to be a good value. This method is good but has one problem: if the player is between the ball and the target he will jostle the ball. So we joined the variable value of r with the approach of Algorithm 6.9. The al- gorithm maintains the same except that the ray of the circumference is not fixed. It changes following equation 6.1.
Aligning foot during walk When the player is going to the ball he may want to kick it as soon as he is close enough. As it will be discussed in 6.3.5.1, for the shot to be precise it is required some adjustment time. Some of this adjustment time will be for the player to side-walk so one of the feet (the one that will perform the kick) is aligned with the ball. This is necessary because when the player is going to a specific point what is going to that point is the torso of the player. As the kicks are performed by the feet and they are not aligned with torso (more details in 3.5.2), the player must side-walk until one of them is aligned with the ball. This adjustment time can be reduced if we eliminate (or at least reduce drastically) the adjustment previously referred. And how we do that? The player don’t wait to stop to walk to align one foot and then kick. He aligns one of the feet while still walking in direction to the ball.
92 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.3. PLAYERS BEHAVIOR
As soon as the player decides that the action he is going to take after getting near the ball is to kick it, he starts adjusting his position so when he gets near the ball the foot is already aligned, reducing the adjustment time. The method to the alignment is the same used in “move to point” (see 6.3.2.1) but only using omnidirectional side-walk parameter. So, as much aligned the foot is, less side-walking will be performed. The foot that is aligned with the ball can be chosen. We are always aligning the same foot because we’re always kicking using it. But in the future, if both feet are used, the player can choose what foot to align.
6.3.3 Walk with the ball
Besides from shooting, one thing that is useful is the ability to walk controlling the ball. This lets the player to catch the ball in any point of the field and go with it to a point where he can kick it to goal, for example.
(a) (b)
Figure 6.21: Walk with the ball
As the omnidirectional walk has small frontal steps and the used robot (NAO) has big feet, it is not difficult to walk with the ball controlled. If the player goes to the ball aligned with it and keep walking, it will “fit” in the frontal part of the feet and the player can walk controlling the ball. Most of the time, if the player walk in front, the ball will stay there and go with the player. The problem is when the player needs to make a turn. The ball will leave its position between the feet and player will not be able to control it. The strategy used to not lose the ball control is the same used in 6.3.2.2 for aligning the feet. There will be side-walking to compensate the ball deviation from its position be- tween the feet.
93 6.3. PLAYERS BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
(a) (b) (c)
Figure 6.22: Walk with the ball adjustments
If the ball is going to the right side, the player will do some side-walk to the right side so the ball will be back to its position.
This simple strategy shows itself very effective and the player is able to walk con- trolling the ball well enough.
6.3.4 Avoid obstacles
When the player is walking with the ball in direction to the opponent’s goal there can be some obstacles. In fact it is probable that obstacles will exist because the oppo- nent players will try to obstruct and stop him.
So the player needs to have the ability to avoid obstacles. This ability consists in:
94 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.3. PLAYERS BEHAVIOR
Algorithm 6.10 Avoid obstacles l ⇐ line between the player and the target; for all players do c ⇐ circle around the player with ray = security distance; if l intersepts c then if closestPlayer not defined then closestPlayer ⇐ currentPlayer; else if distance to currentPlayer < distance to currentPlayer then closestPlayer ⇐ currentPlayer; end if end if end for if closestPlayer not defined then Go in front; else v ⇐ vector with origin in the obstacle, turned to the player, with length = security distance; targetDir ⇐ target direction relative to the player; obstacleDir ⇐ obstacle direction relative to the player; if obstacleDir < targetDir then Rotate v 90º; // Avoid obstacle by walking by the right side else Rotate v -90º; // Avoid obstacle by walking by the left side end if Go to v; end if
6.3.5 Shot
The shot is one of most important actions for a soccer player. The same happens to our players. The shot must be, as much as we can, precise. The player must be able to aim to a point and shoot the ball to this point with as less error as possible.
Figure 6.23: Player shooting the ball. Origin: [3]
6.3.5.1 Aiming precision
The ability to shoot the ball with high precision, making the ball go to the desired point is very useful. With that, the ball can be kicked from a closed angle or a distant
95 6.3. PLAYERS BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT point and, even so, hit the goal.
(a) Kick from distant point (b) Kick from closed angle
Figure 6.24: Shots to goal from difficult locations
As we have a low-level skill that is a kick and it is deterministic, which means in the same conditions the ball always goes in the same direction. Knowing that, to make the ball to the desired point we need to be able to replicate the conditions. These “conditions” are, in fact, just the position of the ball relative to the player (or vice-versa). Let’s call it position relation. If we can replicate this position relation we’ll be able to perform very precise shots.
(a) Imprecise shot (b) Imprecise shot
(c) Precise shot (d) Imprecise shot
Figure 6.25: Influence of the position relation in the shot precision
To be able to replicate that precise position difference between the player and the ball we make use of the omnidirectional walk (6.1) facilities. All the three parameters of omnidirectional walk are necessary:
• Frontal walk to adjust the position relation between the player and the ball
• Lateral walk to adjust the position relation between the player and the ball
• Rotation to turn the player to the desired shoot point, so the ball will go exactly to that point
This way we are able to put the player in the precise and needed position relation and turn the player so the ball will go to where we want.
96 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.3. PLAYERS BEHAVIOR
The basic idea is the same of move to point (6.3.2.1): the speed of the movement in any of the parameters is proportional to the difference between the actual and the desired value of these parameters.
• Frontal walk
Frontal walk speed = (desired position – actual position) on longitudinal axis
This means the speed will be higher when the difference is bigger and 0 when the player is in the desired place.
(a) Bigger difference, higher speed (b) Smaller difference, lowest speed
Figure 6.26: Frontal speed
• Lateral walk
Lateral walk speed = (desired position – actual position) on transverse axis
This means the speed will be higher when the difference is bigger and 0 when the player is in the desired place.
(a) Bigger difference, higher speed (b) Smaller difference, lowest speed
Figure 6.27: Lateral speed
97 6.3. PLAYERS BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
• Rotation
Rotation speed = desired direction – actual direction
This means the speed will be higher when the difference is bigger and 0 when the player is turned to the desired direction.
(a) Bigger difference, higher speed (b) Smaller difference, lowest speed
Figure 6.28: Rotation speed
When the player is near the ball and wants to prepare a precise shot just use its om- nidirectional walk with the previous parameters. The desired position referred is the point that is distant from the ball the previously called position relation.
Figure 6.29: Player kicking the ball
As it’s easily understandable this will, in the limit, put the player in the exact de- sired location. But it will take as much time as we want it to be exact. Hence we can evaluate what is most important at the moment: a very precise shot or a kick shot?
98 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.3. PLAYERS BEHAVIOR
When the player is far from the opponent’s goal or has several obstacles in front of him – basically when the shot utility value is low (see 6.3.5.2) – it may be useful a more precise shot. On the other hand, when the player is near the opponent’s goal or he has an opponent near him that could trouble his shot maybe it’s better to kick quickly, even if not with high precision.
The kick will be performed after the preparation phase is over and it is over when for all the three omnidirectional parameters: desired value − actual value = 0 ± tolerance.
These tolerance values will be as bigger as we want the shot to be quick and less precise.
6.3.5.2 Best point to shoot to and its utility value
The player is now able to shoot the ball with high precision so it goes to the desired point.
Now the player must be able choose which point is best. Where should the player kick the ball to?
Figure 6.30: Possible points the player can shoot the ball to, for it to hit the goal
To determine the best point for the player to shoot the ball to the following method is used:
1. Draw a triangle with the corners being the two goal limits and the player.
99 6.3. PLAYERS BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
Figure 6.31: Best shoot point calculation, step 1
2. Draw circles representing every other players on the field. The ray of the cir- cles depends on whether the players are estimated to stand up or down on the ground. This estimation is based on the z-axis value received for that player (remember the players are only seen as a point; see also 3.6).
Figure 6.32: Best shoot point calculation, step 2
3. Remove from the initial triangle the points hidden by the players. Divide trian- gle in sub-triangles, if necessary.
Figure 6.33: Best shoot point calculation, step 3
100 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.3. PLAYERS BEHAVIOR
4. Determine mean point for every triangle’s base. These are the possible point that will be evaluated
Figure 6.34: Best shoot point calculation, step 4
5. Determine distance between points determined in previous step and player.
Figure 6.35: Best shoot point calculation, step 5
6. Calculate utility value for every triangle.
triangle “open angle” Utility Value = (6.2) distance to base mean point
101 6.3. PLAYERS BEHAVIOR CHAPTER 6. HIGH-LEVEL DEVELOPMENT
Figure 6.36: Best shoot point calculation, step 6
7. The best shoot point is the one the the biggest utility value.
Figure 6.37: Shot to the best point
This method gives the best point to shoot the ball to. It considers obstacles blocking the way to the goal, it considers the biggest “open space” to shoot to and it considers the distance to the possible shoot points. It gives also an utility value based on how good could a shot to that point be. That utility value could be (and it is) used by the player to evaluate if to shoot to that point is the best action he can take.
6.3.6 Conclusion
We passed from a player that initially only walked to the ball and kicked it without any kind of aiming. We passed to a player that chooses the best place to shoot the ball, is able to shoot it to that point with high precision and, using an omnidirectional walk, moves to near ball adjusting automatically his position to reduce the time needed to adjust to a precise kick. And specially, the new agent has a decision-making structure that allows future work in this area. All the new actions the player will be capable of, just need to have an utility value calculation method. The player will then follow the structure and choose the action with the highest utility value at that moment.
102 CHAPTER 6. HIGH-LEVEL DEVELOPMENT 6.4. PLAYERS COMMUNICATION
6.4 Players communication
During real soccer games the players talk to each other. Sometimes to give some advices or instructions or to request some information to teammates, other times to say things not very kind to the opponents or the referee.
In this simulation the referee will not hear what the player is saying and the oppo- nents will not be psychologically affected, but the communication between teammates could be very useful. Several informations can be exchanged, like formation decisions or role-swap information [82].
At the moment the vision information sent by the simulator is clean of any noise, but is expected that soon the vision will be affected by noise like other RoboCup Simu- lation Leagues. When this happens, communication could be used to exchange infor- mation about the location for other objects of the field (players, goals, flags or others).
The communication directly between agents is not allowed, but they can exchange messages via the simulator.
Players communication allow players to send messages, just like a real soccer player talks out loud. Every other players (teammates and opponents) at less than a threshold distance will be able to hear that messages. More informations in 3.2.1.3 and 3.2.2.2.
Figure 6.38: Saying a message
103 6.4. PLAYERS COMMUNICATION CHAPTER 6. HIGH-LEVEL DEVELOPMENT
Figure 6.39: Hearing messages
One Between Players Communication module has been implemented that has two methods: say and hear. Say creates a message (see 3.2.2.2) and sends it to the simulator so the other players can hear it. Hear is called when message parser finds a hear message. Right now it does nothing but can in the future be used to make useful the information heard. Additional conditions were added to the message parser so the agent is able un- derstand the hear messages (see 3.2.1.3). This communication ability is implemented and functional but not yet used in the agent.
104 Chapter 7
Conclusion
Concluded this project there are some conclusions we can take. Some conclusions about (simulated) robotic soccer domain, another ones about the work done, the mod- ules studied and implemented, and other conclusions about the general performance of the team. About the domain where this project belongs we can conclude that robotic soccer is having a quite fast evolution. This is very interesting, not only in a purely research view, but also in a civil view. Some of the improvements achieved in RoboCup com- petitions are later applied to civil world. As seen in Chapter 2, some of the research done in the robotic soccer domain is applicable in RoboCupRescue and this is directly useful and usable in civil means. One thing that is essential in robotic soccer domain, just like many others, is the knowledge database of the agent. The agent perception and knowledge about the world surrounding him. The FC Portugal 3D humanoid agent already possessed a very good mechanism for this purpose, the so called WorldState package of the inher- ited FC Portugal structure. The systems and modules studied and implemented revealed its usefulness. The new decision-making structure has been implemented thinking on future work. Its Utility Value based procedure is highly flexible, being easy to introduce new behav- iors or improve the existent ones. This structure also improves the modularity of the agent. Forward kinematics has already been used to improve low-level skills of the agent, and it also is important to inverse kinematics. The inverse kinematics model is built based on forward kinematics equations. Inverse kinematics itself has not been used yet, but may be very useful in future work (see Chapter 8). The numeric inverse kinematics has not been software implemented yet. The self-location system revealed very good results, not having any unexpected effect. Also the calculation of other objects location works great. Ball movement prediction module is already being used by the goalkeeper, but may and should be used in several other situations. This module works great, giv-
105 CHAPTER 7. CONCLUSION ing very good predictions if the given data (location, velocity and acceleration of the object) is not noisy. As already seen, it is necessary to filter this data in order to have good predictions. If the data is filtered, the predictions are very good. The goalkeeper has improved a lot since the beginning of this work. The choice of the best point to defend the goal is showing itself a good mechanism. The “leaving the defense point” procedure is an idea to be improved because right now it is quite basic. Specially because goalkeeper and his teammates don’t strategically plan this and leaving the defense point could cause problems sometimes, when several players of the same team go to ball. The defense is a major improvement in the goalkeeper. Although, it could be even better if the “fall” skill were faster. May be an issue for future work research. The field players have also evolving in some points: the implemented “walk to the ball” has good results. The ability to walk with the ball controlled is very useful. Its implementation has been simple and it has very good results. The obstacle avoidance is quite basic and needs improvements. The player shooting ability has also been improved. Initially the player kicked the ball in front, without any kind of aiming, without adjusting, without knowing precisely where the ball is going to. Two complementary systems have been imple- mented: one to determine the best point of the goal to shoot the ball to, and its utility value; another one to adjust the player so the shot has high precision. Both have very good results. The first system allows the player to know where to kick the ball with the highest probability to score, and even, in the future, calculating if it is better to kick the ball or pass it. The second system give the player to kick the ball to where he desires with very high precision. The only problem is that it needs some time to adjust. Although, the player must choose what is most important at the moment: the precision of the kick or the time he takes adjusting. The player communication mechanism has been tested and works as expected. Although, it is not yet used. In the future (see Chapter 8) this module can be quite useful. FC Portugal 3D humanoid agent is a project whose improvement needs to con- tinue. Some possible approaches to improve the agent are analyzed in Chapter 8. The team general performance improvement is quite visible. We passed from a goalkeeper that stand still in front of the goal, and a player that walk to the ball and kick it to where he is turned, to a goalkeeper that chooses the best point to cover the goal and actively defends the goal by predicting the ball movement, and players that go to the ball by the correct side, can walk with the ball controlled and shoot with very high precision.
106 Chapter 8
Future work
As it is the major intention of the RoboCup project, this research area is in a fast evolution. So there is a lot of future work that can be done. Specially since one major part of this work was the creation of a structure for the agent that allows the creation and integration of new behaviors, attributing to each one of them an Utility Value. Then the agent will choose in runtime the best action to take. So there are some features that can be implemented in the future.
8.1 Behaviors
In the future some new behaviors can be added to the agent. Can and should be added, because the number of players per match will grow and they will need to do teamwork to be successful.
8.1.1 Pass
One basic movement in real soccer is the pass. This allows the player that possesses the ball to send it to a teammate. This could be because the teammate is in a better position to score, or an opponent is obstructing the player and his teammate is free from opponents, or any other situation where a teammate is in better situation to do something than the player that has the ball possession. The ability to pass the ball is not yet implemented because at this point we’re not able to control with enough precision how strong are the kicks. When, in the future, we are able to control how strong are the kicks we’ll be able to (since we already can do very precise shots, see section 6.3.5) send the ball to the point in the field where we want it. The integration of the pass ability will be very easy, just like any other new be- havior. Due the agent decision-making structure, we only have to attribute an Utility Value to the pass. This will extremely helpful in offensive actions of the team. At this moment the
107 8.1. BEHAVIORS CHAPTER 8. FUTURE WORK player is able to determine the Utility Value of the Shot for himself and any other player in the field. If a teammate has a bigger Shot Utility Value than the player it would be smart to pass him the ball, as he is in a better situation to score. Although, the pass action has risks: there could be obstacles and the pass can fail his target. So it is necessary to quantify these risks. This quantification is the inverse of the Utility − Value. Utility value = risk value 1. Then we can evaluate the “pass to teammate + teammate shoots” action utility value by multiplying Pass Utility Value by Teammate Shot Utility Value. Let’s see some examples:
• Situation 1
£ Player 1 shot utility value1: 100
£ Player 2 shot utility value:80
£ Pass utility value:?
Figure 8.1: Situation where it’s better to shoot than pass
£ Best to do: shoot the ball
£ Comments: it is not even necessary take in consideration to pass the ball because the player is in a better situation to score than his teammate.
• Situation 2
£ Player 1 shot utility value: 100
£ Player 2 shot utility value: 150
£ Pass utility value: 0.5
1This and the next utility values of these examples are not calculated and are just for illustrative purposes
108 CHAPTER 8. FUTURE WORK 8.1. BEHAVIORS
Figure 8.2: Situation where it’s better to shoot than pass
£ Best to do: kick the ball £ Comments: Player 2 has a higher shot utility value (150) but because of the pass utility value, the “pass + shot” action has a lower utility value (0.5 × 150 = 75) than shooting the ball to goal (100).
• Situation 3
£ Player 1 shot utility value: 100 £ Player 2 shot utility value: 150 £ Pass utility value: 0.9
Figure 8.3: Situation where it’s better to pass than shoot
£ Best to do: pass the ball £ Comments: the utility value of “pass + shot” is higher (0.9 × 150 = 135) than shooting the ball directly to goal (100).
The ability to pass the ball can also use the ball movement prediction (section 5.3) to pass the ball not directly to a teammate, but to an open space where a teammate will be in a short time.
8.1.2 Intercept passes & shots
Just like our agent, in the near future the opponent teams will probably be capable of passing the ball between players.
109 8.2. PLANNING THE PATH CHAPTER 8. FUTURE WORK
Using the ball movement prediction (section 5.3) our agent is able to determine where the ball will be within a few moments. This gives him the possibility to intercept passes made between opponent players and start a counter-attack. Like passes, shots to goal can also be intercepted and avoid the opponent’s goal.
8.1.3 Covering
Some kind of defensive covering can be implemented. For example, place a player between an opponent and the ball. This way it’s much harder to pass him the ball without us to catch it.
8.1.4 Walk backwards to avoid rotating
As seen in section 6.3.2, when walking in direction to the ball the player will do the necessary path to get behind the ball. This is done by rotating when necessary. But is it necessary and is it useful to do all that procedure in a situation like in Figure 8.4?
Figure 8.4: Situation where is not good to perform the actual “walk towards the ball”
In a situation like this one is better not to perform the old path of “walk towards the ball” but instead just walk backwards and then left or right side, which is best. The amount of time waisted with the first method is way bigger than the time needed by the second method. The possibility to do this is not yet implemented because the ability of our agent to walk backwards is recent.
8.2 Planning the path
At this moment, when with the ball possession, the player will walk in direction to the opponent’s goal. If, in his way, he finds some obstacle (an opponent player or a teammate on the ground) he will try to avoid it using a simple method (see section 6.3.4). This is not a very good method because, let’s imagine a large number of players is in the central zone. Our player will not plan his path soon enough and will walk in
110 CHAPTER 8. FUTURE WORK 8.3. VISION direction to them. He will only try to avoid those players when almost close to them. This can lead the player to loose the ball. One possible approach to improve this is to use path planning algorithms, such as A*, for example. In fact, given the nature of the problem we could use Lifelong Planning A* [61]. Lifelong Planning A* is a variation of A* where, when the world state changes, it’s not necessary to do all the calculations again. It is incremental, so the search tree is reduced so there will be less calculations to do. Using a path planning algorithm the player will know, at every moment, what is the best path to take. This will minimize the amount of time for the player to reach the target (usually the opponent’s goal, but any other can be specified) and automatically avoid the obstacles.
8.3 Vision
8.3.1 Noise and Restricted vision
In a near future the vision perceptor will suffer changes. The vision will become noisy which means that the player no longer can trust 100% in what it sees. The infor- mation sent by the simulator saying what the play is seeing will have some random noise. The vision will also become restricted, instead of the actual omnidirectional one. The player will not see 360º. He will not see what’s behind him, for example. There will be a specific angle inside what the player will have information.
Figure 8.5: Restricted vision
If the vision will not be as secure as it is now, the players, to have always the most trustful information about the location of everything, can exchange information. The Say & Hear mechanism, implemented but not yet used, will then be very useful. Players can exchange with each other what he sees and what is the degree of certainty of that information. If another player α knows the location of another player β with a higher degree of certainty than myself, I should consider my information wrong and his correct.
111 8.3. VISION CHAPTER 8. FUTURE WORK
This degree of certainty can be obtained, for example, by evaluation the variation of the information in the last messages. If it varies too much, some of that messages have a lot of noise and the degree of certainty is low. Otherwise we can assume the information is trustful and the degree of certainty is high.
8.3.2 Players posture estimation
One big problem of the actual version of SimSpark is that the agent sees other player as single points. This doesn’t allow to know what is the player posture. Is it up or down on the ground? Is it turned to me or to any other side? Is the opponent goalkeeper covering just a small part of the goal or, on the other hand, is he down on the ground covering almost all the goal? At this moment we are only estimating if the players are up or down and rep- resenting them as circles with ray equal to the distance between head and shoulder (in case of being up) or leg length (in case of being down on the ground). This is a pessimist approach. We consider that the player is in all positions he can be. The estimation is simply based on z coordinate of the point that represents the player. By analyzing this coordinate when the players were up and down on the ground we came to a value that we use as threshold to decide the posture of the play- ers. Of course this method is not ideal. Although the estimation of if the player is up or down works well, the used pessimist approach of representing the players by circles is not good because sometimes our agent is avoiding obstacles that are not there, leading it to loose time. And loosing time means, a lot of times, to loose an opportunity to score. So, while the simulator doesn’t give us more complete information about the other players we may try to improve the estimation method. The main situation where is important to know the player posture is when he is on the ground. This is because his legs are bigger than his head2, so there is one side around the point that represents the player that is effectively occupied by him (by his legs). The other sides are just a few occupied. With the actual method we consider that all sides are equally occupied. To avoid this assumption, we can analyze the player’s movement to try to estimate which side he fell. Just like in the previous section, we can use inter-agent communication to ex- change information between players.
2Remember the vision is on the torso
112 CHAPTER 8. FUTURE WORK 8.4. USAGE OF INVERSE KINEMATICS
8.4 Usage of Inverse Kinematics
The usage of the inverse kinematics module to improve high-level behavior should also be studied in the future. Besides being useful to study and improve low-level skills, inverse kinematics can also be used to improve high-level behaviors. One example is the goalkeeper: using the ball movement prediction the goalkeeper knows where the ball is going to be. Using inverse kinematics the goalkeeper can determine the necessary angles of the arm joints so he can defend the ball with the hand.
8.5 Integration with FC Portugal strategy
As already seen, one of the main research areas of the FC Portugal team is strategy and strategic behaviors. At this point the agent lacks this kind of behavior. So it is a good idea to improve the agent with all the strategic mechanisms already built for other FC Portugal teams. The strategic mechanisms of FC Portugal should be implemented in the agent, in order to boost its strategic abilities. This is specially important because the number of players per match will keep growing and strategic teamwork will become very important.
113 8.5. INTEGRATION WITH FC PORTUGAL STRATEGYCHAPTER 8. FUTURE WORK
114 Bibliography
[1] Aldebaran Robotics | Humanoid Robot - NAO’s World - RoboCup website. , November 2008.
[2] Fedora website. , November 2008.
[3] Football or Soccer. , November 2008.
[4] Fujitsu HOAP Humanoid Robot. , November 2008.
[5] Honda’s Asimo. , November 2008.
[6] Humanoid Robot HOAP-1 Specification. , December 2008.
[7] Humanoid Robot HOAP-2 Specification. , December 2008.
[8] John Doyle Soccer Camp - Goalkeeper Camps. , November 2008.
[9] Kinematics – design of machines: Types of kinematic joints. , Novem- ber 2008.
[10] openSUSE website. , November 2008.
[11] Player project. , December 2008.
[12] A review of robotics software platforms. , December 2008.
[13] RoboCup 2007 website. , November 2008.
[14] RoboCup 2008 website. , November 2008.
115 BIBLIOGRAPHY BIBLIOGRAPHY
[15] RoboCup Junior Official Website. , De- cember 2008.
[16] RoboCup Rescue Official Website. , December 2008.
[17] RoboCup Soccer Server 3D Manual, April 2008.
[18] RoboCup website. , November 2008.
[19] RoboCup@Home Website. , December 2008.
[20] SimSpark website. , November 2008.
[21] Small Size Robot League. , December 2008.
[22] Soccer with RoboSapien: Team NimbRo of Freiburg University. , December 2008.
[23] Sony AIBO Discontinuation Announcement. , November 2008.
[24] Sony AIBO Europe - Official Website. , November 2008.
[25] SONY Dream Robot website. , November 2008.
[26] Ubuntu website. , November 2008.
[27] , December 2008.
[28] Saeid Akhavan, Mohammad Babaeizadeh, Hamid Reza Hasani, Arefeh Kazemi, Hoda Safaeipour, Mohammad Sheykholeslam, Hedayat Vatankhah, Zahra Zo- jaji, and Zainab Zolaktaf. UI-AI3D 2007 Team Description. In RoboCup 2007 Team Description Papers, 2007.
[29] Saeid Akhavan, Hamid Reza Hasani, Kamal Jamshidi, Arefeh Kazemi, Hoda Safaeipour, Mohammad Hoseyn Sheykholeslam, Hedayat Vatankhah, Moham- mad Reza Yazdchi, Zahra Zojaji, and Zainab Zolaktaf. Ui-ai3d 2008 team de- scripton paper. In RoboCup 2008 CD, 2008.
[30] Jorge Angeles. Fundamentals of Robotic Mechanical Systems: Theory, Methods, and Algorithms. Mechanical Engineering Series. Springer US, third edition edition, 2007.
116 BIBLIOGRAPHY BIBLIOGRAPHY
[31] Haruhiko Asada and Jean-Jacques E. Slotine. Robot Analysis and Control. Wiley- IEEE, 1986.
[32] Siavash Aslani, Nima Shafii, S.Mohammad H.S.Javadi, Vahid Azizi, Omid Mo- hamad Nezami, and Siavash Mahmoudian. Mrl soccer 3d team description pa- per. In RoboCup 2008 CD, 2008.
[33] Dunqiao Bao, Hao Wang, Baofu Fang, and Long Li. Hfutengine3d soccer simu- lation team description 2008. In RoboCup 2008 CD, 2008.
[34] Sven Behnke, Jürgen Müller, and Michael Schreiber. Playing soccer with ro- bosapien. In RoboCup-2005: Robot Soccer World Cup IX, volume LNCS 4020 of Lecture Notes in Artificial Intelligence, pages 36–48, 2006.
[35] Sven Behnke, Michael Schreiber, Jörg Stückler, Hauke Strasdat, and Konrad Meier. Nimbro kidsize 2007 team description. In RoboCup 2007 Team Descrip- tion Papers, 2007.
[36] Reinaldo Bianchi. Robótica, aula 6: Cinemática inversa. Centro Universitário da FEI, 2005.
[37] Rodrigo Morante Blanco. Cinemática Inversa, 2008.
[38] Joschka Boedecker. Re: [Sserver-three-d] Specifications of Humanoid. RoboCup Soccer Simulator 3D Mailing List, , 28 February 2007.
[39] Joschka Boedecker. Re: [Sserver-three-d] Stealthy Server Development. RoboCup Soccer Simulator 3D Mailing List, ,3 January 2007.
[40] Joschka Boedecker. [Sserver-three-d] rcssserver3D version 0.5.3 released. RoboCup Soccer Simulator 3D Mailing List, ,12 February 2007.
[41] Joschka Boedecker, Klaus Dorer, Markus Rollmann, and Yuan Xu. SimSpark User’s Manual, March 2008.
[42] Carlos Bustamante, Xavier Pérez, Noel Liarte, César Flores, and Leonardo Gar- rido. Borregos3d team description 2008. In RoboCup 2008 CD, 2008.
[43] Jianhuai Cai, Zhao Yin, Shunmin Xun, Saixian Ye, Li Wei, Yang Chen, and Shiyu Fu. Amoiensisnq-3d soccer simulation team description. In RoboCup 2008 CD, 2008.
117 BIBLIOGRAPHY BIBLIOGRAPHY
[44] All About Circuits.com. Low-pass filter. , May 2008.
[45] Joseph K. Davidson and Kenneth Henderson Hunt. Robots and Screw Theory: Applications of Kinematics and Statics to Robotics. Oxford University Press, 2004.
[46] Remco de Boer and Jelle Kok. The Incremental Development of a Synthetic Multi-Agent System: The UvA Trilearn 2001 Robotic Soccer Simulation Team. Master’s thesis, Faculty of Science, University of Amsterdam, February 2002.
[47] Isolda Giana de Lima, Vania Maria Pinheiro Slaviero, and Monica Scotti. Base de um Espaço Vetorial. , October 2008.
[48] Fernando Duarte. Controlo de robots redundantes. Escola Superior de Tecnologia de Viseu, 2007.
[49] Britannica Concise Encyclopedia. ’Kinematics’ Definition. , May 2008.
[50] Amin Milani Fard, Amir Farzad, Amin Zamiri, M. Hossein Ansari, Ehsan Sa- boori, Mahdi Aledaghi, and Mahmoud Naghibzadeh. Nexus 3d 2008 team de- scription. In RoboCup 2008 CD, 2008.
[51] Xue Feng, Tai Yunfang, Xie Jiongkun, Zhou Weimin, Ji Dinghuang, Zhang Zhiqiang, and Xiaoping Chen. Wrighteagle2008 3d team description paper. In RoboCup 2008 CD, 2008.
[52] Liang Gao, Guangbin Cui, Pu Li, Hongxia Chai, and Xiaomin Tang. Fantasia 2007 Team Description. In RoboCup 2007 Team Description Papers, 2007.
[53] Liang Gao, Guangbin Cui, Pu Li, Hongxia Chai, and Xiaomin Tang. Fantasia 2008 team description. In RoboCup 2008 CD, 2008.
[54] Kang Teresa Ge. Solving Inverse Kinematics Constraint Problems for Highly Articulated Models. Master’s thesis, University of Waterloo, Waterloo, Ontario, Canada, 2000.
[55] Luiz M. G. Gonçalves. Robótica: Sistemas Sensorial e Motor. , 2008.
[56] David Gouaillier, Vincent Hugel, and Pierre Blazevic. The NAO humanoid: a combination of performance and affordability.
[57] R. S. Hartenberg and J. Denavit. Kinematic Synthesis of Linkages. McGraw-Hill, New York, 1964.
118 BIBLIOGRAPHY BIBLIOGRAPHY
[58] Shivaram Kalyanakrishnan and Peter Stone. The UT Austin Villa 3D Simulation Soccer Team 2007. In RoboCup 2007 Team Description Papers, 2007.
[59] Shivaram Kalyanakrishnan and Peter Stone. Ut austin villa 3d simulation soccer team 2008. In RoboCup 2008 CD, 2008.
[60] H. Kitano et al. RoboCup – The Robot World Cup Initiative.
[61] Sven Koenig. Greedy On-Line Planning, January 2002.
[62] Mohammad Mehdi Korjani, Arman Sarrafi, and Golnaz Ghiasi. Parsian (amirk- abir univ. of technology robocup 3d simulation team) team description for robocup 2008. In RoboCup 2008 CD, 2008.
[63] Jeff Lander. Making kine more flexible. Game Developer Magazine, pages 15–22, November 1998.
[64] Andreas D. Lattner, Cord Niehaus, Carsten Rachuy, Arne Stahlbock, Ubbo Visser, and Tobias Warden. Virtual Werder 3D RoboCup 2007 Team Descrip- tion Paper. In RoboCup 2007 Team Description Papers, 2007.
[65] Nuno Lau and Luis Paulo Reis. FC Portugal 2001 Team Description: Flexible Teamwork and Configurable Strategy. In RoboCup 2001: Robot Soccer World Cup V, volume 2377/2002 of Lecture Notes in Computer Science, pages 1–10. Springer Berlin / Heidelberg, 2002.
[66] Pengcheng Lian, Yanbin Zhuang, Yiqing Song, and Chunguang Li. Czu3d soc- cer simulation team description for robocup2008. In RoboCup 2008 CD, 2008.
[67] Jie Ma and Stephen Cameron. Oxblue2008(3d) team description. In RoboCup 2008 CD, 2008.
[68] Hugo Miguel Gravato Marques. RoboCup 3D Simulator FCPortugal User’s Guide v0.1, August 2004.
[69] Richard M. Murray, Zexiang Li, and S. Shankar Sastry. A Mathematical Introduc- tion to Robotic Manipulation. CRC Press, 2004.
[70] Tomoharu Nakashima, Seiya Fujii, Yukio Shoji, and Yosuke Nakamura. Opu_hana_3d team description paper. In RoboCup 2008 CD, 2008.
[71] Hamid Reza Mohseni Nejad, Roya Hemmat Pour, Mohammad Mazinani, Amir Kharmandar, Hamid Bakhtiyari, Hojjat Nikan, and Hamed Tirdad. Simula- tion of a Humanoid Soccer Robot Team Description Proposal for RobCup2007 Sama3D. In RoboCup 2007 Team Description Papers, 2007.
[72] Isaac Newton. Philosophiæ Naturalis Principia Mathematica. apud Sa. Smith, London, July 1687.
119 BIBLIOGRAPHY BIBLIOGRAPHY
[73] Oliver Obst and Markus Rollmann. SPARK – A Generic Simulator for Physical Multiagent Simulations. Computer Systems Science and Engineering, 20(5):347– 356, September 2005.
[74] João Oliveira. Microsoft Robotics Soccer Challenge: Movement Optimization of a Quadruped Robot. Master’s thesis, Faculdade de Engenharia da Universidade do Porto, March 2008.
[75] Kenji Ozoe and Nobuhiro Ito. Design and implementation of agents’ motion by genetic algorithm naito-horizon. In RoboCup 2008 CD, 2008.
[76] Hugo Picado. Desenvolvimento de comportamentos para robô humanóide sim- ulado. Master’s thesis, Universidade de Aveiro, November 2008.
[77] Hugo Picado and Nuno Almeida. PT2D: Relatório de Inteligência Artificial Dis- tribuída. DETI, Universidade de Aveiro, January 2008.
[78] Roland Priemer. Introductory Signal Processing. World Scientific Publishing Co., 1991.
[79] Lawrence Rabiner and Bernard Gold. Theory and Application of Digital Signal Processing. Prentice Hall, Englewood Cliffs, 1975.
[80] Luis Paulo Reis and Nuno Lau. FC Portugal Team Description: RoboCup 2000 Simulation League Champion. In RoboCup 2000: Robot Soccer World Cup IV, volume 2019/2001 of Lecture Notes in Computer Science, pages 29–40. Springer Berlin / Heidelberg, 2001.
[81] Luis Paulo Reis and Nuno Lau. Coordination Methodologies Developed for FC Portugal 3D Team. In RoboCup 2007 Team Description Papers, 2007.
[82] Luis Paulo Reis, Nuno Lau, and Eugénio Costa Oliveira. Situation Based Strate- gic Positioning for Coordinating a Team of Homogeneous Agents. In Markus Hannebauer, Jan Wendler, and Enrico Pagello, editors, Balancing Reactivity and Social Deliberation in Multi-Agent Systems, Lecture Notes in Computer Science, pages 175–197. Springer Berlin / Heidelberg, 2001.
[83] Luis Paulo Reis, Nuno Lau, Hugo Picado, and Nuno Almeida. FCPortugal: Simulated Humanoid Robot Team Description Proposal for RoboCup 2008. In RoboCup 2008 CD, 2008.
[84] Luis Paulo Reis, Nuno Lau, Hugo Picado, and Nuno Almeida. Paper Contribu- tions, Results and Work for the Simulation Community of FC Portugal, March 2008.
[85] Yoichi Setoguchi and Nobuhiro Ito. The World Model for Autonomous Soccer Agents NAITO-StrikerS. In RoboCup 2007 Team Description Papers, 2007.
120 BIBLIOGRAPHY BIBLIOGRAPHY
[86] B. A. Shenoi. Introduction to Digital Signal Processing and Filter Design. Wiley- IEEE, 2005.
[87] Jörg Stückler and Sven Behnke. Soccer behaviors for humanoid robots. In IEEE- Ras International Conference on Humanoid Robots, Humanoid Soccer Robots, pages 62–70, 2006.
[88] Ali Tavasoli, Roya Hematpour, Hojjat Nikan Meghrazeh, Amir Khermandar, and Seyed Ahmad Adeli. Simulation of a humanoid soccer robot team descrip- tion proposal for robocup 2008 sama3d. In RoboCup 2008 CD, 2008.
[89] Deepak Tolani, Ambarish Goswami, and Norman I. Badler. Real-Time Inverse Kinematics Techniques for Anthropomorphic Limbs. Computer and Information Science Department, University of Pennsylvania, 2000.
[90] Takeshi Uchitane, Youichi Akabane, Nobuhiko Kondo, and Toshiharu Hatanaka. Nomofc team description paper for robocup 2008. In RoboCup 2008 CD, 2008.
[91] Sander van Dijk, Martin Klomp, Jeroen Kuijpers, A. Bram Neijt, Matthijs Platje, Mart van de Sanden, Marijn Stollenga, Alle Veenstra, Fons Vermeulen, Gauke Veenstra, and Jelle Prins. Little green bats humanoid 3d simulation team de- scription paper. In RoboCup 2008 CD, 2008.
[92] Philipp Vorst. Readylog agents for the robocup 3d soccer simulation league. Master’s thesis, RWTH Aachen, 2006.
[93] Gang Wang, LaiZhihui, CaiHuaxu, and YangZhou. Jmu 3d team description 2008. In RoboCup 2008 CD, 2008.
[94] Junqing Wang, Guoping Luo, Ke Ding, and Zhiyong Zhang. Development ar- chitecture of a humanoid soccer simulation robot: Team description proposal for robocup2008 apollo3d. In RoboCup 2008 CD, 2008.
[95] Xichao Xia and Haonan Ma. DNU_Explorer 3D Team Description 2007. In RoboCup 2007 Team Description Papers, Education Innovation Center, Dalian Na- tionalies University, China, 2007.
[96] Ming Xie. Fundamentals of Robotics - Linking Perception to Action, volume 54 of Machine Perception and Artificial Intelligence. World Scientific Publishing Co., April 2003.
[97] Majid Yasari, Yousof Kanani, Arash Sahebolamri, Vahid Garoosy, Naser Moza- iani, and Majid Sadeghi Alavijeh. Robocup 2008 – soccer simulation league 3d soccer simulation team description iust (iran). In RoboCup 2008 CD, 2008.
121 BIBLIOGRAPHY BIBLIOGRAPHY
[98] Xu Yuan, Shen Hui, Qian Cheng, Chen Si, and Tan Yingzi. Seu-redsun 2008 soccer simulation team description. In RoboCup 2008 CD, 2008.
[99] Xu Yuan and Tan Yingzi. SEU-3D 2007 Soccer Simulation Team Description. In RoboCup 2007 Team Description Papers, 2007.
[100] Ming Zhu, Jiangtao Wu, choaqun Ding, Junwei Hu, and Jianjun Ruan. Strive 3d team description 2008. In RoboCup 2008 CD, 2008.
122 Appendix A
SimSpark Installation
This chapter explains how to install SimSpark on an Ubuntu Linux system1.It should work with slight modifications on other distributions like openSUSE2 and es- pecially Debian3. Also installation in Fedora4 is referred. This appendix is based in [41].
A.1 By source-code
1. Enable additional repositories Depending the distribution version used, might be necessary to enable addi- tional repositories in order to install all required packages. Please refer to system specific documentation for details. In Ubuntu Linux these repositories are called and To enable them it’s necessary to edit the file and update the local package database.
In RPM based distributions may be necessary to enable further download lo- cations or download and install RPM packets manually. There are specialized search engines for RPM packages available like
(a) and (b)
2. Install dependencies
1This guide is adapted from the guide created by the Little Green Bats Team at
2 3 4
123 A.1. BY SOURCE-CODE APPENDIX A. SIMSPARK INSTALLATION
SimSpark builds and depends upon the work of other software projects. GNU autotools are used to configure and build SimSpark. Therefore these packages are required:
(a) autoconf (b) automake (c) libtool
Further required packages are:
(a) Ruby (b) The Open Dynamics Engine (ODE) (c) The boost C++ libraries (d) S-Lang (libslang)
The rendering of SimSpark can be omitted from the build process therefore these packages are optional:
(a) OpenGL (b) FreeGlut (c) SDL (d) Freetype (e) Developer Image Library (DevIL) (f) Tiff library (libtiff)
In order to build the SimSpark documentation a Latex installation is required (e.g. ). If you want to build the rsgedit GUI you need to install . The follow- ing commands download and installed the required packages:
3. Check out the source from the source forge CVS repository The SimSpark source is hosted in a CVS repository at sourceforge.net. In order to build the source first download the current version, this is called in CVS terminology:
124 APPENDIX A. SIMSPARK INSTALLATION A.1. BY SOURCE-CODE
When asked for a password, just press enter.
4. Build and install the soccer server
The automake build tools uses a script that adapts the build process to the system and allows to customize the build. The configure script accepts a number of options that you can add to it’s command line:
(a) lists all available configure options.
(b) builds an optimized version of SimSpark that contains no debug symbols
(c) builds SimSpark without rendering support
(d) defines the path where the will later install the SimSpark executable, plugins and resources into the system. If omitted it defaults to /usr/local
Change in to the top level source directory call the bootstrap script that invokes the autotools, run configure with the custom options, start the build process and install the server into the system.
5. Make sure the linker can find your shared libraries if you changed the install prefix as described above with the option.
Add your install prefix if it isn’t already there, save and close.
6. run the simulation
125 A.2. FEDORA APPENDIX A. SIMSPARK INSTALLATION
A.2 Fedora
In Fedora system it’s in fact very easy to install SimSpark as it is now part of the official repository. The installation is just resumed to execute in a command line as root:
The installation will perform, automatically installing all the libraries needed.
A.3 On other systems
It is also possible to install SimSpark on MacOS X and also Windows (experimen- tal). Details about these procedures can be consulted in .
126 Appendix B
Real robots
The major objective of RoboCup is to make a robot team win against a human team. Since it is impossible for the humans to play in a virtual world, the robotic team has to be composed by real robots, not simulated robots. But to do research on real robots it’s kind of risky. The robots could fall, crash, damage some parts. Usually these robots are very expensive, so it is a good idea to work on a simulated environment (like SimSpark) first and then apply the research on the real world.
Let’s take a quick look on some of the most important and well know and used for research purposes robots.
B.1 Fujitsu HOAP
HOAP1 is a series of humanoid robots made by Fujitsu Automation.
In 2001 Fujitsu releases its first humanoid robot, HOAP-1, standing 48cm tall and weighing 6kg.
1Acronym to “Humanoid for Open Architecture Platform”
127 B.1. FUJITSU HOAP APPENDIX B. REAL ROBOTS
(a) (b)
Figure B.1: Fujitsu HOAP-1
With 20 DoF2 (6 in each leg and 4 in each arm), an accelerometer and a gyrometer on the torso, a force sensor in each foot and a complete open hardware and software architecture, it was a robot very used for research in some areas such as humanoid walking. Later, in 2003, HOAP-2 was released with some internal improvements and en- hanced gesture expression with moving head, waist and hands.
(a) (b)
Figure B.2: Fujitsu HOAP-2
The main advantage of the the HOAP series is its completely open hardware and software architecture, allowing to easily develop programs and behaviors. More details in [4, 6, 7].
2Degrees of Freedom
128 APPENDIX B. REAL ROBOTS B.2. HONDA ASIMO
B.2 Honda ASIMO
ASIMO3 is one of the best known humanoid robots. It is the result of almost 15 years of research by Honda Motor Company4. In 1986 Honda started the E series, revealing the E0 prototype. With only 6 DoF (one in each groin, one in each knee and one in each ankle) it was able to walk in a straight line. It took 5 second to make a single step.
Figure B.3: Honda E0 prototype
In 1987 a second prototype has been released. E1 was able to walk at 2.5 km/h. Since E1, all the released models have 12 DoF on their legs. Through the next few years Honda continues releasing new prototypes with higher maximum speed:
• E2 in 1989, 1.2 km/h
• E3 in 1991, 3 km/h
• E4 in 1991, 4.7 km/h
• E5 in 1992
3Acronym to “Advanced Step in Innovative MObility” 4
129 B.2. HONDA ASIMO APPENDIX B. REAL ROBOTS
(a) E1 (b) E2 (c) E3 (d) E4 (e) E5
Figure B.4: Honda E1 to E5 prototypes
In 1993 it was revealed the E6 model. This prototype was able to autonomously control the balance, up and down stairs and walk over obstacles. This model was a major update since from now on, these robots were able to walk on sloping surfaces.
Figure B.5: Honda E6 prototype
After E6, a human-like body was attached (E0 to E6 were only legs) and the series was renamed to P series. P1, released in 1993 with 1915 mm of height and 175 kg of weight was able to turn switches on and off, grab doorknobs and pick up and carry things. Some research was made to coordinate arm and leg movements.
130 APPENDIX B. REAL ROBOTS B.2. HONDA ASIMO
Figure B.6: Honda P1 prototype
In December 1996 P2 stunned the world with its abilities. This robot was com- pletely autonomous, using batteries, a computer contained in its torso and wireless technologies to walk, go up and down stairs, and other humanoid actions. In Septem- ber 1997 P3 was revealed, being a smaller P2 built with different materials better suited for use in the human environment.
Figure B.7: Honda P2 and P3 prototypes
In 2000 ASIMO was released. With a height of 120 cm and 52 kg it has the indicated size to be present in the human environment. Able to walk at 1.6 km/h maximum and recognize moving objects, postures, gestures and environment and face and voice recognition, it is a full-featured humanoid robot.
131 B.3. ROBOSAPIEN APPENDIX B. REAL ROBOTS
Figure B.8: Honda ASIMO
In 2005 a new version of ASIMO was released. This new version is able not only to walk at 2.7 km/h, but also to run at the impressive value of 6 km/h.
There are no ASIMOs to sell, although exist 46 units and some can be hired out.
More details in [5].
B.3 RoboSapien
RoboSapien is a robotic toy made by WowWee5. Very cheap (around €100) it has very powerful features for its price. It has been used for research due its price and some teams have also used some modified RoboSapiens robots to participate in RoboCup [34].
5
132 APPENDIX B. REAL ROBOTS B.3. ROBOSAPIEN
(a) First version (b) Second version
Figure B.9: RoboSapien
RoboSapien uses 4 “D”-size batteries to work and has microphone, speaker, cam- era and all the other “normal” features the humanoid robots have. Although its price, it has very interesting performances. By default it has some behaviors, like pick-up, throw, kick, dance, kung-fu, fart, belch, rap and more.
One of the features that made it very popular in robotics and IA research is its possibility to be programed. It’s very easy to modify it and program it.
A second version of RoboSapien has been released with some changes, like visual improvements and faster movements.
Figure B.10: NimbRo robots. Origin: [22]
Although sold as a toy, RoboSapien is a very powerful a cheap robot, used by some teams to do experiments and even to compete.
133 B.4. SONY AIBO APPENDIX B. REAL ROBOTS
B.4 Sony AIBO
One robot that can not be dismissed is Sony AIBO6. Although not a humanoid robot, this robot made by Sony7 has been used for several years in RoboCup and other simulated soccer competitions. Definitely AIBO is a case of success. Project of AIBO started in April 1994. One prototype has been showed in March 1997. This robot was able to express some emotions like joy, sadness, surprise and others. It also simulated several ages (childhood, youth, adult, ...) and his behavior changed according to the age. It was able to learn by modifying the probabilities of its actions (reinforcement learning). On June 1999 it has been released to the market. In just 20 minutes 3000 units have be sold to the Japanese market through the internet. The AIBO family has evolved and other models have been announced:
• June 1999: 110 Series
• July 2001: 210 Series
• December 2001: 220 Series
• April 2002: 310 Series
• September 2004: 7 Series
Able to walk, “see” its environment via camera and recognize spoken commands, they it is to be proper AI autonomous robot, since it is able to learn and mature based on external stimuli from their owner or environment, or from other AIBOs. It has very interesting and useful features, like wireless communication, cameras to “see” the world, face and voice recognition, being highly programmable and others.
Figure B.11: Sony AIBO playing soccer at RoboCup
Other advantages of this robot are that it has been commercially very successful, so it has a lot of communities around the globe. His low price (compared with other robots with the same features) also helped a lot.
6AIBO is an acronym to “Artificial Intelligence roBOt”. In Japanese, AIBO also means “pal” or “part- ner”. 7
134 APPENDIX B. REAL ROBOTS B.5. SONY QRIO
Sony AIBO has been discontinued since March 2006 [23] and Sony has focused his attention on his humanoid robot QRIO. Several informations about this robot can be consulted in [24].
B.5 Sony QRIO
QRIO8 is a humanoid robot made by Sony9. Considered the natural evolution of AIBO, QRIO inheritances several features from its older doggy pal.
Figure B.12: Sony QRIO. Origin: [25]
It has about 7.3 kg of weight and 60 cm of height. It inheritances the CCD color camera, the microphone, the speaker and other use- ful stuff from AIBO. It also adds an inclination sensor and force sensor on his feet. It has some abilities related to humanoid walk issues:
• Real-time balancing/walking
• Avoids falling down by using the inclination sensor
• Ability to walk and climb stairs
It also has some interaction technologies like:
• Face and voice detection, recognition and learning
• Continuous speech recognition with unknown words acquisition
• Speech synthesis with emotion
8Acronym to “Quest for cuRIOsity” 9
135 B.6. ALDEBARAN NAO APPENDIX B. REAL ROBOTS
• Ability to maintain dialogs
• Motion detection
• Sound source direction estimation
• Simultaneous localization and map building + real-time path planning
• Imitation skills
QRIO has some very interesting features but is never has been sold.
B.6 Aldebaran NAO
NAO is a humanoid robot made by Aldebaran Robotics10. The main purpose of the company when building this robot was to make a cheap pleasant robot without sacrificing performance. With 57 cm and 4.5 kg, NAO is classified by Aldebaran as a small child. Its velocity on walking is also similar to a child: 0.6 km/h.
Figure B.13: NAO. Origin: [1]
Able to recognize human faces, self-localize and to interact with the environment, NAO is highly modular, being easy to change its arm, legs or head by another one with different characteristics. Although its low price compared with the majority of other humanoid robots, all the major features are present: color videocamera, gyrometers and accelerometers, force sensors, infrared emitter and receiver, ultrasonic sensors, speakers and several microphones. Being easily programmable is another advantage of this robot. It has been chosen to be the official RoboCup humanoid robot, used in Standard Platform League (and its models in some simulation leagues).
10
136 APPENDIX B. REAL ROBOTSB.7. NON-COMMERCIAL (ROBOCUP PARTICIPANTS)
B.7 Non-commercial (RoboCup participants)
There are also real robots created by research teams just to participate in the RoboCup.
Figure B.14: Darmstadt Dribblers robot
These robots are made with the purpose of participating in RoboCup Humanoid League (see 2.1.4).
137 Appendix C
Homogeneous coordinates systems and Denavit-Hartenberg method
Some common operations applied to a point are translation, scaling, rotation and projection. Homogeneous coordinates systems are based on transformation matrices and mul- tiplying them. Using homogeneous coordinates every one of the previous operations is a transformation matrix. Several operations can be represented by multiplying ma- trices. Usually, in 3D, a point p = (x, y, z) is represented: ⎡ ⎤ x ⎢ ⎥ p = ⎣ y ⎦ z
Using homogeneous coordinates this p is: ⎡ ⎤ ⎧ xw ⎢ ⎥ ⎨⎪ x = xw ⎢ y ⎥ w = ⎢ w ⎥ = yw p ⎢ ⎥ where ⎪ y w ⎣ zw ⎦ ⎩ z = zw w w
As w can be any finite value but 0, it is usual to assume w = 1, so: ⎡ ⎤ ⎢ x ⎥ ⎢ ⎥ ⎢ y ⎥ p = ⎢ ⎥ ⎣ z ⎦ 1
There are transformation matrices that represent the major operations applied to a point. These matrices have also one more dimension than the space where the point is represented. In our case, there are two of the operations that are useful:
138 APPENDIX C. HOMOGENEOUS COORDINATES SYSTEMS AND DENAVIT-HARTENBERG METHOD
• Translations
⎡ ⎤ 100Δx ⎢ ⎥ ⎢ 010Δy ⎥ ⎣ ⎦ 001Δz 000 1 Translation of (Δx, Δy, Δz)
• Rotations
⎡ ⎤ cos (θ) − sin (θ) 00 ⎢ ⎥ ⎢ sin (θ) cos (θ) 00⎥ ⎣ ⎦ 0010 0001 Rotation of θ around z axis in counter-clockwise direction
Using these elementary operations it’s possible to build a kinematic chain1 that repre- sent the robots. For example, it is possible to represent a translation of (6, 4, 8) to a point p followed by a rotation of 60º around z axis, it is as simple as: ⎡ ⎤ ⎡ ⎤ ( ) − ( ) ⎢ cos 60º sin 60º 00⎥ ⎢ 1006⎥ ⎢ ⎥ ⎢ ⎥ ⎢ sin (60º) cos (60º) 00⎥ ⎢ 0104⎥ ⎢ ⎥ × ⎢ ⎥ × p ⎣ 0010⎦ ⎣ 0018⎦ 00010001
These two operations can be represented as one: ⎡ ⎤ ( ) − ( ) × ( ) − × ( ) ⎢ cos 60º sin 60º 06 cos 60º 4 sin 60º ⎥ ⎢ ⎥ ⎢ sin (60º) cos (60º) 06× sin (60º) + 4 × cos (60º) ⎥ ⎢ ⎥ × p ⎣ 001 8 ⎦ 000 1
So, no matter how many operations to be applied, there is always a matrix that represents all the operations. Let’s see an example of the application of Denavit-Hartenberg representation in 2D:
1Series of multiplying transformation matrices
139 APPENDIX C. HOMOGENEOUS COORDINATES SYSTEMS AND DENAVIT-HARTENBERG METHOD
⎡ ⎤ ⎡ ⎤ x 0 ⎣ ⎦ ⎣ ⎦ y = 0 1 1
Figure C.1: Denavit-Hartenberg representation, step 1
⎡ ⎤ ⎡ ⎤ ⎡ ⎤ x 10r2 0 ⎣ ⎦ ⎣ ⎦ ⎣ ⎦ y = 01 0 × 0 1 00 1 1
Figure C.2: Denavit-Hartenberg representation, step 2
⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ θ − θ x cos ( 2) sin ( 2) 0 10r2 0 ⎣ ⎦ = ⎣ θ θ ⎦ × ⎣ ⎦ × ⎣ ⎦ y sin ( 2) cos ( 2) 0 01 0 0 1 00100 1 1
Figure C.3: Denavit-Hartenberg representation, step 3
140 APPENDIX C. HOMOGENEOUS COORDINATES SYSTEMS AND DENAVIT-HARTENBERG METHOD
⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ (θ ) − (θ ) x 10r1 cos 2 sin 2 0 10r2 0 ⎣ ⎦ = ⎣ ⎦ × ⎣ θ θ ⎦ × ⎣ ⎦ × ⎣ ⎦ y 01 0 sin ( 2) cos ( 2) 0 01 0 0 1 00 1 00100 1 1
Figure C.4: Denavit-Hartenberg representation, step 4
⎡ ⎤ ⎡ ⎤ ⎡ ⎤ (θ ) − (θ ) x cos 1 sin 1 0 10r1 ⎣ ⎦ = ⎣ (θ ) (θ ) ⎦ × ⎣ ⎦ × y sin 1 cos 1 0 01 0 1 ⎡ 001⎤ ⎡ 00 1⎤ ⎡ ⎤ θ − θ cos ( 2) sin ( 2) 0 10r2 0 × ⎣ θ θ ⎦ × ⎣ ⎦ × ⎣ ⎦ sin ( 2) cos ( 2) 0 01 0 0 00100 1 1
Figure C.5: Denavit-Hartenberg representation, step 5
θ Generically, for a kinematic chain of n links and being i the angle of link i, the transformation between link m and link n is:
n m = i−1 (θ ) Tn ∏ Ti i (C.1) i=m+1 i−1 (θ ) − Where Ti i is the transformation matrix between link i 1 and i.
141 Appendix D
Forward Kinematics
D.1 Transformation matrices relative to previous joint
Following the robot model configuration in section 3.5.2, we get the transformation matrices for all the joints.
• Neck Relative to torso:
£ Translation of (0, 0, 0.09) £ Rotation of NeckAngle around z
Resulting: ⎡ ⎤ ⎡ ⎤ ( ) − ( ) ⎢ 100 0 ⎥ ⎢ cos NeckAngle sin NeckAngle 00⎥ ⎢ ⎥ ⎢ ⎥ ⎢ 010 0 ⎥ ⎢ sin (NeckAngle) cos (NeckAngle) 00⎥ ⎢ ⎥ × ⎢ ⎥ = ⎣ 0 0 1 0.09 ⎦ ⎣ 0010⎦ 000 1 0001 ⎡ ⎤ ( ) − ( ) ⎢ cos NeckAngle sin NeckAngle 00⎥ ⎢ ⎥ ⎢ sin (NeckAngle) cos (NeckAngle) 00⎥ = ⎢ ⎥ ⎣ 0 0 1 0.09 ⎦ 0001 (D.1)
• Head Relative to neck (D.1):
£ Translation of (0, 0, 0.06) £ Rotation of HeadAngle around x
Resulting:
142 APPENDIXD.1. D. FORWARD TRANSFORMATION KINEMATICS MATRICES RELATIVE TO PREVIOUS JOINT
⎡ ⎤ ⎢ 10 0 0⎥ ⎢ ⎥ ⎢ 0 cos (HeadAngle) − sin (HeadAngle) 0 ⎥ ⎢RightShoulderAngle ⎥ ⎣ 0 sin (HeadAngle) cos (HeadAngle) 0.06 ⎦ 00 0 1 (D.2)
• Right Shoulder Relative to torso:
£ Translation of (0.098, 0, 0.075) £ Rotation of RightShoulderAngle around x
Resulting: ⎡ ⎤ ⎢ 1 0 0 0.098 ⎥ ⎢ ⎥ ⎢ 0 cos (RightShoulderAngle) − sin (RightShoulderAngle) 0 ⎥ ⎢ ⎥ (D.3) ⎣ 0 sin (RightShoulderAngle) cos (RightShoulderAngle) 0.075 ⎦ 00 0 1
• Left Shoulder Relative to torso:
£ Translation of (−0.098, 0, 0.075) £ Rotation of Lef tShoulderAngle around x
Resulting: ⎡ ⎤ − ⎢ 10 0 0.098 ⎥ ⎢ ⎥ ⎢ 0 cos (Lef tShoulderAngle) − sin (Lef tShoulderAngle) 0 ⎥ ⎢ ⎥ (D.4) ⎣ 0 sin (Lef tShoulderAngle) cos (Lef tShoulderAngle) 0.075 ⎦ 00 0 1
• Right Upper Arm Relative to right shoulder (D.3):
£ Rotation of RightUpperArmAngle around z
Resulting: ⎡ ⎤ ( ) − ( ) ⎢ cos RightUpperArmAngle sin RightUpperArmAngle 00⎥ ⎢ ⎥ ⎢ sin (RightUpperArmAngle) cos (RightUpperArmAngle) 00⎥ ⎢ ⎥ (D.5) ⎣ 0010⎦ 0001
143 D.1. TRANSFORMATION MATRICES RELATIVEAPPENDIX TO PREVIOUS D. FORWARD JOINT KINEMATICS
• Left Upper Arm
Relative to left shoulder (D.4):
£ Rotation of Le f tUpperArmAngle around z
Resulting: ⎡ ⎤ ( ) − ( ) ⎢ cos Le f tUpperArmAngle sin Le f tUpperArmAngle 00⎥ ⎢ ⎥ ⎢ sin (Le f tUpperArmAngle) cos (Le f tUpperArmAngle) 00⎥ ⎢ ⎥ (D.6) ⎣ 0010⎦ 0001
• Right Elbow
Relative to right upper arm (D.5):
£ Translation of (0, 0.09, 0.009) £ Rotation of RightElbowAngle around y
Resulting: ⎡ ⎤ ( ) − ( ) ⎢ cos RightElbowAngle 0 sin RightElbowAngle 0 ⎥ ⎢ ⎥ ⎢ 0 1 0 0.09 ⎥ ⎢ ⎥ (D.7) ⎣ sin (RightElbowAngle) 0 cos (RightElbowAngle) 0.009 ⎦ 00 0 1
• Left Elbow
Relative to left upper arm (D.6):
£ Translation of (0, 0.09, 0.009) £ Rotation of Le f tElbowAngle around y
Resulting: ⎡ ⎤ ( ) − ( ) ⎢ cos Le f tElbowAngle 0 sin Le f tElbowAngle 0 ⎥ ⎢ ⎥ ⎢ 0 1 0 0.09 ⎥ ⎢ ⎥ (D.8) ⎣ sin (Le f tElbowAngle) 0 cos (Le f tElbowAngle) 0.009 ⎦ 00 0 1
• Right Lower Arm
Relative to right elbow (D.7):
£ Rotation of RightLowerArmAngle around z
144 APPENDIXD.1. D. FORWARD TRANSFORMATION KINEMATICS MATRICES RELATIVE TO PREVIOUS JOINT
Resulting: ⎡ ⎤ ( ) − ( ) ⎢ cos RightLowerArmAngle sin RightLowerArmAngle 00⎥ ⎢ ⎥ ⎢ sin (RightLowerArmAngle) cos (RightLowerArmAngle) 00⎥ ⎢ ⎥ (D.9) ⎣ 0010⎦ 0001
• Left Lower Arm Relative to left elbow (D.8):
£ Rotation of Le f tLowerArmAngle around z
Resulting: ⎡ ⎤ ( ) − ( ) ⎢ cos Le f tLowerArmAngle sin Le f tLowerArmAngle 00⎥ ⎢ ⎥ ⎢ sin (Le f tLowerArmAngle) cos (Le f tLowerArmAngle) 00⎥ ⎢ ⎥ (D.10) ⎣ 0010⎦ 0001
• Right Hip 1 Relative to torso:
£ Translation of (0.05, 0, −0.115) £ Rotation of RightHip1Angle around special axis1
Resulting: ⎡ ⎤ ⎡ ⎤ (− ) − (− ) ⎢ 1 0 0 0.05 ⎥ ⎢ cos 45º 0 sin 45º 0 ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ 010 0 ⎥ ⎢ 01 0 0⎥ ⎢ ⎥ × ⎢ ⎥ × ⎣ 001−0.115 ⎦ ⎣ sin (−45º) 0 cos (−45º) 0 ⎦ 000 1 00 0 1 ⎡ ⎤ ⎡ ⎤ ( ) − ( ) ⎢ 10 0 0⎥ ⎢ cos 45º 0 sin 45º 0 ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ 0 cos (α) − sin (α) 0 ⎥ ⎢ 01 0 0⎥ × ⎢ ⎥ × ⎢ ⎥ = ⎣ 0 sin (α) cos (α) 0 ⎦ ⎣ sin (45º) 0 cos (45º) 0 ⎦ 00 0 1 00 0 1 ⎡ √ ⎤ 1 + 1 cos (α) 2 sin (α) − 1 + 1 cos (α) 0.05 ⎢ 2 √ 2 2 2 √ 2 ⎥ ⎢ 2 2 ⎥ ⎢ − sin (α) cos (α) − sin (α) 0 ⎥ = ⎢ 2 √ 2 ⎥ with α = RightHip1Angle ⎣ − 1 + 1 (α) 2 (α) 1 + 1 (α) − ⎦ 2 2 cos 2 sin 2 2 cos 0.115 0001 (D.11)
1As seen in Figure 3.12 on page 25, right and left Hip1 rotate around a special axis that is not one of the three basis generators
145 D.1. TRANSFORMATION MATRICES RELATIVEAPPENDIX TO PREVIOUS D. FORWARD JOINT KINEMATICS
Note: we are considering the special axis coincident with x axis, rotating it (around y) to its special position, applying the rotation of RightHip1Angle and rotating the axis back to its initial position.
• Left Hip 1 Relative to torso:
£ Translation of (−0.05, 0, −0.115) £ Rotation of Le f tHip1Angle around special axis
Resulting: ⎡ ⎤ ⎡ ⎤ ( ) − ( ) ⎢ 1 0 0 0.05 ⎥ ⎢ cos 45º 0 sin 45º 0 ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ 010 0 ⎥ ⎢ 01 0 0⎥ ⎢ ⎥ × ⎢ ⎥ × ⎣ 001−0.115 ⎦ ⎣ sin (45º) 0 cos (45º) 0 ⎦ 000 1 00 0 1 ⎡ ⎤ ⎡ ⎤ (− ) − (− ) ⎢ 10 0 0⎥ ⎢ cos 45º 0 sin 45º 0 ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ 0 cos (α) − sin (α) 0 ⎥ ⎢ 01 0 0⎥ × ⎢ ⎥ × ⎢ ⎥ = ⎣ 0 sin (α) cos (α) 0 ⎦ ⎣ sin (−45º) 0 cos (−45º) 0 ⎦ 00 0 1 00 0 1 ⎡ √ ⎤ 1 + 1 cos (α) − 2 sin (α) 1 + 1 cos (α) −0.05 ⎢ 2 √ 2 2 2 √ 2 ⎥ ⎢ 2 2 ⎥ ⎢ sin (α) cos (α) − sin (α) 0 ⎥ = ⎢ 2 √ 2 ⎥ with α = Le f tHip1Angle ⎣ 1 + 1 (α) 2 (α) 1 + 1 (α) − ⎦ 2 2 cos 2 sin 2 2 cos 0.115 0001 (D.12)
• Right Hip 2 Relative to right hip 1 (D.11):
£ Rotation of RightHip2Angle around y
Resulting: ⎡ ⎤ ( ) − ( ) ⎢ cos RightHip2Angle 0 sin RightHip2Angle 0 ⎥ ⎢ ⎥ ⎢ 01 0 0⎥ ⎢ ⎥ (D.13) ⎣ sin (RightHip2Angle) 0 cos (RightHip2Angle) 0 ⎦ 00 0 1
• Left Hip 2 Relative to left hip 1 (D.12):
£ Rotation of Le f tHip2Angle around y
146 APPENDIXD.1. D. FORWARD TRANSFORMATION KINEMATICS MATRICES RELATIVE TO PREVIOUS JOINT
Resulting: ⎡ ⎤ ( ) − ( ) ⎢ cos Le f tHip2Angle 0 sin Le f tHip2Angle 0 ⎥ ⎢ ⎥ ⎢ 01 0 0⎥ ⎢ ⎥ (D.14) ⎣ sin (Le f tHip2Angle) 0 cos (Le f tHip2Angle) 0 ⎦ 00 0 1
• Right Thigh Relative to right hip 2 (D.14):
£ Rotation of RightThighAngle around x
Resulting: ⎡ ⎤ ⎢ 10 0 0⎥ ⎢ ⎥ ⎢ 0 cos (RightThighAngle) − sin (RightThighAngle) 0 ⎥ ⎢ ⎥ (D.15) ⎣ 0 sin (RightThighAngle) cos (RightThighAngle) 0 ⎦ 00 0 1
• Left Thigh Relative to left hip 2 (D.14):
£ Rotation of LeftThighAngle around x
Resulting: ⎡ ⎤ ⎢ 10 0 0⎥ ⎢ ⎥ ⎢ 0 cos (LeftThighAngle) − sin (LeftThighAngle) 0 ⎥ ⎢ ⎥ (D.16) ⎣ 0 sin (LeftThighAngle) cos (LeftThighAngle) 0 ⎦ 00 0 1
• Right Shank Relative to right thigh (D.15):
£ Translation of (0, 0.005, −0.12) £ Rotation of RightShankAngle around x
Resulting: ⎡ ⎤ ⎢ 10 0 0⎥ ⎢ ⎥ ⎢ 0 cos (RightShankAngle) − sin (RightShankAngle) 0.005 ⎥ ⎢ ⎥ (D.17) ⎣ 0 sin (RightShankAngle) cos (RightShankAngle) −0.12 ⎦ 00 0 1
147 D.1. TRANSFORMATION MATRICES RELATIVEAPPENDIX TO PREVIOUS D. FORWARD JOINT KINEMATICS
• Left Shank Relative to left thigh (D.16):
£ Translation of (0, 0.005, −0.12) £ Rotation of Lef tShankAngle around x
Resulting: ⎡ ⎤ ⎢ 10 0 0⎥ ⎢ ⎥ ⎢ 0 cos (Lef tShankAngle) − sin (Lef tShankAngle) 0.005 ⎥ ⎢ ⎥ (D.18) ⎣ 0 sin (Lef tShankAngle) cos (Lef tShankAngle) −0.12 ⎦ 00 0 1
• Right Ankle Relative to right shank (D.17):
£ Translation of (0, 0, −0.1) £ Rotation of RightAnkleAngle around x
Resulting: ⎡ ⎤ ⎢ 10 0 0⎥ ⎢ ⎥ ⎢ 0 cos (RightAnkleAngle) − sin (RightAnkleAngle) 0 ⎥ ⎢ ⎥ (D.19) ⎣ 0 sin (RightAnkleAngle) cos (RightAnkleAngle) −0.1 ⎦ 00 0 1
• Left Ankle Relative to left shank (D.18):
£ Translation of (0, 0, −0.1) £ Rotation of Lef tAnkleAngle around x
Resulting: ⎡ ⎤ ⎢ 10 0 0⎥ ⎢ ⎥ ⎢ 0 cos (Lef tAnkleAngle) − sin (Lef tAnkleAngle) 0 ⎥ ⎢ ⎥ (D.20) ⎣ 0 sin (Lef tAnkleAngle) cos (Lef tAnkleAngle) −0.1 ⎦ 00 0 1
• Right Foot Relative to right ankle (D.19):
£ Rotation of RightFootAngle around y
148 APPENDIX D. FORWARDD.2. TRANSFORMATION KINEMATICS MATRICES RELATIVE TO THE VISION
Resulting: ⎡ ⎤ ( ) − ( ) ⎢ cos RightFootAngle 0 sin RightFootAngle 0 ⎥ ⎢ ⎥ ⎢ 01 0 0⎥ ⎢ ⎥ (D.21) ⎣ sin (RightFootAngle) 0 cos (RightFootAngle) 0 ⎦ 0001
• Left Foot
Relative to left ankle (D.20):
£ Rotation of LeftFootAngle around y
Resulting: ⎡ ⎤ ( ) − ( ) ⎢ cos LeftFootAngle 0 sin LeftFootAngle 0 ⎥ ⎢ ⎥ ⎢ 01 0 0⎥ ⎢ ⎥ (D.22) ⎣ sin (LeftFootAngle) 0 cos (LeftFootAngle) 0 ⎦ 00 0 1
D.2 Transformation matrices relative to the vision
• Neck ⎡ ⎤ Transformation matrix ⎢ ⎥ ⎣ Vision → Neck ⎦ (D.23) (D.1)
• Head ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Neck ⎦ × ⎣ Neck → Head ⎦ (D.24) (D.23) (D.2)
• Right Shoulder ⎡ ⎤ Transformation matrix ⎢ ⎥ ⎣ Vision → Right Shoulder ⎦ (D.25) (D.3)
• Left Shoulder ⎡ ⎤ Transformation matrix ⎢ ⎥ ⎣ Vision → Left Shoulder ⎦ (D.26) (D.4)
149 D.2. TRANSFORMATION MATRICES RELATIVEAPPENDIX TO THE D. FORWARD VISION KINEMATICS
• Right Upper Arm ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Right Shoulder ⎦ × ⎣ Right Shoulder → Right Upper Arm ⎦ (D.25) (D.5) (D.27)
• Left Upper Arm ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Left Shoulder ⎦ × ⎣ Left Shoulder → Left Upper Arm ⎦ (D.28) (D.26) (D.6)
• Right Elbow ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Right Upper Arm ⎦ × ⎣ Right Upper Arm → Right Elbow ⎦ (D.27) (D.7) (D.29)
• Left Elbow ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Left Upper Arm ⎦ × ⎣ Left Upper Arm → Left Elbow ⎦ (D.30) (D.28) (D.8)
• Right Lower Arm ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Right Elbow ⎦ × ⎣ Right Elbow → Right Lower Arm ⎦ (D.31) (D.29) (D.9)
• Left Lower Arm ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Left Elbow ⎦ × ⎣ Left Elbow → Left Lower Arm ⎦ (D.32) (D.30) (D.10)
• Right Hip 1 ⎡ ⎤ Transformation matrix ⎢ ⎥ ⎣ Vision → Right Hip 1 ⎦ (D.33) (D.11)
150 APPENDIX D. FORWARDD.2. TRANSFORMATION KINEMATICS MATRICES RELATIVE TO THE VISION
• Left Hip 1 ⎡ ⎤ Transformation matrix ⎢ ⎥ ⎣ Vision → Left Hip 1 ⎦ (D.34) (D.12)
• Right Hip 2 ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Right Hip 1 ⎦ × ⎣ Right Hip 1 → Right Hip 2 ⎦ (D.35) (D.33) (D.13)
• Left Hip 2 ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Left Hip 1 ⎦ × ⎣ Left Hip 1 → Left Hip 2 ⎦ (D.36) (D.34) (D.14)
• Right Thigh ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Right Hip 2 ⎦ × ⎣ Right Hip 2 → Right Thigh ⎦ (D.37) (D.35) (D.15)
• Left Thigh ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Left Hip 2 ⎦ × ⎣ Left Hip 2 → Left Thigh ⎦ (D.38) (D.36) (D.16)
• Right Shank ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Right Thigh ⎦ × ⎣ Right Thigh → Right Shank ⎦ (D.39) (D.37) (D.17)
• Left Shank ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Left Thigh ⎦ × ⎣ Left Thigh → Left Shank ⎦ (D.40) (D.38) (D.18)
151 D.2. TRANSFORMATION MATRICES RELATIVEAPPENDIX TO THE D. FORWARD VISION KINEMATICS
• Right Ankle ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Right Shank ⎦ × ⎣ Right Shank → Right Ankle ⎦ (D.41) (D.39) (D.19)
• Left Ankle ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Left Shank ⎦ × ⎣ Left Shank → Left Ankle ⎦ (D.42) (D.40) (D.20)
• Right Foot ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Right Ankle ⎦ × ⎣ Right Ankle → Right Foot ⎦ (D.43) (D.41) (D.21)
• Left Foot ⎡ ⎤ ⎡ ⎤ Transformation matrix Transformation matrix ⎢ ⎥ ⎢ ⎥ ⎣ Vision → Left Ankle ⎦ × ⎣ Left Ankle → Left Foot ⎦ (D.44) (D.42) (D.22)
152 Appendix E
Some derivative concepts
E.1 Derivative of a scalar function
If we have a scalar function f with only one variable x, we can write it as f (x).
df The derivative of f in order to x is . dx
The derivative is defined as:
df Δ f f (x + Δx) − f (x) = lim = lim dx Δx→0 Δx Δx→0 Δx
Figure E.1: Derivative of a function. Origin: [36]
153 E.2. DERIVATIVE OF A VECTORIALAPPENDIX FUNCTION E. SOME DERIVATIVE CONCEPTS
For example: f (x) = x2
df f (x + Δx) − f (x) = lim dx Δx→0 Δx (x + Δx)2 − (x)2 = lim Δx→0 Δx x2 + 2xΔx + (Δx)2 − x2 = lim Δx→0 Δx 2xΔx + (Δx)2 = lim Δx→0 Δx = lim 2x + Δx Δx→0 = 2x
E.2 Derivative of a vectorial function
If a vectorial function r represents the location of a particle through time: = r rx ry rz
dr = drx dry drz dt dt dt dt
E.3 Gradient
The gradient of a function is the vector with the first order derivatives in order to all its variables. df df df ∇ f (x, y, z) = i + j + k dx dy dz
It gives information of how the function changes in relation to all its variables independently.
154 APPENDIX E. SOME DERIVATIVE CONCEPTS E.4. JACOBIAN
Figure E.2: Gradient of a function. Origin: [36]
E.4 Jacobian
Jacobian is the derivative of a vector in order to another vector. If we have a vector x and a function f (x), the jacobian is the matrix of all the partial derivatives for every component of the vectors. df Usually the jacobian is written J ( f , x) but conceptually it is . dx ⎡ ⎤ ∂ ∂ ∂ f1 f1 f1 ⎢ ∂ ∂ ... ∂ ⎥ ⎢ x1 x2 xn ⎥ ⎢ ∂ ∂ ⎥ ⎢ f2 f2 ··· . ⎥ df ⎢ ∂ ∂ . ⎥ J ( f , x) = = ⎢ x1 x2 ⎥ dx ⎢ . . . . ⎥ ⎢ . . .. . ⎥ ⎣ ∂ ∂ ⎦ fm ··· ··· fm ∂ ∂ x1 xn
E.5 Approximated derivative
Many algorithms require the value of a derivative to be calculated. In some simple cases it can calculated analytically, like:
df f (x) = x2 = 2x dx
155 E.5. APPROXIMATED DERIVATIVEAPPENDIX E. SOME DERIVATIVE CONCEPTS
In cases where the derivative is much more complex it is almost impossible to calculate its value. But if we can compute the function the value of its derivative can be approximated.
df f (x + Δx) − f (x) ≈ for small values of Δx (E.1) dx Δx
Figure E.3: Approximated value of the derivative. Origin: [36]
Then we can calculated the approximated values of f for points near x.
Δ f df df ≈ ⇔ Δ f ≈ Δx Δx dx dx ⇔ Δ f ≈ J ( f , x) · Δx
156