Skip to content

Conversation

@nycrat
Copy link
Member

@nycrat nycrat commented Oct 18, 2025

Description

Create a 2D arrow under the ball directed to its velocity, shows where and the direction the ball is chipped in tests. Shows octagon (stop sign) when ball is not moving.

ball_is_off_ground_validation.mp4

Testing Done

Ran crease_defender_tactics_test, which is the only test that uses the ball_is_off_ground validation

Resolved Issues

resolves #3244

Review Checklist

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

@nycrat
Copy link
Member Author

nycrat commented Oct 18, 2025

NOTE: a lot of changes come from the pre-commit auto-formatting, I'm not sure which one is the correct formatting. It was mentioned here #3499 (comment)

@nycrat
Copy link
Member Author

nycrat commented Nov 1, 2025

nvm the bot updated the formatting its all good

Comment on lines 41 to 43
if direction.x() == 0.0 and direction.y() == 0.0:
# NOTE if ball is not moving, displays arrow pointing to the right
direction = tbots_cpp.Vector(1.0, 0.0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we do this? If it is an arbitrary design decision, I think we should think of some other more intuitive way of representing non-movement. Consider the following example: suppose we have a bug where the ball is moving at 0.0000000001 m/s to the right. In this case, we will not be able to visually differentiate the fact that the ball is drifting which might cause us to fail to catch this bug.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea I agree, maybe I'll try implementing a different shape like an octagon to represent that the ball is stopped ?

Comment on lines 47 to 50
line_width = 0.08
line_length = 0.2
triangle_height = 0.15
triangle_width = 0.2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, we should use either existing constants for these values, and in the worst case, we can define then as static values either in this class, or if appropriate, in some constants class.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I'll try to look for some existing constants, and if nothing makes sense in this context I'll define them as static values in the class

Comment on lines 54 to 61
line_bottom_left = start_point - perpendicular * (line_width / 2)
line_bottom_right = start_point + perpendicular * (line_width / 2)
line_top_right = end_point + perpendicular * (line_width / 2)
line_top_left = end_point - perpendicular * (line_width / 2)

triangle_top = end_point + direction * triangle_height
triangle_bottom_left = end_point + perpendicular * (triangle_width / 2)
triangle_bottom_right = end_point - perpendicular * (triangle_width / 2)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there is a lot of repeated calculations here. Maybe encapsulating some of this in to a helper will clean things up and make the calculations easier to interpret.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll make a helper function named something like "get_arrow(start, end)" that will generate the geometry. I also now realize that I could make the entire arrow a polygon geom instead of two polygons combined.

Do you think I should keep this helper local to this validation class or add it to another helper file in case we would want to reuse arrows?

Copy link
Contributor

@Andrewyx Andrewyx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to attach a clip + pics of this new visual test in action? We usually try to do this for features which make visual verifiable changes 👍

@nycrat
Copy link
Member Author

nycrat commented Nov 3, 2025

I'll attach some videos and screenshots of the visual test in this PR after I make some changes to resolve the comments you made about the code

@nycrat nycrat force-pushed the avah/thunderscope_ball_off_ground_visual branch from f4e4f85 to 1057d84 Compare November 30, 2025 08:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Thunderscope] Improve ball_is_off_ground.py Validation Test Visual

2 participants