Soccer Software

Of programs and data.

The software is the fourth main part of our team, next to the electronics, hardware and strategy department. The task of the software is to provide the strategy department with a way to send commands to the robots in order to make the game as fluid and tactical as possible.

But how can a computer program fulfill this functionality? To achieve this, our software is divided into different modules, each of which has different tasks. Before we get to the modules, some information about the software language and creation tools:

Software language and creation tools

Currently we use C++20 without a major framework to implement our modules. We build our software using CMake and Conan as dependency management. For graphics we use our own OpenGL rendering with ImGui as GUI backend. Apart from some external dependencies (like protobuf, asio or boost) we try to write everything from scratch.

To communicate with the outside world (the robots and cameras), we have the modules “ssl_interface” and “robot_interface”. The “ssl_interface” module receives the data from the field cameras and translates the images into our own format so that we can quickly access the information that is important to us. It also receives the current game status and messages from the referee and stores this information accordingly. The “robot_interface” module, in turn, translates software commands into a format that can be read by our RF base station, which in turn communicates directly with the robot.

All the information coming from different places goes through a module, the “game_data_provider”, where it is filtered among other things. This module also decides where all this data is stored. For example, position data of any kind is passed to the “world_model”, which then interpolates it.

The “Observer” is responsible for analyzing the data. This is an analysis tool that receives positional data of the robots and the ball and uses this information to provide information about the current state of the game (ball possession, risk factor, target probability).

The decision of what actions each robot should perform next is left to our strategy. This works in Python and can interact with our software via “pybind11” and the methods we provide.

The navigation of the robots is a non-trivial problem, as it must be ensured that they do not collide with each other, with opponent robots or with the gangs. This is complicated by the fact that all robots on the field can potentially travel across the field at several meters per second. This problem is dealt with by the “localplanner”. This takes care of the path calculation and of sending the actual movement commands to the robots.

To display all these processes in a reasonable way, we also write our own visualization “luhviz”. With the help of this, in addition to the general monitoring of the processes, you can also manually control the robots or send strategic commands to them.

Software Modules

Strategy

In order to enable rapid development in the field of strategy, it is necessary to write it in an interpreted language such as Python. However, since our main software is written in C++, it is a challenge to enable proper communication between software and strategy. To overcome this problem, we created an interface using pybind11 that allows the strategy to make necessary function calls in our software.

Navigation

The navigation includes the localization of the robots and the ball on the field. We do this by displaying them as individual coordinate systems in a global coordinate system. This makes it easier to calculate the rotation and position of two robots to each other. This data is used by the strategy and the navigation modules equally. The main goal of the navigation system is the planning of the best route for the robot to reach the desired destination.

Communication

The connection module handles the communication with everything outside our own Network. It receives data and formats it to our network internal messaging format for further use. It also converts data from the internal messaging format to the format used by the external device. Lastly establishing and maintaining connection to the external devices is a task of the connection module.

Our Software is Open Source!

As part of the RoboCup 2023 Open Source Challenge, we published our software entirely on GitHub. Open Source for the Win!

The Software-Team

Malte Sparenborg

Malte Sparenborg

Software Leader, Local Planning
B.Sc. Computer science

Member since January 2023

Tim Füchsel

Tim Füchsel

Tooling
B.Sc. Computer science

Member since May 2022

Sebastian Knackstedt

Sebastian Knackstedt

Build-Systems
B.Sc. Computer engineering

Member since October 2021

Steffen Begemann

Steffen Begemann

Skills, Local Planning
B.Sc. Computer science

Member since January 2023

Tobias Pahl

Tobias Pahl

Filter, Visualization
M.Sc. Computer engineering

Member since January 2022

Robert Hart

Robert Hart

Visualization
M.Sc. Computer engineering

Member since October 2021

Georg Laios

Georg Laios

Visualization
B.Sc. Computer engineering

Member since January 2023

Nastya Martynkova

Anastasia Martynkova

Simulation, Local Planning
B.Sc. Computer science

Member since January 2023

Fabrice Zeug

Fabrice Zeug

Local Planning
B.Sc. Mechatronics

Member since November 2019

Interested in joining the team?