Skip to content
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

graceful_controller: implement iterative selection of control point #4115

Open
mikeferguson opened this issue Feb 15, 2024 · 2 comments
Open
Assignees
Labels
enhancement New feature or request

Comments

@mikeferguson
Copy link
Contributor

I'm already working on this - just ticketing it for visibility

@mikeferguson mikeferguson added the enhancement New feature or request label Feb 15, 2024
@mikeferguson mikeferguson self-assigned this Feb 15, 2024
@SteveMacenski
Copy link
Member

SteveMacenski commented Mar 1, 2024

From the wobbling in https://youtu.be/QHdrfadFhRg I was thinking about how to potentially address it. I believe you mentioned that your aim would be to back out the control point on the path for collision avoidance reasons -- which my understanding would also help with turns in confined environments where going too far ahead isn't possible. I believe that makes the controller wholesale more functional, but doesn't help with the wobbling caused by recomputing the curves constantly.

So my initial thoughts last night over a notepad:

  • Only recompute the control points on occasion, not every iteration. Let the robot commit to an action for longer and recompute either every N cycles, once the robot has driven N meters, or within some N meter radius of the final control point. Possibly with a velocity multiplier so that we can preemptively recompute it sooner when moving faster (such that if a new curve cannot be found, we have enough time to stop safely at the end of the current curve)

While not related to wobbling, something I want to try and thus documenting here: Either use gradient descent or sample different spiral parameters given the anchors of the boundary conditions and use the best by some scoring metric (distance to path, cost-distance metric, etc), My preference would be gradient descent so its not something tuned on the window sizes and such -- and thus falling into less of the traps of DWA.

@SteveMacenski
Copy link
Member

SteveMacenski commented Mar 14, 2024

Smoothing out path before execution (greedy, spline?) -- changing gains.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants