This page gives a technical overview of the league. It is meant to give people that are not yet familiar with how the SSL is structured a first high level overview and references to where to look for more information.
SSL Components
The following figure shows the different components and how they interact with each other:
SSL-Vision
This is the official, league-maintained software for robot and ball detection. It is responsible for transforming images from all cameras over the field to coordinates that are broadcast to the teams via multicast. During a competition, it is set up by the technical committee. Teams do not have to take care of it. However, the detections are not reliable and require further processing. Also, for division A there are two cameras. Detections can be on both cameras and need to be merged accordingly.
SSL-Game-Controller
A match is coordinated by the SSL-Game-Controller. It is running on a computer next to each field and has a UI for the game controller operator. The game controller broadcasts referee messages via multicast, just like SSL-Vision. Additionally, there are synchronous network interfaces for autoRefs and teams to communicate bidirectionally.
AutoRefs
There are automatic referees that supervise a match and support the SSL-Game-Controller, mainly with detecting fouls. In order to increase robustness and fairness of the foul detections, multiple AutoRefs can (and will) run simultaneously and decisions can be based on a majority vote.
There are two implementations that are currently under active development by teams and that are used since RoboCup 2018:
For reference, the following implementations also exist, but are not currently in use:
- ssl-autonomous-refbox (one of the first prototypes)
- CM Dragons
- RoboTeam Twente
Simulators
The Simulation Protocol defines a common way to communicate with an SSL simulator. It has been initially introduced for the virtual tournament at RoboCup 2021. The common protocol should encourage teams to publish their simulator or to use other open sourced simulators. By having a common protocol, switching between different implementations gets easier.
The protocol allows simulators to add some custom definitions, like additional realism configurations.
There are currently two open-sourced simulators available:
Vision Trackers
The data that is published by SSL-Vision is only raw positions per camera. They are noisy, can vanish sometimes and there is no velocity included.
Not only teams have to take care of that, but also the autoRefs. Since RoboCup 2023, the autoRefs officially publish their filtered/tracked data. Teams, especially new ones, are welcome to use this data instead or in addition to the SSL-Vision data. The SSL-Game-Controller also consumes these packages.
You can find the Vision Tracker Protocol on GitHub.
Team AI
Teams have to write their own software framework that is capable of receiving data from ssl-vision and ssl-game-controller and to communicate with their robots. The communication to the robots is not yet standardized. Most SSL teams use either low-level radio modules that work in the 2.4 GHz range or use 5 GHz Wifi.
Team Robots
Teams have to build their robots from scratch. They have to comply to the rules, mainly fit into a 180x150mm cylinder. A lot about how to design a robot can be found in the Open Source Contributions and the TDPs.
Additional League Infrastructure
League-maintained software is stored and managed in the RoboCup Small Size League Github organization. Although the repositories are maintained by the Technical Committee, contributions from all members of the community are highly encouraged.
There are a couple of interesting repositories:
SSL-Log-Tools
The ssl-go-tools contain several CLI tools to work with SSL Gamelogs, including:
- ssl-auto-recorder: Automatically detect new matches and create individual logs per match
- ssl-log-recorder: Record logs manually
- ssl-log-player: Play a logfile back into the network
- ssl-log-converter: Convert log files to a human-readable format – a JSON stream.
For more tools, have a look at the repository.
SSL-Status-Board
The SSL-Status-Board can be run on a large screen to present the current state of the game to the audience and the human referee.
SSL-Vision-Client
A simple browser-based visualizer for the field.
SSL-Simulation-Setup
The Simulation-Setup has been created for the virtual tournament at RoboCup 2021 and can also be used for future virtual events or for testing a full setup with all league software.
SSL-Setup
The SSL Setup is used to set up all the required software for a real tournament. It contains scripts and Docker Compose configs to install everything on a fresh computer running Ubuntu.
SSL-Match-Stats
The SSL measures metrics and statistics over past RoboCups. The code for the Match Statistics is maintained on GitHub.
Standard Network Parameters
Protocol | Protobuf | Type | Address | Port |
SSL-Game-Controller (GC) | Referee | UDP Multicast | 224.5.23.1 | 10003 |
SSL-Vision Detections | SSL_WrapperPacket | UDP Multicast | 224.5.23.2 | 10006 |
SSL-Vision Detections Legacy | SSL_WrapperPacket | UDP Multicast | 224.5.23.2 | 10005 |
AutoRef -> GC | AutoRef | TCP | GC | 10007 |
AutoRef -> GC | AutoRef | TCP + SSL | GC | 10107 |
Team -> GC | Team | TCP | GC | 10008 |
Team -> GC | Team | TCP + SSL | GC | 10108 |
Remote Control -> GC | Remote Control | TCP | GC | 10011 |
Remote Control -> GC | Remote Control | TCP + SSL | GC | 10111 |
Continuous Integration -> GC | Continuous Integration | TCP | GC | 10009 |
Continuous Integration -> AutoRef | AutoRefCi | TCP | AutoRef | 10013 |
SSL-Vision-Tracker | TrackerWrapperPacket | UDP Multicast | 224.5.23.2 | 10010 |
SSL-Vision-Client Visualization | Visualization | UDP Multicast | 224.5.23.2 | 10012 |
Simulation Control | SimulationControl | UDP | Simulator | 10300 |
Robot Control Blue | RobotControl | UDP | Simulator | 10301 |
Robot Control Yellow | RobotControl | UDP | Simulator | 10302 |
Protobuf Definitions
There are several different protobuf definitions, distributed over multiple repositories. This section gives an overview of the available definitions and links to the respective repositories for the latest version of the protocol.
In general, protocol updates will always be made in an compatible way on the transmission side, so that no software needs to be changed on updates. However, renaming and removing (with reserved flag) fields can be done, if there are good reasons for it.
- SSL-Vision
- SSL_DetectionFrame: Raw robot and ball detections per camera
- SSL_GeometryData: Global field geometry, camera calibration per camera and ball model parameters
- SSL_WrapperPacket: Message that wraps the DetectionFrame and GeometryData
- TrackedFrame: Filtered robot and ball detections
- TrackerWrapperPacket: Message that wraps the TrackedFrame with additional metadata (not produced by SSL-Vision, see SSL-Vision-Tracker-Protocol)
- SSL-Game-Controller
- Referee: The current game state with commands, game events, team state, etc.
- Remote Control
- AutoRef: Send detected game events to the GC
- Team: Change the keeper id and request robot substitution
- Remote Control: Control from external device, like RaspberryPi with Display
- Continuous Integration: Single connection for integration of the GC into a teams software
- SSL-Simulation-Protocol: A common protocol for different interchangeable simulator implementations
- SSL-Vision-Client
- Visualization: Send shapes (circles and lines) to the vision-client