Introducing a new Control Toolbox for Julia with Interactive root locus

[Ronis_BR]

Hi guys!

I finally decided to publish a Control Toolbox we were developing at my institution. I know that there are a few alternatives already coded in Julia, but we wanted something more specific. We wanted that the continuous systems are simulated by means of an ODE solver instead of the usual approach of converting the continuous system into a discrete one. This was easily achieved by the amazing package OrdinaryDiffEq.jl of @ChrisRackauckas.

Moreover, the root locus should be interactive to make the design more easy. This feature was almost stalled since 2015 due to the bug Can't "connect" to events, PyCall can't create weak references to Julia function · Issue #21 · JuliaPy/PyPlot.jl · GitHub . However, for some reason, it is now working! I am uploading a gif so that you can see the proof of concept. If everything goes right, tomorrow the package (pre-unstable-very-alpha version) will be on GitHub!

[juliohm]

Hi @Ronis_BR that is really cool! Do you have a link for the repo?

Are you at a Brazilian institution? Guessing from your nickname…

Cheers,

[Ronis_BR]

@juliohm

Hi @Ronis_BR that is really cool! Do you have a link for the repo?

Are you at a Brazilian institution? Guessing from your nickname…

Hi @juliohm,

Thanks! Indeed, I am from Brazil I am with the National Institute for Space Research (INPE).

I am just finishing the last adjustments before submitting the package to github (I tested it only in macOS and now I am trying to verify if everything is working under Linux also). It should be available today. As soon as I commit the code, I will post the link here!

Cheers,
Ronan

[Ronis_BR]

It is online!

https://github.com/ronisbr/ControlToolbox.jl/

Sorry, I did not have time to test everything, so there should be some rough edges But I will work to improve this!

[mfalt]

It is nice to see that people are working on Control applications in julia.

However, as a developer of one of the toolboxes you mention (ControlSystems.jl), I can’t avoid thinking that the community could gain so much more if we would work together in developing these tools. There might be some advantages to having a few different packages doing similar things, but it seems like we too often get carried away with the coding, and start reinventing the wheel.

Are there any specific reason why you didn’t feel like contacting us to talk about possible improvements to our existing package? Do we need better docs for developers, or maybe make the code more readable?

I obviously don’t know exactly what you have been implementing, but it seems like something that could trivially be added to our (or another) control toolbox. I know that ControlSystems.jl has several short-comings, but because we are a small team, at a single department, mostly working on this on our own free time, there is not much time to make it better/perfect. Do you think the same thing might happen to your new toolbox? I think this could be avoided if more groups tried to work together, making improvements on existing code, instead of rewriting everything all the time.

The example you show with the interactive part (which I assume is clicking on the curves to get some data) looks quite useful. We have been working on doing interactive plots, like bode, Nyquist and so on using the Interact.jl package, where we have sliders controlling different parameters. We have however not been able to do what you did, does it work for other backends as well? Does it work with Plots.jl?
We have been thinking about creating a package or directory for interactive plots, maybe this could be a nice addition there?

As a proof of concept, I spent a few minutes now, implementing a similar feature for the ‘rlocusplot’ in our package, using Plots.jl recipe. It is not quite as fancy as yours, but I think it illustrates how easy it would be to add some of these features to existing packages. The code is here and figure below (using plotly)

I believe there are some interesting applications for continuous simulations, so we would gladly accept any PRs or discusstions on this.

Cheers,
Mattias

[jlperla]

Economists also use a variety of tools from control (e.g. kalman filters, linear-quadratic control, etc.) You can see some of this in https://lectures.quantecon.org/jl/tools_and_techniques.html

It would be great if there could at least be a shared linear Gaussian state space type to enable inter-operation of the libraries. For example, see https://github.com/QuantEcon/QuantEcon.jl/blob/master/src/lss.jl for an example of how economists have set this up and the sorts of utilities we require.

[juliohm]

That is great! I am from Brazil as well. Will send you a private message.

Congrats on the work!

[crbinz]

At risk of derailing this thread a little, are you aware of StateSpace.jl? They have nice implementations of the estimation pieces, at least. In general, I agree that it would be very useful for the community to agree on a common implementation for these tools.

[jlperla]

@crbinz Yup. Saw it, love it, and hope that it becomes part of the standard set of libraries we use to represent this concept. It was a little tricky to find it when I was researching things a few weeks ago.

It would be great it if was moved to JuliaControl · GitHub with the eventual goal of splitting out the GitHub - JuliaControl/ControlSystems.jl: A Control Systems Toolbox for Julia tools for state space representations from the underlying algorithms.

[Ronis_BR]

@mfalt

It is nice to see that people are working on Control applications in julia.

However, as a developer of one of the toolboxes you mention (ControlSystems.jl), I can’t avoid thinking that the community could gain so much more if we would work together in developing these tools. There might be some advantages to having a few different packages doing similar things, but it seems like we too often get carried away with the coding, and start reinventing the wheel.

Are there any specific reason why you didn’t feel like contacting us to talk about possible improvements to our existing package? Do we need better docs for developers, or maybe make the code more readable?

I obviously don’t know exactly what you have been implementing, but it seems like something that could trivially be added to our (or another) control toolbox. I know that ControlSystems.jl has several short-comings, but because we are a small team, at a single department, mostly working on this on our own free time, there is not much time to make it better/perfect. Do you think the same thing might happen to your new toolbox? I think this could be avoided if more groups tried to work together, making improvements on existing code, instead of rewriting everything all the time.

The example you show with the interactive part (which I assume is clicking on the curves to get some data) looks quite useful. We have been working on doing interactive plots, like bode, Nyquist and so on using the Interact.jl package, where we have sliders controlling different parameters. We have however not been able to do what you did, does it work for other backends as well? Does it work with Plots.jl?

We have been thinking about creating a package or directory for interactive plots, maybe this could be a nice addition there?

As a proof of concept, I spent a few minutes now, implementing a similar feature for the ‘rlocusplot’ in our package, using Plots.jl recipe. It is not quite as fancy as yours, but I think it illustrates how easy it would be to add some of these features to existing packages. The code is here and figure below (using plotly)

Hi @mfalt!

In fact, the very first version of this package date back to 2014. At that time, there weren’t any complete toolbox like the one you had now. I am at a research institution that has post-grad courses. Some of the students come here without knowing Control, and then take some initial classes. This was a way to show then the basics of Control Theory. Some of the functions was even programmed by those students (with some adaptations / changes performed by me). The idea was to let them have a place to play with those tools. We have been using this since 2014 and the only thing lacking was the interactive root locus plot, which was fixed recently. Hence, I decided to make this public. This is why I haven’t been using your toolbox

Looking at your code, the only thing I would change is that the continuous systems are discretized before the simulation. I would rather use a ODE solver in which you can change the tolerances. This, in my opinion, is better for continuous systems simulation. But, it is just my opinion. MATLAB itself uses your approach.

You can be sure that if I found something interesting to add to your package, I will send you a PR. But since this was and will be part of control-related courses here, the students have the right to choose if they want to use A or B. Usually, at the end of the courses, they have some interesting modifications that we send back to upstream. I will let them know about your package in the next year! However, you should notice that they usually do not know julia, and it is better if the programming style reminds more MATLAB than julia itself…

As for your root locus plot, we had problems regarding how we automatically choose the gains. Hence, we adapted the algorithm in Octave and in other free software tools to come-up to that. In our tests, the plots are very consistent with MATLAB without computing a huge number of gains. The interactive plot need a feature very specific to PyPlot. I am not aware of any other plotting system that can do this, but it might have.

@jlperla

Economists also use a variety of tools from control (e.g. kalman filters, linear-quadratic control, etc.) You can see some of this in https://lectures.quantecon.org/jl/tools_and_techniques.html

It would be great if there could at least be a shared linear Gaussian state space type to enable inter-operation of the libraries. For example, see https://github.com/QuantEcon/QuantEcon.jl/blob/master/src/lss.jl for an example of how economists have set this up and the sorts of utilities we require.

Hi @jlperla,

Nice! I was not aware of this Looking at your code, if you need just to define and simulate a system by adding some pre-defined function, I think both the package I am introducing here or ControlSystems.jl are ready for this! With respect to Kalman Filters, we have a full toolbox with many filters implemented (EKF, UKF, Particle Filter with many variations, etc. etc. etc.). Unfortunately, I am not able yet to release to the general public. Maybe in the next months!

@crbinz

At risk of derailing this thread a little, are you aware of StateSpace.jl? They have nice implementations of the estimation pieces, at least. In general, I agree that it would be very useful for the community to agree on a common implementation for these tools.

Hi @crbinz,

Please, see the answer to @mfalt! The initial idea of the package was to be a tool for students and it was created in 2014.

[neveritt]

I like the work that you have done with your toolbox, and especially the work on root locus. As you might be aware of it, there is already a registered package with the name ControlToolbox.jl in ‘METADATA.jl’, which I have been working on with @aytekinar and CristianRojas quite for some time. If you would like to register your package to make it accessible to more people easily, the name of your package might be problematic, until the packaging system of Julia is changed.

It is nice to to see that you have opted to rely on the ODE solvers found in
DifferentialEquations.jl. We have tried to use a similar philosophy in our toolbox, where DiffEqBase.jl is used for the simulation engine, Plots.jl (through RecipiesBase.jl) is used for the plotting support, and MathProgBase.jl is used for solving the optimization problems involved in some computations. Using these “Base” packages allows the package to be a more social package (apologies if the word is misused) in the sense that it can use any ODE solver, plotting backend and optimization solver supported by these base packages. In fact, using RecipesBase.jl
it is possible to use all the powerful features of Plots.jl, e.g., animations, gifs and interactive plots, and using MathProgBase.jl, it is possible to change the solver as you experiment with the code (as in the case of
place).

Keeping this base package design philosophy in mind, we have tried to come up with a set of tools regarding control systems. Since a lot of application areas might rely on some set of basic functionality (as is already mentioned by the posters under this thread regarding, for instance, StateSpace.jl), we have tried to abstract away some basic operations on linear, time-invariant systems in the package LTISystems.jl. To this end, we have created RationalFunctions.jl and PolynomialMatrices.jl, which have helped facilitate working with ratinal transfer function models and polynomial matrices (matrix fraction descriptions). Maybe you will find them useful. Similarly, LTISystems.jl might be a good starting point, should you want, as it contains mathematical operations among transfer function,
state space and matrix fractional description based system models, all in both continuous and discrete time, and in SISO and MIMO mode. We have also done our best to support simulation through the use of DifferentialEquations.jl ecosystem, be it in discrete time or countinuous time, for different input signal abstractions and their superpositions.

Currently we are trying to spend our free time in implementing some basic
functionality regarding system identification and control.
As for IdentificationToolbox.jl, so far, we support identification of basic polynomial models, and we aim to add support state-space system identification, as well. Currently, we are working on having also the identification toolbox use DifferentialEquations.jl for doing the work for us. For ControlToolbox.jl, we currently support basic analysis tools such as dcgain and root locus, design tools such as robust pole placement, some matrix computation tools such as lyap, gram, care, dare, and c2d functionality with different discretizers. Since we are also a small group working on the project, mostly as a serious hobby, we slowly add things to our toolboxes.

From what I see, though, the most important thing we are missing in our package is the documentation. If we had had a nice documentation, it could have taken a bit of attention.

We hope that any of the above functionality would be of help to some people in the community, and we are open to discussions on how to change the design and/or improve the ecosystem.

[Ronis_BR]

Hi @neveritt!

I indeed knew that your package was already register, but I did not change the name because currently I have no plans to register this package in Julia system. This is something that was and will be created by students that have about no knowledge of Julia but know MATLAB. Hence, you will see a lot of MATLABish programming style, which, IMHO, is not good for an “official” Julia package.

People can use it for the same educational purposes that I have, that’s why I published the package. But I think Julia deserves a much more professional control toolbox In this sense, the other alternatives seems very interesting!

[mfalt]

@jlperla

It would be great it if was moved to JuliaControl · GitHub with the eventual goal of splitting out the GitHub - JuliaControl/ControlSystems.jl: A Control Systems Toolbox for Julia tools for state space representations from the underlying algorithms.

I agree that it would be nice to split the control package(s) into one package for a standard set of structures and packages for different applications. For example, one for basic abstract types (and maybe some concrete), one for simulation and analysis, one for plotting tools, one for nonlinear systems, one for system identification, and so on. Some or several of these could be compatible between different toolboxes if we are able to agree on a common base and some well thought out API.

We have had extensive discussions on how to structure the package, and in particular the types (see here, here, here). This discussion could be lifted to a discussion about API and compatibility between packages.

If serveral packages ensures that, for example “pole” or “freqresp” (or some lower level “getABCD”), can be called on all <:AbstractRationalLTISystem, then there could be different packages that implement rootlocus, nyquist or lsim.

[Ronis_BR]

@mfalt

If serveral packages ensures that, for example “pole” or “freqresp” (or some lower level “getABCD”), can be called on all <:AbstractRationalLTISystem, then there could be different packages that implement rootlocus, nyquist or lsim.

+1 for a global definition of LTI! This will make interoperability very easy.