juliacontrol / controlsystems.jl Goto Github PK
View Code? Open in Web Editor NEWA Control Systems Toolbox for Julia
Home Page: https://juliacontrol.github.io/ControlSystems.jl/stable/
License: Other
A Control Systems Toolbox for Julia
Home Page: https://juliacontrol.github.io/ControlSystems.jl/stable/
License: Other
The function
Base.call(sys::TransferFunction, s::AbstractVector, map_to_unit_circle::Bool)
does not seem to handle the boolean value.
Our docs have apparently not been properly compiled (and updated) for a while since they were running the pidplots
function which uses the subplot
command. Could you update this function @baggepinnen. When this is done, I will make sure to deploy new docs.
G = tf([1], [1; zeros(3)], 1)
y, t, x = step(G, 10)
gives
ERROR: Time vector must match sample time for discrete system
The problem seems to be that the wrong time vector is created for the step response.
From @baggepinnen on February 19, 2016 16:50
So that one can write
?func
and get a meaningful help text
We should keep a list here of all the functions that are lacking proper doc-string:
The num
and den
functions zero pad the returned arrays to make them have equal length.
This breaks the behavior of ControlSystems.isproper
, For example ControlSystems.isproper(tf("s"))
evaluates to true
.
This results in that ss(tf("s"))
returns a stranger result.
What was the motivation for the zero-padding? Should it be removed or should isproper
be modified?
It is currently possible to do
f = tf(1,[1,1])
[f 0; 0 f]
without any problems but the discrete version
f = tf(1,[1,1], 0.01)
[f 0; 0 f]
throws an error that sampling times are not equal. This is because
Base.convert{T<:Real}(::Type{TransferFunction}, b::T) = tf([b], [1])
which is called through promote
in (h)vcat
defaults to continuous time (Ts=0
).
How should we handle this? I can see two solutions:
If the user wants to create a matrix like this it is possible to do
d0 = tf(0, 0.01)
f = tf(1,[1,1], 0.01)
[f d0; d0 f]
The downside is that we are treating continuous and discrete systems differently without any real reason.
Ts=-1
.It is then possible to identify this while concatenating and converting to the appropriate value, and we can throw errors if the user is trying to for example simulate a system like this.
Is step plot working ?
LoadError: UndefVarError: subplot not defined
while loading In[6], in expression starting on line 10
in stepplot at /home/phelipe/.julia/v0.4/ControlSystems/src/plotting.jl:81
in stepplot at /home/phelipe/.julia/v0.4/ControlSystems/src/plotting.jl:103
The code in pid_design.jl and discrete.jl currently has 0% and 20% test coverage, we should definitely improve this if we want to support that functionalty.
We should also convert the functions in piddesign/discrete to use the new functions numvec/denvec/numpoly/denpoly where it is useful.
I could help out with this but @baggepinnen is tagged since the code was implemented by him.
feedback2dof and probably others completely disregard the Ts field, automatically creating continuous systems.
The subplot syntax was changed in Plots 0.7 so our plot code does not work with that version yet. It has been fixed in branch newplotssyntax
but I will not pull it until I know this will be the final subplot syntax.
it just returns a siso tf
Hey this looks like a great package!
I'm curious if you are planning to support subspace identification and similar functionality here, or would that live in a different repo? I could contribute it if there is interest. Sorry if this is outside your scope.
sys = tf([1, -1.45, 0.475], [1, -2*0.5, 0.5^2], 1.0); norm(sys)
returns "Inf". Both poles are at 0.5, so the norm should be bounded. Same code in Matlab returns 1.1269.
From @baggepinnen on February 22, 2016 19:25
This behavior causes lots of squeeze statements
julia> Control.bode(S)
(
1x1x200 Array{Float64,3}:
[:, :, 1] =
1.00504
[:, :, 2] =
1.04091
[:, :, 3] =
1.07809
...
Copied from original issue: mfalt/Control.jl#22
From @mfalt on February 21, 2016 1:9
The dampreport test seems to fail on my julia 0.4.2. Not sure if I broke it or some julia update.
Copied from original issue: mfalt/Control.jl#10
From @baggepinnen on February 22, 2016 8:46
Currently, only gain and phase margins are computed, delay margin is also of interest
Copied from original issue: mfalt/Control.jl#21
There has been a long going discussion on how to restructure the toolbox to allow for better extendability and performance. The discussion has so far mainly been between @mfalt @baggepinnen @aytekinar and @neveritt. It is very valuable to me that we are able to agree on a solution that can help the package become better and to avoid any unnecessary forks of the project (I think this wold be really bad for the community).
I therefore tried to summarize the proposals on the wiki HERE. Anyone is welcome to edit and add new proposals and Pros/Cons on each of the points. I have tried to be as impartial as possible when stating the proposals.
The more views the better, I think anyone who is currently using or planning to use this toolbox should feel free to add their view! I am therefore also tagging some users that have previously shown interest in the package: @ufechner7, @jcrist, @denglerchr, @phelipe, @jleny, I hope you don't mind.
The main difference between our views is whether or not Proposal 2 is a good option. The main point of this proposal is to have both a SISO and a MIMO type visible to the user. The SISO type is currently only an internal representation of a function that is not directly available to the user.
I will try to wait until a few people have had the chance to weigh in before I state my opinions.
What is the problem, that this package shall solve? Which functionality shall be implemented?
a) linear system design
b) PID controller design
c) optimal control design
d) non-linear control system design
Shall it be used for a specific type of control system course (teaching)?
If yes, which level of courses?
Shall all the functions of Scilab be implemented?
See: https://help.scilab.org/docs/5.5.2/en_US/section_64a8529216e858b335b0e6c058385350.html
Any comments welcome.
I create this issue to facilitate a discussion on whether to update all or a subset of the plot functions to recipes
http://plots.readthedocs.io/en/latest/recipes/
I have updated a few other packages to recipes and will create a branch where I translate a single function, like bodeplot
to a recipe to see how it works out.
Some pros and cons I have noted so far
Pros:
Cons:
All functions in matrix_comps seems to be limited to accepting the same type of arguments, is this intended behavior?
For example, these work as expected
care(eye(1), eye(1), eye(1), eye(1))
e1 = eye(Int64,1)
care(e1, e1, e1, e1)
with output
1x1 Array{Float64,2}:
2.41421
but you do not allow
care(eye(Int64,1), eye(1), eye(1), eye(1))
ERROR: MethodError: `care` has no method matching care(::Array{Int64,2}, ::Array{Float64,2}, ::Array{Float64,2}, ::Array{Float64,2})
I assume that this was a mistake, but since it is consistent over all functions in this file, as well as in a few others, I wanted to make sure before I spend any more time on it, especially since I am not familiar with the BLAS types. The solutions should be quite simple, mostly changing this:
function foo{T<:Bar}(a::T,b::T)..
to something like:
function foo(a::Bar,b::Bar)..
You are also not allowing scalars as inputs, is this intentional?
The poles of a transfer matrix is not the concatenation of the poles of the matrix elements.
Compare for example Example 3.1 in Control Theory by Glad&Ljung.
which concludes that
s=tf("s"); sort(pole([2/(s+1) 3/(s+2); 1/(s+1) 1/(s+1)])) == [-2, -1, -1]`
`'`
another test case is
s=tf("s"); pole(tf(ss([-2], ones(1,2), ones(2,1), zeros(2,2)))) == [-2]
I don't know how it should be handled in a numerically sound way.
From @baggepinnen on February 21, 2016 12:30
It would be nice with support for transfer functions with SymPy symbols
Copied from original issue: mfalt/Control.jl#13
From @baggepinnen on February 25, 2016 8:16
evalfr and freqresp does not yield the same result, this caused bug in margin. Bug has been repaired by switching to freqresp, but evalfr should be fixed
Copied from original issue: mfalt/Control.jl#27
This issue is not urgent, but it would be nice feature. Similar problems arise when solving LQG problems with integrators that we are not looking to control for example.
A brief repetition of what covar
is supposed to do for continuous systems:
Calculate the stationary covariance P of the system output y(t) when the input has the property
E[u(t)u(tau)'] = W*delta(t-tau)
, wheredelta(t)
is the dirac delta.
The current implementation of covar returns a covariance Matrix
of Inf
if the system is unstable or if there is a direct termD .!= 0.
This is quite reasonable and the same as current versions of matlab. It could however be done better. The current algorithm does the following
Q = lyap(A, B*W*B')
P = C*Q*C' + D*W*D'
with the extra case of when D .!= 0
and system is unstable. However, some of the outputs might still have definable variance on the output (if for example the noise is correlated so that it doesn't pass through the direct term D*W*D' = 0
). A solution for this would be
Q = lyap(A, B*W*B')
P = C*Q*C'
P[D*W*D' .!= 0] = Inf
But we also have the case where some states are not controllable/observable. It would be nice to be able to capture these cases properly. For example A=1, B=C=D=0
would generate a zero output (P=0
), but we would output Inf
. And A=B=C=D=0
throws an error because lyap
is not solvable (or has no unique solution), but again P=0
is correct.
To be able to put this toolbox in julia METADATA it seems like we need to change name to ControlSystems.jl instead of Control.jl, does anyone have any objections or thoughts about this?
@jcrist?
I would prefer Control.jl but it seems unlikely that they would accept this (see JuliaLang/METADATA.jl#4753 for discussion). "ControlSystem" is the name that matlab uses for example, is this better than "ControlSystems"?
pidplots should be updated such that it makes use of the standard functions for nyquistplots etc.
We should start considering this during all development of new code and eventually start porting the old code.
From @mfalt on March 1, 2016 10:2
Zpkdata
or similar is implemented twice and incorrect at least once (in transferfunction.jl 58)
return SisoZpk(roots(sys.num),roots(sys.den),sys.num[1]/sys.den[1])
Copied from original issue: mfalt/Control.jl#29
minreal is currently only supporting tf, and it's not very reliable
From @mfalt on February 21, 2016 1:7
The implementation of Poly
is outdated and the roots
function extremely inaccurate. We should consider using the Polynomial.jl package.
Copied from original issue: mfalt/Control.jl#9
From @baggepinnen on February 23, 2016 20:2
Should be renamed to static gain, or dcgain as in matlab.
Should also be * working properly*
Copied from original issue: mfalt/Control.jl#24
Add documentation through Read-the-docs. "Docstrings" are added using the @doc
macro already, there may be a way to use these to pull these in to the documentation.
It would be nice to have some examples as well. The StateSpace
and timeresp
stuff is already fairly functional, some simple examples from an intro linear-systems course could be added.
The Nyquist frequency is half the sampling frequency and not equal to it.
If frequency vector is specified it should perhaps not be truncated at the Nyquist frequency, but rather a point should mark it on the Nichols curve.
The arguments to the plot function are very short, val, sat and pInc doesn't say much about what they are used for. They are only used once in the code, so a longer, more descriptive name would make the code more self documenting for example:
gain_line_hue
gain_line_saturation
or something similar.
I find the unicode characters for real and imaginary parts are hard to read (subjective), would prefer just write Re and Im.
In the gangoffour function, the transfer function from d -> y and n -> y are referred to as D and N respectively, (the sensitivity and complementary sensitivity functions are referred to as S and T)
However D and N are typically used to denote the spectrum of d and n.
More suitable names for the transfer functions in the gangoffour would be either
or
2) Gyd and Gun while retaining S and T
3) Gyd and Gun while with some transfer functions G?? and G?? for S and T
Would perhaps be good to adopt some style guide for the notation throughout the package.
Hi,
I have been reading your wiki on "Restructuring ControlSystems".
You mention the:
Modia implementation of the Modelica language
This sounds very interesting. Could you elaborate? I could only find module "Sims.jl". Is Modia going to be Tom Short's next iteration? I do not know where to find information on this.
There seems to be alot of overlap in the facilities provided by the https://github.com/JuliaDSP and https://github.com/JuliaControl groups.
JuliaControl | JuliaDSP |
---|---|
zpk |
ZeroPoleGain |
tf / SisoRational |
PolynomialRatio |
... | ... |
LTISystems
- a facilty that the JuliaDSP users might also want to apply to their solutions.I think both solutions have merit - and I am not asking anybody to necessarily comply with the other group's solutions (that might actually hinder development). However: I am could not tell if either one of the groups was aware of the other.
Eventually, (if the two solutions need to go in their own seperate direction) it might be nice to at least have a bridging package so that users can easily convert data structures and use the other module's facilities - almost transparently.
Testing is woefully incomplete. This should be fixed before new features are added.
We are not allowed to checkout unregistered packages in the tests so have to change how we test the plots. The current structure is using the ControlExamplePlots.jl, we should restructure it so that we download specific versions of that repo instead of using Pkg.checkout
. See discussion on pull request here and on Plots.jl here
This is urgent because of for example #75.
From @baggepinnen on February 23, 2016 19:47
One should be allowed to supply any subset of the following
Copied from original issue: mfalt/Control.jl#23
I try run feedback function but I get "UndefVarError: feedback not defined". Code:
using ControlSystems
S1=tf([1],[0.01,1])
feedback(S1)
Is It a package error or my code?
From @baggepinnen on March 4, 2016 15:42
the roots are sometimes mixed up in rlocus, there must be some intelligence to sort the roots such that the trajectories are continuous
Copied from original issue: mfalt/Control.jl#32
Current plotting uses only PyPlot. It would be nice to add Gadfly as another plotting backend, as it only depends on Julia (not python).
One possible way of doing this is refactoring out the plotting commands (probably a good idea anyway) into separate function(s). This can then be included lazily using Requires.jl
, with different files for PyPlot
and Gadfly
. A user is unlikely to load both in the same session, but if they do, then the last one loaded before a *plot
function is called will be the one used. One way around this would be to include a set_plot_backend(backend::Symbol)
, which sets a global, which is used in the plotting to determine which interface to call. This is similar to how the array printing works in base, with the _limit_output
global. However, as stated above, it's unlikely that a user will be using two plotting packages at the same time, so this is probably unnecessary.
Needs a description, installation instructions, a link to documentation (see #2) and possibly a simple example.
With coverage working again after the move to LLVM 3.5, this should be possible finally.
Hello,
I have a non-sense problem. When i use Step, or somtehing like that, i never get a graphic.
For example:
using ControlSystems g = tf(1,1) step (g)
The output is: ([1.0; 1.0; . ; 1.0; 1.0],
0.0:1.0:100.0,)
I cant figure whats going on. Any idea?
From @baggepinnen on February 21, 2016 12:28
e.g. numerator = num(G)
and num,denom = poly(G)
Copied from original issue: mfalt/Control.jl#12
From @baggepinnen on February 27, 2016 9:47
The code below, is wrong, both for continuous and discrete systems
function _zpk_kern(s::SisoRational)
return roots(s.num), roots(s.den), s.num[1]/s.den[1]
end
this fix works for continuous
function _zpk_kern(s::SisoRational)
return roots(s.num), roots(s.den), s.num[end]/s.den[end]
end
but not for discrete, since SisoRational does not hold info regarding cont/discrete
Copied from original issue: mfalt/Control.jl#28
The current algorithm detects all features (poles and zeros) of the individual channels, and creates a range covering these, expanded to the nearest decades. This approach is ok, but has a few issues:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.