Behavior related modules in B-Human¶
Ball Search¶
The current behavioral system at B-Human already implements a recognition that specifies when the ball position is assumed to be unknown. If this is the case, it automatically switches to the behavioral part described in this report, which implements the finding of an unknown ball. Each robot uses its own local grid of the field. To ensure that the whole field is covered without communicating, the Voronoi regions are used. Each robot uses only the part of the grid that lies within its own Voronoi region. This ensures that the entire field is covered to find the ball efficiently. The cell to look at next is determined by multiplying the priority and the difference between the timestamp of the last time the cell was looked at and the current system timestamp. The grid continues to be updated by the robot. This has the effect that the robot completely searches its own Voronoi region.
During the RoboCup 2023 in Bordeaux, B-Human used this module to find the ball in case of an unknown ball position. However, the module was only used in normal play, i.e. not in any standard situations. The exception is the standard situation kickIn. Here, the implementation was also used. The ball was recovered in an average time of 2.873 seconds. This results in a success rate of 100%.
Current Problems¶
The ball search works quite well, but some aspects still need to be adjusted: - The runtime of the module can still be minimised. - The behaviour of this ball search can also be used in standard situations, the basics are already there, it has to be checked whether the use of the grid-based search brings an advantage over the current behavior
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
Zweikampf State¶
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 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, 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
Zweikampfskill 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.