-
Notifications
You must be signed in to change notification settings - Fork 113
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
Zane kaber/movement speed #3473
Conversation
@@ -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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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/
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay sounds good 🙏
There was a problem hiding this 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!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM ⚽ 🥅
cleaner code Co-authored-by: itsarune <[email protected]>
There was a problem hiding this 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
@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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice work!
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
Length Justification and Key Files to Review
Review Checklist
It is the reviewers responsibility to also make sure every item here has been covered
.h
file) 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 issue