New passing and receiving architecture and tuned offense strategy #3200

nimazareian · 2024-05-10T04:41:08Z

Description

updated_passing2_cut.mp4

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

❗ 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

…rav_banna/pass_speed_cost � Conflicts: � src/software/thunderscope/thunderscope.py

…rav_banna/pass_speed_cost

itsarune · 2024-06-20T05:20:35Z

src/software/ai/passing/cost_function.cpp

+    // Linearly scale score to [min_pass_shoot_score, 1.0] to stop this cost function
+    // from returning a very low score, causing the other cost functions to be ignored.
+    return open_angle_to_goal_score;


shouldn't this return a minimum of min_pass_shoot_score (according to the comment)?

oh you've done it in a different function. you should delete that comment

good call! Updated.

src/software/ai/passing/cost_function.cpp

itsarune

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)

nimazareian · 2024-06-23T22:47:29Z

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:

Software/src/software/simulated_tests/validation.py

Lines 194 to 209 in 6dcfd29

    
           for validation in validation_sequence: 
        
               # Add to validation_proto_set and get status 
        
               status = create_validation_proto_helper( 
        
                   eventually_validation_proto_set, validation 
        
               ) 
        
               # If the current validation is failing, we don't care about 
        
               # the next one. Keep evaluating until this one passes. 
        
               if status == ValidationStatus.FAILING: 
        
                   break 
        
               # If the validation has passed, remove it from the set. 
        
               if status == ValidationStatus.PASSING: 
        
                   validation_sequence.remove(validation) 
        
                   continue

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).

williamckha

⚽

src/software/ai/hl/stp/tactic/receiver/receiver_tactic.h

itsarune · 2024-06-29T04:31:11Z

src/proto/parameters.proto

+
+    // TODO (#2570): try to make it as big as possible when tuning
+    // The maximum deflection angle that we will attempt a one-touch kick towards the
+    // enemy goal with


Suggested change

// enemy goal with

// enemy goal

itsarune · 2024-06-29T04:33:40Z

src/proto/parameters.proto

