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.
43 Drive System
44 Mechanical locomotion of robots is based on 4 omnidirectional wheels, which are currently
3D45 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 [
V_TRANS VCC C1
C2
C3 C4
C5 + GND VCC
VCC V_TRANS
GND Signal
R1 R2 R3 R4 R5 R6 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:
H = u 41 .D2.2d + D2/ + D1.4pd * 2d * D1/ + 4pd2.1 * p// + d2 ; (1)
83 where d and p 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 EKC1 16, BRUSHLESS, 30 WATT, SENSORLESS, handled by an
86 ESC LettleBee opto 6s. 1APF30212A
87 Both the engine and roller join using2a gear system with ratio 1:1, configuration that let us drive
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 [
u = V T W = [u1; u2; u3; u4]T = r;
101 where u is the wheel velocity vector, which divided by r (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
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
game135 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
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 [