-
Notifications
You must be signed in to change notification settings - Fork 4
Behaviour
Other than the goalie, roles are dynamically assigned to each robot on the field based on their positions and the position of the ball.
The general rule for evaluating whether the robot should take on the role in question is:
- If no one else is in this role, take it
- Approximate time to get to the position of the role. If this time is less than any other robot, take the role. As a form of hysteresis, slight bonus to this time is given if the role in question is the same as the current role.
The order in which roles are evaluated is:
- Striker
- Defender
- Midfielder
- Upfielder
The function to approximate time to reach given role is a weighted sum of the distance to target position, heading to target, and the required heading after reaching the target. For striker, the ball is the target position and the required heading is heading towards to enemy goal. For other roles, see Positioning policies for their target positions.
Robots' roles and their own time approximations is broadcasted as team data. However, no agreements are made and each robot will evaluate their own roles based on the team data.
Other than the striker and goalie, the remaining 3 robots are classified as supporters. They share the same behaviour, but different positioning strategies depending on the position of the ball. The role of the supporter is to occupy designated areas on the field while keeping track of the ball if it can. Its goal is to not obstruct the striker, and be in a good position to switch into the striker role when the ball gets near.
For our kickoff play, the supporter charges forward for a few seconds towards the enemy goal, anticipating an implicit pass from the striker that would land in the vicinity. The aim is setup the supporter to switch into striker, maintaining possession of the ball and move further into the enemy half. Only the midfielder and upfielder that are close to the starting positions will consider this.
The supporter prioritises in finding the ball, since it assists with localisation for the entire team. The find ball behaviour task walks around in the direction of the team ball, or the last known ball location if team information is not available. The localisation module decides when the ball is found. This does not necessarily mean the ball is in vision.
The supporter walks to its designated position on the field when the ball is not lost. Often when the ball rolls towards the supporter, the supporter moves away due to its positioning policy. However, the supporter will only get a chance to switch into striker when it can see the ball. To aid this, the supporter will keep facing the ball while walking in the first few seconds. After this, the supporter faces the direction of its target position until it arrives. The supporter will face the ball if it's rolling towards the supporter, since the likelihood of switching into striker is high.
When the supporter arrives at its designated position, it will stand tall(prevents overheating) and look at the ball. If the supporter haven't seen the ball in vision for a long time, it spins and tries to search for the ball in vision without relying on any team information. This is because the supporter can possibly "flip" due to mislocalisation and thinks it's looking at the team ball. But the ball is in the opposite direction in the real world and it never sees the ball. Searching for the ball in vision and seeing the real ball can help correct its localisation quicker.
The supporter needs to avoid robot obstacles, the ball, and the centre of the field to minimise obstructing the striker and other robots. The potential field approach is used to plan its path towards the target position. The idea is that the supporter is moved by the vector sums of the attractive force of the target and repulsive forces from the obstacles. This is achieved by defining potential functions where the obstacles are on "high ground" and the target is at "low ground". The supporter follows the negative gradient of the total potential to get to the target.
The repulsive potentials of robot obstacles were turned off for debugging purposes. It still uses the emergency avoidance maneuver defined in the walkToPoint behaviour task, which simply side steps when an obstacle is sensed from the sonar.
The positioning policies were designed with these factors in mind:
- easy to implement and reason about
- minimise moving around and save energy
- get good observations of the ball and field features
- minimise obstructing other robots
The robot is positioned based on the current position of the ball. The field is divided into sectors, and the policy is if the ball is in the given sector, go to the position shown by the matching colour. The position is just a circular region on the field. When the robot arrives, it can stop and stand still until it needs to relocate.
Our Striker strategy took into account many different aspects of the environment in order to determine what course of action was best. This could easily turn into a list of undecipherable if statements, so care was taken to structure the decision hierarchy in such a way that it would be clear and maintainable, as well as flexible.
The Striker's intention was boiled down to the following variables, which were set by the strategy component. The rest of the Striker code read from these variables in order to determine what to do.
-
kick_mode
: This was one ofKICK
,DRIBBLE
, orTURN_DRIBBLE
-
kick_target
: The global(x, y)
coordinates of where the ball needs to end up -
kick_hard
: A flag determining whether we should kick as hard as we can in the direction of thekick_target
, or try to get the ball to land at thekick_target
The strategy code therefore just needs to come up with values for these variables somehow. This decision making process was divided into two parts: the high-level target, and the target adjustments. The high-level target was an expression of intent without taking into consideration other opponents on the field. Target adjustments took into account the robot's immediate surroundings, and adapted the target in order to better achieve its goal.
The following outcomes were decided between using a variety of decision variables, most having been passed through Hystereses. The outcomes were prioritised in the following order, with the first decision evaluating to true being executed.
- Penalty Kick: It's a penalty shootout. Aim to the edge of the goals, either to the left or right.
- Kick-off play: It's a kick-off. Determine whose kick-off it is. If it's our kick-off, wait 10 seconds and get the ball into the position that the Supporter role is currently moving to.
- Corner Play: The angle to the goal is too sharp, because we're in one of the opponent's corners. Attempt to place the ball near the penalty spot.
- Pass upfield: We're too far from the goal to reliably shoot. Try to place the ball in the direction of the goal but a safe distance back, so that it doesn't go out.
- Goal center: We're within range, but we're too far to do anything fancy. Shoot for the centre of goal as hard as possible.
- Goal lazy angle: We're well within range, to the point where there's no need to turn all the way to face the centre of the goal. We calculate a position to shoot for which requires minimal change of heading while still getting the ball in. This might be straight ahead as we are, or it might mean aiming a little bit towards the centre to clear the left or right post.
Each of these high-level goals decided whether they allowed target adjustments on their instructions or not. For example, if we were very close to the goal, target adjustments were deactivated.
Whether to apply an adjustment or not was decided upon through conditions which were passed through Hystereses. They were evaluated in the following order, but sometimes multiple adjustments could occur on the same target.
-
Close Quarters Combat: An opponent has been detected near the ball. Forget trying to shoot to the goal, get in front of their shot and
TURN_DRIBBLE
the ball away from their feet. -
Ronaldo: There's an opponent occluding our shot to target. Adjust our aim to avoid the opponent, and change a
KICK
to aDRIBBLE
instead if our adjusted heading is no longer aimed at the goals. -
Ball Contended: There are opponents near the ball. Change a
KICK
to aDRIBBLE
instead
##Goalie
As the last line of defense robot, the task for goalie is to cover goal post as much as possible and block goals effectively. In order to achieve this, goalie need keep switching cover position regarding to ball position and angle related to goal post while the ball is in our side but far from goal box, and dive to appropriate direction to save the goal when enemy shoot the goal. Also, once enemy enter its score range and goalie is the robot closest to the ball at the meanwhile, goalie will become striker to defend more aggressively. Moreover, in this year, goalie is allowed to use hands to touch the ball to perform more advanced defense strategy when he is inside the goal box. Therefore, we develop a pick up strategy for goalie and once the ball is successfully picked up, it will be placed at the center of field.
There are two cover goal states in current goalie behavior, one is STATE_COVERGOAL, the other is STATE_DYNAMICCOVER. The first one is used when the ball is in our side but distance between ball and goalie is greater than 3m. In this state, goalie just simply stands at the top of goal box to prepare for attacking. When ball is closer to goalie, less than 3m, goalie state will switch to STATE_DYNAMICCOVER. In this case, goalie will switch its positions more frequently regarding to the ball's position.
As shown in the following diagram, within STATE_DYNAMICCOVER, an oval curve will be generated within the goal box. First, we get the angle ɑ, which is the ball heading, and calculate the corresponding radius of the oval curve and finally get the correspond x and y coordinate position. This is exactly the cover position.
The condition to trigger dive action is that the time for ball passing goalie is less that 4 sec and distance between ball and goalie is less than 700 cm which goalie is reachable. Also the ball’s y coordinates position need to be within goal box range. Once the dive condition is satisfied, goalie need to choose which direction to dive in range of left, right and center dive. This is decided by the relative distance between ball and goalie, if the relative distance is within center threshold goalie will perform center dive, if relative distance is less than the threshold left dive will perform otherwise will perform right dive. Also, in order to filter out the noise from vision, hysteresis is adopted so the first five decisions will be omitted.
There are some blind spots in goalie’s vision especially when the ball is just next to goalie’s foot. But its shoulder will block the view sight when goalie performs a scanning. So this state is designed to handle this special case. The condition to trigger this state is that the team ball indicates the ball is nearby goalie but goalie hasn’t seen the ball greater than 200 frames. In this state goalie will spin left 180 degree and right 180 degree in turn in order to find the lost ball.
The spin state is used to recover from mis-localization, which goalie think it is in correct position but actually not. The condition to trigger is that goalie hasn’t seen a far goal post for 400 frames. Once condition is satisfied, goalie will spin around about 2 seconds to re localize from the new land mark.
This state will be trigger only when the ball and goalie are both in the goal box. Also sonar do not detect object in front of goalie because if there is other robots nearby, kick off the ball will be more efficient than pick up.