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

added more textrm, first attempt at structure as per #348 #350

Merged
merged 2 commits into from
Feb 10, 2025

Conversation

Peter230655
Copy link
Contributor

@Peter230655
Copy link
Contributor Author

Peter230655 commented Feb 10, 2025

Unsure, how these unsuccessful tests are related to the simulation I pushed.
Error message says something about pause not defined. I did not touch the code, only optical changes.

@Peter230655 Peter230655 reopened this Feb 10, 2025
@Peter230655
Copy link
Contributor Author

Trying again.

@Peter230655
Copy link
Contributor Author

I am very unclear about this error about pause


- 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.
Copy link
Member

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 ?

Copy link
Contributor Author

@Peter230655 Peter230655 Feb 10, 2025

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

Copy link
Member

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

Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, got it.

Copy link
Contributor Author

@Peter230655 Peter230655 Feb 11, 2025

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?

Copy link
Member

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.

@moorepants moorepants merged commit 075e2e3 into csu-hmc:master Feb 10, 2025
22 checks passed
@Peter230655 Peter230655 deleted the car-around-pylons branch February 10, 2025 19:53
@Peter230655
Copy link
Contributor Author

The linear combination of the two eoms seems to work fine, and gives expected results.
At present however, I have no idea how get the initial speed of the 2nd phase to be e*final speed of the first phase.

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

Successfully merging this pull request may close these issues.

2 participants