Purpose

Attack

An attack-orientated robot position.

Description

The attacker either dribbles the ball towards the goal to score or tackles the ball off an opponent if they have possession.

Usage

Designed to be used by one robot as the main attacker.

Consumes

• message::purpose::Attack a task telling the robot to be an attacking player.

Emits

• message::strategy::WalkToKickBall when dribbling towards the goal.

Dependencies

• Director

Defend

A defending orientated robot.

Description

The robot hangs back in line with the edge of the penalty box, in line with vector between our own goal and the ball.

Usage

Designed for keeping the robot at the back in case the ball is taken towards our goal. If the ball gets close, the robot should switch to an attacking robot to take the ball.

Consumes

• message::purpose::Defend a task telling the robot to be a defending player.
• message::localisation::Ball to identify where to position relative to the ball.
• message::localisation::Field to measure the position to walk to in field space.
• message::support::FieldDescription to measure where the goals and penalty box are.

Emits

• message::strategy::WalkToFieldPosition to tell the robot where to walk to on the field.

Dependencies

• Director
• utility::math::euler::pos_rpy_to_transform to change the position and orientation into a homogenous transformation matrix.

FieldPlayer

A general soccer field player - not the goalie.

Description

In the READY mode, the player will dynamically position based on the number of team mates on each side. One robot (closest to the field center on the left side) will position either inside or just outside of the center circle for kick off.

The FieldPlayer will find the ball if it can't see it, and it will look at the ball if it can.

The closest robot to the ball will become an Attack player.

The closest robot to our own goal that isn't an Attack player will Defend. Any other player will Support.

If it's the other team's kick off and the kick off time isn't up and ball hasn't moved enough yet, the robot will wait.

In penalty positioning, the player will ReadyAttack. This will position the robot either offensively or defensively, ready for when play resumes.

Usage

Use this module by including it in the role and emitting a message::purpose::FieldPlayer message to run the robot as a dynamic field player.

Consumes

• message::purpose::FieldPlayer a task telling the robot to be a field player.
• message::localisation::Ball for determining who is closest to the ball, to become the Attack player.
• message::localisation::Robots to determine where team mates are and who has possession of the ball.
• message::input::Sensors to include ourselves in the list of robots.
• message::localisation::Field to calculate in field space.
• message::input::GameState for penalty and kick off information.
• message::input::GameState::Phase to know if it is the READY phase, or PLAYING, or another phase of the game.
• message::support::GlobalConfig to get our own player ID.
• message::support::FieldDescription to calculate ready positioning.

Emits

• message::strategy::FindBall tells the robot to find the ball if it hasn't seen it in a while.
• message::strategy::LookAtBall tells the robot to look at the ball if it does know where it is.
• message::strategy::Attack tells the robot to act as the attacking player.
• message::strategy::ReadyAttack tells the robot to get ready to attack, but something is preventing it from actually attacking (penalty positioning, kick off).
• message::strategy::Defend tells the robot to hang back near the goals to defend.
• message::strategy::Support tells the robot it's not the attacking or defending player, it should instead act as support.
• message::strategy::WalkToFieldPosition task to walk to the calculated ready position.

Dependencies

• Director
• utility/strategy/positioning.hpp
• utility/strategy/soccer_strategy.hpp

Goalie

Description

Play soccer in the goalie position.

In the ready state, walks to the goals.

In the playing state, the goalie will typically stay within the goals unless the ball enters our half. In this case, it will either kick it back out (if the closest player) or it will stay between the ball and goals if another player is closer. In penalty states, it will freeze when appropriate and position for attacking if the ball is in our half and it is the closest to the ball.

If there are no teammates, it will act as a normal FieldPlayer.

If the ball is not visible it will look around without moving.

Usage

Add this module to the role and emit a Goalie Task.

Consumes

