search

JuliaControl / ControlSystems.jl

A Control Systems Toolbox for Julia
https://juliacontrol.github.io/ControlSystems.jl/stable/
Other
509 stars 85 forks source link

ControlSystems + DSP #92

Open ma-laforge opened 7 years ago

ma-laforge commented 7 years ago

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
... ...

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.

baggepinnen commented 7 years ago

See issue #68

Sent from mobile device

On Dec 26, 2016 19:45, "ma-laforge" notifications@github.com wrote:

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 ... ...

  • 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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JuliaControl/ControlSystems.jl/issues/92, or mute the thread https://github.com/notifications/unsubscribe-auth/ADnx8_9cHOjWBX9d4UilX2IlOR5PNappks5rMAtYgaJpZM4LV4T4 .

ma-laforge commented 7 years ago

Sorry. I did not see that this had been raised already.

mfalt commented 7 years ago

Thanks for your input. To elaborate on the comment by baggepinnen: We have been taking about this and definitely agree that it should be possible to covert/work with both types but we are not sure what the best solution is. I think the two packages needs to be tailored for different use cases so i don't think merging would be a good solution. There have been some (diverging) work on pulling out the core types and functions to a different package. I think this would be a good first step if we want interoperability, with this as well as other packages. There has also been talks about not representing all systems as either transfer function or state space, but also storing something like a block diagram. This could allow for better numerics, but maybe make it harder to work with other packages. Any input and help is always appreciated!

ma-laforge commented 7 years ago

pulling out the core types and functions to a different package.

Indeed, at first thought: this seems like a good idea to me as well.

Having said that: I am very aware that you guys are experimenting with what you can do for control systems in Julia. I see your tf/TransferFunction object tries to deal with more general problems that I am typically used to considering. I see the inclusion of a .matrix member, and even embeds the sample time (Ts) with TransferFunction.

I must admit: I am not convinced Ts should be part of TransferFunction, though. Instead, it looks to me that you are building a representation for an even more complex idea than a simple transfer function. Other modules might not like this level of complexity for representing a simple transfer function.

Then again... this might just be my naive way of looking at things. Maybe it is not really practical to think of a TransferFunction without a sampling interval. I have not really put much thought into this idea.

Hmmm... An AbstractSystem, which could be represented as TransferFunction <: AbstractSystem, StateSpace <: AbstractSystem, or SignalFlowGraph <: AbstractSystem, .... Really interesting idea!