OffensePlayTest checking that there is Never Excessive Dribbling#3536
OffensePlayTest checking that there is Never Excessive Dribbling#3536adrianchan787 wants to merge 48 commits intoUBC-Thunderbots:masterfrom
Conversation
|
(oops really sorry not sure if i was supposed to resolve the merge conflict) |
…/adrianchan787/Software into adrian/offense_play_test_dribble
nycrat
left a comment
There was a problem hiding this comment.
Added some comments, just some refactoring changes recommended but the new implementation of excessive_dribbing validation seems good and the test are thorough
src/software/ai/hl/stp/tactic/dribble/excessive_dribble_test.py
Outdated
Show resolved
Hide resolved
src/software/ai/hl/stp/tactic/dribble/excessive_dribble_test.py
Outdated
Show resolved
Hide resolved
|
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) |
This reverts commit 6d9a363.
Andrewyx
left a comment
There was a problem hiding this comment.
Nice work so far, I left some feedback!
docs/getting-started.md
Outdated
| - [Installing Software Dependencies](#installing-software-dependencies) | ||
| - [Installing an IDE](#installing-an-ide) | ||
| - [Installing an IDE: CLion](#installing-an-ide-clion) | ||
| - [Getting your Student License](#getting-your-student-license) | ||
| - [Installing CLion](#installing-clion) | ||
| - [Installing an IDE: VS Code](#installing-an-ide-vs-code) | ||
| - [Editing with Vim or NeoVim](#editing-with-vim-or-neovim) | ||
| - [Building and Running the Code](#building-and-running-the-code) | ||
| - [Building from the command line](#building-from-the-command-line) | ||
| - [Building from the command line using the fuzzy finder](#building-from-the-command-line-using-the-fuzzy-finder) | ||
| - [Building with CLion](#building-with-clion) | ||
| - [Building with VS Code](#building-with-vs-code) | ||
| - [Running our AI, Simulator, SimulatedTests or Robot Diagnostics](#running-our-ai-simulator-simulatedtests-or-robot-diagnostics) | ||
| - [Debugging](#debugging) | ||
| - [Debugging with CLion](#debugging-with-clion) | ||
| - [Debugging from the Command Line](#debugging-from-the-command-line) | ||
| - [Profiling](#profiling) | ||
| - [Callgrind](#callgrind) | ||
| - [Tracy](#tracy) | ||
| - [Building for the robot](#building-for-the-robot) | ||
| - [Deploying Robot Software to the robot](#deploying-robot-software-to-the-robot) | ||
| - [Testing Robot Software locally](#testing-robot-software-locally) | ||
| - [Setting up Virtual Robocup 2021](#setting-up-virtual-robocup-2021) | ||
| - [Setting up the SSL Simulation Environment](#setting-up-the-ssl-simulation-environment) |
There was a problem hiding this comment.
nit: Probably unintended formatting change
|
|
||
| # Software Setup | ||
|
|
||
| ## Introduction | ||
|
|
||
| These instructions assume that you have the following accounts setup: | ||
| - [GitHub](https://github.com/login) | ||
| - [Discord](https://discord.com). Please contact a Thunderbots lead to receive the invite link. | ||
|
|
||
| These instructions assume you have a basic understanding of Linux and the command line. There are many great tutorials online, such as [LinuxCommand](http://linuxcommand.org/). The most important things you'll need to know are how to move around the filesystem and how to run programs or scripts. | ||
|
|
||
| ## Installation and Setup | ||
|
|
||
| ### Operating systems | ||
|
|
||
| We currently only support Linux, specifically Ubuntu. |
| def get_validation_status( | ||
| self, | ||
| world, | ||
| ) -> ValidationStatus: |
There was a problem hiding this comment.
nit: is this formatting right?
| """Checks if any friendly robot is excessively dribbling the ball, i.e. for over 1m. | ||
|
|
||
| :param world: The world msg to validate | ||
| estimate of max dribble distance (effective dribble distance is length - error margin) |
There was a problem hiding this comment.
Where is this comment directed to?
| if ( | ||
| world.HasField("dribble_displacement") | ||
| and world.dribble_displacement is not None | ||
| ): | ||
| dribble_disp = world.dribble_displacement | ||
| dist = tbots_cpp.createSegment(dribble_disp).length() | ||
| if dist > ( | ||
| DribblingConstants.MAX_DRIBBLING_DISTANCE | ||
| - DribblingConstants.DRIBBLING_ERROR_MARGIN | ||
| ): | ||
| return ValidationStatus.FAILING | ||
| elif self.continous_dribbling_start_point is None: | ||
| # ball is in dribbler, but previously wasn't in dribbler, so set continuous dribbling start point | ||
| self.continous_dribbling_start_point = ball_position | ||
|
|
There was a problem hiding this comment.
@sauravbanna @williamckha Can you take a look at this? I am hesitant to think this code is correct since dribble_displacement might be determined by SensorFusion and in that case, our internal logic is also referencing dribble_displacement when deciding when to let go of the ball.
Additionally, suppose a bug arises in SensorFusion where dribble_displacement is None, but in fact we are dribbling. In that case, this test would pass since it is referencing the value passed on by SensorFusion.
There was a problem hiding this comment.
I see your concern. Though imo it does not make sense to return FAILING if dribble_displacement is null, since if it is accurate, that would mean we are not dribbling at all and therefore not breaking the excessive dribbling rule. I would suggest adding an extra validation to the excessively dribbling test that checks if the ball is eventually moved to its destination. This would validate that the ball is actually being dribbled.
There was a problem hiding this comment.
wait nevermind I didn't read the second part of your comment properly. To address that potential bug, we should check that the dribble_displacement member is eventually non null.
| class DribblingConstants: | ||
| """Constants to be used to check whether the robot has dribbled beyond competition regulations""" | ||
|
|
||
| MAX_DRIBBLING_DISTANCE = 1.0 |
There was a problem hiding this comment.
nit: Displacement not distance
| @pytest.mark.parametrize( | ||
| "initial_location,dribble_destination,final_dribble_orientation, should_excessively_dribble", | ||
| [ | ||
| # Tests Should not excessively dribble |
There was a problem hiding this comment.
nit: Unnecessary comment
There was a problem hiding this comment.
probably unclear, but my tests are split between not excessively dribbling and excessively dribbling, hence the comment (there's a corresponding comment below for excessively dribbling). I'll try to format it better?
| simulated_test_runner, | ||
| ): | ||
| if should_excessively_dribble: | ||
| blue_robot_locations = [tbots_cpp.Point(0, 0.0)] |
There was a problem hiding this comment.
We probably do not want to set the locations in the test, and instead have them parameterized. This clear separation makes reading the logic of the test cases make more sense.
There was a problem hiding this comment.
got it makes sense
| ), | ||
| ], | ||
| ) | ||
| def test_excessive_dribbling( |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Description
Testing Done
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
.hfile) should have a javadoc style comment at the start of them. For examples, see the functions defined inthunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.TODO(or similar) statements should either be completed or associated with a github issueAdditional 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
Sorry if that was a bit unclear, please let me know if it was. Thanks!