diff --git a/2024/2019-game-log-event-labeling-rules.html b/2024/2019-game-log-event-labeling-rules.html new file mode 100644 index 0000000..dc8d390 --- /dev/null +++ b/2024/2019-game-log-event-labeling-rules.html @@ -0,0 +1,735 @@ + + + + + + + +Game Log Event Labeling Technical Challenge + + + + + + + +
+

Game Log Event Labeling Technical Challenge

+
+

Table of Contents

+ +
+ +
+

1 Goal of the Technical Challenge

+
+

+Label an SSL game log file for specific event types (with associated +metadata). Being able to detect important game events can be useful +for the decision making algorithms of the robots. Additionally, in +future years, being able to automatically label events with associated +metadata may lead to more explainable auto-ref decisions and +potentially auto commentary on a game. +

+
+
+ +
+

2 Event Types

+
+

+There are two event types: instantaneous and durations. Instantaneous +events have a label associated with a specific time in the +log. Duration events have a label associated with a range of time in +the log. +

+
+ +
+

2.1 Dribbling

+
+

+Detect when dribbling is occuring. This is an instantaneous +event. Dribbling is defined as one robot is touching the ball with the +dribbler. The decision is based on the same criteria used in the +excessive dribbling rule. +

+ +

+The following table summarizes the metadata associated with this event. +

+ + + + +++ ++ + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
IsDribbling?Is a robot dribbling in this frame?
Robot IDWhich robot is dribbling
Robot TeamWhich team is dribbling
+
+
+ +
+

2.2 Ball Possession

+
+

+Detect which robot/team is in control of the ball (if any). This is an +instantaneous event. +

+ +

+The following table summarizes the metadata associated with this +event. +

+ + + + +++ ++ + + + + + + + + + + + + + + + + + +
FieldDescription
StateOne of the following values: yellow-posses, blue-posses, none
Robot IDWhich robot is in possession (ignored if loose state is chosen)
+ +

+The state refers to who is in control of the ball. Either yellow, blue +or no team (none). The none state applies both when the ball is free +on the field, and when the ball is under contention from opposing team +robots. +

+
+
+ +
+

2.3 Passing

+
+

+Detect pass attempts. This is a duration event. The duration lasts +from when the ball leaves the passer and ends when the pass either +reaches the receiver or fails (out of bounds, intercepted, deflected). +

+ + + + +++ ++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
Start TimeWhen did the pass start
End TimeWhen did the pass end
Successful?Did the pass reach a receiver on the same team?
Passer IDWhich robot was the one who passed the ball
Passer TeamWhich team is passing
Receiver IDWhich robot was the intended recipient
+
+
+ +
+

2.4 Goal Shots

+
+

+Detect attempts at scoring a goal. This is a duration event. The +duration lasts from when the ball leaves the shooter and ends when the +ball either enters the goal, or is stopped/deflected by a robot. +

+ + + + +++ ++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
Start TimeWhen did the shot start
End TimeWhen did the shot end
Successful?Did the shot enter the goal?
Shooter IDWhich robot took the shot?
Shooter TeamWhich team did the shooter belong to
+
+
+
+ + +
+

3 Procedure

+
+

+During the competition, two of the game logs. These game logs will be +pre-processed by the tools described in the software section +below. Participants will receive a copy of the pre-processed game +logs. A ground truth label file for these logs will be created by the +TC. The TC will attempt to use game logs from games where none of the +participants in this challenge played. This is to prevent an advantage +for teams that may have saved additional information in their own log +files. However, as this cannot be guaranteed, we will require all +participants to label 2 different game logs, so at most a participant +in this challenge will have competed in a single game log. +

+ +

+Participants will produce their own set of labels for this game log +using the provided pre-processed data files. Teams will submit their +log files to the TC for scoring. The submitted label files will be +scored using the released scoring program. Participants will be ranked +by score, with higher scores being better. +

+ +

+Participants can use any approach that is automated to label the +data. In other words, you must label the data with an algorithm that +does not require human interaction. You cannot hand-label the data, +you cannot ask for human assistance, and you cannot correct the labels +produced by your software. +

+ +

+You may use any algorithm for labeling (rule-based, deep learning, +etc.). You can also use a non-causal labeling algorithm (i.e. your +labeling can look at future events to help label the current +event). Non-causal labeling may be useful in ambiguous situations. +

+ +

+The participants should label all frames with the appropriate +instantaneous event types and metadata. To ease scoring, the number of +duration events in the ground truth data will be provided to the +participants before they produce their labels. This is to avoid having +to do sequence alignment of the ground truth and participant label +files. +

+
+ +
+

3.1 File Formats and Utilities

+
+

+Figure 1 below shows a flow-chart of the +various utilities and file formats used in this challenge. The colors +of the boxes indicate who is responsible for running the +utility/producing the file. Clicking on this image will open a PDF +with clickable links to documentation for the different file formats +and software utilities. +

+ + +
+

file_format_flowchart.png +

+

Figure 1: File Formats and Utilities. See for PDF version with clickable links: clickable PDF version

+
+ +

+See also: 5 and 6 +

+
+
+
+ +
+

4 Scoring

+
+

+Scoring differs by event type. +

+
+ +
+

4.1 Instantaneous Event Scoring

+
+

+Each instantaneous event has a state label (e.g. dribbling or +not). For each frame that matches the ground truth labels, +1 +point. For each matching piece of metadata +0.5 points. +

+
+
+ +
+

4.2 Duration Event Scoring

+
+

+Duration events main score will be calculated using the Intersection +over Union (IoU) of the start and end times. The IoU is equal to the +area of overlap over the area of the union. +

+ +\begin{equation} +IoU = \frac{\text{area of overlap}}{\text{area of union}} +\end{equation} + +

+The IoU is guaranteed to be \(\le 1\). All IoU will be added +up. Additionally, each correct piece of metadata for an event will add ++0.5 points to the score. +

+
+
+ +
+

4.3 Final Score

+
+

+Each category will be ranked individually in order to make each label +category equally important for an overall win. Depending on the +ranking in that category, each participant will get an amount of +overall points. The amount of points is equal to \(\text{number of +participants} - \text{placement}\). So that first place has the most +points, and last place has the least. For example, with 7 participants +first place would get 6 points, second place 5, etc. +

+ +

+Each of the category points will then be totaled to determine an +overall winner. This way each event type accuracy is equally +important, as they all contribute to the final score evenly. +

+
+
+
+ + +
+

5 Software Tooling

+
+

+All software tooling is located in a separate repo: https://github.com/RoboCup-SSL/ssl-rust-tools +

+ +

+Below is an overview of the different parts, but refer to the +repository for more details on usage and file formats. +

+
+ +
+

5.1 Label Preprocessing

+
+

+We have provided a simple tool that will process an SSL game log +file. This will strip unnecessary messages as well as group messages into +discrete frames that can be labeled. +

+
+
+ +
+

5.2 Labeler

+
+

+We have provided a simple UI for creating label files. This can be +used to manually label training data for your algorithms. This will +also be the tool used by the TC to produce the ground truth labels. +

+
+
+ +
+

5.3 Scoring Program

+
+

+We have provided a scoring tool. It will take in two different label +files, one ground truth and one to be scored, and produce a score for +each category described above. +

+
+
+
+ +
+

6 File Format

+
+

+There are two formats: a data file format and a label file format. +

+ +

+The data file is produced by the log preprocessor tool. The label file +is the list of labels for each of the frames in the data file. Both +use protobuf files and are designed to support fast random access. +

+ +

+Please refer to the software repo for more information: https://github.com/RoboCup-SSL/ssl-rust-tools +

+
+
+
+
+

Created: 2019-06-26 Wed 08:04

+

Validate

+
+ + diff --git a/2024/2019-game-log-event-labeling-rules.pdf b/2024/2019-game-log-event-labeling-rules.pdf new file mode 100644 index 0000000..9c282fb Binary files /dev/null and b/2024/2019-game-log-event-labeling-rules.pdf differ diff --git a/2024/2019-ssl-vision-blackout-rules.html b/2024/2019-ssl-vision-blackout-rules.html new file mode 100644 index 0000000..97d2199 --- /dev/null +++ b/2024/2019-ssl-vision-blackout-rules.html @@ -0,0 +1,466 @@ + + + + + + + +SSL-Vision Blackout Technical Challenge + + + + + +
+

SSL-Vision Blackout Technical Challenge

+
+

Table of Contents

+ +
+ +
+

1 Goal of the Technical Challenge

+
+

+The goal of this challenge is to intercept and manipulate a ball +without access to the global ssl-vision position estimates. While the +competition will still use the standard SSL vision software, this +challenge is intended to encourage teams to work on the problem of +onboard sensing and control. We believe teams capable of onboard +control and sensing will have a significant advantage over teams that +rely solely on the SSL vision position estimates. +

+
+
+ +
+

2 Procedure

+
+

+There are two main stages to this challenge. In each stage, there will +be a single robot from the team undergoing the challenge. There will +also be a single ball. The starting conditions and scoring will vary +by stage. +

+ +

+Teams may still remotely control their robots as they do during normal +competition, but their software will not receive data from the SSL +vision software. The SSL vision software will still be running, but +the vision network will be isolated from the team undergoing the +challenge. This way automatic referee programs may still be run to +verify properties like ball speeds, out of bounds, etc. Teams will +still receive start, stop and halt ref commands. +

+ +

+All robot hardware requirements apply to this challenge EXCEPT the +height restrictions and the pattern markings. Participant robots may +be taller than the rules dictate. Participants also do not need a +fully visible butterfly pattern on top. However, other hardware +conditions (e.g. the width of the robot, etc.) still apply. As normal +the robot may not have orange markings that can be confused for the +ball. Participants may use any kind of onboard sensors to detect the +ball. This means, for example, you can stick a camera on top of the +robot with no need to package everything inside the normal robot +dimensions. +

+
+ +
+

2.1 Grab a stationary ball

+
+

+The robot will be placed in a random location on the field at least 2m +from all edges. A ball will be placed within a 1m x 1m box around the +robot at a randomly selected location. The goal is for the robot to +find the ball and touch the ball with it's dribbler. Each team will +have 10 seconds to complete the task. The procedure will be repeated 3 +times and scores will be totaled. +

+ +

+The robot may move anywhere within the field boundaries. If either the +robot or the ball leave the field lines then the run is ended. +

+ +

+Figure 1 shows an example for the initial state of a +run. +

+ +

+Before each run the robot will begin in the halt state. A stop command +will be issued to ready the robot, but the robot should not yet +move. The run begins with a force start command at which point the +timer starts and the robot may attempt to complete the task. +

+ + +
+

stage1.png +

+

Figure 1: Example starting state for stage 1. The actual position on the field may vary. Ball may be placed anywhere in the red dashed box. This robot will be at least 2 meters from the edge of the field. The robot will begin with an arbitrary orientation with respect to the field.

+
+
+ +
+

2.1.1 Scoring

+
+

+ +

+ +
+
touching the ball with any part of the robot
+1
+
touching the ball with the dribbler
+1
+
robot stopped with ball touching dribbler at the end of the run
+1
+
+
+
+
+ +
+

2.2 Intercept a moving ball

+
+

+The goal is to intercept and gain control of a ball rolling towards +the robot. +

+ +

+The robot will be placed at a random location on the field at least 2m +from all edges. The robot will begin by facing towards the ball's +starting location. +

+ +

+The ball will be kicked by a robot at a speed under 6.5 m/s. The ball +will start it's trajectory between 3 and 5 meters from the robot. The +ball's path will pass within 0.5m of the robot's starting position. If +the ball trajectory fails to meet these conditions the team may choose +to repeat the run, or keep the score they managed to achieve. +

+ +

+Figure 2 shows an example starting state for stage 2. +

+ +

+Figure 3 shows an example of a good ball trajectory +that passes within the specified distance of the robot's starting +point. Figure 4 shows an example of a bad ball +trajectory, where the ball does not pass within the specified distance +of the robot's starting point. +

+ +

+If either the robot or the ball leave the field the run will be +stopped. The run will end after 10 seconds of time. +

+ +

+The procedure will be repeated 3 times with scores totaled. +

+ +

+Before each run the robot will begin in the halt state. A stop command +will be issued to ready the robot, but the robot should not yet +move. The run begins with a force start command, at which point the +ball should begin moving and the robot may attempt to complete the +task. +

+ + +
+

stage2_starting_state.png +

+

Figure 2: Example starting state for stage 2. Actual position on the field may vary.

+
+ + +
+

stage2_valid_trajectory.png +

+

Figure 3: Example of a good trajectory for stage 2. The ball's straight line path passes within 0.5m of the robot's starting position marked by the red dashed circle

+
+ + +
+

stage2_invalid_trajectory.png +

+

Figure 4: Example of a bad trajectory for stage 2. The ball's straight line path does not pass within 0.5m of the robot's starting position marked by the red dashed circle

+
+
+ + +
+

2.2.1 Scoring

+
+

+ +

+ +
+
touching the ball with any part of the robot
+1
+
touching the ball with the dribbler
+1
+
robot stopped with ball touching the dribbler at the end of the run
+1
+
+
+
+
+
+ +
+

3 Scoring

+
+

+The totals from each stage (2.1.1, 2.2.1) will be +added to determine the winner. If there is a tie in terms of points, +then the team which took the least amount of time on average, for runs +in which the ball was touched, will win. +

+
+
+
+
+

Created: 2019-01-03 Thu 16:14

+

Validate

+
+ + diff --git a/2024/2019-ssl-vision-blackout-rules.pdf b/2024/2019-ssl-vision-blackout-rules.pdf new file mode 100644 index 0000000..53c1242 Binary files /dev/null and b/2024/2019-ssl-vision-blackout-rules.pdf differ diff --git a/2024/2021-ssl-ball-placement-rules.html b/2024/2021-ssl-ball-placement-rules.html new file mode 100644 index 0000000..06aff0c --- /dev/null +++ b/2024/2021-ssl-ball-placement-rules.html @@ -0,0 +1,850 @@ + + + + + + + + +RoboCup 2021 SSL Ball Placement Technical Challenge Rules + + + + + + +
+
+
+ +
+ + + + + +
+ + +References to the male gender in the rules with respect to referees, team +members, officials, etc. are for simplification and apply to both males and +females. +
+
+
+
+
+

Goals of the Technical Challenge

+
+
+

Given the goal of preparing Division B teams to participate in Division A, this +technical challenge aims to incentive Division B teams to develop one of the +skills needed to play a match in Division A. In this case, the challenge is to +autonomously place the ball using the robots ("AutoPlacement").

+
+
+

Participation Requirements

+
+

All Division B teams are eligible and must participate in this challenge.

+
+
+

Also, this challenge must be performed with real robots, i.e., not using the +simulator. In case of any problems regarding access to your labs, please +contact the TC/OC.

+
+
+
+
+
+

Procedure

+
+
+

Similarly to the hardware challenges, the Ball Placement Technical Challenge +will also be executed using the +SSL Hardware Challenge Tool. +This challenge is the number 5 in the tool. Therefore, the procedure is as +follows:

+
+
+
    +
  • +

    The Game Controller, SSL Vision and at least one Auto Referee must be already +running

    +
  • +
  • +

    Make sure the game state is First Half or Second Half

    +
  • +
  • +

    The SSL Hardware Challenge Tool must be executed with the corresponding +json file and challenge number (5)

    +
  • +
  • +

    The ball must be placed in the indicated position

    +
  • +
  • +

    The robot(s) must be placed on the middle line of the field

    +
  • +
  • +

    When all positions are correct, the challenge will start when the user +presses Enter

    +
  • +
  • +

    A Stop command will be issued for 2 seconds

    +
  • +
  • +

    Then, the AutoPlacement command will be issued

    +
  • +
+
+
+

The AutoPlacement command includes a game state, which will be +BallPlacementBlue, and the requested ball position. Before and after those +commands the game is in Stop state, therefore, the robots are allowed to +position themselves wherever they want before the placement starts, while +following all Stop state rules.

+
+
+

The rules for the AutoPlacement can be found in the +rule book. +Teams should provide a video stream along with the screen share of the GC, +which prints the placement timings. The logs of the challenge can also be +recorded through the SSL Log tools and sent to the TC, in case of any technical +issues.

+
+
+

The starting and desired positions of the ball can be seen in the Appendix at +the end of the document. The positions are formated in a json file similar to +the hardware challenges. The "ball" is the starting position, and the +"ball_placement" is the position where the ball must be placed.

+
+
+

In scenarios 6 and 7, the ball must be placed with an Y value, such that +the robot cannot get between the ball and the wall. Since teams might have +different extra space between the field boundaries and the wall, the json file +can be edited to match this criteria.

+
+
+

Teams are allowed to use up to 6 robots.

+
+
+
+
+

Evaluation

+
+
+

Every team places the ball in the same scenarios, and there are 3 tries per +scenario.

+
+
+

In total, there will be 8 scenarios in this challenge. The order of the +scenarios will be chosen randomly, just like the hardware challenges.

+
+
+

A point will be awarded for every successfully placed ball. In case of ties, +the team that was capable of placing the balls in the least amount of time +wins.

+
+
+

The TC reserves the right to change the evaluation procedure.

+
+
+
+
+

Appendix A: Scenarios for Ball Placement

+
+
+

Scenario 1

+
+
+
{
+    "ball": {
+        "pos": [
+            -200,
+            -1800,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -200,
+            1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 2

+
+
+
{
+    "ball": {
+        "pos": [
+            -2200,
+            -1500,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            0,
+            0,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 3

+
+
+
{
+    "ball": {
+        "pos": [
+            -1000,
+            -1500,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -200,
+            -1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 4

+
+
+
{
+    "ball": {
+        "pos": [
+            -2900,
+            -1900,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -200,
+            1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 5

+
+
+
{
+    "ball": {
+        "pos": [
+            -500,
+            0,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -2800,
+            1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 6

+
+
+
{
+    "ball": {
+        "pos": [
+            -660,
+            -2140,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -2200,
+            -1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 7

+
+
+
{
+    "ball": {
+        "pos": [
+            -660,
+            2140,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -2200,
+            1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 8

+
+
+
{
+    "ball": {
+        "pos": [
+            -3050,
+            -100,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -500,
+            1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+
+
+ + + + + \ No newline at end of file diff --git a/2024/2021-ssl-ball-placement-rules.pdf b/2024/2021-ssl-ball-placement-rules.pdf new file mode 100644 index 0000000..e9076aa Binary files /dev/null and b/2024/2021-ssl-ball-placement-rules.pdf differ diff --git a/2024/2021-ssl-vision-blackout-rules.html b/2024/2021-ssl-vision-blackout-rules.html new file mode 100644 index 0000000..0458689 --- /dev/null +++ b/2024/2021-ssl-vision-blackout-rules.html @@ -0,0 +1,940 @@ + + + + + + + + +RoboCup 2021 SSL Vision Blackout Technical Challenge Rules + + + + + +
+
+
+ +
+ + + + + +
+ + +References to the male gender in the rules with respect to referees, team members, officials, etc. are for simplification and apply to both males and females. +
+
+
+
+
+

Goals of the Technical Challenge

+
+
+

The goal of this technical challenge is to incentivize teams to +explore local sensing and processing rather than the typical SSL +approach of an off-board computer and a global set of cameras sensing +the environment. While the main league still uses the standard SSL +vision software with overhead cameras, there is desire to reduce the +reliance on this vision system. We believe that not only will more +distributed sensing and processing on robots help advance research in +this league, it will provide a benefit to teams who take this +approach.

+
+
+

Overall, this technical challenge will focus on demonstrating standard +SSL soccer skills (e.g. locomotion and ball manipulation) in without +the ssl-vision software running. The challenge is split into multiple +stages designed to have different levels of difficulty, with each +stage building on the skills of the prior.

+
+
+

Participation Requirements

+
+

Anyone participating in SSL RoboCup is eligible to participate in this +challenge. Anyone participating must publish their approach to solving +this technical challenege after the competition has concluded. The +goal of forcing publication is that other participants in the league +and the wider research community can learn and benefit from those that +participated.

+
+
+
+

Overview of Competition Stages

+
+

The competition will consist of four stages:

+
+
+
    +
  1. +

    Grab a stationary ball somewhere on the field

    +
  2. +
  3. +

    Score with the ball on an empty goal

    +
  4. +
  5. +

    Score with the ball on a statically defended goal

    +
  6. +
  7. +

    Move the robot to specific coordinates

    +
  8. +
+
+
+

Stage 1 is designed to demonstrate basic sensing and locomotion +capabilities of each participating team.

+
+
+

Stage 2 is designed to demonstrate similar skills to stage 1 plus the +ability to localize and aim at a known target on the field.

+
+
+

Stage 3 builds on stage 2 where now the participant’s robot must +detect which portion of the goal is unblocked when aiming and +shooting.

+
+
+

Stage 4 demonstrates ball manipulation skills and strong localization +abilities without the use of the global vision system. Stage 4 has +been removed for the remote competition, as each team may have a different field +setup with different coordinate systems.

+
+
+

We believe that teams who can complete even a single one of these +skills without the vision system information will have an advantage in +the main competition over those teams who rely solely on the global +vision system.

+
+
+

The following sections describe the hardware requirements, and +procedures of each stage. The final chapter describes overall scoring +that will be used to determine the winner.

+
+
+
+
+
+

Hardware/Software Requirements

+
+
+

Robot Hardware

+
+

While we encourage participants to attempt the use of their blackout +solutions during main competition to help deal with noise and dropouts +in the global vision system, we recognize that integration into the +main competition robots is a difficult task. For these reasons, the +hardware restrictions are relaxed for this technical challenge.

+
+
+

Teams may still remotely control their robots during normal +competition, however, we encourage teams to experiment with onboard +processing and autonomy. Regardless of where the control software +executes, team will not receive data from the SSL vision +software. Teams will still receive start, stop, and halt ref commands +which will be used to initiate and stop trials of each stage.

+
+
+

All robot hardware requirements apply to this challenge EXCEPT the height +restrictions and the pattern markings. Participant robots may be taller than the +rules dictate. The vision pattern on-top of the robot MUST be covered or +removed to guarantee that ssl-vision is not being utilized. However, other rules +such as maximum speed, kick power, ball manipulation strategies, etc. must still +be observed.

+
+
+

There are no restrictions on onboard sensor types. External sensors +not attached to the robot are not allowed for this competition. We +encourage teams to be creative in their choice of sensors and their +strategies for completing each stage of the challenge. There is no +restriction on processing power or where the processing takes +place. However, keep in mind that bandwidth at competition is limited, +so solutions requiring streaming large amounts of data wirelessly will +likely not work.

+
+
+
+

Field Setup

+
+

The technical challenge has the same requirements for the remote field as the +2021 hardware challenges. The field must be 4x3m or larger. The field will need +to have a goal of 0.7m wide, just as in the hardware challenges. The field will +need to have a penalty area of 0.8x2m in size just as in the hardware +challenges. Additionally participants will require a golf ball and an additional +robot that can act as a static defender for stage 3.

+
+
+

Participants should NOT modify the goal or field to aid in navigation or +recognition of objects. This includes things like visual fiduciary markers, IR +reflectors, non-standard color splotches, etc. Teams should strive to have as +close to a regulation Division B field as possible. The TC members reserve the +right to ask teams to sweep the camera to show that additional markers have not +been added off-frame and may require certain objects/signs/etc. to be covered up +or removed during the runs.

+
+
+
+
+
+

Competition Procedure

+
+
+

Each stage will consist of 3 independent trial runs by each +participant. This is to account for any random effects as well as to +allow participants to adjust in-between their trials. Scoring will be +based on overall performance among the trials for each stage, so it is +important for teams to perform consistently well.

+
+
+

While the particular starting configurations of the ball and the robot will be +different between stages and trial to trial, the TC member running the +competition stage will strive to make the starting conditions similar between +each participant for that trial run. This is further complicated by each team +having a remote setup. The TC running the competition will pre-determine +starting positions of ball, robot and static defender for each independent trial +ahead of the competition. These positions will be specified relative to the +common landmark of the goal. The TC will send/show a diagram with these +positions to the team during their assigned technical challenge slot and ensure +that the robot, ball and static defender are at the approximate positions before +the run begins.

+
+
+

Each participating team will have a slot assigned to them to complete the +challenge. The trials will be done live on video, just like the hardware +challenges teams need to provide a camera that covers the whole field. +Participants will do each stage and every trial back-to-back during their +assigned time. Teams will have a maximum of 2 hours from the start of their slot +to complete all of the trials under the supervision of the TC. Once the two +hours are finished, any unfinished trials or stages will receive a score of +zero. If teams have technical issues, they can resolve them in between trials, +keeping in mind the overall time that all trials must be completed in.

+
+
+

Challenges will be executed on a field of at least 4x3m with a goal size of +0.7m. See the hardware section for more details on the field setup.

+
+
+

Each run will start with a halt command. Just before the start, a stop command +will be given, but the robot should not move during the stop command. This is +just to allow teams a few seconds to initialize any internal state. The run will +officially start when a force start command is sent. This will start the timer +and at this point the robot may begin moving.

+
+
+

Stage 1: Grab a Stationary Ball

+
+

This stage is designed to be the easiest and demonstrate basic sensing +and control capabilities. The robot will need to detect a ball on the +field, navigate to it, and place it on its dribbler. Partial points +will be awarded, and time will be used for tie-breaking.

+
+
+

For each trial a random robot starting location/orientation and a random ball +starting position will have been pre-generated by the TC. Just before the trial +the TC will show the participant a diagram for the starting configuration and +the participant will configure the field as specified. Both the robot and the +ball will start stationary. There are no restrictions on the starting +configuration other than that both robot and ball will be somewhere on the +field.

+
+
+

Before each run the robot will begin in the halt state. A stop command +will be issued to ready the robot, but the robot should not yet +move. The run begins with a force start command at which point the +timer starts and the robot may attempt to complete the task.

+
+
+

The robot may move anywhere on the field within the walls. The ball +may similarly move anywhere on the field throughout the time. Each +trial will last a maximum of one minute.

+
+
+

Scoring

+
+
    +
  • +

    Touching the ball with any part of the robot — +1

    +
  • +
  • +

    Touching the ball with the dribbler — +1

    +
  • +
  • +

    Robot stopped with ball touching dribbler at the end of the run :: +1

    +
  • +
+
+
+

In the event of a tie between participants for this trial shorter +times will be used to determine ordering.

+
+
+
+

Differences to 2019 SSL Vision Blackout Challenge

+
+

Unlike the 2019 challenge, there are no restrictions placed on the +relative distances of the robot’s start configuration and the +ball. The total time to complete each trial has also been +increased. Finally, the ball and robot may go out of bounds on the +field without ending the trial.

+
+
+
+
+

Stage 2: Scoring on an Empty Goal

+
+

This stage is designed to build on stage 1, requiring that participant +robot’s can also detect/localize on a goal without the SSL vision +software. Like stage 1, the robot will need to detect a ball, move to +it and manipulate it. The robot must put the ball into the goal to +receive maximum points in the trial.

+
+
+

The robot and ball will start the same as in Stage 1. The TC will have +pre-generated starting positions for this stage and just before each trial show +the starting configuration diagram to the participant. The participants will +attempt to replicate this starting configuration on their field setup. In this +stage, the goal is for the robot to score on an empty goal. If the team has +multiple goals on their field, only the goal used for the initial configuration +reference point will count as scoring. While scoring the robot may not enter +the defense zone. Unlike regular gameplay the ball does not need to stay on the +ground in order for the goal to be counted.

+
+
+

Before each run the robot will begin in the halt state. A stop command +will be issued to ready the robot, but the robot should not yet +move. The run begins with a force start command at which point the +timer starts and the robot may attempt to complete the task. Each +trial will last a maximum of one minute. The trial will stop when the +goal has occurred or time has elapsed.

+
+
+

Scoring

+
+
    +
  • +

    Touching the ball with any part of the robot — +1

    +
  • +
  • +

    Touching the ball with the dribbler — +1

    +
  • +
  • +

    Ball entered defense zone — +1

    +
  • +
  • +

    Ball entered goal — +1

    +
  • +
  • +

    Robot entered defense zone — -1

    +
  • +
+
+
+
+
+

Stage 3: Scoring on a Statically Defended Goal

+
+

This stage is a more complex version of stage 2. The goal is the same, +but now there will be a static obstacle placed somewhere inside the +defense zone. Unlike stage 2, a specific goal will be designated so +that robots can attempt to score on the statically defended goal.

+
+
+

The obstacle will be another robot provided by the participating team. The goal +is to be able to use local sensing to detect opponent robots in a game like +scenario.

+
+
+

The robot and ball will start the same as in Stage 1 and Stage +2. Unlike Stage 2, robots must only score in the designated goal. The target +goal will be on the same half that the robot starts on. While scoring the robot +may not enter the defense zone. This time the ball must enter the goal via a +flat kick to prevent kicking over the obstacle. Just as in the previous stages +the TC will have pre-generated starting configurations. These configurations +will be given to the team just before starting the trial so that the team can +configure their field to match as closely as possible.

+
+
+

Scoring

+
+
    +
  • +

    Touching the ball with any part of the robot — +1

    +
  • +
  • +

    Touching the ball with the dribbler — +1

    +
  • +
  • +

    Ball entered defense zone — +1

    +
  • +
  • +

    Ball entered goal — +1

    +
  • +
  • +

    Robot entered defense zone — -1

    +
  • +
+
+
+
+
+
+
+

Overall Scoring

+
+
+

As each stage is quite different in terms of scoring, in order to +determine an overall winner, each stage will be ranked individually by +total score. Depending on ranking in the category, each participant +will get an amount of overall points. The amount of points is equal to +the number of participants - placement in that stage. For example, +with 7 participants, first place gets 6 points, second place gets 5, +etc.

+
+
+

Each of the stage points will then be totaled to determine an overall +winner. Therefore, performance in all stages is considered equal in +the final scoring.

+
+
+

In the event of a tie, the team with the lowest total time across all +the stages will win.

+
+
+
+
+

Appendix A: Stage Scenarios

+
+
+

The scenarios for each stage can be seen below, the team has 3 tries in each +scenario and there are 3 scenarios per stage, the first one being the easiest, +and the last one being the hardest.

+
+
+

Stage 1

+
+
+Interactive +
+
+
+
+Interactive +
+
+
+
+Interactive +
+
+
+
+

Stage 2

+
+
+Interactive +
+
+
+
+Interactive +
+
+
+
+Interactive +
+
+
+
+

Stage 3

+
+
+Interactive +
+
+
+
+Interactive +
+
+
+
+Interactive +
+
+
+
+
+
+ + + \ No newline at end of file diff --git a/2024/2021-ssl-vision-blackout-rules.pdf b/2024/2021-ssl-vision-blackout-rules.pdf new file mode 100644 index 0000000..4f204a7 Binary files /dev/null and b/2024/2021-ssl-vision-blackout-rules.pdf differ diff --git a/2024/2022-ssl-ball-placement-rules.html b/2024/2022-ssl-ball-placement-rules.html new file mode 100644 index 0000000..4134ecd --- /dev/null +++ b/2024/2022-ssl-ball-placement-rules.html @@ -0,0 +1,851 @@ + + + + + + + + +RoboCup 2022 SSL Ball Placement Technical Challenge Rules + + + + + + +
+
+
+ +
+ + + + + +
+ + +References to the male gender in the rules with respect to referees, team +members, officials, etc. are for simplification and apply to both males and +females. +
+
+
+
+
+

Goals of the Technical Challenge

+
+
+

Given the goal of preparing Division B teams to participate in Division A, this +technical challenge aims to incentive Division B teams to develop one of the +skills needed to play a match in Division A. In this case, the challenge is to +autonomously place the ball using the robots ("AutoPlacement").

+
+
+

Participation Requirements

+
+

All Division B teams are eligible and must participate in this challenge.

+
+
+

Also, this challenge must be performed with real robots, i.e., not using the +simulator. In case of any problems regarding access to your labs, please +contact the TC/OC.

+
+
+
+
+
+

Procedure

+
+
+

Similarly to the hardware challenges, the Ball Placement Technical Challenge +will also be executed using the +SSL Hardware Challenge Tool. +This challenge is the number 5 in the tool. Therefore, the procedure is as +follows:

+
+
+
    +
  • +

    The Game Controller, SSL Vision and at least one Auto Referee must be already +running

    +
  • +
  • +

    Make sure the game state is First Half or Second Half

    +
  • +
  • +

    The SSL Hardware Challenge Tool must be executed with the corresponding +json file and challenge number (5)

    +
  • +
  • +

    The ball must be placed in the indicated position

    +
  • +
  • +

    The robot(s) must be placed on the middle line of the field

    +
  • +
  • +

    When all positions are correct, the challenge will start when the user +presses Enter

    +
  • +
  • +

    A Stop command will be issued for 2 seconds

    +
  • +
  • +

    Then, the AutoPlacement command will be issued

    +
  • +
+
+
+

The AutoPlacement command includes a game state, which will be +BallPlacementBlue, and the requested ball position. Before and after those +commands the game is in Stop state, therefore, the robots are allowed to +position themselves wherever they want before the placement starts, while +following all Stop state rules.

+
+
+

The rules for the AutoPlacement can be found in the +rule book. +Teams should provide a video stream along with the screen share of the GC, +which prints the placement timings. The logs of the challenge can also be +recorded through the SSL Log tools and sent to the TC, in case of any technical +issues.

+
+
+

The starting and desired positions of the ball can be seen in the Appendix at +the end of the document. The positions are formated in a json file similar to +the hardware challenges. The "ball" is the starting position, and the +"ball_placement" is the position where the ball must be placed.

+
+
+

In scenarios 6 and 7, the ball must be placed with an Y value, such that +the robot cannot get between the ball and the wall. Since teams might have +different extra space between the field boundaries and the wall, the json file +can be edited to match this criteria.

+
+
+

Teams are allowed to use up to 6 robots.

+
+
+
+
+

Evaluation

+
+
+

Every team places the ball in the same scenarios, and there are 3 tries per +scenario.

+
+
+

In total, there will be 8 scenarios in this challenge. The order of the +scenarios will be chosen randomly, just like the hardware challenges.

+
+
+

A point will be awarded for every successfully placed ball. In case of ties, +the team that was capable of placing the balls in the least amount of time +wins.

+
+
+

The TC reserves the right to change the evaluation procedure.

+
+
+
+
+

Appendix A: Scenarios for Ball Placement

+
+
+

Scenario 1

+
+
+
{
+    "ball": {
+        "pos": [
+            -200,
+            -1800,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -200,
+            1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 2

+
+
+
{
+    "ball": {
+        "pos": [
+            -2200,
+            -1500,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            0,
+            0,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 3

+
+
+
{
+    "ball": {
+        "pos": [
+            -1000,
+            -1500,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -200,
+            -1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 4

+
+
+
{
+    "ball": {
+        "pos": [
+            -2900,
+            -1900,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -200,
+            1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 5

+
+
+
{
+    "ball": {
+        "pos": [
+            -500,
+            0,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -2800,
+            1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 6

+
+
+
{
+    "ball": {
+        "pos": [
+            -660,
+            -2140,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -2200,
+            -1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 7

+
+
+
{
+    "ball": {
+        "pos": [
+            -660,
+            2140,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -2200,
+            1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+

Scenario 8

+
+
+
{
+    "ball": {
+        "pos": [
+            -3050,
+            -100,
+            0
+        ]
+    },
+    "ball_placement": {
+        "pos": [
+            -500,
+            1800,
+            0
+        ]
+    }
+}
+
+
+
+
+Interactive +
+
+
+
+
+
+ + + + + \ No newline at end of file diff --git a/2024/2022-ssl-ball-placement-rules.pdf b/2024/2022-ssl-ball-placement-rules.pdf new file mode 100644 index 0000000..027f5bd Binary files /dev/null and b/2024/2022-ssl-ball-placement-rules.pdf differ diff --git a/2024/2022-ssl-dribble-rules.html b/2024/2022-ssl-dribble-rules.html new file mode 100644 index 0000000..541743b --- /dev/null +++ b/2024/2022-ssl-dribble-rules.html @@ -0,0 +1,634 @@ + + + + + + + + +RoboCup 2022 SSL Dribbling Technical Challenge Rules + + + + + + +
+
+
+ +
+ + + + + +
+ + +References to the male gender in the rules with respect to referees, team +members, officials, etc. are for simplification and apply to both males and +females. +
+
+
+
+
+

Goals of the Technical Challenge

+
+
+

Last year we hosted hardware challenges as a way to promote the development of hardware +even though there would be no physical competition. However, we noticed that many teams had +trouble performing the dribbling challenge. Because of that, we decided to keep it as a +technical challenge this year, giving teams more opportunity to work on this.

+
+
+
+
+

Procedure

+
+
+

Each team will be given a 20 minute slot to complete this challenge, so please do set up before it begins. When the challenge begins, teams are free to start a trial when they are ready, informing the supervisor that they will start. The supervisor will make sure that all robots are in position according to the Appendix A. If there are no issues, a FORCE_START command will be given and the timer will start. There is no time limit for one trial, however, if the robot breaks any of the rules, the trial will be considered a failure. The team may also opt to stop the trial. The supervisor will keep score of the gates passed. Each team can do up to three trials. However, if 30 minutes has passed since the start of the challenge and not all trials have been done, those that have not been done will be considered failures. If teams want to modify their code between trials, they are allowed to. During trials teams are not allowed to touch the computer.

+
+
+

Performance of a trial

+
+

There are six gates defined in this challenge. A gate is the line between two robots. For a robot to successfully pass a gate, it must cross this line.

+
+
+

The gates are:

+
+
+
    +
  • +

    Gate A - between robot 0 and 1

    +
  • +
  • +

    Gate B - between robot 1 and 2

    +
  • +
  • +

    Gate C - between robot 2 and 3

    +
  • +
  • +

    Gate D - between robot 3 and 0

    +
  • +
  • +

    Gate E - between robot 0 and 4

    +
  • +
  • +

    Gate F - between robot 5 and 6

    +
  • +
+
+
+

The ball starts inside the bots 0-1-2-3 shape, the (blue) robot at the corner.

+
+
+

The robot should then get the ball and do the following procedure in this order:

+
+
+
    +
  1. +

    Pass with the ball gate A twice

    +
  2. +
  3. +

    Pass with the ball gate B twice

    +
  4. +
  5. +

    Pass with the ball gate C twice

    +
  6. +
  7. +

    Pass with the ball gate D once

    +
  8. +
  9. +

    Pass with the ball gate E once

    +
  10. +
  11. +

    Pass with the ball gate F once

    +
  12. +
+
+
+

The robot should finalize the challenge placing the ball around one meter away from robot 6.

+
+
+

See Appendix A for the visualization of the field before the start of the challenge.

+
+
+

Observation: Some gates must be passed twice. It is up to the teams to decide how to perform this, but the full body of the robot and the ball must +cross the gate line twice for it to be considered successful.

+
+
+
+

Rules

+
+
    +
  • +

    The standard match rules do not apply. This means:

    +
    +
      +
    • +

      The robot is allowed to dribble the ball for more than 1m in this challenge.

      +
    • +
    • +

      The ball can not go out of the field.

      +
    • +
    +
    +
  • +
  • +

    If the robot loses the ball, the robot is allowed to retrieve the ball again and continue. The time will not be paused.

    +
  • +
  • +

    The robot is not allowed to touch the obstacles, else the trial is considered failed.

    +
  • +
+
+
+
+
+
+

Evaluation

+
+
+

The trail with the most amount of gates passed will be taken for overall scoring per team. If there is a tie, the fastest one will be used.

+
+
+

The same applies for the overall challenge: the trail with the most amount of gates passed will win the challenge. If there is a tie, the fastest one will be used.

+
+
+

The TC reserves the right to change the evaluation procedure.

+
+
+
+
+

Appendix A: challenge visualization

+
+
+
+dribble +
+
+
+
+
+ + + + + \ No newline at end of file diff --git a/2024/2022-ssl-dribble-rules.pdf b/2024/2022-ssl-dribble-rules.pdf new file mode 100644 index 0000000..d210212 Binary files /dev/null and b/2024/2022-ssl-dribble-rules.pdf differ diff --git a/2024/2022-ssl-vision-blackout-rules.html b/2024/2022-ssl-vision-blackout-rules.html new file mode 100644 index 0000000..4efc7f5 --- /dev/null +++ b/2024/2022-ssl-vision-blackout-rules.html @@ -0,0 +1,932 @@ + + + + + + + + +RoboCup 2022 SSL Vision Blackout Technical Challenge Rules + + + + + +
+
+
+ +
+ + + + + +
+ + +References to the male gender in the rules with respect to referees, team members, officials, etc. are for simplification and apply to both males and females. +
+
+
+
+
+

Goals of the Technical Challenge

+
+
+

The goal of this technical challenge is to incentivize teams to +explore local sensing and processing rather than the typical SSL +approach of an off-board computer and a global set of cameras sensing +the environment. While the main league still uses the standard SSL +vision software with overhead cameras, there is desire to reduce the +reliance on this vision system. We believe that not only will more +distributed sensing and processing on robots help advance research in +this league, it will provide a benefit to teams who take this +approach.

+
+
+

Overall, this technical challenge will focus on demonstrating standard +SSL soccer skills (e.g. locomotion, ball manipulation and colaboration +between robots) in without the ssl-vision software running. The challenge +is split into multiple stages designed to have different levels of difficulty, +with each stage building on the skills of the prior.

+
+
+

Participation Requirements

+
+

Anyone participating in SSL RoboCup is eligible to participate in this +challenge. Anyone participating must publish their approach to solving +this technical challenege after the competition has concluded. The +goal of forcing publication is that other participants in the league +and the wider research community can learn and benefit from those that +participated. Teams are also encouraged to present their approach in the +poster sessions.

+
+
+
+

Overview of Competition Stages

+
+

The competition will consist of four stages:

+
+
+
    +
  1. +

    Grab a stationary ball somewhere on the field

    +
  2. +
  3. +

    Score with the ball on an empty goal

    +
  4. +
  5. +

    Move the robot to specific coordinates

    +
  6. +
  7. +

    Score an indirect goal (two robots needed)

    +
  8. +
+
+
+

Stage 1 is designed to demonstrate basic sensing and locomotion +capabilities of each participating team.

+
+
+

Stage 2 is designed to demonstrate similar skills to stage 1 plus the +ability to localize and aim at a known target on the field.

+
+
+

Stage 3 demonstrates strong localization abilities without the use of +the global vision system.

+
+
+

Stage 4 is designed to demonstrate coordination skill of multiple robots +without vision. The robots must colaborate to pass and score the goal.

+
+
+

We believe that teams who can complete even a single one of these +skills without the vision system information will have an advantage in +the main competition over those teams who rely solely on the global +vision system.

+
+
+

The following sections describe the hardware requirements, and +procedures of each stage. The final chapter describes overall scoring +that will be used to determine the winner.

+
+
+
+
+
+

Hardware/Software Requirements

+
+
+

Robot Hardware

+
+

While we encourage participants to attempt the use of their blackout +solutions during main competition to help deal with noise and dropouts +in the global vision system, we recognize that integration into the +main competition robots is a difficult task. For these reasons, the +hardware restrictions are relaxed for this technical challenge.

+
+
+

Teams may still remotely control their robots during normal +competition, however, we encourage teams to experiment with onboard +processing and autonomy. Regardless of where the control software +executes, team will not receive data from the SSL vision +software. Teams will still receive start, stop, and halt ref commands +which will be used to initiate and stop trials of each stage.

+
+
+

All robot hardware requirements apply to this challenge EXCEPT the height +restrictions and the pattern markings. Participant robots may be taller than the +rules dictate. The vision pattern on-top of the robot MUST be covered or +removed to guarantee that ssl-vision is not being utilized. However, other rules +such as maximum speed, kick power, ball manipulation strategies, etc. must still +be observed.

+
+
+

There are no restrictions on onboard sensor types. External sensors +not attached to the robot are not allowed for this competition. We +encourage teams to be creative in their choice of sensors and their +strategies for completing each stage of the challenge. There is no +restriction on processing power or where the processing takes +place. However, keep in mind that bandwidth at competition is limited, +so solutions requiring streaming large amounts of data wirelessly will +likely not work.

+
+
+
+
+
+

Competition Procedure

+
+
+

There are multiple stages with increasing difficulty. +Each stage have three different situations. +Participants will have only one trial per situation (three trials per stage). +All trials will be considered for the overall score.

+
+
+

Each trial will be attempted by all participants, one after another. +The starting configuration of the trial will be similar for each team to achieve same conditions for all participants.

+
+
+

If a participant can not attempt a trial for what ever reasons, no points are awarded for this trial. +Other trials are not effected.

+
+
+

The robots may move anywhere on the field within the walls. +Similarly, the ball may move anywhere on the field throughout the time. +Any defined positions will always be inside the field boundaries.

+
+
+

Field setup

+
+

Challenges will be executed on a Division B sized field as described in the main SSL rules.

+
+
+

Because the vision patterns are not required, markings may be added to the field before a run to help the human judges verify that the robots are reaching the desired positions and orientations. +Participants should not expect a perfect field with no additional markings. +However, attempts will be made to keep the marks minimal and small to not interfere with on-board vision solutions. +Additionally, participants should expect visual aspects of the field to vary slightly, including the exact color of the carpet and walls, the width of line markings, etc.

+
+
+
+

Referee commands

+
+

Each trial will start with a HALT command. +Just before the start, a STOP command will be given to allow participants to prepare. +When a FORCE START command is sent, the timer is started and robots may move. +The trial will be stopped with a HALT command after successful challenge completion or after the time ran out

+
+
+
+

Scoring

+
+

Each stage may define a set of criteria which give positive or negative points. +Points will also be given if the overall objective was not achieved. +The duration of a trial is used as a tie-breaker (faster is better).

+
+
+
+

Stage 1: Grab a Stationary Ball

+
+

This stage is designed to be the easiest and to demonstrate basic sensing and control capabilities. +The robot will need to detect a ball on the field, navigate to it, and place it on its dribbler.

+
+
+

Procedure

+
+
    +
  • +

    The supervisor defines random starting positions for robot and ball, as well as a random orientation for the robot.

    +
  • +
  • +

    Robot and ball are placed on their starting positions

    +
  • +
  • +

    The trial is started

    +
  • +
  • +

    The trial is stopped after one minute or if the robot did not move for 10 seconds after moving at least once

    +
  • +
+
+
+
+

Scoring

+
+
    +
  • +

    Touching the ball with any part of the robot — +1

    +
  • +
  • +

    Touching the ball with the dribbler — +1

    +
  • +
  • +

    Robot stopped with the ball touching the dribbler at the end of the run-- +1

    +
  • +
+
+
+
+
+

Stage 2: Scoring on an Empty Goal

+
+

This stage requires robots to localize a goal as well as the ball on the playing field, move to the ball and score a goal.

+
+
+

Procedure

+
+
    +
  • +

    The supervisor defines a random robot starting position and orientation

    +
  • +
  • +

    The supervisor defines a random ball starting position

    +
  • +
  • +

    Robot and ball are placed on their starting positions

    +
  • +
  • +

    The trial is started

    +
  • +
  • +

    The trial is stopped after one minute or if the robot scored a goal

    +
  • +
+
+
+
+

Additional Rules

+
+
    +
  • +

    Either of the two goals may be used for scoring

    +
  • +
+
+
+
+

Scoring

+
+
    +
  • +

    Touching the ball with any part of the robot — +1

    +
  • +
  • +

    Touching the ball with the dribbler — +1

    +
  • +
  • +

    Ball entered any defense zone — +1

    +
  • +
  • +

    Ball entered any goal — +1

    +
  • +
  • +

    Robot entered any defense zone — -1

    +
  • +
+
+
+
+
+

Stage 3: Moving to Specific Coordinates

+
+

This stage is designed to demonstrate localization capabilities without the use of the global vision system. +No ball will be used for this stage.

+
+
+

Procedure

+
+
    +
  • +

    The supervisor defines a

    +
    +
      +
    • +

      random robot target position (no specific orientation is required)

      +
    • +
    • +

      random robot starting orientation

      +
    • +
    • +

      random robot starting position seed

      +
    • +
    +
    +
  • +
  • +

    Participants may enter the starting position seed and the target position into their robot configuration

    +
  • +
  • +

    The supervisor defines a random robot starting orientation

    +
  • +
  • +

    The supervisor defines a random robot starting position that is within 0.5 m distance to the position seed

    +
  • +
  • +

    The robot is placed on its starting position and turned to its starting orientation.

    +
  • +
  • +

    The trial is started

    +
  • +
  • +

    The trial is stopped after one minute or if the robot did not move for 10 seconds after moving at least once

    +
  • +
+
+
+
+

Scoring

+
+

The score is equal to the negative straight line distance between the robot’s final position and the destination position. +(In other words, closer is better)

+
+
+
+
+

Stage 4: Scoring an Indirect Goal (without Obstacles)

+
+

The objective of this stage is to score an indirect goal using two robots. +Robots are required to recognize other robots, receive a ball, coordinate between each other and finally to score a goal.

+
+
+

Procedure

+
+
    +
  • +

    The supervisor defines a random ball starting position seed in the positive field half (positive x-coordinates)

    +
  • +
  • +

    Robot 1 is placed on starting position [0.5 m, 1.5 m, 0°]

    +
  • +
  • +

    Robot 2 is placed on starting position [0.5 m, -1.5 m, 0°]

    +
  • +
  • +

    The ball is placed on a random starting position within 0.5 m distance of the position seed.

    +
  • +
  • +

    The trial is started

    +
    +
      +
    • +

      The first robot that touches the ball will be considered the passer, and the other, the receiver.

      +
    • +
    +
    +
  • +
  • +

    The trial is stopped after two minutes or if a robot scored a goal

    +
  • +
+
+
+
+

Scoring

+
+
    +
  • +

    Touching the ball with any part of the passing robot — +1

    +
  • +
  • +

    Touching the ball with the passing robot dribbler — +1

    +
  • +
  • +

    Pass hits receiver robot — +1

    +
  • +
  • +

    Pass hits the receiver robot dribbler — +1

    +
  • +
  • +

    If both robots have touched the ball:

    +
    +
      +
    • +

      Ball entered any defense zone — +1

      +
    • +
    • +

      Ball entered any goal — +1

      +
    • +
    +
    +
  • +
  • +

    Robot entered any defense zone — -1

    +
  • +
+
+
+
+
+
+
+

Overall Scoring

+
+
+

As each stage is quite different in terms of scoring, in order to +determine an overall winner, each stage will be ranked individually by +total score. Depending on ranking in the category, each participant +will get an amount of overall points. The amount of points is equal to +the number of participants - placement in that stage. For example, +with 7 participants, first place gets 6 points, second place gets 5, +etc.

+
+
+

Each of the stage points will then be totaled to determine an overall +winner. Therefore, performance in all stages is considered equal in +the final scoring.

+
+
+

In the event of a tie, the team with the lowest total time across all +the stages will win.

+
+
+
+
+ + + \ No newline at end of file diff --git a/2024/2022-ssl-vision-blackout-rules.pdf b/2024/2022-ssl-vision-blackout-rules.pdf new file mode 100644 index 0000000..abc880a Binary files /dev/null and b/2024/2022-ssl-vision-blackout-rules.pdf differ diff --git a/2024/2023-ssl-ball-placement-rules.html b/2024/2023-ssl-ball-placement-rules.html new file mode 100644 index 0000000..55bc2e4 --- /dev/null +++ b/2024/2023-ssl-ball-placement-rules.html @@ -0,0 +1,709 @@ + + + + + + + + +RoboCup 2023 SSL Ball Placement Technical Challenge Rules + + + + + + +
+
+
+ +
+ + + + + +
+ + +References to the male gender in the rules with respect to referees, team +members, officials, etc. are for simplification and apply to both males and +females. +
+
+
+
+
+

Goals of the Technical Challenge

+
+
+

Given the goal of preparing Division B teams to participate in Division A, this +technical challenge aims to encourage Division B teams to develop one of the +skills needed to play a match in Division A. In this case, the challenge is to +autonomously place the ball using the robots ("AutoPlacement").

+
+
+

Participation Requirements

+
+

All Division B teams are eligible and are encouraged to participate in this challenge.

+
+
+
+
+
+

Procedure

+
+
+

The Ball Placement Technical Challenge will be executed using the Game Controller manual controls. Therefore, the procedure is as +follows:

+
+
+
    +
  • +

    The Game Controller, SSL Vision and at least one Auto Referee must be already +running

    +
  • +
  • +

    Make sure the game state is First Half or Second Half

    +
  • +
  • +

    The desired position must be set in Game Controller

    +
  • +
  • +

    The ball must be placed at the indicated position

    +
  • +
  • +

    The robot(s) must be placed on the middle line of the field

    +
  • +
  • +

    When all positions are correct, the challenge will start

    +
  • +
  • +

    A Stop command will be issued for 2 seconds

    +
  • +
  • +

    Then, the BALL_PLACEMENT_BLUE/BALL_PLACEMENT_YELLOW command will be issued

    +
  • +
+
+
+

Before and after those commands the game is in Stop state, therefore, the robots are allowed to +position themselves wherever they want before the placement starts, while +following all Stop state rules.

+
+
+

The rules for the AutoPlacement can be found in the +rule book.

+
+
+

The starting and desired positions of the ball can be seen in the Appendix at +the end of the document. The "Start" is the starting position, and the +"Goal" is the position where the ball must be placed.

+
+
+

In scenarios 6 and 7, the ball must be placed with an Y value that the robot cannot get between the ball and the wall, since one of the goals of these scenarios is taking the ball from the boundary.

+
+
+

Teams are allowed to use up to 6 robots.

+
+
+
+
+

Evaluation

+
+
+

Every team places the ball in the same scenarios and has 20 minutes to complete all scenarios. The 20 minutes considers the time for completing the challenges and the time for setting up the scenarios, like positioning the ball each try. There are no restrictions on the quantity of tries per scenario, so each team can choose their own strategy to complete the challenge within the time.

+
+
+

The team is responsible for moving the ball to the right place each try. The TC will only check if the positions are correct and will operate the Game Controller.

+
+
+

In total, there will be 8 scenarios in this challenge. The order of the scenarios will be chosen by the team during the challenge, communicating the next scenario for the TC.

+
+
+

Scoring

+
+

For every scenario, the following criteria will be evaluated.

+
+
+
    +
  • +

    Touching the ball with the dribbler — +1

    +
  • +
  • +

    Moving the ball more than 0.5 meter away from the starting position — +1

    +
  • +
  • +

    The ball, any time of the try, stopped less than 0.5 meter away from the desired position — +1

    +
  • +
  • +

    The ball, when the try is finished, is less than 0.5 meter away from the desired position — +1

    +
  • +
  • +

    Completing the ball placement — +1

    +
  • +
+
+
+

For the scenarios 6, 7 and 8, there will be an additional criteria for taking the ball from the boundary.

+
+
+
    +
  • +

    Taking the ball out from the boundary — +1

    +
  • +
+
+
+

The best try of each scenario will count.

+
+
+

The partial points of each scenario will be summed. In case of ties, the times for the best try of each scenario will be summed, the fastest team wins.

+
+
+

The TC reserves the right to change the evaluation procedure.

+
+
+
+
+
+

Appendix A: Scenarios for Ball Placement

+
+
+

Scenario 1

+
+
+Interactive +
+
+
+
+

Scenario 2

+
+
+Interactive +
+
+
+
+

Scenario 3

+
+
+Interactive +
+
+
+
+

Scenario 4

+
+
+Interactive +
+
+
+
+

Scenario 5

+
+
+Interactive +
+
+
+
+

Scenario 6

+
+
+Interactive +
+
+
+
+

Scenario 7

+
+
+Interactive +
+
+
+
+

Scenario 8

+
+
+Interactive +
+
+
+
+
+
+ + + + + \ No newline at end of file diff --git a/2024/2023-ssl-ball-placement-rules.pdf b/2024/2023-ssl-ball-placement-rules.pdf new file mode 100644 index 0000000..20f1c01 Binary files /dev/null and b/2024/2023-ssl-ball-placement-rules.pdf differ diff --git a/2024/2023-ssl-chip-challenge-rules.html b/2024/2023-ssl-chip-challenge-rules.html new file mode 100644 index 0000000..c52e02b --- /dev/null +++ b/2024/2023-ssl-chip-challenge-rules.html @@ -0,0 +1,666 @@ + + + + + + + + +RoboCup 2023 SSL Chip Pass Challenge Rules + + + + + + +
+
+
+ +
+ + + + + +
+ + +References to the male gender in the rules with respect to referees, team +members, officials, etc., are for simplification and apply to both males and +females. +
+
+
+
+
+

Goal

+
+
+

A key distinguishing characteristic of the Small Size League is its tight integration of software and hardware, which is crucial to create a dynamic, collaborative soccer match.

+
+
+

The task in this technical challenge is to perform as many passes between robots as possible within a limited amount of time, similar to the hardware challenge from 2021. Additionally, teams are encouraged (but not forced) to chip kick the ball to show their ability to precisely perform and receive chipped passes.

+
+
+

This challenge requires both, accurate passing skills and endurance. The robot hardware will be challenged with the high frequency of kicks. Still, the task is pretty straight forward and can be performed by any team with a bit of preparation. Thus, all teams are encouraged to participate.

+
+
+
+
+

Procedure

+
+
+
    +
  • +

    The team places its robots on the middle line and the ball on the center point.

    +
  • +
  • +

    A FORCE_START command will be issued, and the timer will start.

    +
  • +
  • +

    After 5min a HALT command will be issued and the challenge is over.

    +
  • +
+
+
+

Pass Definitions

+
+

Teams are free in how they perform the passes. Definitions of a pass in general and additional constrains for valid pass that are considered in the scoring are given in this section.

+
+
+

A pass is defined as follows:

+
+
+
    +
  • +

    A pass has a source position, a target position and a shooter.

    +
  • +
  • +

    The source position is where a robot kicks the ball.

    +
  • +
  • +

    The target position is where the ball stops or changes direction by more than 30 degrees in field plane (x, y).

    +
  • +
  • +

    The shooter is the robot located nearest to the source position when the pass starts.

    +
  • +
  • +

    The pass distance is the euclidean distance between the source and target position.

    +
  • +
  • +

    The pass direction is the orientation of the target - source vector.

    +
  • +
  • +

    The pass is considered chipped, if the ball reached a maximum height of at least 15cm.

    +
  • +
+
+
+
+
+
+

Scoring

+
+
+

A valid pass must meet the following criteria:

+
+
+
    +
  • +

    The pass distance must be at least 1.5m.

    +
  • +
  • +

    The shooter of the previous pass can not be the receiver of the current pass (this implicitly means you need at least 3 robots).

    +
  • +
  • +

    The pass direction of the pass must differ by at least 10 degrees from the inverted previous pass direction: \(abs(passDirection_{cur} - (passDirection_{previous} + 180°)) > 10°\)

    +
  • +
  • +

    The ball must not exceed 6.5m/s (as defined in the tournament rules).

    +
  • +
  • +

    The source and target must be inside field lines.

    +
  • +
+
+
+ + + + + +
+ + +Previous passes include all passes, not only those considered valid. +
+
+
+

Passes are scored as follows:

+
+
+
    +
  • +

    A valid ground pass — 1 point

    +
  • +
  • +

    A valid chipped pass — 5 points

    +
  • +
+
+
+

Additionally, the following rules apply:

+
+
+
    +
  • +

    The number of robots is limited to 6 robots.

    +
  • +
  • +

    Teams are allowed and encouraged to recover the ball outside of field lines.

    +
  • +
  • +

    Any human interference, including exchanging robots, reduces the final number of points by 15 points.

    +
  • +
  • +

    If the ball is kicked out of the field, the ball can be positioned inside by the team. This will count as human interference.

    +
  • +
+
+
+
+
+

Evaluation

+
+
+

Two or more members of OC/TC will be assigned to each challenge and act as the referee. The referee has the final decision on the result. If the two referees' counts differ, the final result will be the points average.

+
+
+

The team with the most points wins. +The number of chipped passes acts as a tiebreaker. +Teams with the same number of points and same number of chipped passes will share the better position.

+
+
+
+
+ + + + + + + \ No newline at end of file diff --git a/2024/2023-ssl-chip-challenge-rules.pdf b/2024/2023-ssl-chip-challenge-rules.pdf new file mode 100644 index 0000000..d80d10e Binary files /dev/null and b/2024/2023-ssl-chip-challenge-rules.pdf differ diff --git a/2024/2024-ssl-black-white-hulls-rules.html b/2024/2024-ssl-black-white-hulls-rules.html new file mode 100644 index 0000000..60e13a5 --- /dev/null +++ b/2024/2024-ssl-black-white-hulls-rules.html @@ -0,0 +1,557 @@ + + + + + + + + +RoboCup 2024 SSL Black and White Hulls Technical Challenge Rules + + + + + + +
+
+
+ +
+ + + + + +
+ + +References to the male gender in the rules with respect to referees, team +members, officials, etc. are for simplification and apply to both males and +females. +
+
+
+
+
+

Goals of the Technical Challenge

+
+
+

Given that most parts of the teams use similar hulls, differing only in the use of stickers and sponsorships, it can be difficult for spectators to differentiate the teams during a match only by observing the central blob color. Because of it, the TC/OC decided that, in the future, it would be preferable that opponent teams use different hull colors in a match. One team would use black hulls and the other team white hulls. So, the main goal of the challenge is that the teams bring ideas that solve this efficiently and don’t make logistics too complicated.

+
+
+

Participation Requirements

+
+

All teams are eligible and are encouraged to participate in this challenge.

+
+
+
+
+
+

Evaluation

+
+
+

Every team has a 5-minute pitch to explain their solution for the challenge and the built design and 5 minutes for possible questions. During the presentation, the TC/OC will measure the time of the team solution.

+
+
+

At least one member of each team should be present during presentations since all teams will vote for the best solution.

+
+
+

The following criteria will be evaluated.

+
+
+
    +
  • +

    Size efficiency

    +
  • +
  • +

    Durability

    +
  • +
  • +

    Ease of changing

    +
  • +
  • +

    Costs

    +
  • +
  • +

    Ease of building

    +
  • +
+
+
+

Scoring

+
+

After the presentations, every team will receive a ballot where they will rate the solutions from 1 to 5 for each criterion.

+
+
+

The teams are encouraged to use their solutions in the matches to prove their efficiency to the others. Besides, the teams that use their solution in a game earn 5 extra points and can receive more 5 points if they switch the hulls during half-time.

+
+
+

The TC/OC will average the points of each team. The team with the most points wins. In case of ties, the fastest team wins.

+
+
+

The TC reserves the right to change the evaluation procedure.

+
+
+
+
+
+ + + + + \ No newline at end of file diff --git a/2024/2024-ssl-black-white-hulls-rules.pdf b/2024/2024-ssl-black-white-hulls-rules.pdf new file mode 100644 index 0000000..e208ffc Binary files /dev/null and b/2024/2024-ssl-black-white-hulls-rules.pdf differ diff --git a/2024/2024-ssl-teams-vs-teams-passing-challenge.html b/2024/2024-ssl-teams-vs-teams-passing-challenge.html new file mode 100644 index 0000000..428aa5e --- /dev/null +++ b/2024/2024-ssl-teams-vs-teams-passing-challenge.html @@ -0,0 +1,677 @@ + + + + + + + + +RoboCup 2024 Team vs. Team Passing Challenge + + + + + + +
+
+
+ +
+ + + + + +
+ + +References to the male gender in the rules with respect to referees, team +members, officials, etc., are for simplification and apply to both males and +females. +
+
+
+
+
+

Goal

+
+
+

A key distinguishing characteristic of the Small Size League is its tight integration of software and hardware, which is crucial to create a dynamic, collaborative soccer match. +While this goal was pursued in last year’s SSL Chip Pass Challenge, the goal of this year’s challenge is to utilize last year’s work and adapt it to a more realistic situation.

+
+
+

Therefore this year two teams will try to play as many passes as possible while competing against each other. To achieve this, the ruleset used last year has been adapted to the new situation.

+
+
+

Although the teams, which have participated in one of the previous passing challenges, might have a slight advantage, we would like to encourage all teams to participate in this technical challenge.

+
+
+
+
+

Procedure

+
+
+

To level the playing field and to remove the impact of the performance of the opponent team on a teams score, each team will play two games against different contestants of the technical challenge. To reduce the risk of biases the TC/OC will draw the pairings for each match by random and announce the pairings together with the schedule for the technical challenge.

+
+
+

Each game will have the following procedure:

+
+
+
    +
  • +

    To reduce the preparation time, the team colors for each team will be determined by the TC/OC and announced together with the schedule of the technical challenge.

    +
  • +
  • +

    To start the game, a kick-off command for the yellow team will be issued from the game controller. For the start the robots can be positioned in any way preferred, as long as the positioning does not violate the usual ruleset for a kick-off.

    +
  • +
  • +

    After 2 minutes of game time a stop command will be issued and the first half of the game is over.

    +
  • +
  • +

    The half time break for this challenge will be only 60 seconds, since it should be mainly used to set up the robots at their desired position again and to exchange faulty robots.

    +
  • +
  • +

    To start the second half a kick-off command for the blue team will be issued.

    +
  • +
  • +

    After another 2 minutes of game time a stop command will be issued and the game is over.

    +
  • +
+
+
+

Special Rule Set during the Technical Challenge

+
+

For the technical challenge a Div B field will be used with a maximum of 4 robots per team. If the ball leaves the field via any of the field lines, the game will be stopped and the team that did not last touch the ball gets awarded a kick-off.

+
+
+

During the games of the technical challenge only the following fouls from the ssl rulebook apply:

+
+
+
    +
  • +

    Pushing

    +
  • +
  • +

    Ball Holding

    +
  • +
  • +

    Tipping over or dropping parts

    +
  • +
  • +

    Boundary Crossing

    +
  • +
  • +

    Excessive Dribbling

    +
  • +
  • +

    Ball Speed

    +
  • +
  • +

    Crashing

    +
  • +
  • +

    Defender too close to ball

    +
  • +
  • +

    Robot Stop Speed

    +
  • +
+
+
+

If there is no progress in the game for 10 seconds while both teams are allowed to manipulate the ball, the game is stopped and the team that got the first kick-off of this halftime will get a kick off.

+
+
+
+

Pass Definitions

+
+

Teams are free in how they perform the passes. Definitions of a pass in general and additional constraints needed for the scoring are given in this section.

+
+
+

A pass is defined as follows:

+
+
+
    +
  • +

    A pass has a source position, a target position and a shooter.

    +
  • +
  • +

    The source position is where a robot kicks the ball.

    +
  • +
  • +

    The target position is where the ball stops or changes its direction.

    +
  • +
  • +

    The shooter is the robot located nearest to the source position when the pass starts.

    +
  • +
  • +

    The pass distance is the euclidean distance between the source and target position.

    +
  • +
+
+
+
+
+
+

Scoring

+
+
+

A valid pass must meet the following criteria:

+
+
+
    +
  • +

    The pass distance must be at least 1 m.

    +
  • +
  • +

    The shooter and the receiver of the pass must be from the same team.

    +
  • +
  • +

    The ball must not exceed 6.5m/s (as defined in the tournament rules).

    +
  • +
  • +

    The source and target must be inside field lines.

    +
  • +
+
+
+

Each valid pass is worth one point.

+
+
+

Evaluation

+
+

Two or more members of OC/TC will be assigned to each challenge and act as the referee. The referee has the final decision on the result. If the two referees' counts differ, the final result will be the points average.

+
+
+

The points for each team from both games will be added and the team with the most points wins. +Teams with the same number of points will share the better position.

+
+
+
+
+
+ + + + + + + \ No newline at end of file diff --git a/2024/2024-ssl-teams-vs-teams-passing-challenge.pdf b/2024/2024-ssl-teams-vs-teams-passing-challenge.pdf new file mode 100644 index 0000000..ca9bb67 Binary files /dev/null and b/2024/2024-ssl-teams-vs-teams-passing-challenge.pdf differ diff --git a/2024/index.html b/2024/index.html new file mode 100644 index 0000000..9c9954e --- /dev/null +++ b/2024/index.html @@ -0,0 +1,89 @@ + + + + Technical Challenge Rules of the RoboCup Small Size League + + +

Technical Challenge Rules of the RoboCup Small Size League

+ +

2024

+ +

SSL Black and White Hulls Challenge

+ + +

SSL Teams vs Teams Passing Challenge

+ + +

2023

+ +

SSL Pass Chip Challenge

+ + +

SSL Ball Placement Challenge

+ + + +

2022

+ +

SSL Vision Blackout Challenge

+ + +

SSL Ball Placement Challenge

+ + +

SSL Dribble Challenge

+ + + +

2021

+ +

SSL Vision Blackout Challenge

+ + +

SSL Ball Placement Challenge

+ + + +

2019

+ +

SSL Vision Blackout Challenge

+ + +

Game Log Event Labeling

+ + + +