Robots playing soccer often rely on hard-coded behaviors that struggle to generalize when the game environment change. In this paper, we propose a temporal logic based approach that allows robots’ behaviors and goals to adapt to the semantics of the environment.

In particular, we present a hierarchical representation of soccer in which the robot selects the level of operation based on the perceived semantic characteristics of the environment, thus modifying dynamically the set of rules and goals to apply. The proposed approach enables the robot to operate in unstructured environments, just as it happens when humans go from soccer played on an official field to soccer played on a street. Three different use cases set in different scenarios are presented to demonstrate the effectiveness of the proposed approach.

🏆🏆🏆 RoboCup Symposium Best Paper Award 2023 🏆🏆🏆

Our approach consists of three main components:

1) A perception module that extracts relevant features from the environment,

2) A hierarchical representation of the task (the soccer game)

3) A decision-making module that selects the appropriate level of operation and goal function. To model the hierarchical representation and the decision-making module, we start from the definition of a Semantic Map.

The Semantic Map

SM = ⟨R, M, P⟩

where:

– R is the global reference system in which all the elements of the semantic map are expressed;

– M is a set of geometrical elements obtained from sensor data, expressed in the reference frame R, describing spatial information in mathematical form.

– P is a set of predicates, describing the environment.

Here, the definition of a unique reference frame R allows associating the elements of M with those in P. Then, given two semantic maps SM1 = ⟨R1 , M1 , P1 ⟩ and SMm = ⟨Rm , Mm , Pm ⟩ generated as an expected model of the environment, an evaluation metric can be defined as

δ(SM1 , SMm ) = f (|M1 ⊖ Mm |, |P1 ⊟ Pm |),

Architecture

The classification of the environment starts from the perception modules. We rely on different classifiers to percept the field elements of the environment in order to reactive the unused ones (see Fig. below). To be able to play in every scenario, we created classifiers able to detect common objects, easy to retrieve. In particular, for the use-cases presented, we used:

a Ball Perceptor capable to detect the SPL ball on any background and under any light conditions, based on a OpenCV Haar Cascade Classifier.
a Field Perceptor to identify the official SPL field and its elements.
a Goal Perceptor capable to detect official SPL goal posts on any terrain.
a Soda Can Perceptor to perceive soda can as elements representing goal posts, developed with an OpenCV Haar Feature-based Cascade classifiers.
a Player Perceptor, Deep Learning based.

The perception module is responsible for extracting relevant features from the environment and providing them to the decision-making module.

Hierarchical representation of the soccer game. It consists of multiple levels, each Play Soccer Everywhere with Robots using Temporal Logic representing a possible abstraction of the game and a goal that depends on the semantic reconstruction of the environment. This is based on the conceptual layer, which compromises common-sense knowledge about concepts, and relations (mainly IsA and IsPartOf relations) between those concepts, and in stances of spatial entities. It can be easily extended in order to include equivalences between entities belonging to official SPL fields and other heterogeneous environments. Here, the elements are hierarchically classified, and from this representation, the set of predicates extracted Pdeduced are used to condition the planner in the next module.

Use-cases

In order to test the presented approach, we propose three scenarios, in which the agent has to gather data from the environment, extract the set of elements belonging to the environment, determine the level of operation given the available elements, assemble the corresponding goal and compute a policy accordingly. The three use-cases present a progressively increasing number of features made available by the conceptual layer, leading to an increasing level of complexity in the resulting goal, in the number of temporal constraints. The MyND planner was used for the presented experiments. Execution environments for these domain policies were populated using a technique similar to the one used in RoboCup Coach, in which a Python program acting as a "middleware" between robot frameworks and generated policies populates an execution environment with a simple "setup" Python script.

The PDDL domain is unique for all use cases. The adaptability of the domain is enabled by the goal adaptation methodology presented in this work.

