juliacontrol / controlsystems.jl Goto Github PK

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:

1. Keep the code as it is.

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.

2. Default all transfer-functions, that are not explicitly created, to a sampling time of e.g. 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:

• Become very flexible in creating plots.
• Plot functions automatically accept plotting related keyword args.
• Creation of complicated plots and layouts becomes easier

Cons:

• Requires significant rewriting of code
• Recipes are much harder to debug due to errors being thrown from code written in a macro, there will thus be no line number info, not even any help as to what error was thrown.

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), where delta(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

1. PS and CS retaining S and T for sensitivity and complementary sensitivity

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

1. seems like the best approach to me, following Feedback Systems by Åström and Murray

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.

• It appears that ControlSystems is targeting a "Traditional math API", whereas the DSP module is going for Julian function names.
• ControlSystems has methods to generate bode plots of 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

• Initial value
• Final value
• Step time
• Step size

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:

1. Resonant peaks can have poor resolution, due to not enough points near the peak. MATLAB accomplishes this by increasing resolution near the peaks.
2. Expanding the range to the nearest decade doesn't always include enough space. If the feature is near the edge, the steady state may be achieved outside the expanded bounds, making for a poor looking plot.
3. The current algorithm uses too many points to achieve some level of resolution. This is related to 1. In areas with no features, we don't need a dense sampling.