=Paper=
{{Paper
|id=Vol-2312/CRoNe2018_article_3
|storemode=property
|title=AIS: Artificial Intelligent Soccer
|pdfUrl=https://ceur-ws.org/Vol-2312/CRoNe2018_article_3.pdf
|volume=Vol-2312
|authors=Maximiliano Aubel,Ricardo Alfaro,Pablo Yañez,Pablo Reyes,Tomás Rodenas,Nicolás Hernández,Felipe Pinto,Sung Hee Kim,Tania Barrera,Daniel Torres,Ignacio Vicencio,Jorge Alvarez,Felipe Osorio,Sebastián Castillo
}}
==AIS: Artificial Intelligent Soccer==
https://ceur-ws.org/Vol-2312/CRoNe2018_article_3.pdf
Proceedings of the 4th Congress on Robotics and Neuroscience
1 AIS: Artificial Intelligent Soccer
2 Ricardo Alfaro1* , Maximiliano Aubel1* , Pablo Yañez1* , Pablo Reyes1 , Tomás
3 Rodenas1 , Nicolás Hernandez1 , Felipe Pinto1 , Sung Hee Kim1 , Tania Barrera1 ,
4 Daniel Torres1 , Ignacio Vicencio1 , Jorge Alvarez1 , Felipe Osorio1 , Sebastian
5 Castillo1
*For correspondence:
ricardo.alfaro.13@sansano.usm.cl; 1 Innovación y Robótica Estudiantil, Universidad Técnica Federico Santa María
6
maximiliano.aubel@sansano.usm.
cl; pablo.yanez.12@sansano.usm.cl
7
8 Abstract This paper describes the current development status of our SSL team, AIS. Throughout
9 this document, we present the design and implementation we have got so far, showing the
10 electrical, mechanical and software topics involved in our work, which were designed according to
11 satisfy the RoboCup rules. In addition of giving details on the current development, we present
12 some insights on the main challenges that have been identified and tackled in recent years with the
13 consolidation of this team, in order to foster other forming groups around the globe.
14
15 Introduction
16 Innovación y Robótica Estudiantil, which is the affiliation of all members on this team, has been
17 founded in 2001 and corresponds to a self-organized group of students from several faculties, such
18 as Electronics, Informatics and Mechanical Engineering departments at the University (UTFSM). This
19 RoboCup team belongs to one of several projects from this aggroupation and is conformed by
20 students with different specialization areas such as computer science, control, and automation, or
21 power electronics, but also on a multidisciplinary approach including students from mechanical
22 engineering, as well as industrial engineering students.
23 This SSL team follows the nature of the host students initiative, starting from its multidisci-
24 plinary constitution, the self-organization and motivation with professor advises when required but
25 managed independently from any professor funding project, and trascendence over generations
26 renewing its members with a constantly growing development and enhancement, and making
27 both research and development works, like [1] where a previous generation of the team applied
28 reinforcement learning on the goalkeeper task.
29 This document describes our design and the implementation we have got so far, showing all the
30 work made in the different areas involved in this category.
31 In particular, we describe the mechanical design, electronics design for different devices and
32 algorithms implementation for the (robotics) team coordination, also including the expected imple-
33 mentation we are planning to reach by the time of the competition.
34 Mechanical Design
35 The material selected for the chassis structure is chosen by means of priorizing the collision
36 resistance, so an aluminum base is used, while supports for the wheel motors also consists on
37 four aluminum blocks and a second floor of polymethyl-methacrylate (PMMA) which stands for
38 supporting the battery. Then, a third floor is designed also of PMMA, with the aim of supporting the
39 PCB and also isolating the battery and PCB. Finally, the cover is 3D-printed on ABS material.
40 -Height: 150 mm.
41 -Diameter: 180 mm.
42 -Maximum coverage of the ball: 18%.
Proceedings of the 4th Congress on Robotics and Neuroscience
Figure 1. Omnidirectional wheel back view
Figure 2. Robot assembled
43 Drive System
44 Mechanical locomotion of robots is based on 4 omnidirectional wheels, which are currently 3D-
45 printed in PLA. Each wheel is designed with 55 mm of diameter and 15 sub-wheels of 13.5 mm of
46 diameter, so the robot can move in all directions. Also, each one of the 55 mm diameter wheel has
47 a set of 15 mini metal V grove guide pulley rail ball bearing wheels. Each wheel is driven by a Maxon
48 EC45 30 Watts motor [7] and an L6235 driver for 3-phase brush-less DC motor [6], which enables us
49 to program a velocity control for each motor, ensuring that the robot moves to our desired setpoint
50 speed.
51 Hardware
52 Each robot is controlled by a PIC MX440F256H using Pinguino Development board. This model was
53 chosen because of its simplicity, versatility and peripherals features. It has shown an acceptable
54 performance, letting us accomplish communication, movement, and playing skills. The peripherals
55 also replace a lot of external electronics needed to control the motors and dribbler.
56 Peripherals
57 ADC conversion
58 The ease of implementation of this kind of modules allows us to control wheel speed and orientation
59 through an L6235 driver using DAC conversion. Additionally using ADC conversion we can measure
60 the wheel speed, allowing us to implement a PID control on velocities for each wheel.
61 I2C
62 As mentioned before, we use an L6235 driver, which communicates with the PIC through its I2 C
63 module.
64 UART
65 The UART module allows us to develop serial communication between the PIC and our APC220
66 RF module, which will send and receive data from the centralized decision maker placed on the
67 computer. Additionally, we use an FTDI connected to our UART communication module to watch
68 data of interest.
69 GPIO
70 The general purpose Input/Output pins let us program easily, in general, any other significant
71 settings, i.e. set the wheel break and direction pins or activate the kick routine.
72 Kicker
73 The circuit that is shown in Figure 3 is used for the kicking system. This consists of a chip charger
74 controller with regulation which is a controller of flyback of high voltage, raising the voltage from
75 24 [V] to 100 [V] on a capacitor of 2400uF and, therefore, storing an energy of 244 [J]. The time of
76 charge of the capacitor takes up to 3 seconds to reach the voltage setpoint and can be regulated to
77 kick with different intensities.
Proceedings of the 4th Congress on Robotics and Neuroscience
V_TRANS
VCC 9
10
C1 C2 C3 C4 C5
+
11
12 7
D1 D2 COM RelayNO
R11 Solenoid
GND 4 6
3
1
2 C6
Signal 8 20 R10 1
FLUX SHLD
CHARGE RDCM
RV_TRANS
9 CLAMP
18 R9 T1
RV_OUT
GND 13 VCC GND
15
R1 7
HVGATE
14 VCC
M1
DONE LVGATE
VCC CSP 12
R2 6 FAULT
R3 LT3751 R8
2 UVL01
V_TRANS R4 3 OVL01 CSN 11
R5 4 10
UVL02 FB
VCC R6 5 OVL02 GND
GND
RBG
R7
17*3
16
GND
Figure 3. Kicker circuit
78 Dribbler
79 According to RoboCup rules, the robot is allowed to cover up to 20% of the ball. Experimentally, it
80 has been proved that it is easier to catch the ball when the dribbler has a slight curve to center the
81 ball on its own. So, this design involves two diameters, D1 and D2, and based on this information,
82 maximum height possible is calculated obtaining the following expression:
√
1 𝑑
𝐻= (𝐷 (2𝑑 + 𝐷2 ) + 𝐷1(4𝑝𝑑 − 2𝑑 − 𝐷1 ) + 4𝑝𝑑 2 (1 − 𝑝)) + , (1)
4 2 2
83 where 𝑑 and 𝑝 corresponds to the ball diameter and maximum coverage of the ball, whose
84 relation is illustrated in Figure 4.
85 Our team uses the engine MAXON EC K1 16, BRUSHLESS, 30 WATT, SENSORLESS, handled by an
APF30212A
1
86 ESC LettleBee opto 6s.
Both the engine and roller join using a gear system with ratio 1:1, configuration that let us drive
2
87
Figure 5. View of dribbler assembly
Figure 4. Relation between variables involved in
dribbler design
Proceedings of the 4th Congress on Robotics and Neuroscience
Figure 6. Robot wheel speed control system
88 and automatically center the ball with a 3D-printed support structure.
89 Communication
90 For communication, we use an RF module consisting of an APC220 which is a low-cost NRF Athena
91 that integrates an embedded high-speed microprocessor and high-performance IC that creates
92 a transparent UART/TTL interface. It is a 430 MHz system capable of transmitting up to 1000
93 meters. We send every single robot data through a common channel as hexadecimal packages
94 in order to achieve better transmission bytes. Each robot receives and decodes the data in a pic
95 microcontroller.
96 Kinematic model and wheel speed control
97 In order to maintain the expected velocity and position, we applied PID control [2] on every wheel
98 once the setpoint speed is calculated for every robot. To accomplish this task, our control system
99 sends a velocity vector 𝑉 = [𝑣𝑥 , 𝑣𝑦 , 𝑣𝜃 ]𝑇 to each robot, multiplying then its kinematic model matrix
100 𝑊 , defined by the geometry of the robots, obtaining
𝑢 = 𝑉 𝑇 𝑊 = [𝑢1 , 𝑢2 , 𝑢3 , 𝑢4 ]𝑇 = 𝜙𝑟,
101 where 𝑢 is the wheel velocity vector, which divided by 𝑟 (radius of the wheel), it is possible to
102 obtain the angular velocities of the wheels, 𝜙. This is the reference variable to the control speed
103 system shown in Figure 6, and by obtaining direct measure from the hall sensors of the motor we
104 can obtain the input error variable to the PID. Then, the controller generates a PWM as output in
105 order to set the wheel speed. It is important to note that 𝜙 is treated as an absolute value because
106 the direction is set by enabling or disabling certain pins on the driver controller.
107 Software
108 Diagram depicted in Figure 7 shows a general overview of the system, where we implement a
109 high-level AI decision making in order to decide which is the best action to take from a set of high
110 level preprogrammed plays based on the game state that comes just from the vision receiver.
111 Then we have a low-level path planning algorithm to choose the best path in order to execute the
112 play avoiding obstacles. This is implemented on the desktop computer in charge of making the
113 centralized decisions for every robot.
114 High level AI
115 The higher order AI level computes at each processing cycle the best actions to be performed for
116 each robot. This action is chosen by selecting a game-play from a pre-defined static pool. This
117 fundamental part of the system’s architecture is shown in Figure 8, introducing four identifiable
118 processes. First, there is a SceneRater which analyze and encapsulates all the relevant information
119 from the game field for choosing a game-play. Then, that information is used for actually selecting
120 the specific game-play through the block named as PlayChooser, weighting each detected event for
121 deciding whether an attacking strategy or a defensive one should be used, and which one in detail
Proceedings of the 4th Congress on Robotics and Neuroscience
Figure 7. General diagram of the system
High-level AI
SceneRater
Vision/Referee data Events vector
(field data)
Executer Game-plays
PlayChooser
Low level Set of pre-defined plays
Robot control Path-planning
system data
Role vectors
for action performing New
no play?
yes
RoleAssigner
Role vector for
robot assignment
Figure 8. High-Level Artificial Intelligence Architecture Diagram
122 must be performed. Once a game-play is chosen, then a RoleAssigner block is in charge of coherently
123 distribute the roles associated to that game-play, as well as selecting which robots should assume
124 each position. Finally, each position must be run by the robots, a process managed through time by
125 an Executer block.
126 Then, as shown in Figure 8 which depicts the diagram of the algorithm implemented as the top
127 hierarchy intelligence architecture, the processing cycle starts with the receiving of new data either
128 from the vision system or the referee. As illustrated, four blocks are implemented and processed
129 in order: SceneRater, PlayChooser, RoleAssigner, which is executed just if the current play has
130 changed, and the Executer block.
131 Specifically, the SceneRater evaluates conditions as which team has the ball, whether a team has
132 or not high and middle chances of making an annotation, the partial position of the ball in the field,
133 which team is closer to the ball, among others relevant features.
134 The PlayChooser, after receiving the vector of detected events, evaluates all pre-defined game-
135 plays, each one of them rating differently the events detected. Offensive plays rate with higher
136 values the detection of the ball in the enemy team area, and even more if the ball is close to the
137 enemy goal area. Coherently, defensive plays strongly rate when the enemy team has the ball and
138 even more if they have an opportunity for shooting to the team goal area.
139 Each game-play is described by a set of roles, one role for each agent, introduced in a priority
Proceedings of the 4th Congress on Robotics and Neuroscience
140 order in case of using fewer robots than the maximum allowed. Each role considers a set of actions
141 to be developed by the agent, as moving, receiving or giving a pass or shooting to the goal area.
142 To do so, the architecture includes the Executer block, which is in charge of evaluating if either
143 an action has finished or not, managing the changing of steps and computing the next step of an
144 action execution for each robot.
145 In order to simulate the robotic team coordination, and test different multi-agent algorithms,
146 we make use of GrSim [5], software that has been very helpful to test game strategies.
147 Low-level path planning
148 Under the high-level plays, we run a path planning algorithm to find the best way of executing these
149 tasks. We have tested different methods looking for a suitable algorithm which gives good results
150 at the moment of avoiding obstacles.
151 The first method tested was Potential Field algorithms [4]. This proposes a potential field
152 representation for obstacles and target, using sources for the prior and sink for the latter. In this
153 way, vector trajectories are generated avoiding obstacles and leading the agent to the target, as we
154 let a ball fall down. A disadvantage of this method is that we could obtain local minimums without
155 reaching the target.
156 The best method tested was Rapidly-Exploring Random Trees (RRTs)which consists on expanding
157 a tree on the target zone, avoiding to add nodes that could produce collisions with targets. The
158 added points to the tree are randomly chosen with probability 𝑝 in a straight line to the target,
159 and with probability (1 − 𝑝) selecting a random point on the space, making more exploration and
160 avoiding to get stuck on a different location to the target.
161 For improving its performance, we have implemented and tested some of the algorithms based
162 on RRT, way-points, smoothing and some extensions like RRT* presented on 2011 [3].
163 Conclusions
164 Although we tackled several challenges prior to our participation at the Robot Soccer World Cup
165 2018, such as discarding low-level path planning algorithms due to local optimums according
166 to some remarks described throughout this document, and despite efforts about testing game
167 strategies on a simulated environment, a newcomer team into the league should consider several
168 other challenges that should be faced at the time of participation, such as:
169 • Full integration with referee box: it is not enough to communicate this software with the
170 central unit for the team decision-making system, given that all rule cases should be covered.
171 • Number of robots: although each team is allowed to participate with a smaller number of
172 robots, it is important to maximize the number of available prototypes in case of structural
173 damage (chassis should be prepared to receive very strong shoots).
174 • Number of team members: in case of belonging to a self-organized group of students (such
175 as our case), budget and funding search for the tournament participation should include at
176 the very least six members, given that captain is constantly being called for meetings within
177 the contest, and two other members have to serve as referees for other matches.
178 • Precision and time delays: although splitting of teams into Division A and Division B lower the
179 game complexity in order to face similar teams in terms of experience and tasks achievement,
180 there are very experimented teams which have mastered the motion control of robots, so it is
181 important to be prepared to chase and face the ball in the most efficient possible manner.
182 Next challenges for this team in order to qualify for the upcoming world cup in addition to fundrais-
183 ing for participation, include fine-tuning of robots which were already capable of playing matches
184 and even winning one of them, following with the appropriate prototypes replication.
Proceedings of the 4th Congress on Robotics and Neuroscience
References
[1] Ahumada et al. “Accelerating Q-Learning through Kalman Filter Estimations Applied in a
RoboCup SSL Simulation”. In: Robotics Symposium and Competition (LARS/LARC), 2013 Latin
American. IEEE. 2013, pp. 112–117.
[2] Åström et al. PID controllers: theory, design, and tuning. Vol. 2. Instrument society of America
Research Triangle Park, NC, 1995.
[3] Bry et al. “Rapidly-exploring random belief trees for motion planning under uncertainty”. In:
Robotics and Automation (ICRA), 2011 IEEE International Conference on. IEEE. 2011, pp. 723–730.
[4] Ge et al. “New potential functions for mobile robot path planning”. In: IEEE Transactions on
robotics and automation 16.5 (2000), pp. 615–620.
[5] Monajjemi et al. “grsim–robocup small size robot soccer simulator”. In: Robot Soccer World Cup.
Springer. 2011, pp. 450–460.
[6] Vincenzo Marano. “L6235 three phase brushless dc motor driver”. In: Application Note, ST
(2003).
[7] AG Maxon Motor. EC-Powermax 30 Catalogue Information. 2008.