-    // of a soft limit.
-    required double ideal_max_rotation_to_shoot_degrees = 5 [
-        default                   = 60.0,
+    // A value multiplied by the duration that our enemy robot model predicts it will


Suggested change

// A value multiplied by the duration that our enemy robot model predicts it will

// A value multiplied by the duration that our enemy robot model predicts will

itsarune · 2024-06-29T05:23:07Z

src/software/ai/hl/stp/play/passing_sim_test.py

out of curiosity, why'd you need to change some of these parametrized tests?

A limitation of the simulated pytests is that the plays/tactics can only be set at the start of the test. But for passing/receiving to work properly, we need to run the pass generator at each tick if the test. So what was happening with some of these tests was that the passer couldn't find a pass given the starting conditions of the test.

I also tried dividing the test into two parts (i.e. 2 run_test calls), first moving the receivers to the best receiving positions, then finding the best pass. But I ran into an issue which was that there's no easy way of getting the state of the World after the test starts. This was by part caused by the issue I was talking about last week about Python queues not overwriting old values. since I was trying to have a buffer of size one registered to receive the latest World, but that wasn't working.

itsarune

no major concerns from me, pending minor nits

itsarune · 2024-06-29T05:31:57Z

nice catch with the bug!

…2' into nima/receiver_position_generator2

Andrewyx · 2024-07-02T08:00:18Z

src/software/ai/hl/stp/tactic/attacker/attacker_tactic.cpp

@@ -45,8 +44,7 @@ void AttackerTactic::updatePrimitive(const TacticUpdate& tactic_update, bool res
    if (reset_fsm)
    {
        fsm_map[tactic_update.robot.id()] = std::make_unique<FSM<AttackerFSM>>(
-            DribbleFSM(ai_config.dribble_tactic_config()),
-            AttackerFSM(ai_config.attacker_tactic_config()));
+            DribbleFSM(ai_config.dribble_tactic_config()), AttackerFSM(ai_config));


This is the original code writers section below, but why don't you also need to update the DribbleFSM control params as well?

The code here is actually not the ControlParams, rather, it's just creating the FSM objects. In this case we're creating an AttackerFSM and from my understanding of how we've setup boost SML (the FSM library we use), we need to pass in the sub FSMs that the FSM uses + the FSM itself as arguments to the constructor of the FSM<XXXXFSM>.

So in this case, AttackerFSM has DribbleFSM as a sub-FSM, so to generate FSM<AttackerFSM>, we need to pass in both the DribbleFSM and AttackerFSM objects.

Regarding the change I made, in this PR I've update AttackerFSM to take in TbotsProto::AiConfig (part of our dynamic parameters), rather than just taking the TbotsProto::AttackerTacticConfig. You can have a look at attacker FSM and see that I needed some of the other constants from AI config, so I had to make this change.

Andrewyx

Took me two days to even go through all the code. Looks like most comments are addressed. The only part that stands out to me is the free_kick_play changes, but you have already noted that it will be overhauled in #2953 . Additionally, I have made a comment regarding the attacker_tactic update function. I personally had some bugs with FSM update functions, but if this is not the case for you, then LGTM!

nimazareian · 2024-07-05T05:52:22Z

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 · 2024-07-05T05:58:43Z

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 · 2024-07-05T06:03:44Z

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?

sauravbanna added 30 commits May 13, 2023 15:44

added pass speed cost function

021d61d

testing

1657a93

testing

3f9dc79

test

1c08c7d

test

4f21d2e

testing

b59eb7d

testing

ae4adab

testing

f40af89

test

d482e6b

fix

6f34861

fixed cost function

9010163

formatting

84c3a4f

Merge branch 'master' of github.com:UBC-Thunderbots/Software into sau…

ebbeb5e

…rav_banna/pass_speed_cost � Conflicts: � src/software/thunderscope/thunderscope.py

fix

c5e34df

test

b34e972

test

5021ade

test

a9725ec

Merge branch 'master' of github.com:UBC-Thunderbots/Software into sau…

fd34328

…rav_banna/pass_speed_cost

fix tests

023d854

formatting + docs

c72e46c

formatting + docs

044e7a2

test

a8bd1c1

Merge branch 'master' of github.com:UBC-Thunderbots/Software into sau…

babac45

…rav_banna/pass_speed_cost

test

ff36d13

added tests for backward passes

5cc2e7f

uncomment + formatting

4a15972

docs

0ca8c80

fix

3327f89

added new field tets for passing

5893fe8

fix

ff478bf

itsarune reviewed Jun 20, 2024

View reviewed changes

src/software/ai/passing/cost_function.cpp Show resolved Hide resolved

itsarune reviewed Jun 20, 2024

View reviewed changes

Remove dup comment

bb8dd4c

nimazareian mentioned this pull request Jun 22, 2024

Improve FreeKickPlay behaviour and convert it to use FSMs #2953

Draft

5 tasks

nimazareian added 2 commits June 23, 2024 12:24

fix bug in pytest sequenced eventual validations

0505164

Cleanup passing_sim_test.py and few small bug fixes

a649732

nimazareian requested a review from itsarune June 23, 2024 22:41

pre-commit-ci-lite bot and others added 2 commits June 23, 2024 22:49

[pre-commit.ci lite] apply automatic fixes

3abd47d

disable shoot_or_pass_play_test.cpp again

9b710f3

williamckha previously approved these changes Jun 28, 2024

View reviewed changes

src/software/ai/hl/stp/tactic/receiver/receiver_tactic.h Show resolved Hide resolved

itsarune reviewed Jun 29, 2024

View reviewed changes

nimazareian added 2 commits June 29, 2024 20:50

Address comments

d79d913

Merge remote-tracking branch 'origin/nima/receiver_position_generator…

5facdd0

…2' into nima/receiver_position_generator2

nimazareian dismissed williamckha’s stale review via 5facdd0 June 29, 2024 18:51

williamckha approved these changes Jun 29, 2024

View reviewed changes

nimazareian requested review from itsarune and williamckha June 29, 2024 19:01

williamckha approved these changes Jun 29, 2024

View reviewed changes

Andrewyx reviewed Jul 2, 2024

View reviewed changes

Andrewyx approved these changes Jul 2, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New passing and receiving architecture and tuned offense strategy #3200

New passing and receiving architecture and tuned offense strategy #3200

nimazareian commented May 10, 2024 •

edited

Loading

itsarune Jun 20, 2024 •

edited

Loading

itsarune Jun 20, 2024

nimazareian Jun 21, 2024

itsarune left a comment

nimazareian commented Jun 23, 2024

williamckha left a comment

itsarune Jun 29, 2024

itsarune Jun 29, 2024

itsarune Jun 29, 2024

nimazareian Jun 29, 2024

itsarune left a comment

itsarune commented Jun 29, 2024

Andrewyx Jul 2, 2024

nimazareian Jul 5, 2024

Andrewyx left a comment •

edited

Loading

nimazareian commented Jul 5, 2024

Andrewyx commented Jul 5, 2024

nimazareian commented Jul 5, 2024

	// A value multiplied by the duration that our enemy robot model predicts it will
	// A value multiplied by the duration that our enemy robot model predicts will

New passing and receiving architecture and tuned offense strategy #3200

Are you sure you want to change the base?

New passing and receiving architecture and tuned offense strategy #3200

Conversation

nimazareian commented May 10, 2024 • edited Loading

Description

Testing Done

Resolved Issues

Length Justification and Key Files to Review

itsarune Jun 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

itsarune left a comment

Choose a reason for hiding this comment

nimazareian commented Jun 23, 2024

williamckha left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

itsarune left a comment

Choose a reason for hiding this comment

itsarune commented Jun 29, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Andrewyx left a comment • edited Loading

Choose a reason for hiding this comment

nimazareian commented Jul 5, 2024

Andrewyx commented Jul 5, 2024

nimazareian commented Jul 5, 2024

nimazareian commented May 10, 2024 •

edited

Loading

itsarune Jun 20, 2024 •

edited

Loading

Andrewyx left a comment •

edited

Loading