PDDL domain

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; RoboCup Domain for Play Anywhere setting ;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(define (domain robocup)

(:requirements :strips :typing :non-deterministic)

(:types movable location)

(:constants robot1 ball - movable strikerposition ballposition kickingposition goaltarget - location)

(:predicates

(is-robot ?mov - movable)

(is-ball ?mov - movable)

(isat ?mov - movable ?loc - location)

(goalscored)

(ballsafe)

(opponent-goal-available)

(fluentopponentnear)

(fluent-opponent-goal-landmark)

(fluent-own-goal-landmark)

(fluent-jolly-available)

)

(:action move-robot

:parameters (?rob - movable ?from - location ?to - location)

:precondition (and

(is-robot ?rob)

(isat ?rob ?from)

(not (isat ?rob ?to))

)

:effect

(and

(not (isat ?rob ?from))

(isat ?rob ?to)

)

(:action reach-ball

:parameters (?rob - movable ?b - movable ?from - location ?to - location)

:precondition (and

(is-robot ?rob)

(is-ball ?b)

(isat ?rob ?from)

(not (isat ?rob ?to))

(isat ?b ?to)

)

:effect

(and

(not (isat ?rob ?from))

(isat ?rob ?to)

(oneof

(and (fluentopponentnear) (not (ballsafe)))

(and (not (fluentopponentnear)) (ballsafe))

)

(oneof

(and (fluent-opponent-goal-landmark) (opponent-goal-available))

(and (not (fluent-opponent-goal-landmark)) (opponent-goal-available))

)

(oneof

(and (fluent-jolly-available) (jolly-available))

(and (not (fluent-jolly-available)) (jolly-available))

)

(:action kick-ball

:parameters (?rob - movable ?b - movable ?from - location ?to - location)

:precondition (and (is-ball ?b) (is-robot ?rob) (isat ?rob ?from) (not (isat ?rob ?to)) (isat ?b ?from) (not (isat ?b ?to)))

:effect

(and (isat ?rob ?from) (not (isat ?b ?from)) (isat ?b ?to))

)

(:action carry-ball

:parameters (?rob - movable ?b - movable ?from - location ?to - location)

:precondition (and

(is-ball ?b)

(is-location ?from)

(is-location ?to)

(is-robot ?rob)

(isat ?rob ?from)

(not (isat ?rob ?to))

(isat ?b ?from)

(not (isat ?b ?to))

(opponent-goal-available)

)

:effect

(and

(not (isat ?rob ?from))

(isat ?rob ?to)

(not (isat ?b ?from))

(isat ?b ?to)

(oneof

(and (fluentopponentnear) (not (ballsafe)))

(and (not (fluentopponentnear)) (ballsafe))

)

(:action kick-to-goal

:parameters (?rob - movable ?b - movable)

:precondition

(and

(is-ball ?b)

(is-robot ?rob)

(isat ?rob kickingposition)

(isat ?b kickingposition)

(ballsafe)

(opponent-goal-available)

)

:effect

(and (isat ?b goaltarget) (not (isat ?b kickingposition)) (goalscored) (not (ballsafe)))

)

(:action carry-to-goal

:parameters (?rob - movable ?b - movable)

:precondition

(and

(is-ball ?b)

(is-robot ?rob)

(isat ?rob kickingposition)

(isat ?b kickingposition)

(opponent-goal-available)

(not (ballsafe))

)

:effect

(and (isat ?b goaltarget) (not (isat ?b kickingposition)) (goalscored) (ballsafe))

)

(:action pass-ball

:parameters (?rob - movable ?b - movable ?loc - location)

:precondition

(and

(is-ball ?b)

(is-robot ?rob)

(isat ?rob ?loc)

(isat ?b ?loc)

(not (ballsafe))

(jolly-available)

)

:effect

(and (ballpassed))

)

The use-case PDDL problem files are needed by the off-the-shelf planner to correctly initialize the planner, providing an :init block, which could be easily generated by the environment setup script. The goal is overwritten with the synthetic one during the domain compilation phase.

PDDL problem

(define (problem PROBLEM-NAME)

(:domain robocup)

(:objects robot1 ball - movable strikerposition ballposition kickingposition goaltarget - location)

(:init (isat robot1 strikerposition) (isat ball ballposition) (is-robot robot1) (is-ball ball) (is-location strikerposition) (is-location ballposition) (is-location kickingposition) (is-location goaltarget))

(:goal GOAL)

)

First Scenario: Reaching the ball

First, only the ball is made available by the conceptual layer. The goal is G0 = O(isat robot1 ballposition), where the PLTLf operator O(·) (”once”) was used to require that any generated trace satisfies the predicate ”isat robot1 ballposition” at least once. The resulting policy, features only one action that moves the robot to the ball position. The resulting policy is shown in the figure above on the left.

Second Scenario: Reaching the ball

At the conceptual layer, ”Score a goal ” and ”Score in the Opposite Goal ” are different (in the first case two goal posts are required to identify a goal, while in the second case four goal posts are required to identify two different goals and discern which one is the opponent goal), while at the decision-making level, the policy will be the same. The conceptual layer will provide at runtime the correct fluents to determine if a goal is available and the grounded position of the opponent goal. The resulting goal G1 = G0 ∧ O(goalscored) leads to a more complex policy: the additional PLTLf rule O(goalscored), requires that the goal is scored at least once along any generated trace. Given that the policy enumerates all possible combinations of predicates representing runtime fluents, only a single branch of the policy is shown in the figure above, in the middle.

Third Scenario: Reaching the ball

Scoring a goal on the SPL field. In case the full field is perceived (including the field lines), it is safer for the agent to assume the presence of the opponents on the field, adopting a safer strategy in order to ensure that a goal is scored.

The goal is G2 = G_SPL = G1 ∧ (ballsafe S isat robot1 ballposition), where the additional PLTLf construct (ballsafe S isat robot1 ballposition) requires the traces to keep the predicate ”ballsafe” verified in all states in the states following the state in which the predicate isat robot1 ballposition is verified for the first time: the agent will execute domain actions that keep the ball protected (these actions have the predicate ballsaf e in their post-conditions). Result is partially shown in the right part of the image above.

Tests on the Real Robot

The three use cases, we tested the whole architecture on the robot with the set of classifiers descripted in the image above. To this end, we will show here how the system behave with the same code, in three scenarios:

1) in a full field scenario where the robot apply the full set of the SPL rules,

2) in a scenario where there is no field in two different semantically-equivalent scenarios where the goal posts are represented by the real goal posts or by 2 soda cans.

3) where the is no field and no cans. In two equivalent scenarios without field components.

First Scenario: Full SPL Field:

fullFieldDetected.gif

Here the robot has detected the full RoboCup SPL Field and, hence, he uses the wider set of goals that includes: reach the ball, kick in the opponent goal and protect your own goal. The behavior is generated accordingly as a plan.

Second Scenario: Field with only a goal post (the two scenarios are semantically equivalent):

noFieldAndGoal.gif

noFieldAndCans.gif

Here the robot has detected only a couple of goal posts. In fact, the two scenes are semantically equivalent and, in fact, the two robots are acting in the same way since they represent the same scenarios. Here the set of goals includes: reach the ball and kick in the A goal. The behavior is generated accordingly as a plan.

Third Scenario: No field, just ball

output5.gif

justBall.gif

Finally, in this case, the robot has detected only the ball. Now, the set of goals includes only "reach the ball". The behavior is generated accordingly as a plan.

PDDL domain

PDDL problem

Scoring a goal on the SPL field. In case the full field is perceived (including the field lines), it is safer for the agent to assume the presence of the opponents on the field, adopting a safer strategy in order to ensure that a goal is scored.

Tests on the Real Robot

First Scenario: Full SPL Field:

Second Scenario: Field with only a goal post (the two scenarios are semantically equivalent):

Third Scenario: No field, just ball

Citation