Team Strategy and Coordination
To effectively play soccer, it is important that different players have different roles and that they all work together well. When humans play soccer, we tend to assign specific team members to specific roles and then they maintain those roles through the whole game. For the robots, it is much easier to rotate the roles between the players as it allows us to more narrowly define each role. Our team currently has 5 roles:
- Attacker - This player is always going for the ball and trying to shoot towards the opponents goal
- Defender - This player tries to stay in the defending half and prevent shots as well as be in position to steal the ball from the other team's attacker
- Supporter - This player tries to stay near the Attacker in case a shot rebounds or gets stolen
- Defender 2 - This player works with the Defender to guard the goal, this player is exactly the same as the defender, except they move to a different position on the field to cover more area
- Goalie - This player stays in the goal to block shots. This is the only player who doesn't switch roles. The player with jersey number 1 is always the goalie.
These roles are designed so that one player will always be attacking the ball and that other players will try to be in positions where the ball might likely come. If the ball comes close to one of the other players, they will switch to be the attacker and try to kick the ball towards the goal. When our players can get to the ball and kick towards the goal quickly, this strategy works very well. An example of this strategy in action is shown below.
First, player 2 is the Attacker and is close to the ball with the Supporter (player 3) nearby. The opponent is about to kick the ball.
Once the opponent kicks the ball, it is close to player 3, so they become the Attacker and player 2 takes over the Support role.
During a game, the robots are allowed to broadcast wireless packets of information several times per second for their other teammates to listen to. This enables other robots to know what each of the others players is doing so they can make smart decisions about what they should do. The robots communicate a lot of information including details about their location, if they see the ball, their role, where they are going to, if they have fallen, etc. Much of this information is used to carry out the role switching algorithm, though some of it is used other places in the codebase as well.
For this strategy to work, player roles must be able to switch quickly in a decentralized environment. Since there is no central processing happening to tell all of the robots what to do, each robot must figure out their role on their own, but they also don't want to accidentally have everyone become Defenders or Attackers - we want exactly one of each role at all times (assuming all robots are in play, more on this later). There are two main steps to the role switching. First each robot computes the estimate of the team ball and then they use this team ball to compute the new roles.
The team ball is an estimate on the most likely location of the ball given the information from all team members, instead of just one robot. This location is based on how many robots see the ball and the probability that each of them is seeing the correct ball. If multiple robots see the ball at approximately the same location, then it is very likely that is the correct ball. If multiple robots see the ball in different locations, the one with the highest probability score is chosen. Since each robot has all of the same information that every other robot broadcast, each robot will compute the same location for the team ball. This ensures that when the role switching computations occur, all players are using the same estimate for the ball location and will therefore agree on the roles for each player.
To carry out the role switching computations, players compute the distance to the team ball and the distance to the goal for every player. These distances are then sorted and a series of checks performed to determine which player should take which role. There are a lot of edge cases to handle, but the general idea is that the player closest to the ball is the Attacker, the player closest to the defending goal is the Defender, the player second closest to the ball is the Supporter and the player second closest to the defending goal is the Defender2. The Goalie never changes. Once again, the idea here is that since every player has the same information and is using the same team ball location for all of the computations, the roles will distribute properly, even though there is no back-and-forth 'agreement' on the roles.
If there aren't 5 players on the field, the roles get assigned with approximately the same priority (Attacker, Defender, Supporter, Defender2) but can change depending on if the Goalie is in play or not (for example, if we have no goalie, a second defender is more important than a supporter).
More information about role switching and debugging can be found in Testing and Debugging Role Switching