-
Notifications
You must be signed in to change notification settings - Fork 233
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
Improve / robustify swing-leg motion #35
Comments
Hi Alexander, (I write in Latex, there are plugins available to visualize it in Github) Let's assume a polynomial We know We want to find the conditions on the coefficients such that $p(t) < 0 $ for some There are the following possibilities:
So the idea would be to find the coefficients $$ \min || \theta - \theta ' || $$ $$ \theta := [ p(0), p(1), \dot{p}(0), \dot{p}(1)] $$ I will think again about the problem after better reading the code and maybe I'll open a PR |
Yes, that's the effect. The solver doesn't take into account the stair-step height. It only sees the height of the final foothold that it wants to reach, but might connect them in a straight line (falsely going right through the stairs). A hack would be to increase the step height, but a better way would be to add a constraint that takes into account that terrain height information in between. |
Thank you for the quick reply! I'll find a workaround for now and keep it in mind for future work. 👍 |
Stay healthy! :) |
Hi, @prakharg01! :) Kinda; but not within towr. For my use case, I ended up taking the footsteps from towr and then specifying the paths for the feet to follow during swing phases myself. I used a cubic B-spline (zero velocity at start and end points) defined by three waypoints: initial and final positions, and then a midpoint. For the midpoint, I took the literal midpoint in the |
Oh great! I will definitely try this. Thanks a lot! |
While a foot is swinging, it is typically represented by two/three polynomials.
Two types of constraints are active in this phase:
terrain_constraint
Problem:
swing_constraint.h
Problem:
Possible solution:
In order to solve the above problems, possibly a cost term is the most general way to go. One could think about a cost that penalizes distance of the foot to the terrain. By not formulating it only on the node values, but directly on the generated polynomial queried at predefined intervalls, the solver would try to avoid penetration with the ground at all times during swing. Furthermore, the leg would automatically lift off the ground as far as the range-of-motion permits during a step.
Another interesting cost to test, instead of the swing_constraint, is penalizing accelerations of the feet. This would automatically create smooth swinging motions. Since acceleration not part of the node variables (these only include pos/vel), this cost would also have to be formulated on the spline, queried at predefined intervalls (similar to this constraint).
The text was updated successfully, but these errors were encountered: