AutoRef system architecture
The system architecture for the AutoRef autonomous referee for RoboCup Middle Size League (MSL) robot soccer is a proposed conceptual model which describes the structure, behavior, and more views of the AutoRef system.
The system architecture is based on the specification of functions as derived from the MSL rulebook. In short, this functional specification is a breakdown of MSL rulebook laws into robot skills through robot tasks: tasks are statements describing what the AutoRef must do to enforce the rules, written in plain language as to fully explain referee actions without describing the means by which to achieve them; skills are fundamental abilities which are needed to accomplish a specific task. A systems thinking approach underscores the system architecture.
The system architecture reflects team contributions from 2021 onwards, starting with AutoRef MSD 2020. System architectures proposed by AutoRef teams from 2016–2020 (prior to MSD 2020) are available within their respective pages.
Recommendations for short-term future work emphasize an updated functional specification to synchronize the textual breakdown of law-task-skill and the corresponding game state flow visualization. Long-term recommendations emphasize further development of the system architecture as a whole.
Background
A systems thinking analysis by MSD 2020 initiated the development of the system architecture with respect to the AutoRef goal as an autonomous referee system for RoboCup MSL. This process identified two primary stakeholder concerns:
- Fairness, a concern for the RoboCup committee, soccer teams, and spectators.
- Project continuity, a concern for AutoRef stakeholders and teams.
Systems thinking also identified that one the most important and challenging refereeing duties in ensuring fairness is to be able to enforce all the laws of the MSL rulebook.
An archiving of past work running parallel to systems thinking revealed continuity issues — namely, continuity issues based on the patterns observed in past generations’ work. Two main issues identified by this archiving were:
- the lack of an overarching structure and goal for all generations; and
- the lack of an easy and quick overview of what past generations have done and what is yet to be done.
The combined results of systems thinking and archiving led to the idea of creating a global structure which translates laws from the MSL rulebook into enforcement tasks to specify what a referee must do to enforce the laws. Further work revealed that a structure with a single layer was not appropriate for specifying the referee's functions; thus, a second layer of skills was added to the structure to add value to the purpose of that structure. The primary purpose of the skill layer is to describe the kind of information which needs to be collected at MSL matches to perform enforcement tasks.
A puzzle analogy to understand the system architecture approach
To better help in the understanding of the problem and proposed solution, the AutoRef project can be seen as a puzzle with numerous puzzle pieces. Team contributions prior to MSD 2020 introduced new puzzle pieces to the collection of pieces, but in a very unstructured manner, making it difficult for the subsequent teams to integrate their piece to previously developed pieces. The lack of a grid or puzzle layout also made it very difficult for new generations to have a global understanding of the whole system, and thus greater effort was spent trying to understand and analyze the big picture.
The system architecture approach established by MSD 2020 is to introduce the grid and identify all the needed puzzle pieces within the scope of the MSL rulebook. In reality, AutoRef is more complex than a puzzle, and having a grid with all pieces identified is not enough to streamline the development process for all teams, so a visualization showing the connections between different areas of the puzzle was also added. Functional specification is the term given to the development this grid.
Functional specification
Functional specification works like a blueprint that helps development teams to understand how an application will function. A functional specification essentially tells developers what features they need to build and why. For AutoRef, the functional specification defines the functionalities needed to enforce the laws in the RoboCup MSL rulebook.
Video overview
An overview of the functional specification as developed by MSD 2020 is provided in video below. The video includes (among other elements) a demonstration on how to interpret the database and visualization documents.
How the functional specification for AutoRef is derived
Using the MSL rulebook's chapters and laws as the starting point, each chapter of the rulebook was analyzed, then the laws involved in each chapter were extracted, consequently each law is then translated into a set of task groups then tasks, and finally each task is translated into a set of skills. The skills represent the most basic functionality within this structure.
One of the most challenging problems was defining the number of layers involved in this transformation and drawing boundaries between what is considered a task group, a task or a skill. Another challenge was to keep the skills at the right abstraction level to avoid getting into technical specification, thus keeping the functional specification as flexible, when it comes to technical design, as possible.
Guidelines to create the law-task-skill breakdown database document
Law chapters: The RoboCup MSL rulebook is already split into 17 chapters, with each chapter denoted with a number (1 to 17). Each chapter tackles a certain area of the game (Fouls, offsides, the duration of the match … etc.). The chapters are following the FIFA laws, stating the FIFA law and then stating and explaining the corresponding RoboCup Law. We focused on the RoboCup Laws.
Laws: Each chapter contains 1 or more laws, sometimes a law might include sub laws as well. For example, Law 10.1 has 2 sub Laws 10.1.1 and 10.1.2. The decision on what is considered a law was based on the structure used in the law book. For example, 10.1.1 is a law as it has no further sub laws, and 14.1 is also considered a law as it has no further sub laws.
Task groups: As sometimes the smallest subsection within the law book was still too broad, an additional layer between laws and task was introduced to bridge the gap between them. The general guideline for what is considered a task group is that it is a statement describing a huge task that can be further split into smaller tasks.
Tasks: A task is a level more specific than a task group. The general guideline for what is considered a task, is that a task is an explanation of what should be done to enforce a law, written in such a way that is understandable by a human. For example, a task would be to decide if a goal is scored or not.
Skills: A skill is one level lower than a task. The general guideline for a skill is that it is a command given to a robot without getting into any technical details. The main difference between commands given to a robot and instructions given to a human is that human instructions usually do not include any details about what kind of information needs to be extracted from the surrounding, while a robot needs this information. For example, know the position of the ball is a skill, but use a camera to know the position of the ball is too detailed for our definition of a skill as it gets into the territory of technical specification.
Task guideline examples
| Task | Not a task | |
|---|---|---|
| Decide if a goal was scored | Know the position of the ball | |
| Decide if the ball was shot from the correct half of the field | Know the position of the field lines | |
| Decide if chapter 10 of the law book is being followed | ||
| Judge based on MSL RoboCup law book |
Skill guideline examples
| Skill | Not a skill | |
|---|---|---|
| Know the position of the goal line or goal plane | Use 3 cameras to identify the coordinates of the ball in a cartesian coordinate system | |
| Decide if the ball was shot from the correct half of the field | Visually identify players | |
| Decide if chapter 10 of the law book is being followed | ||
| Decide which team gets the goal kick |
Game state flow visualization
Visualization of the tasks of the referee in a game situation are currently provided in a yEd diagram. In previous generations’ work several game situations are specified, though none of these show the transitions and events leading to a change in these game-states. This year’s progress, in the context of domain modelling, resulted in the game-state visualization including the referee’s tasks and state transitions. The main purpose of this visualization is to show the flow of the game and the sequence of referee actions leading to this flow. The diagram can be used to create context for implementing certain tasks in the autonomous referee system.
yEd
The diagram is created in yEd, a freely available application to create high-quality diagrams. The overall diagram is shown in the figure below and can be downloaded with access to AutoRef's TU/e SharePoint folder. To improve the readability in yEd please use File -> Preferences -> Bridge style and select a proper bridge style.
Derivation from the MSL rulebook
The entire visualization is derived from the RoboCup MSL rulebook. The used approach to deriving the tasks from the rulebook is to read through all the rules and denote all observing and decision tasks the referee should perform to enforce the game laws. In several cases, a certain level of interpretation is required to derive a specified task, e.g. deciding what is a collision and what is an accidental touch. In most of these cases a choice is made to ensure the rules are followed as closely as possible, though some cases are still open for future work.
Creation
The visualization is created from the semantic building blocks as shown in the table below. The RefBox commands are communication commands to the players on the field. (See also: MSL RefBox GitHub). In certain game-states, some observations are needed in order ensure no game laws are infringed. For example, in the normal game state observations are needed to see if a goal is scored. With the observations and other available information, the referee should make decisions on e.g. penalizing infringements and awarding free-kicks. It is assumed a game record is kept up to date during the game, where the referee can update and extract information to make the decisions. As an example, when the ball crosses the touchline, the referee should ‘know’ where the ball crossed the line for restarting the game with a throw-in. Finally, in game state changer events, the game state changes, where the transition is indicated as a throw and catch manner.
Furthermore, the diagram consist of several colored arrows of which each color has its own meaning. A sequence arrow means that after completing a certain task, the referee should go to the next task. Furthermore, these arrows can indicate a flow of information. This information is then used in the corresponding block to which the arrow points at.
Example: Throw-in game state
Below an example is given of the “throw-in” game-state just before restarting the game. In this state, the referee should call STOP to all players and place the ball on the correct throw-in spot. After this the players should position themselves correctly before the START signal is given by the referee. In a similar way, the diagram is created for the entire game.
Visualization review and recommendations
An initial game-state flow of the referee tasks is created as a yEd diagram. This diagram shows the overall different game-states in which the soccer match can involve and how events or referee decisions lead to the flow through these states. Several interpretable referee tasks have been given an interpretation already, though still the diagram could be specified in more detail.
For future work on this diagram and how to use it for creating the autonomous referee system, the following recommendations are given:
- Specify in more detail several task groups such as offences, methods of scoring (including lobbing from own half) and end-of-game penalty sequence.
- Use this for benefit in creating an overall architecture of the autonomous referee system. This can be done by identifying, specifying and implementing all the referee tasks.
- Complete player ID stats.
- Complete game stats.
- Complete the end-of-game penalty sequence.
How the functional specification helps in implementing a system component
The main purpose of the functional specification is to provide a unified goal and structure to all generations to facilitate the implementation of the functions needed to enforce the laws of the lawbook. When it comes to implementation of the system, 5 possible approaches were identified.
Approach 1: Implement 1 or more individual skills
In this approach, the Excel document (the database) would provide an understanding of how the chosen skill is connected to all tasks within the scope of the game laws in the lawbook. Having this view would allow the implementation team to formulate the requirements that would satisfy all the tasks needing this skill in the future, thus nullifying the need to ever reimplement the same skill again. For example, if “Ball identify (X,Y)” is the chosen skill, then if this skill was implemented just to satisfy the “Determine if the ball is in or out of pitch (BOOP)” task, then might be implemented to simply know if the ball is in or out of pitch, while in the overall system it might also be important to know in which area of the field is the ball and maybe even the exact coordinates of the ball, and not only whether it is in the field or not. This shows that implementing a skill to satisfy a single task might lead to the reimplementation of that skill one more time to satisfy another task. Which is not a very efficient way of implementation.
Approach 2: Implement a task
In this approach, the Excel document would give an idea about the individual skills needed to fulfill the chosen task (from the perspective of the functional specification) as well as clearly showing the laws needing this task. Ideally, if the implementation team decides to pursue implementing a whole task, then each new skill associated with that task should be implemented in a way that negates the need for reimplementation of that skill, as explained in the first approach.
Tasks can be dependent on other tasks, and some tasks are only applicable during certain game states. That is where the need for the visualization (yEd diagram) arises. The visualization clarifies which tasks are needed in each game state and the dependencies between these tasks. Having this information would further help the implementation team know the scope and operating environment of their task, moreover it will clarify the connections between the chosen task and other tasks in the system helping in smoothening the integration between different tasks.
Approach 3: Implement a law
If a law is to be implemented, then the Excel document presents the tasks and skills needed to implement the chosen law. Ideally, if a law is to be implemented, then each new task or skill associated with that law should be implemented in a way that negates the need for reimplementation of that task or skill in the future, as explained in the first 2 approaches.
Implementing a whole law involves a lot of integration steps. That is again where the visualization proves its usefulness, as it shows the which tasks needs to be integrated and in which order should they operate. This eases the understanding of the system interactions and streamlines the integration process.
Approach 4: Improve the implementation of a skill or a task to satisfy more requirements that were not considered before
If the best-case scenario is not achieved while implementing a skill or a task, and there is a need for reimplementing a skill or a task, having the excel document and the yEd diagram, and using them as explained in the first and second approach, will help in achieving the best-case scenario where the reimplemented skill or task would never need to be reimplemented.
Approach 5: Integrate skills or tasks
The integration approaches benefit the most from having an overall understanding of the connections between different system components, as this will help in streamlining the integration process.
Recommendations for implementation
In all cases, it will be extremely useful for the implementation team to have a global understanding of the whole system as well as knowing all the connections related to their specifically chosen subsystem of interest. Having this info will help in formulating more globally fitting requirements for their subsystem.
Regardless of the approach chosen, the most efficient method of working is to aim to implement each component in such a way that it easily integrates well with other related components of the system without the need for reimplementation. Implementing components in such a manner will make the system modular, flexible, and highly adaptable to changes. The main purpose of the functional specification is to provide future implementation teams with a good base structure (puzzle grid) that eases the process of extracting the information needed to implement or integrate system components.
Future work
After the system thinking and archive analysis processes, the need for a global architecture was realized, as it will provide a long-term structure and goal for future generations. However, the functional specification within the scope of the rulebook, is just the first step towards achieving a global architecture. This means that there is huge space for future architecture teams to expand on the current state of the global architecture. There three possible areas of expansion:
Complete and/or improve the currently available documents
Database for law-task-skill breakdown
- As previously mentioned, the excel pivot table has not been fully specified yet, and the guidelines used to differentiate different layers of the structure might be vague. So, it is possible to continue working on fully specifying all the chapters of the lawbook. It is also possible to make the guidelines used more specific.
- While specifying the skills, it was discovered that some skills are dependent on the output of other skills. For example, the skill “Ball position identify (X,Y)” needs the skill “Ball identify” as it is not possible to know the position of the ball without first identifying the ball. So, the dependencies between skills could be specified to further add to the value of the database.
- Some pattern was also observed in the skills used. For example, some skills were related to the ball, other to the players and other to both the ball and the player. Visually presenting these patterns could also add to the value of the functional specification, as the implementation team would have information regarding closely related skills. This could further ease implementation decisions. For example, the implementation team could decide to join “Ball position identify (X,Y)” and “Ball height identify (Z)” as one implementation package.
- Task and skill names were kept as minimalistic as possible. As a result, it was observed that there were different interpretations of the names used. To solve this problem, without increasing the name complexity, is to add an extra information tab in the database and link it to the short name of the task or skill.
- It is respectively hard to populate a pivot table, finding a faster process to populate the table, or changing the structure of the database to be better suited for the intended function would greatly ease populating and editing the database.
- The database could also be used as a tracking document, in which the each year reports the component they have implemented, and the requirements that their component satisfies.
Visualization of game state flow
- As previously mentioned, some game states are not yet specified to the intended level of detail. The visualization would be more complete if all the game states are fully specified.
- The visualization in its current state was intended to reach the task level of specification, but the same concept could be expanded to include the skill level as well.
- The semantics behind the symbols and arrow colors used in the visualization do not follow any global standards. The value of the visualization would greatly increase if the semantics followed a global standard. This will decrease the effort needed to understand the visualization and will widen the targeted audience.
The functional specification as a whole
The database and the visualization were intended to be 2 closely related documents, but due to time constraints, they were developed parallelly. As a result, they are not fully synchronized. For example, different naming is used to represent similar things. Synchronizing both documents would further reduce the effort needed by implementation teams to use these documents.
In the current state of the database and visualization, even after synchronizing them, it will always be needed to manually synchronize changes between them. That is a very labor-intensive process. The maintainability of the functional specification would be better if both the database and visualization were joined into a single software package.
Expand the scope of the functional specification beyond the lawbook
Currently the functional specification is limited to the law in the lawbook, but it could be extended to other parts of the project, such as the communication functionalities.
The scope of global architecture is way broader than just functional specifications. Future architecture teams could expand the global architecture by creating global design concepts, and choosing the most suitable design, or they could formulate specific requirements for the entire system.