Rule Changes: Visual Referee

[pejotejo]

There are multiple changes in the rule book regarding Visual referee:

1. Game Controller does not send the kicking team anymore. It still sends the SetPlay, but the indication of the kicking team is done visually.
   In most of the situation we can guess the team (Goal Kick, Kickoff, Freekick, Penaltykick, Cornerkick), but in others it is more difficult (Kickin).

2. Initial Ready signal is not send at all. Motion ins standby will be updated

Also on could think about switching from YOLO to MoveNet

[ThagonDuarte]

The first major issue I faced is the handling of not knowing the kicking team in all situations. Currently, the kicking team is always set in the FilteredGameControllerState. We have one edge case currently handled during Ready, which was addressed in #1427. Here a kicking_team_unknown boolean is introduced to the FilteredGameState Ready enum. This is however not a sustainable solution, as this is highly confusing when the case of not knowing the kicking team occurs more frequently. In that case, whenever one needs to read the kicking_team in the FilteredGameControllerState, one also has to check kicking_team_known in FilteredGameState to check the validity of kicking_team.
A solution to this would be to change the kicking_team to a Option<Team>. This has, however, major consequences, as the None case has to be handled non-trivially in several places in behavior.

[ThagonDuarte]

After handling not always knowing kicking_team, the next step is to implement the behavior of looking at the referee during the four free kicks SubState: GoalKick, PushingFreeKick, CornerKick and KickIn.
My approach would be to introduce an Action LookAtReferee which produces a Stand Motion with a HeadMotion that looks at the expected_referee_position.
Which role performs this action is mainly a strategic behavior choice. It is not clear for me yet, which role is best suited for this.

[ThagonDuarte]

Next, with the Nao actually looking at the referee, the detection would produce a FreeKickPose PoseKind which contains a Side indicating the defending teams side. This is done by simple geometric comparison of the Keypoints of the referees HumanPose.

[ThagonDuarte]

Finally, with a valid FreeKickPose detection, the kicking_team can be set in the FilteredGameControllerState. This then has to also be propagated to other NAOs via a game controller message.

[ThagonDuarte]

Current todos:

• Handle not knowing the kicking_team
  • Also use team_ball in KickingTeamFilter. Depends on Striker transition from ball search to normal role assignment is riddich broken #1412
• Implement behavior for looking at the referee for pose detection during set plays.
• Implement detection logic and filtering.
• Use detection to set kicking_team and propagate to other Naos.

Next iteration:

• Determine kicking_team directly by looking at the Penalty set in the same GameControllerMessage as the transition to the SubState PushingFreeKick.

[ThagonDuarte]

The first major issue I faced is the handling of not knowing the kicking team in all situations. Currently, the kicking team is always set in the FilteredGameControllerState. We have one edge case currently handled during Ready, which was addressed in #1427. Here a kicking_team_unknown boolean is introduced to the FilteredGameState Ready enum. This is however not a sustainable solution, as this is highly confusing when the case of not knowing the kicking team occurs more frequently. In that case, whenever one needs to read the kicking_team in the FilteredGameControllerState, one also has to check kicking_team_known in FilteredGameState to check the validity of kicking_team. A solution to this would be to change the kicking_team to a Option<Team>. This has, however, major consequences, as the None case has to be handled non-trivially in several places in behavior.

A list of all cases where None of kicking_team: Option<Team> has to specifically handled:

1. In ball_state_composer.rs a side_factor uses the kicking_team. What is its value for kicking_team == None`?
2. In stand.rs the kicking_team is read multiple times to determine the Half.
3. In localization.rs the kicking_team is used to modify_state().
4. In rule_obstacle_composer.rs the create_penalty_box() uses the kicking_team.
5. In search_suggestor.rs uses the kicking_team to determine the Half.
6. The PathDeserialize implementation of Option<T> requires a default to be defined for the underlying type T. Here this means Team has to receive a default value. Is Opponent a reasonable choice for this?