League Protocols and Communication

Just looking for the connection summary table?

“How do I connect to an SSL field?” is one of the first questions a software team member will ask. This page and its sub-pages document the process of connecting up: interfacing to the field, transport protocols, and data formats. If you aren’t already roughly familiar with the SSL field, checkout the field documentation to learn about the layout and network structure.

What does a SSL field provide?

RoboCup SSL fields provide two primary services to teams.

  1. Robot and Ball Localization (where are the robots and balls?)

  2. Game State (game half, timeouts, penalties, etc.)

This article first covers vision (field geometry, robot and ball localization), then game controller (game state). Conceptually, teams first want to receive robot positions. It does not matter what the game state is if you can’t see anything. Ensuring rules and game state compliance comes next.

How do I connect to an SSL Field?

  1. A team is never required to reply to the field. Teams can and do play full matches only receiving field vision and game controller data. The only input required from a team is it’s keeper number which is entered via the Game Controller Operator or the Remote Control, neither of which is provided by the team.

  2. Field data delivery is not guaranteed. It’s sent at a high rate so teams are expected to tolerate occasional dropped packets without re-transmission. Typically a re-transmission would take a few ms to execute, by which time the next data frame is probably ready anyway.

  3. All required field data is sent via multicast or broadcast. This allows the networking equipment to duplicate the data stream as many times as needed without the league software managing dozens of connections. It also means the team’s software does not need to know the addresses or hostnames of any specific field computers in order to connect. The team software simply needs to know the standard multicast addresses and ports of vision and game controller, and you’ll be able to connect to any standard field around the world. Specifically, these data streams are UDP /IPv4 +IGMP.

  4. All league packet data is defined by protocol buffers. You can find the definitions in the ssl-protocol-defs repository.

The actual protocols and data formats are documented in the sections below.

Vision

A detailed description of the vision protocol is provided in a dedicated article.

Vision Protocol

Game Controller

A detailed description of the game controller protocol is provided in a dedicated article.

Game Controller Protocol

Connection Summary Table

Below is the summary table of protocol addressing and ports. The GC address can be found by listening to the GC multicast group and reading the source address field of the IP layer, rather than knowing it statically.

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

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

SSL-Vision-Tracker

TrackerWrapperPacket

UDP Multicast

224.5.23.2

10010

Simulation Control

SimulationControl

UDP

Simulator

10300

Robot Control Blue

RobotControl

UDP

Simulator

10301

Robot Control Yellow

RobotControl

UDP

Simulator

10302

Additional Resources

  • Unicast

  • Multicast

  • Broadcast

  • TCP

  • UDP

  • IPv4

  • IGMPv4

Contents