New passing and receiving architecture and tuned offense strategy

nimazareian commented 1 month ago

Description

https://github.com/UBC-Thunderbots/Software/assets/28585597/4afa9dd8-359e-414e-b7a7-e8e3328b6dcb

This PR includes many changes across our offensive gameplay. To name a few:

Updated PassGenerator to sample pass receiver positions more intelligently around where the robots are most likely going to be able to receive passes from as opposed to sampling the entire field. As a result, the pass generator does not use zones or pass evaluations anymore, however, it still does use the GradientDescentOptimizer to optimize the sampled passes.
New ReceiverPositionGenerator used for finding the best receiving positions. This allows the offensive robots that do not have the ball to constantly look for better receiving positions, independent of the pass generator. Previously the receiving robots were tied to the best passes found by the pass generator which limited the receiving robots ability to go around the field. This was fundamentally as a result of ratePassFriendlyCapability only giving high scores to receiving positions around the robot's current position.
Many cost functions were rewritten, tuned, or newly added. As part of this I tried to expand the cost functions that we could visualize in Thunderscope's pass cost layer. Furthermore, the cost functions should be much more tunable on the go since many of the core constants were added to the dynamic parameters.
New visualization features were added for the PassGenerator and ReceiverPositionGenerator that could be enabled through the dynamic parameters. For simplicity, these visualizations are shown in the debug shapes layer.
Shoot or pass play FSM was updated to abort poor passes better while also aborting good passes less. Some notable changes include aborting passes that were previously highly rated but are now poorly rated (e.g. an enemy has moved in the way). Receiver FSM was also updated to make one touch kicks more likely to happen. Keep away + Offense play were also updated to not have the robot with the ball constantly look away from enemies even when there was no thread nearby.

Testing Done

Added new unit tests for pass generator, cost functions, and receiver position generator. Ran AI vs AI and tuned many of the constants manually.

Resolved Issues

Resolves #3191 Resolves #3192 Resolves #2577 Resolves #2538 Resolves #2136 Resolves #1988 Could affect #2930

Length Justification and Key Files to Review

:exclamation: This PR includes the changes from #3198, so please ignore those files, or comment on that PR for specific Thunderscope changes that are unrelated to this PR. Some of the changes are also taken from #2953 (e.g. removing corner kick play. This was done to make the integration of the pass generator simpler.)

Core files to review:

receiver_position_generator.hpp
pass_generator.h/cpp
cost_functions.h/cpp
shoot_or_pass_play_fsm.cpp

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

[ ] 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.
[ ] Remove all commented out code
[ ] Remove extra print statements: for example, those just used for testing
[ ] Resolve all TODO's: All TODO (or similar) statements should either be completed or associated with a github issue

sauravbanna commented 1 month ago

some of aruns comments were from my in progress branch so i fixed them

nimazareian commented 1 month ago

To add to what Saurav mentioned, note that this PR is just for showcase of the current progress and is nowhere near complete. It is also an accumulation of multiple PRs (some of which are open separately). So not all changes here are new.

nimazareian commented 3 weeks ago

It definitely seems like we're passing significantly better!

Glad to hear that :smile: There was a lot of tuning involved with the pass generator, cost functions, and the AI logic. I would imagine that we would have to do some of this with the new gameplay as well. Though I've tried to incorporate more visualizations and have more values in dynamic parameters to hopefully make it simpler.

Mr-Anyone commented 3 weeks ago

This may be a dumb question.

Are we using .h or .hpp for header files?

Would continue reading this entire PR tmr.

itsarune commented 3 weeks ago

@Mr-Anyone our convention is to usually use .hpp for tempaltes and .h for classes

nimazareian commented 2 weeks ago

could you also update passing_sim_test.py? It seems like it ends very early and probably requires fiddling around with some of the validations. (mayhaps use an OrValidation to do an if-then type of thing)

@itsarune I digged further into this, and interestingly enough I found a bug which results in us ignoring the second validation, when we have a sequence of eventual validations. This bug is caused by us removing the first validation from the list of validations (after it is PASSING) while we're iterating over it. Here's the original code: https://github.com/UBC-Thunderbots/Software/blob/6dcfd29c234fa28a2bb387d57f3b51e4ab574f2b/src/software/simulated_tests/validation.py#L194-L209

Most of the tests run longer now since we actually wait for the receiver to receive the pass, however, some still end really fast. In those cases, your best off watching the replay since the test was likely very short (e.g. the robot taking a very short pass).

itsarune commented 1 week ago

nice catch with the bug!

nimazareian commented 3 days ago

I personally had some bugs with FSM update functions, but if this is not the case for you, then LGTM!

@Andrewyx Did you have bugs running code from this branch, or are you referring to running into FSM problems elsewhere?

Andrewyx commented 3 days ago

I personally had some bugs with FSM update functions, but if this is not the case for you, then LGTM!

@Andrewyx Did you have bugs running code from this branch, or are you referring to running into FSM problems elsewhere?

FSM problems elsewhere, I have not tested it with your branch directly since I am not fully familiar with the intended behaviour of the new strategy. But for my ticket where I was adding DribbleFSM to the Creases, I realized that I needed to update the DribbleFSM control params within the updatePrimitive function for it to work effectively, otherwise, I had a bug where the Crease would endlessly chase the ball.

nimazareian commented 3 days ago

But for my ticket where I was adding DribbleFSM to the Creases, I realized that I needed to update the DribbleFSM control params within the updatePrimitive function for it to work effectively, otherwise, I had a bug where the Crease would endlessly chase the ball.

That's interesting. So are you saying that you added DribbleFSM as a sub-FSM to the CreaseDefenderFSM, and as part of CreaseDefenderTactic::updatePrimitive you had to call process_event with the DribbleFSM::update as well for it to work?

UBC-Thunderbots / Software