Autoref

This repository contains the autoref implementation by ER-Force.

Table of Contents

• Compilation
• Docker
• Usage
• Features
• Advanced usage
  • User interface
  • Log recorder
  • Ball speed plotter
  • Implementing rules

Compilation

Follow the instructions in COMPILE.md. Building the framework separately is not neccesary!

Docker

A Docker image is provided at roboticserlangen/autoref.

The available tags are latest and commit-<hash>, where <hash> are the first 12 characters of the commit hash the image was built from.

The image can also be built locally using standard Docker commands.

$ docker build -t <sometag> .

When you run the image in a container, it exposes a VNC server on port 5900. Connect using any VNC client, e.g. TigerVNC.

Important the autoref will only start once the first VNC connection has been established. It will however continue running once the connection terminates.

Usage

In order to use the Autoref, run the previously built binary autoref.

The program receives the Protobuf data via network from SSL-Vision and the Refbox.

Referee decisions will be printed on the log textbox next to the playing field. The Autoref connects to a refbox running on the same machine and tries to use it in order to send referee commands to the game. You can disable refbox remote control in the "Configuration" menu.

In case you do not see a "Successfully loaded" message in the lower left box, you probably moved the autorefs directory after building.

When started with a command line argument, an Infoboard will be shown. This window is supposed to be placed on a big screen at the playing field. It shows the current game score as well as the autoref's decisions. It can be set to fullscreen mode by double-clicking inside the window.

The Autoref supports switching between different rule versions. These currently include:

• 2017 rules (default)
• 2018 rules for division A
• 2018 rules for division B The rule version can be changed by using the dock widget called 'Autoref'.

The Autoref allows settings parameters that are used detecting rules. These include for example the time robots have after stop was issued to slow down below 1.5 m/s. These parameters are stored in a configuration file at autoref/parameters. They can be edited by hand, even while the autoref is currently running. In this case the autoref will load the new parameters and use them immediately.

Features

Currently, the Autoref detects a number of fouls according to the Technical Challgenge 2016. It is able to autonomously stop the game, conduct ball placement and send free kick commands via the refbox.

The next step should be to exhaustively categorize the rules into infringements which can either be:

• currently detected by Autoref
• detectable but not yet implemented
• hard to detect/decide upon by a machine
• not detectable with the available data sources

Implementation/Testing

Game rules are implemented as Lua scripts and live in the 'autoref' directory. For details see below. If you want to test them with a simulated game, you can use the framework and load autoref/init.lua as a yellow strategy.

Another possibility to test the Autoref without an actual field is to use Michael Bleier's logplayer with a recorded game. Make sure to configure the vision port to 10002.

Feedback regarding the implementation of rules is highly welcome, especially in the form of pull requests!

Advanced usage

User interface

You can rotate and flip the field by right-clicking into it and select the appropriate action.

Log recorder

You can record games via the "Logging" menu or by pressing Ctrl-R. Log files will be saved in the directory from where the Autoref was started. These can be played with the logplayer, which is part of the framework.

Ball speed plotter

If you experience GUI freezes, try to enable "Plotter in extra window" in the configuration menu. This needs an application restart to take effect.

Implementing rules

Rules are implemented as lua tables. Each of them is located in a distinct file inside the autoref folder. They have then to be included in init.lua. A rule must define the following attributes:

• possibleRefStates: A table which indicates the referee states in which this foul can occur
• occuring: A function which either returns true or false. true means that the foul occurs and that the print and consequence attributes have to be set
• message: Describes the foul and possibly involved robots
• consequence: The referee command which follows the foul, e.g. "INDIRECT_FREE_BLUE". If it is not "STOP" or a card, freekickPosition has to be set
• freekickPosition: A vector with the position where the resulting free kick will be executed. This field is used for autonomous ball placement
• executingTeam: This should either be World.YellowColorStr or World.BlueColorStr It has to be set whenever freekickPosition is set