Maracatronics VSS Team Description Paper for LARC 2020

Júlia D. T. Souza1 , Joaquim E. A. Araújo, Zilde S. M. Neto, Amanda S. de C. Moraes, Caio M. A.

Montarroyos, Danillo do N. Santos, Flavio L. C. Oliva, Flávio M. C. da Silva, Gabriel T. S. Muniz,
Guilherme S. A. e Silva, Ítalo R. A. Silva, Lucas F. Benozatti, Luı́s E. M. Alves, Luiz H. de S. Arruda,
Marcos E. A. de Lima, Pedro S. V. Motta, Vı́ctor H. M. Silva, Victor X. C. de Oliveira, Vinı́cius A. Pereira,
Pedro J. L. da Silva, João P. C. Cajueiro, João M. X. N. Teixeira, José R. de O. Neto, Guilherme N. Melo

Abstract— This paper presents the current state of the II. C ONTROL S YSTEM A RCHITECTURE
Maracatronics team as it stands for Latin American Robotics
Competitions - Very Small Size Soccer League 2020. Due to
A. GEARSystem
the competition being made using simulators this year, this We choose the GEARSystem [1] as the main framework of
paper contains descriptions only of controller software used as the project as long as it is used on the Warthog Robotics SSL
part of Armorial Project, the current project to create mobile team. This architecture offers some important information
and autonomous robots of Maracatronics Robotics Team. The
description of the mechanical and electronic projects will be used along the main code at Armorial-Suassuna-VSS [2].
for the next edition of the championship, when both projects GEARSystem provides an architecture based on dis-
are tested for the rigors of the competition. tributed systems with 3 modules and 1 server to provide
communication between modules, as can be seen in Figure
I. I NTRODUCTION 1. The first module is the Sensor module which is responsible
In 2020, since the Very Small Size Soccer category com- to get information from the real world through sensors
petition announced that will use a simulated environment, (cameras) or network, filter them and delivery it to other
the team decided to start the development of the software modules. The Controller module is responsible to process
responsible for controlling robots on the field as part of the the collected data and decide what each robot will execute
Armorial Project, a long-term project for the development in the field. The Actuator module is responsible to send
and improvement of robots autonomous. the commands to the robots, whether simulated or real.
For the software development, a base structure provided The server or Backbone is responsible to connect the three
by the Warthog Robotics team from USP São Carlos, modules and communicate them. A simple representation can
called GEARSystem, was used. Thus, the entire project was be see in Figure 1.
built using an architecture with distributed systems allowing B. Backbone (Server Module)
the exchange of components according to the environment
The Server module, or Backbone, is responsible for
played.
communicating the modules. For this purpose, it uses the
This proved to be advantageous, because as the category omniORB library available in CORBA interfaces. There are
does not have yet a single vision software, it is possible to a total of three CORBA interfaces, one for each module,
change only a portion of the code responsible for receiving and this interfaces works as the Backbone boundary, inter-
the data. Thus maintaining a seamless interface for the other facing with the external elements. There are two classes in
components that will not need to be changed. Backbone:
For the main control software, a layer structure was 1) WorldMap: This class saves information from the
adopted with three layers that define individual attributes. sensor about the field geometry, players status and ball status
However for the players and two layers responsible for and sets them available for the controller. To prevent conflicts
defining strategies and organizing the positioning of the from the information sent or received by the server threads,
teams on the field. WorldMap uses Mutex to avoid conflicts during writing or
To present the main changes in the project, this paper reading an information.
is organized as follows: Section II presents GEARSystem 2) CommandBus: This class saves the commands sent by
architecture used to develop the entire solution. Section III the controller and sets them available to the actuator. To
presents the hierarchy tree of Coach Coach entity. Sections prevent errors from the simultaneous commands sent, it also
IV presents algorithms used to defend out goal. Section uses a Mutex to ordinate the commands in a queue.
V presents the algorithms used to path planning. Finally,
Section VI presents results of preliminary tests and our open- C. Armorial-Carrero (Sensor Module)
source contributions to Robocup and LARC community. Our Sensor module, called Armorial-Carrero, has role of
taking data from the field and treat them to make some useful
1 All authors are with Maracatronics Robotics Team, at Mechani-
stuff.
cal Engineering Department, Center for Technology and Geosciences,
Universidade Federal de Pernambuco, State of Pernambuco, Brazil This operation uses 2 different threads to complete its
[email protected] objectives with one submodule running in each one. A
 Fig. 1. GEARSystem structure.

