# Behavior¶

Last update: 10.09.2022

## FieldRatingProvider¶

The module FieldRatingProvider provides functions to calculate a potential field for the Zweikampf and DribbleToGoal skill. Different potential fields are supported, which all use a base computation of linear scaling from a repelling or to an attracting point on the field. Weighted based on their ratings they are summed up to give a value for each point on the field for the Zweikampf skill or just the directional value for the DribbleToGoal skill.

The following potential fields are provided (see Potential Fields):

• Field Border: the field border is a repelling field.
• Goal: the opponent goal is an attracting field.
• Opponent corners: the opponent corners are repelling fields, to help dribbling in an arc towards the goal from the corner instead of a direct line.
• Obstacles: obstacles are repelling fields, no matter if it is a robot from our or the opponent team. But based on the communication the communicated teammate positions are used to reduce those repelling fields.
• Teammates: based on the communicated positions an attracting field in front of the teammate is created.
• Ball: an attracting field a fixed distance in the direction of the goal. Small dribble kicks are therefore always good, really short or far ones are bad.
• Facing direction: an attracting field based on the current direction the robot is facing.

You can use the following command, to see the drawings for each potential field in the world state:

call Drawings/FieldRating


### Potential Fields¶

FieldBorder
Goal
Opponent Corner
Obstacles Base Two Obstacles Obstacles with Teammate
Teammate Ball Facing
Sum Example 1 Sum Example 2 Sum Example 3

### Current Problems¶

Here we list current problems with the used FieldRating:

• Some potentials have edges and not smooth interpolations.
• The pass field could be larger.
• Our jersey detection is not good enough, to distinguish between opponent and teammate.
• Facing potential could probably be deleted.

## DribbleToGoal¶

The DribbleToGoal skill dribbles the ball to the goal, but tries to avoid obstacles and handles the field border to not dribble outside. For this the potential field from the representation FieldRating is used. Based on the last direction, the potential field direction 1 cm further is determined in a loop, until a distance of one meter is reached. The end position is then used to calculate the base dribble direction. Afterwards a sector wheel and the distances to the field border are used, to determine the nearest best dribble direction. The potential field and sector wheel usage is shown below.

You can use the following command, to see the drawings in the world state, whenever the robot is executing the DribbleToGoal skill and is near the ball:

call Drawings/DribbleToGoal


### Current Problems¶

The skill works quite well, but still has a few short comings:

• Near the opponent goal posts the resulting directions tends to dribble directly into the goal post.
• Different kick ranges, which the walk kicks support, are not used. The problems comes from the kicks themself, because they have high range deviations.
• Kicks near the field border are handled by using a minimal distance to the field border. Additionally using a minimal angle would reduce the risk of kicking outside even further.

## Zweikampf¶

In situations when the ball is near another robot, we use the skill Zweikampf. The state procedure can be seen below. At the start we update the last direction based on the changes in the RobotPose, because the calculated direction is in relative robot coordinates. Here we also handle requests from the higher behavior like passing or dribbling. Afterwards based on this updated last kick direction a sub set of directions around it are determined. The number of directions are kept small, because the computation time grows fast. For every direction every kick type and multiple ranges must be checked, therefore we only check a subset, which finds the local best direction over multiple execution cycles.

After determining the list of directions, we calculate a sector wheel, to add directions to the goal and get the information about the distance to an obstacle in a given direction. With those information, we check for every kick direction some constraints and a sub set of ratings from a potential field, provided by the representation FieldRating. This is done once per direction, to save computing the same field positions multiple times. Afterwards we determine the final rating for every kick type for the given direction. Here a handful of kicks are filtered through some constraints, like the robot is only allowed to turn by a maximum rotation to adjust for a given kick pose or the kick would place the ball outside the field. Also kicks that place the robot into another robot are given worse ratings, while goal kicks and kicks similar to the previous determined kick are given better ratings.

Now we have a list of kick types, with directions, ranges and ratings. They are sorted by four categories: goal, steal, pass, other. A kick-off type goal is always better than every other kick, even if the rating is a lot worse. These categories are used to make sure, given the current context, a good kick is always selected.

Last but not least a precision range is calculated. This information is used by Motion to start a kick early, because it then knows how much the kick direction is allowed to vary, while still executing walking steps for the target direction.

In case no kick was calculated, because all kicks were filtered out, the robot will simply walk between the own goal and the ball. This can normally only happen, if the Zweikampf is active near the opponent ground line and the ball lies between the ground line and the own robot, while the nearest detected obstacle is too far away from the ball. In this case every kick would place the ball outside the field, the forward steal cannot start because the obstacle is too far away and the robot is not allowed to turn that much. To resolve this problem, after a short time the Zweikampf starts the DribbleToGoal skill, which can turn as much it wants and dribble the ball to the goal.

You can use the following command to see the different drawings in the world state, whenever the robot executes the Zweikampf skill:

call Drawings/Zweikampf


### Parameters¶

The parameters are split up into different groups:

• SearchParameters: all parameters for the search of the sub set of kick directions.
• DuelRatings: the additional ratings for bonus and malus, like goals, similarity of the previous kick or a kick pose inside another robot.
• DuelTimings: timing parameters to artificially keep the forward steal active or when to start dribbling if no kick is possible.
• ObstacleHandling: all parameters to handle detected obstacles.
• StealBallParameters: parameters for the forward steal kick.
• allowedKicks: all allowed kick types to be used for the Zweikampf.

### Current Problems¶

The Zweikampf skill works really well, but still has some problems that are planned to be solved in the future:

• The skill still takes too much computation time. The potential field takes most of the time. Many ranges do not need to be calculated, because the kicks, that need the result, are often filtered out.
• A lot more hysteresis is needed. Goal kicks are filtered out in one computation cycle, but used again in the next one. The kick directions are adjusted in every cycle, because a direction was selected at the border to an obstacle sector.
• The pass skill request from the higher behavior is only used, to improve the teammate rating from the potential field. The Zweikampf skill will not dribble to the pass target if the range too far away, goal kicks are preferred over passes and back passes are filtered out completely.
• Kicks near the field border are handled by using a minimal distance to the field border. Additionally using a minimal angle would reduce the risk of kicking outside even further.