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 subset 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 that 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 some constraints for every kick direction as well as a subset 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, such as: 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. In addition, kicks that place the robot into another robot are given worse ratings, while goal kicks and kicks similar to the previously 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 of 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, as 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 as 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
Zweikampf State¶
Indirect Kick Rule¶
In case the robot is not allowed to kick at the goal yet, the ball is dribbled towards the opponent penalty mark instead. Strong kicks are still allowed, but discouraged in the direction of the goal.
Parameters¶
The parameters are split up into different groups:
SearchParameters: all parameters for the search of the subset 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 theZweikampf.
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, as 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
Zweikampfskill will not dribble to the pass target. If the range is 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 minimum angle would reduce the risk of kicking outside even further.