-
Notifications
You must be signed in to change notification settings - Fork 24
Attempt at solving a simple problem with friction using a slack variable. #476
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
base: master
Are you sure you want to change the base?
Conversation
@Neville-N this may be helpful for you as an option to have elements in your equations that switch discontinuously (in alternative to making smoothened step functions). @Peter230655 I'm curious what you can do with this and whether you can get better solutions than I am. Have a look! |
m*v(t).diff(t) - Ffp(t) + Ffn(t) - F(t), | ||
# following two lines ensure: psi >= abs(v) | ||
psi(t) + v(t), # >= 0 | ||
psi(t) - v(t), # >= 0 |
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.
Peter and I discussed making this psi(t) - v(t)**2
instead.
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.
Or maybe it needs to be psi - sqrt(v**2)
.
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 this and it seems to work.
I will definitely look at it on Tuesday. Tomorrow I will be on the road and too cumbersome on ipad. |
Update 5-6-25:
|
Yes, that happens with me often in this problem. |
I wonder whether this slack variable approach is suitable for opty/Ipopt:
Same for Ffn. If I bound like 0 <= Ffp, Ffn <= mu * m * g, which is correct mechanically I think, I do not get any reasonable solution. |
IPOPT requires that the objective function and the constraints for the NLP are continuous. As far as I can tell, this results in a continuous formulation of the NLP. There is no necessity that the optimal control differential equations are continuous, IPOPT doesn't even know anything about the differential equations. |
Also, note that this is the same formulation we used for solving the skateboard ollie, which is also solved by IPOPT. |
One more thing: all unknown inputs to this system can be discontinuous with respect to time. We have many problems with such solutions in the examples. |
This is what kept me wondering, why it does not easily work here. |
Very true, I did not think of this! Still, it solves rapidly if I use a smooth step function, with the slack variables I am still struggling. Even if it converges the results are considerably worse ( = longer time to finish) compared to smooth step. |
As far as opty / Ipopt are concerned, would the slack variable formulation be equivalent to:
If you think so, I can easily try this formulation. |
No, that creates a discontinuous constraint function. |
Clear. |
In this case, its advantage is that it can find the correct solution for a system with Coulomb friction vs. the solution with an approximation of Coulomb friction. In general, the advantage is to find solutions for differential equations that have discontinuities. |
Clear, thanks! |
The only stipulation is that the NLP objective and constraint functions are continuous. This says nothing about the differential algebraic equations. Opty converts the description of the optimal control of differential algebraic equations into a NLP problem via direct collocation. If the DAE's are continuous, then the NLP problem is continuous, but if the DAE's are not continuous, then you may be able to still construct a continuous NLP. That's what this example is attempting to show. |
Slowly getting it. I will play around with it more. |
Update 7-6-2025:
Overall, convergence seems very sensitive to the initial guess. |
I was wondering what it would do if given the initial guess as the smooth solution. Interesting. Note that psi = abs(v) makes the NLP problem discontinuous. SymPy will produce a derivative for abs() but the discontinuity is present in the constraints and its Jacobian. |
I did not express myself correctly: |
Maybe a dumb question:
Similar for Ffn(t) |
In the NLP formulation there are the unknown variables x that are subject to |
Makes sense. |
I think I must have something wrong in the formulation that causes the difficulty to converge. |
It is the same formulation used for the skateboard ollie, which converged easily? |
It is the formulation shown in the paper, but I don't know if that is what is in the code. |
Right now I have no ideas, will continue to play around. |
I chatted with Ton about this today and he pointed me to this: https://en.wikipedia.org/wiki/Linear_complementarity_problem, which points to this: https://en.wikipedia.org/wiki/Slack_variable |
I think, in this sense I may have used slack variables in some of my simulations, without being aware of it: I needed this variable to be positive and tf to ensure the particle was close to the gate at some time during the simulation, but no idea of the value of This ensured, that the particle was close to the gate at some point, it also worked in my simulations. |
|
Of course I could have set |
Update:
Still, the convergence is quite 'sensitive' to changes in the parameters. |
Nice! I'm curious if it solves without having to give the hump solution as the initial guess. If so, I'd prefer that in the gallery to keep it minimal. If we add this to the gallery, I'd prefer if my commits are retained and you open a PR that is based on a branch off of this PR (with your commits added). |
What is this change? |
Sorry, I did not change the eoms. I changed bounds: |
Attempt to fix #475
Observations: