When ball placement fails, it is not always clear why

[g3force]

Problem

Ball placement can fail for different reasons. The most obvious one is, when the ball is not yet on the placement position. If it is, the placing robot still needs to bring some distance to the ball, see: https://robocup-ssl.github.io/ssl-rules/sslrules.html#_ball_placement The PLACEMENT_FAILED event only includes the remaining_distance. If it is close to zero, it is not obvious, for which reason the placement failed.

Current situation

Currently, the autoRefs are responsible to create PLACEMENT_SUCCESSFUL events, when all conditions are met. The GC will create a PLACEMENT_FAILED event, when no successful event was sent by the autoRefs in time. The GC will include the remaining distance from ball to placement position in the failed event.

Proposed solution

Easy short-term solution

• Add a nearest_own_bot_distance property to the PLACEMENT_FAILED event.
• Calculate the value in the GC and add it to the event

Better solution

The above proposed solution does not solve the problem reliably: There could still be an inconsistency between how an autoRef judges the success / failure of the placement. Specifically, if using majority voting and a majority is not reached, the placement would be counted as failed, without reporting additional information about why it failed.

A better solution could be to report success and failure consistently at only one place: Either the autoRefs or the GC:

• The responsibility of sending the PLACEMENT_FAILED event could be transferred to the autoRefs. However, especially with the current majority implementation, there is no guaranty, that all autoRefs report the failure, so the timeout mechanism of placement may not work.
• The responsibility of sending the PLACEMENT_SUCCESSFUL event could be transferred to the GC. The majority mechanism would be lost. However, the detection is not that complicated. This could also solve another corner case: If multiple autoRefs report the success at different times, the current majority implementation would not accept it.

[g3force]

After further discussion, we decided to stick to the short-term solution. We want to keep the majority.