Behaviour

The behaviour subsystem includes the purpose, strategy and planning layers of the system. These utilise the Director system and will be made up of Providers and Tasks. The behaviour subsystem is responsible for the high-level decision making of the robot.

Planning

The planning layer is given a straightforward goal and uses mathematics to determine how to achieve that goal using skills. These skills are generally motions, such as kicking, walking and getting up. Examples of planners are the walk path planner and the kick planner.

Walk Path Planner

There are three main walk path planners. Each are Providers and emit Walk Tasks.

• WalkTo: This planner is given a vector position and heading to walk to in robot space. It moves towards the position linearly and rotates to reach the given heading. As it approaches the position to walk to, it decelerates so it stops smoothly.
• TurnOnSpot: This planner is given a direction to rotate (clockwise or anti-clockwise) and rotates in that direction on the spot.
• TurnAroundBall: This planner assumes the ball is in front of the robot and pivots around it so that the ball is still in front of the robot. It is given a direction to rotate (clockwise or anti-clockwise). This is useful for aligning the robot with the ball and a target, ie the ball or a teammate.

Kick Planner

The kick planner checks if the ball is close enough to kick and if we are aligned towards our target, ie goal or teammate. When these conditions are satisifed, it emits a Kick Task.

Look Planner

Looking does not often need planning functionality behind it, as a vector to look to can be given directly to the skill. We do implement a LookAround planner that oscillates between points given from the module's configuration file. This is useful for looking around the field for the ball.

Strategy

The strategy modules contain a high-level request that utilises environment information and the planning layer to achieve its goal. The module/strategy folder contains these strategies. We list some of these with their functions below.

• StandStill: uses the walk engine to stand still.
• FindBall: if the ball is not visible, uses the look and walk planners to find it
• WalkToBall: uses ball localisation to emit a Task to the walk path planner.
• LookAtBall: uses ball localisation to emit a Task to the look planner to look at the ball.
• KickToGoal: uses field localisation to determine when to emit a Task to the kick planner.
• AlignToGoal: uses field localisation to determine when to emit a Task to the walk path planner to pivot around the ball to face the goal.

Purpose

The purpose layer determines the overall goal of the robot. For soccer-playing, it contains the logic for soccer positions. These modules form the root of the Director tree.

Soccer

The Soccer purpose uses GameController information to determine how to act. If it is penalised, then it stands still. If it is not penalised, it determines whether to play as a striker, defender or goalie.

• Striker: An offensive position that attempts to score goals by moving towards the ball and kicking to the goal.
• Defender: A defensive position that attempts to prevent the opponent from scoring goals by moving towards the ball and kicking it away from the goal if the ball is in our half.
• Goalie: A defensive position that attempts to prevent the opponent from scoring goals by staying in the goal area and diving towards the ball if the opponent tries to score.

Keyboard Walk

The keyboardwalk module is a purpose-level module used for testing and demonstration purposes. Keyboard walk can use any of the walk engines in the codebase, and acts as an interface for any one of them.

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

To use KeyboardWalk, build the keyboardwalk role and run the binary.

The fake/keyboardwalk role uses HardwareSimulator, and is useful for when you don't want to run keyboard walk on the robot.

PS3 Walk

The PS3 walk module is an interface for testing and demonstrating the walk and other functionalities using a PS3 controller.

The module connects to the PS3 controller using USB or bluetooth and reacts based on joystick or button input.

To use this module, build the PS3Walk role and install it on the robot. Ensure the PS3 controller is paired and connected to the right robot. You can set up bluetooth on the robot and pair the controller using the steps below. Once these have been run once, the robot should automatically connect to the controller when both the robot and controller are powered. When you are ready, run ./ps3walk on the robot to begin controlling it.

The robot will initially not perform any action. If you want the robot to stand, pick up the robot and press the start button. It will then move to its standing position and begin looking for walk inputs.

Setup

1. Install bluez, bluez-utils, and bluez-plugins if they have not already been installed:

   Copy
   pacman -S --needed bluez bluez-utils bluez-plugins