• message::strategy::Goalie a Task requesting to play as a Goalie
• message::input::GameState to get information about the state of the game, including penalties
• message::input::GameState::Phase to get specific information about the current game phase (initial, ready, set, playing, etc).
• message::localisation::Ball for determining if the ball is in our half, and act appropriately.
• message::localisation::Robots to determine where team mates are.
• message::input::Sensors to include ourself in possession and distance calculations
• message::localisation::Field to calculate in field space.
• message::support::GlobalConfig to get our own player ID.
• message::support::FieldDescription to calculate where the goals are for positioning.

Emits

• message::strategy::StandStill a Task requesting to stand still and not move, outside of READY or PLAYING
• message::planning:::LookAround a Task requesting to look around for the ball
• message::strategy::LookAtBall a Task requesting to look at a known ball
• message::strategy::WalkToFieldPosition Task requesting to walk to position on field, for positioning at the goals
• message::strategy::Attack tells the robot to act as the attacking player when the ball is close to the goals
• message::strategy::ReadyAttack tells the robot to get ready to attack, but something is preventing it from actually attacking (penalty positioning, kick off).
• message::purpose::FieldPlayer a task telling the robot to be a field player, when there are no teammates.
• message::purpose::Purpose information on the position the robot is playing (goalie), its ID and active state.

Dependencies

• Director

KeyboardWalk

Description

Starts the Director graph for the KeyboardWalk scenario.

Keyboard walk uses keyboard inputs to control the robot. The inputs available are detailed in the following table.

Usage

Include this in your role to start the Director tree to run KeyboardWalk.

Consumes

Emits

• message::strategy::StandStill to make the robot still while not walking
• message::behaviour::state::Stability to set the robot's initial stability state
• message::strategy::FallRecovery to enable getting up when fallen
• message::skill::Kick to kick with left/right leg
• message::skill::Look to look in desired direction
• message::skill::Walk to walk with desired velocity

Dependencies

• Director
• ncurses

ReadyAttack

An attacking player who can't attack yet, and must get ready.

Description

If it is kick off, we aren't the kick off team if we can't attack yet. Position outside the center circle and wait for play to properly start.

If it is a penalty state and we aren't the attacking team, position in line with our goal and the ball to defend at the distance back specified in the rules.

If we are the attacking team, walk around to position behind the ball, ready to play.

Usage

Include this module and emit a ReadyAttack task if the robot cannot attack due to the game state.

Consumes

• message::purpose::ReadyAttack a task telling the robot to ready for attacking.
• message::input::GameState to determine which team is taking the penalty.
• message::support::FieldDescription to determine positioning relative to the goal.
• message::localisation::Field for measurements in field space.
• message::localisation::Ball to position relative to the ball.

Emits

• message::strategy::WalkToFieldPosition to position the robot on the field away from the ball, for defending situations.
• message::strategy::PositionBehindBall to position the robot behind the ball without kicking it.

Dependencies

• Director
• utility::math::euler::pos_rpy_to_transform for field position matrix creation.

Soccer

Description

Coordinates the high-level soccer behaviour state machine.

This module manages when the robot should actively play, idle, or pause due to penalties, then starts the purpose-selection flow and persistent recovery behaviours.

Key responsibilities:

• Startup initialisation (Stability, WalkState, idle stand/look)
• Starting purpose selection (FindPurpose) and always-on fall recovery
• Selecting Goalie or FieldPlayer based on GameState.self.goalie
• Handling self penalisation/unpenalisation transitions
• Handling button-based idle enable/disable flow with configurable delay

Usage

Include this module in a soccer role.

Configuration is read from Soccer.yaml:

• force_playing: if true, forces GameState::Phase::PLAYING
• disable_idle_delay: delay (seconds) before exiting idle after middle button press
• startup_delay: delay (seconds) before starting soccer behaviours after startup

Control flow:

• Left button (ButtonLeftDown) enables idle mode (pauses soccer tasks)
• Middle button (ButtonMiddleDown) disables idle mode after disable_idle_delay
• On penalisation (GameEvents::Penalisation for self), purpose tasks are cancelled and localisation/servo state is reset
• On unpenalisation, purpose and fall-recovery tasks are restarted (unless idling)

Consumes

