Skip to content

Conversation

@knoellle
Copy link
Contributor

@knoellle knoellle commented Jul 7, 2025

Why? What?

Currently, step plans are ordered by a distance metric (also taking into account orientation).
But not all kick decisions are created equal, some may be better even if slightly further away because the foot used to kick the ball fits better to the current support foot "phase".
With this PR, the kick selector does greedy step planning for each kick decision and calculates the total duration of these steps.
This duration metric is then used instead of the distance metric for the calculating the Güte of kick decisions.

You may want to review the first commit separately.

Fixes #1186

ToDo / Known Issues

  • Actually use the calculated walk duration for comparing kick decisions.
  • Think long and hard again about how to compare the kicking side to the current support foot
  • Clean up the walking engine mess
  • Check if the robot can get stuck oscillating between two kick decisions

Ideas for Next Iterations (Not This PR)

How to Test

A robot walking in place in front of a ball should repeatedly switch which kick decision it thinks is best depending on the current support foot.

@github-project-automation github-project-automation bot moved this to Request for Review in Development Jul 7, 2025
@knoellle knoellle moved this from Request for Review to In Progress in Development Jul 7, 2025
@knoellle knoellle force-pushed the kick_decision_step_planning branch from 950cfeb to 4de9dfa Compare July 13, 2025 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

Prefer Foot that doesn't need Zero Step

1 participant