AutoRef Challenge
Goal of the Technical Challenge
This document is intended to describe the requirements of AutoRef software. The goal of this software is to help the human referee by automating decisions.
The Technical Challenge is conducted entirely before RoboCup 2016. Extended deadline for the AutoRef version that will be evaluated: March 14th 2016 (old deadline: Feb 28th 2016)
Setup and Requirements
The Autoref receives vision packets and sends its decisions to the traditional SSL Refbox which forwards these referee commands to the actual game. Both programs run on the same computer and communicate via network sockets.
The Refbox listens on Port 10007 for TCP connections communicating in the Refbox remote control format.
The goal is to provide software that:
- detects as many infringements as possible (Alertness)
- minimize the number of false decisions (Accuracy)
- detects as many different infringements as possible (Completeness)
- subordinates to any decision a human makes on the Refbox
- is able to send commands for AutoPlacement
- has the ability to log a game in order to evaluate decisions
- is able to run on Ubuntu 14.04, with clear build instructions.
Evaluation
Subsequently, the submitted software will be tested. Every team is encouraged to conduct the tests and share their results. Ideally, a video of the tests is provided.
- A correctly detected rule infringement adds 1 point to the score of this Technical Challenge.
- Every infringement will be tested multiple times according to the maximum number of points that is stated below.
- Wrong detection will subtract 2 points. Negative points in single infringements are possible.
- The total points are the sum of all points. If the sum is negative, the result is treated as 0 points in this Technical Challenge.
- The points will be normalized by the maximum number of points, which is 50. A team with 38 points will receive a 76% rating for this Technical challenge.
- Law 3: Number of Players (2)
- Law 12: Pushing / Substantial Contact (2)
- Law 12: Multiple Defender (2)
- Law 12: Attacker in Defense Area (2)
- Law 12: Icing / Kicking over midline and opponent goal line (2)
- Law 12: Ball Speed (2)
- Law 12: Robot Speed during Stop (2)
- Law 12: Maximum Dribbling Distance (2)
- Law 12: Touching the opponent goalkeeper (2)
- Law 12: Double Touch (2)
- Law 15: Throw-in (2)
- Law 16: Goal Kick (2)
- Law 17: Corner Kick (2)
- Law 13 – 17: Attacker not too close to the opponent’s penalty area when ball enters play (2)
- Law 13 – 17: Keeping the correct distance during opponent’s freekicks (2)
- Correct forwarding of commands to RefBox (10)
- Correct AutoPlacement commands (10)
Submission
So far, the following AutoRef software has been submitted: CMDragons ER-Force Tigers Mannheim
Autonomous Ball Placement
Goal of the Technical Challenge
The intention of this feature is to minimize the time needed to restart the game. This is achieved by placing the ball autonomously by robots (“AutoPlacement“).
The Technical Challenge is conducted on Thursday, after the games.
Procedure
AutoPlacement commands are issued by the AutoRef software. They are forwarded by the Refbox as game states BallPlacementYellow or BallPlacementBlue and include the requested ball position. Before and after those commands the game is in Stop state. AutoPlacement may be requested before any referee decision, e.g. before kickoffs, direct or indirect freekicks, or penalties.
During ball placement the same rules apply as in Stop state. The only exception is that robots of one team are allowed to approach the ball, according to the team that is mentioned in the BallPlacement state.
The ball is considered placed successfully if the following conditions apply:
- no more than 15 seconds passed since the placement command
- there is no robot within 50cm distance to the ball
- the ball is stationary
- the ball is at a position within 10cm radius from the requested position
This means that the robot has to move away from the ball once the team considers the ball placed correctly.
In the case of failure, the AutoRef will command the other team to place the ball. The team that receives the ball after the placement remains the same. If both teams fail to place the ball, Stop will be sent and the ball is placed by the human referee.
If a team has not implemented ball placement or fails AutoPlacement the third time in a half game, AutoPlacement is disabled for this team in the AutoRef software. In this case, the other team will receive the AutoPlacement request. If AutoPlacement is disable for both teams, the human ref places the ball at all times.
If the ball left the field surroundings (e.g. after a chip kick) or is not visible, the ball is always placed by the human ref.
Evaluation
The TC reserves the right to change the evaluation procedure.
Every team places the ball in the same situations. The number and kind of situations will be determined by the TC. The command will be issued and the teams have to place the ball in 15 seconds and move away from the ball.
A point will be awarded for every successfully placed ball. The points will be normalized and merged with the 11 vs. 11 Technical challenge.
11v11 Mixed Team Challenge
The 11 on 11 Technical challenge is a full match between two teams of up to 11 robots, each composed of robots from two different SSL teams (here referred to as sub-teams). Each robot must be controlled by its originating sub-team’s software. Sub-team pairings will rotate so that each team plays with all possible partner teams.
Communication
Communication between the two sub-teams of a team is allowed, according to the following specifications:
- Messages are sent as UDP packets encoded with Google protobuf to port 10012.
- Sub-teams communicate only a rough plan for each of their robots using the TeamPlan message specified by the multi_team_communication.proto Google protobuf:
package multi_team_comm;
//Protocol to communicate rough plans to other teammates
//Units are specified as follows:
//length - millimeters
//time - seconds
//angle - radians
//Plan of a list of robots
message TeamPlan {
repeated RobotPlan plans = 1;
}
//Plan of a single robot
message RobotPlan {
//ID of the robot from SSL vision
required uint32 robot_id = 1;
//Role that this robot is assuming
// 0 - no specified role
// 1 - goalie
// 2 - defense
// 3 - offense
optional int32 role = 2;
//Planned navigation target
optional Pose nav_target = 3;
//Planned shot target
optional Location shot_target = 4;
}
// Location message, in mm. The center of the field is specified as (0, 0).
// Positive x axis points to the opponent's goal
message Location {
required int32 x = 1;
required int32 y = 2;
}
message Pose {
//location of the robot
optional Location loc = 1;
//heading of the robot
optional float heading = 2;
};
Rules
Standard SSL rules apply to mixed team games with the following additions:
- A mixed team is formed from robots of two sub-teams.
- The maximum robot number is increased to 11 per mixed team. Each sub-team may have only a maximum of 5 players on the field at any time. Each sub-team may additionally provide a goalkeeper for one period. The goal keeper for the second period must not be provided by the same sub-team that provided the goalkeeper for the first period.
- Goals are only valid if robots from both of the two sub-teams forming a mixed team have touched the ball since the last stoppage of play.
- The robots must be able to submit to a speed limit imposed by the referee, subject to change during the game due to safety concerns. Teams will be allowed to touch their computers for up to a minute if the speed limit is changed; this time will be used exclusively to change the speed configuration as requested.
Field Setup
The size of the field will be approximately 13.4 meters by 9 meters, as shown below.
For the quad-size field setup, a total of eight cameras will be used, with two separate computers running ssl-vision. The coordinate system, and camera layout will be as shown in the following figure:
Computer 0 will run process images from cameras 0-3, and computer 1 will process images from cameras 4-7. On ssl-vision on computer 0, cameras 4-7 will be enumerated, but not running. On ssl-vision on computer 1, cameras 0-3 will be enumerated, but not running. Both computers will publish their data to the standard ssl-vision UDP multicast and port, 224.5.23.2:10006
The quad-size-field branch of SSL-Vision has been pre-configured to the coordinate system and camera assignment for the quad-size field.