workflow of Armorial-Carrero structure is shown in Figure Suassuna-VSS and send packages of information which will
2. update the game situation on the simulator FIRASim. The
connection with FIRASim occurs via the Protobuf protocol.
Armorial-Actuator has a timer information, that way con-
nection problems can be pointed and it’s a way we can verify
if the packages are being sent the right way.
E. Armorial-Suassuna-VSS (Controller)
The controller module, Armorial-Suassuana-VSS, pro-
cesses the current state of the game and based on that decides
what actions will be taken by each robot. It receives infor-
mation from Armorial-Carrero and use this values to make
Fig. 2. Armorial-Carrero structure. some standard values used along the codes. A workflow of
Armorial-Suasuna-VSS structure is shown in Figure 3.
The first one is the ArmorialVisionClient which takes brute
data from the field or simulator (in packages) and ordenate
them for a posterior treatment..
The second one is the ArmorialVisionUpdater which
takes the packages from ArmorialVisionClient and threat
the informations, generating the geometry limitations, like
the field, player and ball dimensions, and some interesting
informations using classes available on GEARSystem, like
the id of players and teams, the position of the ball and
players and some relevant points at the field, like the penalty
mark. Then, this information is sent to Backbone.
ArmorialVisionUpdater also uses some filters to get more Fig. 3. Armorial-Suassuna structure.
precise informations:
1) Multi-Object filter: : This one guarantees the oneness Then, we have to make connections with the standard
of the objects. information, like a yellow robot has the same team id of
2) Noise filter: : It prevents the apperance of invalid another yellow robot, so that we can have control of (only)
objects on the field our players and useful information.
3) Loss filter: : A filter used to solve the disappearance of Armorial-Suassuna-VSS has a thread named WorldMap,
objects on field for any reason. It doesn’t solve the problem which manages everything, and sub-threads:
at all, but it prevents that many objects disapppear for much 1) Player: : This thread controls our players and its
time. actions, like the torque applied in the wheels, the skills
4) Kalman filter: This one takes some data from the available to it and the information associated with it (id,
vision and some data about the data the module already have team, color, etc).
and makes a prediction of the positioning of moving objects. 2) Coach: : This thread collects the coach commands and
A full descriptions of the methods used in the submodules controls the actions and formations our robots would choose
and the filters are available at [1]. in the actual game situation.
3) User Interface: : This thread controls what is seen on
D. Armorial-Actuator (Actuator Module) the User Interface which can be defined up to debug some
The actuator module, called Armorial-Actuator, has the features implemented or show the game from top as a way
role of connecting the informations obtained from Armorial- of game transmission.
 III. C OACH A RCHITECTURE 1) Playbooks: The playbook level is the first to enable
interaction between individual elements at lower levels in
The coach is the entity responsible for determining the the control hierarchy (following a bottom-up approach on
strategy to be followed by the team. Once the strategy Figure 4). A playbook is responsible for grouping roles
is defined, the team plays according to a hierarchical tree capable of working together and for assigning them to
composed of an individual layer and a collective layer, each a group of players. An offensive playbook, for example,
of them with multiple levels, represented by Figure 4. can bring together the Attacker and Supporter roles, while
a defensive one can group the Goalkeeper and Defensive
Assistant roles.
2) Strategies: A strategy manages the playbooks used by
the team and the number of players assigned to each one of
them. Different strategies can be used depending on the state
of the game and on the aggressivity module (which uses the
distribution of players on the field as a parameter).

IV. D EFENSIVE TACTIC

Our defensive tactic consists on reducing the score chance
for the opponent team. So that, there are two main locals
which we use a different heuristics: The goal area and our
half side (excluding the goal area).
1) The goal area: The goalkeeper will protect that area
predicting the position the ball should enter on that area. For
this, it creates a line in the slope-intercept form:

y =a∗x+b (1)

Which coefficients are described by the equations below:

a = tan(θball ) (2)

b = yball − a × xball (3)

Fig. 4. Control Hierarchy Tree Where θball is the angle of the velocity vector of the ball
in the system coordinates of FIRASim. To prevent that the
robot takes unwilling movements, we limit its movements at
A. The Individual Layer x = 0.7 or x = −0.7 (depending which is our team side) and
−0.35 < y < 0.35. That way, the goalkeeper will remain on
The individual layer corresponds to the actions and set of the goal area all the time.
actions that can be individually assigned to a single player. 2) Our half side: The middle robot will take a barrier
Its levels are composed by: behaviour and protect this region from plays started at the
1) Skills: Skills are the atomic actions that can be per- enemy half side, staying in front of the ball when an enemy
formed by a player, such as pushing the ball, spinning and has the ball possession. This way we can prevent an enemy
going to a specific point on the field. dash advance which are the most imminent score chance
2) Behaviors: A behavior can be described as a set of nowadays. To complete this task, it creates a line the same
skills and conditions that combined form a more reactive way used by the goalkeeper, but it has a bigger range of
attitude: It is able to alternate the skills according to the field actuation, which means it has less moviment limitations.
elements state (ball position, ball velocity, closest enemy In both situations, the robots can spin to clear the ball and
position etc). take away the danger.
3) Roles: A role is a complex set of behaviors that
assigns to a player a well-defined function in the team. Some V. NAVIGATION
examples of roles are: attacker role, goalkeeper role etc. A. Free Angles Algorithm
The Free Angles algorithm is used to assess the presence
B. The Collective Layer
of obstacles with respect to an observer’s position and a
The collective layer represents a grouping of elements search radius. Through the range of angles provided by this
from lower levels that can be assigned to a group of players. algorithm it is possible to move the robot avoiding collision
Its levels are composed by: with the other players on the field.
 In order to develop this assessment of obstacles present
