Skip to content

Zane kaber/movement speed #3473

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
Jul 18, 2025

Conversation

zuperzane
Copy link
Contributor

@zuperzane zuperzane commented Jul 1, 2025

simplescreenrecorder-2025-07-02_21.39.37.mp4

Description

Makes the goalie dive if it can't make it to the ball on time

Testing Done

Added a tough save to the goalie tactic test

Resolved Issues

I dont want to directly link this issue but helps with #3377 

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

@@ -182,6 +183,48 @@ void GoalieFSM::panic(const Update &event)
Angle goalie_orientation =
(event.common.world_ptr->ball().position() - goalie_pos).orientation();

Point save_pos = goalie_pos;
Copy link
Contributor

Choose a reason for hiding this comment

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

this looks great, if you think that there is more work that could be done, you should add a comment with // TODO(#3377): ... to improve this logic

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure if I should add much to this but I would like to add similar logic to pass defender the thing is the dribble fsm is the thing doing a good piece of the work in pass defender, should I attempt some predictive logic for the dribble fsm?

Copy link
Contributor

@itsarune itsarune Jul 2, 2025

Choose a reason for hiding this comment

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

I see, then you can skip doing the TODO thing that I suggested. It would be pretty useful to have some similar logic in PassDefender as well (maybe by adding a custom state that uses your iterative algorithm to try to find a good final velocity if the final position isn't reachable in time)

Either way, you should try to abstract out this algorithm so that you can use it in the goalie and the pass defender and put the function in software/ai/evaluation/

Copy link
Contributor Author

@zuperzane zuperzane Jul 2, 2025

Choose a reason for hiding this comment

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

Okok I'll combine the prs then?

Copy link
Contributor

Choose a reason for hiding this comment

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

up to you, I think this one is fairly complete. So we could merge it and then make a new PR for the pass defender later

Copy link
Contributor

Choose a reason for hiding this comment

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

although if the reviews for this take a long time, you can just merge it into this one

@@ -182,6 +183,48 @@ void GoalieFSM::panic(const Update &event)
Angle goalie_orientation =
(event.common.world_ptr->ball().position() - goalie_pos).orientation();

Point save_pos = goalie_pos;
Copy link
Contributor

Choose a reason for hiding this comment

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

what if we search along the stop_ball_point (the point where the ball intersects the goal segment) rather than the goalie_pos (which right now is the perpendicular intersection point between the goalie to intersecting the ball on the way to the goal line).

My rationale is that if we can't make an intersection in time, the best position will always be along the goalie line because it gives us the maximum time to accelerate before the ball gets there

Copy link
Contributor Author

@zuperzane zuperzane Jul 2, 2025

Choose a reason for hiding this comment

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

Hmm am I visualizing this correctly you mean like see if travelling to the ball goal intersection would give you time? Cuz my reasoning is it would be ideal if we had some run off because then we would never need to decelerate till we reach the ball, but if we are travelling towards the goal line we need to stop or else we will hit the inside of the goal, like there would be time spent decelerating essentially, idk how the math works lol

Copy link
Contributor

@itsarune itsarune Jul 4, 2025

Choose a reason for hiding this comment

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

goalkeeper-intersection-point

I hope this diagram helps. The intersection point (goalie_pos) is calculated to minimize the distance to the intersection point (dotted line). If we know for sure that we can't arrive at this position in time, then maybe the best position is the intersection along the goal segment. The ball would take longer to arrive at this position, so it gives us the most time to accelerate to a faster velocity to intersect the ball.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Untitled drawing(1)

The OG plan was the orange destination which due to the overshoot allows the robot to be always accelerating and never have to decelerate, and my thing with the blue line is that it gives the most time but the robot would spend half the time accelerating and half the time decelerating due to not wanting to hit the wall as opposed to somewhere where the robot can freely go past. But I see now that maybe a green line of some kind might be a good mix allowing overshoot and more time. I put a gif as well up top somewhere, it's a weird optimization problem, I'll try and fix it during the pass defender pr. Thanks for the tips 🙏

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay sounds good 🙏

Copy link
Contributor

@itsarune itsarune left a comment

Choose a reason for hiding this comment

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

great work! just a few nits from me!

@zuperzane zuperzane requested a review from itsarune July 3, 2025 06:19
itsarune
itsarune previously approved these changes Jul 4, 2025
Copy link
Contributor

@itsarune itsarune left a comment

Choose a reason for hiding this comment

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

LGTM ⚽ 🥅

@zuperzane zuperzane requested a review from itsarune July 4, 2025 07:40
williamckha
williamckha previously approved these changes Jul 4, 2025
Copy link
Contributor

@williamckha williamckha left a comment

Choose a reason for hiding this comment

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

I tried to field test this today but couldn't get the robots working (unrelated to your PR). Regardless, I think this change looks good! I would second Arun's comment about extracting the interception logic and putting it in a separate func for future reuse

@zuperzane
Copy link
Contributor Author

@itsarune sorry could u recheck it I did the epsilon thing lol

Point new_destination = save_pos;
double final_speed = GOALIE_STEP_SPEED_M_PER_S;
bool finished = false;
double max_speed = event.common.robot.robotConstants().robot_max_speed_m_per_s;
Copy link
Contributor

@mkhlb mkhlb Jul 13, 2025

Choose a reason for hiding this comment

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

What if we are too close to the ball to attain this max speed? We should check that and potentially use another max_allowed_speed_mode to accelerate faster or something (although i doubt our robot can even attain a higher acceleration without slipping) if this speed is insufficient.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If it's too close it won't affect its behaviour but idk it s probably weird code practice, but the function that I check the time to destination uses the maximum possible speed and calculates it for us and mins it against the one that's passed should I repeat that check before passing the soeed? I'm very down to do the acceleration thing though

Copy link
Contributor

Choose a reason for hiding this comment

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

this could probably be handled in a separate PR. I'm not sure how much more benefit we would get

Copy link
Contributor

@itsarune itsarune left a comment

Choose a reason for hiding this comment

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

nice work!

@zuperzane zuperzane merged commit 7e9d289 into UBC-Thunderbots:master Jul 18, 2025
6 checks passed
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.

4 participants