-
Notifications
You must be signed in to change notification settings - Fork 21
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
added more textrm, first attempt at structure as per #348 #350
Conversation
Unsure, how these unsuccessful tests are related to the simulation I pushed. |
Trying again. |
I am very unclear about this error about |
|
||
- Show a way to circumvent the current inability of *opty* to handle instance | ||
constraints at times that are not specified in advance but selected optimally | ||
by *opty* itself. |
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.
Can this be applied to #333 ?
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 have been thinking along a bit different lines for a while, like:
eom = step(t) * eom1 + (1-step(t)) * eom2, where step(t) = 1 for 0 <= t <= t_impact, step(t) = 0 else.
step(t) must be differentiable, for opty to work no problem here.
step(..) is easy to define along the lines of #350, I think.
Like this, one could handle staged problems if initial_conditions(eom2) = states(eom1(t_impact) - but this is not the case with #333.
I will continue my thinking
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 explicitly want to handle the non-defferntiability as a multiphase problem. It is how we solved the skateboard ollie paper here: https://link.springer.com/article/10.1007/s12283-023-00448-y
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 only thing I need for that example to work is to allow the instance constraint to be at a time not specified in advance, which is exactly what you write in the description to this example.
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 am afraid, my wording is misleading. What I meant was this:
Say, (x, y) is the location of the body.
Then at present, if you want the body to come close to (x0,y0) during its journey you have to specify a time (which may depend on h) when this should happen.
All my hack does is to avoid having to do this. It does not allow an instance constraint of the form
x.func(t_arbitrary) - x0
y.func(t_arbitrary) - y0
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.
Ok, got it.
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.
Ok, got it.
What would be a less misleading description?
Examples-gallery must no mislead users.
I could explicitly mention, that it does not allow "arbitrary_time" instance constraints?
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 think it is fine, once you read the rest of the example it is clear.
The linear combination of the two eoms seems to work fine, and gives expected results. |
textrm
for nicer looks.prevent_print = 0
to avoid nonsense being output, a semicolon did not work.