in a search area, in the first step the algorithm fills in a list
of obstacles that are within range with respect to a given
position. Having the complete list, the obstructiona angle of
the obstacle in relation to the observer is calculated for each
element of the list. To perform this calculation of the angular
range of obstruction, it is first necessary to calculate the
angular inclination of the line segment between the position
of the observer Pw and the position of the obstacle Po , where
we can calculate using the equation 4.
P xo − P xw
angleT oObst = arctan( ) (4)
P yo − P yw
With this, it is necessary to calculate the Euclidean dis-
tance from the observer to the obstacle, in order to find
the amplitude of the angular range of vision obstruction. To
calculate the amplitude of this angular range, the obstacle
geometry was approximated to a circumference of radius
Ro , where the center of that circumference corresponds to
its position Po . And using the equation 6 it is possible to
calculate half the amplitude of the obstruction angular range
defined as angleOffset. Fig. 5. Sketch of the angles that define the obstacle’s angle of obstruction
in relation to an observer
p
distow = (P xo − P xw )2 + (P yo − P yw )2 (5)

Ro
angleOf f set = arctan( ) (6)
distow
Finally, it is necessary to reference the initial and final
angles that form the obstruction of vision of the obstacle,
using the equations 7 and 8:

initAngleT oObst = angleT oObst − angleOf f Set (7)

f inalAngleT oObst = angleT oObst + angleOf f Set (8)

Having all the information regarding the range of angles
that are blocked by obstacles within the search area, it is
Fig. 6. Example of breaking intervals that the Free Angles algorithm
now enough to include the ranges of angles that are free, that performs - In red, the interval that is blocked. In green, the intervals are
is, to fill the gaps between the ranges of obstructed angles. free intervals, and the red arrow is positioned in the middle of the largest
Therefore, at the end of the process, Free angles is able to free interval
provide a list that contains both the angle ranges that are
blocked by obstacles, and the angle ranges that are free as
shown in the figure 6. of the field, and then traces several possible routes through
these positions forming a tree graph. Having the graph
B. Path Planning calculated, the system must choose which branch of the
To enable the robot to reach a position of interest in graph has the lowest travel cost, i.e. the shortest route for
the field, without collisions with the other robots present, the robot to reach the position of interest. A example of a
the RRT [3] navigation algorithm was implemented. This path generated by RRT algorithm is shown in Figure 7.
algorithm works by constructing two position trees that are
generated in a random way for quick exploration that are C. Navigation Control
rooted at the starting point of the robot and the desired end To allows robot to follow the trajectory defined by the path
position. In this way, each tree must explore the environment planning algorithm, it is necessary to carry out a control
around them and also move towards themselves. of the speed of each wheel. Therefore, the control of the
To find the best trajectory of the robot’s displacement, this robot’s position is not only done through its linear speed,
method performs a sampling process with the free positions but also depends on the angular orientation of the robot at
 VI. C ONCLUSION
Preliminary tests using the FIRASim simulator, the code
showed good results managing to perform from simple tasks
such as avoiding obstacles and moving towards the ball to
more complex tasks such as playing with the complete team
against another complete team.
Looking at the 5x5 challenge, the structure presents fea-
tures that will allow the software to scale without major
problems as well as the creation of new roles for the players,
allowing for a more dynamic game and for the players to
have acting specialties just like in human football.
All the project’s source code is available on the team’s
Github with documentation for the community.

Fig. 7. Example of the path generated using the RRT algorithm R EFERENCES
[1] R. G. Lang, I. N. da Silva, and R. A. Romero, “Development of
distributed control architecture for multi-robot systems,” in 2014 Joint
Conference on Robotics: SBR-LARS Robotics Symposium and Robo-
each moment of the displacement in the path. control. IEEE, 2014, pp. 163–168.
In the figure 8 it is possible to identify the basic elements [2] Maracatronics, “Armorial-suassuna vsss repository,” https://github.com/
that defines the kinematic model of the robot. From the MaracatronicsRobotics/Armorial-VSS, 2020.
[3] J. J. Kuffner and S. M. LaValle, “Rrt-connect: An efficient approach
study of these elements, we can use some mathematical to single-query path planning,” in Proceedings 2000 ICRA. Millennium
relationships to define the linear and angular displacement Conference. IEEE International Conference on Robotics and Automa-
of the robot. Thus, we can define the angular speeds of each tion. Symposia Proceedings (Cat. No. 00CH37065), vol. 2. IEEE,
2000, pp. 995–1001.
wheel using the equations 9 and 10:

Fig. 8. Kinematic model of the robot

2∗v+l∗w
Wr = (9)
2r

l∗w
W l = Wr − (10)
r
In the equations 9 and 10 w and v represent the angular
and linear velocities of the robot and l and r are the distance
between the wheels and wheel radius respectively.
To optimize the robot movement, we can use both the front
of the robot and the back to perform the displacement. This
decision on which side to use can be made with respect to
the robot’s angular displacement angle module (angle φ in
the figure 8), since this is greater than 90◦ it would be more
advantageous to use the back of the robot to perform the
displacement.