• extension::Configuration from Soccer.yaml
• message::input::GameState
• message::support::GlobalConfig
• message::input::GameEvents::Penalisation
• message::input::GameEvents::Unpenalisation
• message::input::ButtonLeftDown
• message::input::ButtonLeftUp
• message::input::ButtonMiddleDown
• message::input::ButtonMiddleUp

Emits

• message::behaviour::state::Stability
• message::behaviour::state::WalkState
• message::skill::Walk
• message::skill::Look
• message::purpose::FindPurpose
• message::purpose::FieldPlayer
• message::purpose::Goalie
• message::strategy::FallRecovery
• message::purpose::Purpose
• message::localisation::ResetFieldLocalisation
• message::platform::ResetWebotsServos
• message::output::Buzzer

Dependencies

• Director

Support

Description

This module runs a support field player. It stays aligned with the ball on the y-axis, and stays a quarter of the field length away from the ball on the y-axis on whichever side is closest to the robot. It is then ready to take over as the attacker if the attacker becomes inactive.

Usage

Include this module and emit a Support Director task to have the robot act as a support player. Intended to be used when teammates already occupy the attack and defend roles.

Consumes

• message::purpose::Support a task telling the robot to be a supporting player.
• message::localisation::Ball information on where the ball is, to align with it.
• message::localisation::Field to perform calculations in field space for positioning.
• message::input::Sensors to get the position of the robot.
• message::support::FieldDescription for positioning relative to field width.

Emits

• message::strategy::WalkToFieldPosition to tell the robot where to walk to on the field.

Dependencies

• Director
• utility::math::euler::pos_rpy_to_transform to change the position and orientation into a homogenous transformation matrix.

TeamBehaviourTester

Description

Drives the FieldPlayer team behaviour logic for the test/teambehaviour role without letting it control the robot.

Every tick it synthesises a "we are playing a normal game" GameState (PLAYING phase, not stopped, unpenalised) and requests the FieldPlayer purpose. This makes FieldPlayer run its real in-game decision logic - based on the localised ball, teammates and field - and emit the Purpose (the role it would take: attack, defend, support, etc.) and, when supporting, a SupportPosition. Both are forwarded to NUsight for visualisation.

The robot itself is still driven around manually by KeyboardWalk. FieldPlayer's own locomotion tasks (Attack, Defend, Support, ...) are deliberately left without providers in the role, so they are inert and the robot never moves on its own - this module only reports what role the robot would take if it were in a real game.

Usage

Include this module in a role alongside purpose::FieldPlayer, extension::Director, localisation and purpose::KeyboardWalk. See roles/test/teambehaviour.role.

Consumes

• message::input::GameState and message::input::GameState::Phase to trigger the FieldPlayer decision logic.

Emits

• message::input::GameState - a synthetic PLAYING game state.
• message::input::GameState::Phase - the PLAYING phase guard read by FieldPlayer.
• message::purpose::FieldPlayer as a Task to activate the field player purpose.

Dependencies

• extension::Director
• module::purpose::FieldPlayer

Tester

Description

This module allows the user to select various combinations of strategies and planners with different priorities for testing purposes. For example, you may want to only test walking to the ball and kicking, which can be achieved by only enabling the WalkToBal and KickTo tasks in the config.

Usage

Add this module and enable/disable strategies and planners in the config which you wish to test.

Emits

If enabled in the config the module emits the following.

• message::strategy::StandStill a Task requesting to stand still and not move
• message::strategy::FindBall a Task requesting to look and move around to find the ball
• message::strategy::LookAtBall a Task requesting to look at a known ball
• message::strategy::WalkToBall a Task requesting to walk to a known ball
• message::planning::KickToGoal a Task requesting to kick the ball towards the goal
• message::planning::KickTo a Task requesting to kick the ball if close
• message::strategy::StandStill a Task requesting the robot to stand still
• message::strategy::LookAround a Task requesting the robot to look around
• message::strategy::WalkToFieldPosition a Task requesting the robot to walk to a specified position

Dependencies

• Director
• Eigen