OffensePlayTest checking that there is Never Excessive Dribbling

[adrianchan787]

Description

• Added a validation status check in offense play test that checks if the friendly team has excessively dribbled
• Changed the validation status check (NeverExcessivelyDribbles and EventuallyStartsExcessiveDribbles) to look at the dribble_displacement field in World instead of the previous "brute force" method; this (theoretically) aligns more with the AutoRef's implementation of excessive dribbling
• Added a testing file for the validation status check

Testing Done

- Reran all pytests that used NeverExcessivelyDribbles; some of them were flaky for unrelated reasons e.g. pass_defender_test had a robot enter region validation error first time around
- Created a testing file that tests never excessively and eventually starts dribbling, using the dribble_tactic. (since the main dribbling done in offense_play_test is in dribble_tactic). These tests typically pass but are also flaky; I'll expand more in the comments at the end.

Resolved Issues

Resolves #3452

Length Justification and Key Files to Review

Review Checklist

It is the reviewers responsibility to also make sure every item here has been covered

• [x ] Function & Class comments: All function definitions (usually in the .h file) should have a javadoc style comment at the start of them. For examples, see the functions defined in thunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.
• [ x] Remove all commented out code
• [ x] Remove extra print statements: for example, those just used for testing
• [ x] Resolve all TODO's: All TODO (or similar) statements should either be completed or associated with a github issue

Additional Comments

• Not really an addition and more of a few observations and questions. Wanted to still make this PR since I feel like it's not directly related to my current ticket (and also because I've dragged this on for too long lol).

• Was looking at how the Autoref implemented dribble distance, and from what I understood it seems to compare initial position of the robot to the final position of the ball (see the code snippet below, taken from https://github.com/TIGERs-Mannheim/AutoReferee/tree/53063578e38ac4818849df3196b32a856a5fa41d). If I'm mistaken, please tell me and I'll edit the comments in my branch lol

• However, because they use robot to ball and not e.g. ball to ball, the dribble displacement field is extremely inconsistent. For example, in my tests, if you start the robot in the same location as the ball, you get a different dribble displacement than if you started the robot a meter way. (which I think makes sense? since the orientation with which you start dribbling will probably be different).
• Similarly, that's why the maximum distance between the initial point location of the ball and its location after dribbling is greater than 1 m. From tests I got up to 1.03 m. However, this maximum limit was pretty flaky for me, and fluctuated between 1.03 and 1.01 m. (which is why there's a decent chance my code won't pass my own tests).
• So I was wondering if this is an issue? On one hand, (I think?) if this mirrors the Autoref's behaviour, it doesn't matter how inconsistent it is. On the other, I know William said the 1 meter max dribbling was a pretty strict limit, so would it be worthwhile to be conservative and use like 0.98 max distance in testing and tactics?

Sorry if that was a bit unclear, please let me know if it was. Thanks!

[adrianchan787]

(oops really sorry not sure if i was supposed to resolve the merge conflict)

[nycrat]

Added some comments, just some refactoring changes recommended but the new implementation of excessive_dribbing validation seems good and the test are thorough

[adrianchan787]

Hey @adrianchan787 could you pull from master so that the ci passes?

really sorry that it took this long, should be good now

Wow I have messed this up horribly one sec (ok i am so incredibly sorry for this cursed git log)

[Andrewyx]

Nice work so far, I left some feedback!

[Andrewyx]

I'm not quite sure what the reasoning was for this test, since the issue this PR is marked for is regarding offense play. Reading through the work here, it appears to be more akin to a DribbleTactic test. Excessive dribbling is a characteristic of Gameplay more than a particular state, so I think it is a bit odd to be testing it explicitly since it is really just testing the implementation of DribbleTactic itself.

[adrianchan787]

Hmm ig that makes sense. I was thinking (please correct me if I'm wrong or really misguided) but the main dribbling tactic used in offense play is DribbleTactic, and if that's the case if it works in DribbleTactic then it should work everywhere else, including in offense play. As it is easier to test (especially boundary test) DribbleTactic directly rather than test offense play, I was thinking it might be the better option.

[williamckha]

I'm not sure if I fully understand Andrew's point, but imo the purpose of this test is clear and makes sense

[StarrryNight]

lgtm, left some comments

[williamckha]

Do we have to set a tolerance here? Or could we just pass in the ball position and have the tolerance default to BALL_TO_FRONT_OF_ROBOT_DISTANCE_WHEN_DRIBBLING?

[adrianchan787]

Yeah unfortunately the default doesn't work and am almost certain it is far too small. i tested it a bit and for some reason the robot position and ball position are weirdly offsetted by some variable amount, so a smaller tolerance is a lot flakier than usual (and the default just doesn't pass tests)

[williamckha]

I think the implementation of this function needs to change a bit. The docstring says it should check if any robot is excessively dribbling, but this is only true if we have one robot (notice that, currently, the dribble starting point is reset if any robot is not near the ball, so if there is more than one robot, the dribble start point will never be set).

I would suggest splitting the implementation into two parts. First part would determine whether we should set or reset the dribble starting point. The dribble starting point should only be reset if no robots are near the ball. It should be set if it is currently None and there is a robot near the ball. Second part would only be run if the dribble starting point is set, and it would check whether the ball has been excessively dribbled.

[williamckha]

We should probably visualize the max dribble displacement minus the allowed error margin

[nycrat]

I think this is good 👍