Immortals 2020 Extended Team Description Paper

Omid Najafi, MohammadAli Ghasemieh, Mehran Khanloghi, AmirMahdi Matin, AliReza Mohammadi, AmirMahdi Torabian

Sharif University of Technology; Pars University of Art; University of Tehran; University of Science and Technology

http://www.immortals-robotics.com

Abstract This paper describes the recent work done by the Immortals Robotics Team for the upcoming competitions including the RoboCup 2020.

Introduction

The Immortals Robotics Team consists of art and engineering students from different Persian universities. The team was established in 2007 with the focus of designing a robust robot while meeting all the requirements according to the Small Size League rules. The team's strategy is to adapt itself with all the rule changes in order to experience the new challenges. This makes the team to take part in the division-A which is intended for the advanced teams of the league [1].

In the previous years the team reached close enough to a SSL robot design and solved most of the issues found in the previous designs. The process of upgrading the robot can be seen in the previous years TDPs and ETDPs [2] of this team. The readers who are interested in designing or upgrading a SSL robot are encouraged to study the previous papers of this team.

This year the team had the chance to improve the AI software design which is the core program running on a desktop or laptop computer and is the means to navigate each robot. The robots move and take actions defined by this program. Other enhancements, however, have been continued to be made to the robots mechanics and electronics which will be explained further.

Kicking System

Before 2018 the limit for the ball velocity was 8m/s. In order for robots to kick a ball that much fast, a strong shooting system including capacitors and solenoids where required. Since RoboCup 2018, Montréal, Canada, the maximum speed limit has been decreased to 6.5m/s which makes teams to wonder if they want to redesign their robots kicking system and optimize the space consumption or battery power in their robot. This year the Immortals robots kicking system has been modified in order to optimize the energy consumption from the battery. This way robots have the chance to stay longer in a match without the need of their batteries to get changed.

To understand the upgrade process of the shooting system, the reader is referred to the previous year (E)TDPs of this team [2, 3].

This year it has been decided to redesign the shooting solenoid which is the part that converts the electrical power to a magnetic field and thus it will move the metal plunger towards the ball to be kicked. The previous solenoid had a low resistance so a higher current will pass through it which will result in a higher speed. However, the kicking force will get a bit hard to control and it will generate a notable amount of heat. This part has been modified in a way that less current is flown in the solenoid to optimize energy consumption and generate less heat. Although the kicking power will decrease, it is still possible to kick the ball to more than 6.5m/s.

Software

This year the main software also known as the AI software is redesigned in order to be more understandable and extendable. In previous years the software core was the same for each year but with slight changes according to rules and new referee commands. The new members who wanted to implement a new idea in the software needed to spend a great amount of time to understand the methods to use for the robot navigation and data input.

The inputs for the software are vision data, referee commands and a configuration file which tells the initial parameter values for the network and match conditions. The outputs are simple navigation commands to the robots (e.g. moving with a given speed vector or kicking a ball with a specified amount of force).

The new software is written in C++ same as the previous one. The only reason to use this language is the performance and easy to extend capabilities of it. For example the ability to optimize the code by using GPUs are well known in this language.

Finite-State Machine

After a few years of experience in the Small Size League as a software designer the key idea that every team is looking to implement is to make the robots to take the correct action at the exact time and condition. If the actions are performed correctly, the robots will accomplish their task which is scoring a goal or preventing the opponent from scoring. Unfortunately, there are many conditions that can happen in a match and each one has its own set of solutions these solutions are the sequence of commands which are given to a set of robots. For the software designer it may be hard to implement the solutions with a group of IF conditions and no special structures.

In order to simplify the implementation for multiple software designers in the team, a Finite-State Machine implementation structure has been introduced. This gives a great flexibility and readability of implementation in the code. Each state is connected to other states by a condition or a set of conditions. This makes the implementation easier to probe. By tracking each state transition the faulty part of the code will be simply found.

Each state is basically a function which will be called whenever a complete picture of a field is received from the vision. The input of the function, or state, are the vision data. In each state, the set of commands which have to be given to the robots in the field are defined and if there is a condition which a state transition is required the next state will be defined to be called next time. Table 1 shows a sample group of commands which can be used in every state:

Example commands which can be used in every state.

As shown in Table 1 the commands are fairly simple to be understood. This simple implementation saves a great amount of time for the programmers to extend or debug the code.

Debugging

Another experience with the previous AI software was the process of debugging the algorithms and, in general, the code itself. To overcome this problem, a logging protocol has been implemented which defines the messages that are sent from the AI software while operating. Using that protocol, whenever a computer is running the AI software while connected to the network, any other computer in the same network can run a logging software and monitor the AI software's parameters including not just the simple inputs from the vision, but also the state, predictions of the algorithms and et al. Fig 3 shows the graphical visualizer which monitors and records the parameters in the AI software. The visualizer is implement in python while the AI is written in C++ as mentioned before.

Fig 4 shows a simple plotter which visualizes the changes in the speed and commanded velocity of a single robot. This logging tool is also written in python.

Analyzing

With the tools and designs which were introduced above, it is now possible to demonstrate different features of this project. Below, we will describe the analyzing process in the AI with an example. In the example the goal is to find the best spot in order for a robot to perform a one-touch kick.

There are many parameters to notice while performing a successful one-touch kick (e.g. Initial Ball Velocity, Robots Angle, Velocity of the robot, Target position of the kick). A simple solution to find the optimum values for the parameters is to run tests with different initializations of the parameters. Here, the tests are performed in grSim [6].

For this example at first, a ball and two robots are stationed at defined locations and a target position is randomly picked in a defined window.

