state variables vs. unknown input trajectories

[Peter230655]

The main difference between them seems to be:

• state variables allow instance constraints to be set.
• state variables allow differentiation to be used.

In my practical simulations this made no difference, I simply converted an unknown trajectory to be a state variable when I needed these features.
In a 'formal' way it may look 'better' to keep state variables and unknown input trajectories separate.

Would it be possible to endow these trajectories with the same features as state variables?

[moorepants]

state variables allow instance constraints to be set.

You should be able to set instance constraints on unknown input trajectories now.

In my practical simulations this made no difference, I simply converted an unknown trajectory to be a state variable when I needed these features.

The differentiation in a state and an input (or "control") in a dynamical system is clear. One is specified apriori in time (inputs) and the other evolves in time based on the definition of the derivative. The distinctions are present in opty because it is a tool to solve optimal control problems of dynamical systems.

But the tool converts this problem to an NLP problem which does not have distinction between these two things, at least not in a mathematical sense. So, as you've discovered, you don't have to stick to this distinction.

I think we should keep the concepts in opty because we are often seeking the inputs/controls that cause the evolution of the states to behave in a certain way.

We can change opty to support all needed functionality, for example supply delta and deltadot as controls (as in the bicycle countersteering example) without breaking the conceptual divisions. If you want such functionality, I suggest you provide concrete examples of what you desire in an issue (just like what we have done for all feature requests) and then we can try to implement it. The more specific the proposal, the easier it is to evaluate it and possibly implement it.

[Peter230655]

I made a comparison between using state variables to enforce a terminal instance constraint and using unknown input trajectories to do it.
I have four equations of motion of the form $h_i - \dfrac{d}{dt}u_i$ where $u_i$ are speeds.
Instance constraints are $h_i(t_f) = 0.0$
I got these results:
$h_i$ as state variables,
backend = 'numpy
320 iterations / 32.8 sec

backed='cython'
462 iterations / 35.5 sec

$h_i$ as unkonwn input trajectories
backend = 'numpy
449 iterations / 20.2 sec

backed='cython'
232 iterations / 8.6 sec

I guess, minimally one can say, that using unknown trajectories instead of state variables speeds up the calculation quite a bit.

The simulation was this:
A triple pendulum attached to a cart. (just an expansion of the double pendulum in examples-gallery)
The job is to get it to a vertical position by moving the cart left and right.
The initial guess for the calculation above was to get it up with all final speeds = 0.0
(This was not so easy to find, it calculated a long time, like 60 min or more)
Update: I moved it to pst-notebooks, under the name triple_pendulum_on_cart

[Peter230655]

I ran more tests, and consistently convergence was much faster with unknown input trajectories.
( In a slightly changed case, with unknown input trajectories a solutiopn was found in 37 sec / 1514 iterations, with state variables, even after 30 min no solution was found)

In some cases the time differential is needed. Up to now, one has to use state variables for this.
I wonder, if the time differential of unknown input trajectories was available, would this also speed up convergence a lot?