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.
The official software for robot and ball detection is called SSL-Vision. It is responsible for transforming images from all cameras to coordinates that are broadcast to the teams.
The game is controlled with the SSL-Game-Controller since 2019. It replaces the Refbox and acts as the interface between team computers, Auto-Referees and human referees.
The SSL-Refbox is a small UI that allows the operator to send referee commands to the teams. It was replaced by the SSL-Game-Controller since 2019.
The SSL provides several tools to deal with log files of SSL games. There is currently a C++ toolset and a Go toolset that can both record and play log files, among other actions.
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. It can also be used to live-stream the game to the internet (not video, only the 2D-field).
The simulator grSim was contributed to the SSL community by Parsian. It performs a physical simulation of SSL robots and publishes SSL-Vision network packages. It supports the Simulation Protocol.
The SSL measures metrics and statistics over past RoboCups. The code for the Match Statistics is maintained on GitHub.
SSL-Vision broadcasts detections unfiltered. Implementing a filter that merges data among cameras, calculates velocities, smooth data and does some predictions is one of the tasks that each team has to do. Starting with 2020, the SSL provides a standardized protocol for tracking implementations that does all or part of the tasks mentioned above. The autoRefs from TIGERs and ER-Force (see below) will implement this protocol initially. There is also a test-client and the protocol is implemented in the Go Log-Tools.
The Simulation Protocol defines a common way to communicate with a 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: grSim and ER-Force simulator.
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.
With the introduction of the SSL-Game-Controller, it is possible to have multiple active Auto-Referees running in parallel. Ideally, we would like to have at least three implementations. That way, a majority vote can be performed on critical rule violations, before the game is stopped. Teams are encouraged to contribute their own implementation.
There are two implementations that are currently under active development by teams and that are used since RoboCup 2018: ER-Force and TIGERs Mannheim.
Following implementations were not used in previous years:
- CM Dragons
- ssl-autonomous-refbox (one of the first prototypes)
The ER-Force simulator has been published by team ER-Force and is part of their open-sourced framework. It supports the Simulation Protocol.
Standard Network Parameters
|SSL-Game-Controller (GC)||Referee||UDP Multicast||22.214.171.124||10003|
|SSL-Vision Detections||SSL_WrapperPacket||UDP Multicast||126.96.36.199||10006|
|SSL-Vision Detections Legacy||SSL_WrapperPacket||UDP Multicast||188.8.131.52||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-Client Visualization||Visualization||UDP Multicast||184.108.40.206||10012|
|Robot Control Blue||RobotControl||UDP||Simulator||10301|
|Robot Control Yellow||RobotControl||UDP||Simulator||10302|
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_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)
- 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
- Visualization: Send shapes (circles and lines) to the vision-client