You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use LinearizationOpPoint for trajectory_ss, remove robust_sol_getindex
Replace manual operating point extraction in `trajectory_ss` with
MTK's `LinearizationOpPoint` API (SciML/ModelingToolkit.jl#4443).
This removes the fragile `robust_sol_getindex` helper and simplifies
the implementation.
- Use `_build_op_from_solution` to extract differential states + parameters
- Supplement with linearization system unknowns from the solution
- Remove `robust_sol_getindex` (no longer needed)
- Bump version to 2.7.0, require MTK >= 11.7
- Update docs narrative for trajectory_ss
ClosesSciML/ModelingToolkit.jl#4159
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Not how the closed-loop system changes very little along the trajectory, this is a good indication that the gain-scheduled controller is able to make the system appear linear.
166
166
167
-
Internally, [`trajectory_ss`](@ref) works very much the same as [`batch_ss`](@ref), but constructs operating points automatically along the trajectory. This requires that the solution contains the states of the simplified system, accessible through the `idxs` argument like `sol(t, idxs=x)`. By linearizing the same system as we simulated, we ensure that this condition holds, doing so requires that we specify the inputs and outputs as analysis points rather than as variables.
167
+
Internally, [`trajectory_ss`](@ref) works very much the same as [`batch_ss`](@ref), but constructs operating points automatically along the trajectory using `ModelingToolkit.LinearizationOpPoint`. The operating points are extracted from the differential states and parameters of the solution. We specify the inputs and outputs as analysis points to properly define the linearization interface.
168
168
169
169
170
170
We can replicate the figure above by linearizing the plant and the controller individually, by providing the `loop_openings` argument. When linearizing the plant, we disconnect the controller input by passing `loop_openings=[closed_loop.u]`, and when linearizing the controller, we have various options for disconnecting the the plant:
@@ -221,7 +221,7 @@ plot(
221
221
if we open at both `y` and `v` or we open at `u`, we get controllers for the different values of the scheduling variable, and the corresponding measurement feedback (which is the same as the scheduling variable in this case).
However, if we only open at `y` we get controller linearizations that _still contain the closed loop through the scheduling connection_`v`. We can verify this by looking at what variables are present in the input-output map
Linearize `sys` around the trajectory `sol` at times `t`. Returns a vector of `StateSpace` objects and the simplified system.
514
518
519
+
Operating points are extracted from the solution automatically using [`ModelingToolkit.LinearizationOpPoint`](@ref).
520
+
515
521
# Arguments:
516
522
- `inputs`: A vector of variables or analysis points.
517
523
- `outputs`: A vector of variables or analysis points.
518
-
- `sol`: An ODE solution object. This solution must contain the states of the simplified system, accessible through the `idxs` argument like `sol(t, idxs=x)`.
524
+
- `sol`: An ODE solution object.
519
525
- `t`: Time points along the solution trajectory at which to linearize. The returned array of `StateSpace` objects will be of the same length as `t`.
520
526
- `fuzzer`: A function that takes an operating point dictionary and returns an array of "fuzzed" operating points. This is useful for adding noise/uncertainty to the operating points along the trajectory. See [`ControlSystemsMTK.fuzz`](@ref) for such a function.
521
-
- `verbose`: If `true`, print warnings for variables that are not found in `sol`.
522
-
- `kwargs`: Are sent to the linearization functions.
527
+
- `kwargs`: Are sent to the linearization functions (e.g., `loop_openings`).
523
528
- `named`: If `true`, the returned systems will be of type `NamedStateSpace`, otherwise they will be of type `StateSpace`.
524
529
"""
525
530
functiontrajectory_ss(sys, inputs, outputs, sol; t =_max_100(sol.t), allow_input_derivatives =false, fuzzer =nothing, verbose =true, named =true, kwargs...)
526
531
maximum(t) >maximum(sol.t) &&@warn("The maximum time in `t`: $(maximum(t)), is larger than the maximum time in `sol.t`: $(maximum(sol.t)).")
527
532
minimum(t) <minimum(sol.t) &&@warn("The minimum time in `t`: $(minimum(t)), is smaller than the minimum time in `sol.t`: $(minimum(sol.t)).")
528
-
# NOTE: we call linearization_funciton twice :( The first call is to get x=unknowns(ssys), the second call provides the operating points.
0 commit comments