Second, after waiting for a while, one of the robots moves toward the ball and kicks it towards the target position. Meanwhile, the other robot tries to reach to the target position.

Third, After the ball has been moved the second robot is commanded to perform a one touch kick and direct the ball to the center of the goal. This process continues until the ball passes the fields side line or the ball stops moving. If the ball enters the goal, the target position is tagged as a success, in other cases it is tagged as a fail. After this the round counter increases by one and the process is repeated from the first state.

At last, After 500 rounds the process is finished and the results are shown in the debugging tools (i.e. the graphical visualizer).

Fig 5 shows how a single round is performed.

To define this process the FSM chart shown in Fig 6 can be implemented in the project.

Now that the FSM is known, each state can be implemented. The pseudocodes of the states are defined in Tables 3, 4, 5 and 6. These state functions have access to global variables which are defined in Table 2.

Global variables of the FSM.

var targetPosition, initRobotPositions, initBallPosition,
  oppGoalPosition:Position;
var round, cnt:int;
var successPositions,failPositions:Position[];
var nextFunc2Run:function;

In Table 2, the targetPosition is the location where the robot will perform its one-touch kick. This variable is initialized in every round.

The initRobotPositions and initBallPosition are the initial locations of the robots and the ball in every round. These variables are defined before the start of the test. oppGoalPosition is the position of the center of the opponents goal line. This variable is defined before the start of the test.

successPositions and failPositions are two vectors which store the positions according to their tags, fail or success.

nextFunc2Run is the function which will run in the next cycle (i.e. The next time a new vision dataset is received). This variable is defined as a C++ pointer to function in our executable code.

Implementation of the Setup state.

function S1_setup()
  placeRobots(initRobotPositions);
  placeBall(initBallPosition);
  targetPosition = pickRandomPosition();
  logData();
  if round >= 500 then
    nextFunc2Run := S4_done;
    cnt := 0;
  else if cnt >= 130 then
    nextFunc2Run := S2_initKick;
    cnt := 0;
  else
    cnt := cnt + 1;

In S1_setup(), the robots and the ball have to get placed in the specified positions. This can be done by replacing the balls by hand or by robots and at last navigating the robots towards the specified positions. If the test is being performed in a simulator (e.g. grSim) it is possible to immediately place the robot by a command. Since the current test is performed in grSim, the robots will be placed using the placement commands implemented in grSim. These commands are shown as initRobotPositions() and initBallPosition() in the pseudocode. In every cycle (i.e. every time the function is called) A variable called cnt is incremented by one. It is checked in an if statement to check whether it is time to transit to the next state or to stay in the current state. Another if statement checks if the round number has reached to 500, if so, the FSM will transit to the done state which brings the process to an end.

Implementation of the Initial Kick state.

function S2_initKick()
  circleKickBall(Robot3, targetPosition, 100);
  ERRTNavigate2Point(Robot0, targetPosition);
  logData();
  if cnt >= 5 then
    nextFunc2Run := S3_oneTouchKick;
    cnt := 0;
  else if ballIsMoving() then
    cnt := cnt + 1;

In S2_initKick(), Robot #3 tries to aim the targetPosition and kick the ball towards it. Meanwhile, Robot #0 will try to reach the targetPosition. After a few moments when the ball is moving, the FSM will transit to the next state.

Implementation of the OneTouchKick state.

function S3_oneTouchKick()
  halt(Robot3);
  oneTouchDirect(Robot0, targetPosition, oppGoalPosition);
  logData();
  if ballIsOut() then
    if ballInGoal() then
      successPositions.add(targetPosition);
    else
      failPositions.add(targetPosition);
    nextFunc2Run := S1_setup;
    round := round + 1;
  else if ballIsNotMoving() then
    failPositions.add(targetPosition);
    nextFunc2Run := S1_setup;
    round := round + 1;

In S3_oneTouchKick(), Robot #3 gets into a halt mode and Robot #0 will wait for the ball to reach it. Once the ball gets fetched by the robot. it will get kicked towards the oppGoalPosition. The state transition will not happen until the ball exits the field or stops moving. When one of the transition conditions happen it will be judged whether the test was a success or a fail according to the position of the ball in relation with the goal.

Implementation of the Done state.

function S4_done()
  halt(Robot3);
  halt(Robot0);
  logData();
  logData(successPositions, GREEN);
  logData(failPositions, RED);

In S4_done(), the robots are halted and the results are sent to the visualizer as red and green points.

After running the code with 500 rounds in 1 hour and 20 minutes, the results were shown on the visualizer with 142 successful and 358 failed attempts. Fig 7 shows the visualizer at the end of the test. It is now clearly seen which areas have a high possibility in scoring a goal by a one-touch kick under the tested conditions.

References

1. Immortals Robotics Website, http://www.immortals-robotics.com.
2. Immortals 2019 Team Description Paper, https://ssl.robocup.org/wpcontent/uploads/2019/03/2019_ETDP_Immortals.pdf.
3. Immortals 2018 Team Description Paper, https://ssl.robocup.org/wpcontent/uploads/2019/01/2018_TDP_Immortals.pdf.
4. Immortals Open Source Project. https://github.com/Ma-Ghasemieh/Immortals_ssl_opensource_mech.
5. Immortals Open Source Publish in RoboCup 2016. https://github.com/lordhippo/immortalsSSL.
6. Monajjemi, Valiallah (Mani), Ali Koochakzadeh, and Saeed Shiry Ghidary. "grSim – RoboCup Small Size Robot Soccer Simulator." In Robot Soccer World Cup, pp. 450-460. Springer Berlin Heidelberg, 2011.