2. Restart the system:

   Copy
   reboot now

   This is only necessary if the packages were not previously installed.
3. Start the bluetooth service:

   Copy
   systemctl start bluetooth.service

Pairing the PS3 Controller via Bluetooth

1. Unplug and power off the PS3 controller.
2. Run the interactive program bluetoothctl, and type the following commands:

   Copy
   power on
   scan on
   discoverable on

   If bluetooth is working correctly, you might see other devices appear and disappear.
3. Turn on the PS3 controller by pressing the middle PS button. The four LEDS should start flashing quickly.
4. Plug the PS3 controller into the computer with a USB cable.
5. Type yes when the following prompt appears:

   Copy
   Authorize service 00001124-0000-1000-8000-00805f9b34fb (yes/no)

The PS3 controller is now paired. You can unplug it and it will remain connected.

Verifying the PS3 Controller is functioning correctly.

Verifying the PS3 controller is connected and sending messages is useful for debugging the range, interference, event codes, and making sure the controller is connect to the right robot.

1. Install joyutils:

   Copy
   pacman -S --needed joyutils

2. If you are connected via ssh run:

   Copy
   jstest --event /dev/input/js0

   Otherwise, if you're connected to a virtual console:

   Copy
   jstest /dev/input/js0

3. Move controller inputs, and press Ctrl + C to exit.

Connecting multiple PS3 controllers is possible. The first PS3 controller that connects is located at /dev/input/js0. The second controller that connects is then located at /dev/input/js1. Additionally, the LEDs on the controllers show which number they are. This holds true regardless of whether the controller is connected over Bluetooth or USB.

Script Runner

ScriptRunner is a purpose-level module. It takes the name of one or more script files as arguments and attempts to run the scripts. It does not take file paths, only the file name/s of the script/s to execute.

When ScriptRunner is executed, it stores the script file names passed to it as a vector of strings. When the green button on the robot is pushed, the scripts are executed in order of appearance, one after the other. ScriptRunner also provides an option to set a delay before the execution of the first script, as well as a delay between the execution of each script.

An example of using ScriptRunner to run a script called Stand.yaml is:

Copy
./scriptrunner Stand.yaml

Script Tuner

ScriptTuner is a purpose-level module. Using a command-line argument, it can either create a new script or open an existing script for editing. It uses curses to create a user interface in the terminal. Through this user interface, YAML files are created or edited that specify a script that can then be used by other modules.

A script consists of frames (also called targets) which specify the position of one or more servos at a given time. The ScriptTuner interface allows for stepping through and modifying those frames. When a frame is selected in ScriptTuner, a ServoCommand for that frame will be emitted to the robot. By stepping through multiple frames, the entire script can be played back on the robot, allowing the user to preview changes to the script.

ScriptTuner also allows for "locking" and "unlocking" servos on the robot. When a servo is "locked", its position can only be changed in ScriptTuner. When it is "unlocked", the servo can be moved physically on the robot, which will update the position value in the script. Locking a servo involves emitting a ServoCommand for the current position of the servo. Unlocking the servo involves emitting a ServoCommand with zero torque and gain.

To learn how to use ScriptTuner, read the ScriptTuner guide.

RoboCup Rules

Currently up to date with the 2024 competition rules.

The latest competition rules as well as previous years' rules can be found on the RoboCup Humanoid League website.

Play-States and Penalty Considerations

There are unique states in the game where the robots need to behave differently to regular play. For example, if the opposing team has been granted a free kick, we might need to stand still, or move out of the way for the duration of the kick.

All free kicks are taken from the place where the offence occurred, except:

• Indirect free kicks to the attacking team for an offence inside the opponent's penalty area are taken from the nearest point on the penalty area line which runs parallel to the goal line.

• In the physical competition, free kicks to the defending team in their goal area may be taken from anywhere in that area

Until the ball is in play all opponents must remain:

• 0.75m for KidSize and 1.5m for AdultSize from the ball until it is in play, unless they are on their own goal line between the goalposts

• Outside the penalty area for free kicks inside the opponent's penalty area