Control system library for Julia?

[Uwe Fechner]

Hello,

I could not find any control system library for Julia yet. Would that make sense?
There is a control system library available for Python:
http://www.cds.caltech.edu/~murray/wiki/index.php/Python-control

Perhaps this could be used as starting point? I think that implementing this in Julia
should be easier and faster than in Python.

Any comments?
Should I open a feature request?

Uwe Fechner, TU Delft, The Netherlands

[Patrick O'Leary]

System controls-oriented tools would be a great thing to have. We don't use the issue tracker for package requests--we prefer to keep that narrowly focused on the base system--but feel free to jump in on starting a package.

[Jeremy West]

Uwe,

I had intended on doing some work on this last summer, but my research got mucky (I'm still working on graduating >.<). However, I just got a job and should have a good amount of time and energy to get cracking on this finally once I get moved and settled. There had seemed to be a good amount of interest before, and even a name was decided on. I had a github repo too but I think it was with the old name. Anyways, long story short there will be one soon and I'll announce it on the list with the github repo for feature requests and what not. I'd like it to be driven by need, and not just my expertise (state estimation).

Jeremy

[Tony Kelman]

Have a look here, https://github.com/jcrist/Control.jl is making better progress than anything else I've found in the topic. He has wrappers to Slicot as well.

[Uwe Fechner]

Hi,

this looks already promising. The important thing is to get started and to have an issue tracker, and with this
git repo this is already in place.

I am currently working on automated control of kite-power systems. A little video about our
project: http://www.youtube.com/watch?v=FJmlt3_dOuA

Best regards:

Uwe

[Tony Kelman]

Well and at least a start on some useful functionality, to get everybody in the same place and not duplicating the initial effort.

Those kite power projects are so incredibly cool! I imagine you're using some combination of Casadi, Acado, and/or Optimica?

I do model predictive control at Berkeley, we have our own custom Matlab/Simulink tools that work pretty well for our uses but longer-term I'd rather have something more elegant (and in an open environment) that doesn't have to work around Matlab's limitations and Simulink's 10+ subtly-incompatible but still-in-common-use versions.

[Jeremy West]

I guess somebody got impatient with my disappearance :) I'll probably contribute to that instead, it looks like a similar roadmap I had in mind before things got messy.

[James Crist]

Hello all,

Glad to see there's some interest in this. I'm the one behind https://github.com/jcrist/Control.jl.

I've been working through the getting the base types defined, before starting work on the analysis functions. The first goal is to get something simliar to matlab's basic control toolbox, with all the commands that an undergrad would use in an intro course. After that, higher level stuff will be tackled. Both Python control and Octave's control toolbox have been serving as inspiration. It's surprising (not really actually) how easily most of this transposes into julia.

I need to get ready for a seminar I'm giving tomorrow, but over the weekend I plan to commit a major refactoring of the base types (TransferFunction and StateSpace) to make them more julia-friendly (python has pythonic, what's the julia version?). After that, it should be fairly trivial for others to write functions that work on these types.

Slicot will be used to do all the heavy lifting, because it's free* and why bother reinventing the wheel. I have a set of wrappers that I generated for the raw interface that still need a human to look over them. I was planning on doing it as I got to using individual functions, but that'd be an easy thing to look through for others.

- - - - -

Major quesion of the moment: what plotting library is best plotting library? I'm coming from heavy python usage, so winston's syntax is more friendly to me.  But gadfly looks great as well. I'd rather not use pyplot - I'd like to keep it as much in julia as possible. Thoughts?

-Jim

*Slicot (per they're website) is no longer GPL after version 4.5. However, the debian repo has 5.0, and the tar ball I got contains a GPL2 license. Not sure what to make of this. The most recent free version should definitely be the one used.

[Uwe Fechner]

Hello,

I know Casadi and know the guys from KU Leuven who developed it. But I currently do not use any of this fancy stuff.
I mainly use Python, Assimulo and C++ for modelling and control. A little bit Matlab and Python for controller development,
but currently our controllers are very basic, just non-linear dynamic inversion and a little bit optimal control.
Next week I will start to work on feed-forward control, a very basic form of model predictive control.

You can find some of my software at https://bitbucket.org/ufechner .

Using Julia instead of Python, C++ and Matlab would be great. I will try to find an MSc student to do a little pilot
project with Julia.

Regards, Uwe

[Tony Kelman]

I think the Julia version of Pythonic is "Julian." My understanding on the Slicot licensing situation is that 5.0 was initially released as GPL, and this is the version that Debian uses, but since then it was taken down and re-released under a different license. We can follow the Homebrew formula's lead and use the Debian repo as a source, unless you needed to make tons of changes to files that were in the tarball. I believe the convention with Julia packages is to minimize the amount of non-Julia source. Hopefully someone who is interested in control, has experience with BinDeps, and has some time can help out here.

[Simon Kornblith]

This is great! ss2tf and potentially other functionality is also relevant to DSP more generally. We currently have conversions between most standard filter representations in DSP.jl (see https://github.com/JuliaDSP/DSP.jl/blob/master/src/filter_design.jl) but no state space representation. There is also a Polynomial package (https://github.com/vtjnash/Polynomial.jl) that may be a good place for polynomial-related functions to live.

Simon

[James Crist]

@Tony,

I agree on pulling from the debian repo. Doesn't make sense to rehost code. The only things that need to be changed are the build process, and the alternate xerbla.f file. Perhaps the makefiles and the xerbla subroutine could live in the git repo, and julia could just switch them out?

@Simon,

I initially started off using the polynomial package, but stopped due to its limitations and some design decisions. I may try to integrate my added functions and send them a pull request. As for the DSP library, nice work! The python control package integrates nicely with scipy's dsp functions, perhaps there's a way we could do the same? Two thoughts on this:

1.) Conversion function between DSP types and control types
- or -
2.) Same base type for both DSP TF and control TF (they're basically the same)

For ease of use, I'm leaning towards the first one. Does DSP.jl support mimo systems?

For those interested in helping, perhaps we should move this discussion somewhere else? Not sure if github issues are the best way to communicate, or if a google group should be started up.

-Jim

[Simon Kornblith]

On Saturday, February 22, 2014 1:14:56 PM UTC-5, James Crist wrote:

@Tony,

I agree on pulling from the debian repo. Doesn't make sense to rehost code. The only things that need to be changed are the build process, and the alternate xerbla.f file. Perhaps the makefiles and the xerbla subroutine could live in the git repo, and julia could just switch them out?

@Simon,

I initially started off using the polynomial package, but stopped due to its limitations and some design decisions. I may try to integrate my added functions and send them a pull request.

That would probably be useful to many people. The current lack of polynomial division in Polynomial.jl is pretty conspicuous.
 

As for the DSP library, nice work! The python control package integrates nicely with scipy's dsp functions, perhaps there's a way we could do the same? Two thoughts on this:

1.) Conversion function between DSP types and control types
- or -
2.) Same base type for both DSP TF and control TF (they're basically the same)

For ease of use, I'm leaning towards the first one. Does DSP.jl support mimo systems?

DSP.jl doesn't presently support MIMO systems. I'm not sure if MIMO is common enough outside of control systems to be worth supporting in DSP.jl, so it may make sense to have separate types with conversions. But it would be great if we could "borrow" your conversions between state space and transfer function representations in DSP.jl, since there are DSP filter transforms that are best implemented in state space. Additionally I suspect that we will both eventually want to implement many of the same plots.

[Andrew Wagner]

Hello again Uwe!  

It's fun running into someone I know on a language geek forum :)  I'm helping one of our bachelor's students implement an LQR controller on our carousel in Freiburg.  It's an ugly hack, but I'm calling an octave script to recompute the feedback gains online.  Octave wraps slicot, so if the licenses are compatible, perhaps wrapping slicot is the way to go for some functions, if the licenses are compatible.

Personally, I have a burning desire for a better language we can actually do control in (rust?).  I doubt Julia qualifies due to the garbage collection, but does anyone know if Julia has some sort of way to JIT Julia expressions to code that does ~not have any garbage collection?  If so, is there a way to export them as object files and link against them from C?  Then you'd still have to write glue code in a systems language, but at least the implementation of the controller wouldn't have to cross a language boundary...  

Cheers,

Andrew

[Spencer Russell]

Hi Andrew,

What are your realtime deadlines? I'm working on live audio processing stuff with Julia, where I'd like to get the audio latency down into a few ms. Julia definitely isn't there yet (and might never get true hard-realtime), but there's some promising work being done on the GC to reduce pause time for lower-latency applications. It's also helpful to profile the code to reduce allocations (and the need for GC) down to a minimum. I haven't yet gotten down to zero-allocation code in my render loop, but once I got it down below 100 bytes I moved on to other more pressing features. At some point I'll dig deeper to see if I can get rid of the last few allocations.

I'd definitely be happy if there are some more folks out there driving demand for lower-latency Julia. :)

peace,

s

[Tony Kelman]

Slicot's not ideal from a licensing standpoint, see the earlier discussion from February in this thread. There is a GPL-licensed version of Slicot available from Debian, which works for the sake of a package. Long term it makes more sense to reimplement the important parts of Slicot that wrap Lapack to provide Sylvester and Lyapunov and Riccati solvers for discrete and continuous time, in base Julia.

I think Jim Crist spent the summer doing a Python GSoC, so progress on control packages for Julia has been mostly stalled.

Eventually I think Julia could make a fine platform for code generation of embedded controllers, hard or soft real time. Array views and the like will make this easier, but I don't see any reason you couldn't refactor Julia code to do the vast majority of allocation up-front and end up generating more or less the same LLVM IR that Rust's compiler would. And I doubt Rust will ever be as good of an interactive technical computing environment as Julia in terms of REPL, plotting, simulation, experimenting, etc. Compile-run-tweak cycles are not a convenient way to do control design (or much of anything, let's be honest).

Generating embedded controllers in LLVM IR rather than C is currently very atypical, but eventually I think it could be made to work. A Julia replacement for "realtime workshop" is a good long-term goal.

[Andrew Wagner]

Hi Spencer!

My job in airborne wind energy is ending soon so I don't have a specific application (aside from control), but I would want to stay sub-ms for anything in-process.  I have been using Orocos extensively for the last few years.  It's the best control middleware in the open source world, but I think a lot of things could be improved if it was re-implemented in a language with a better typesystem and introspection... one example would be that adding a new type to the system requires quite a bit of boilerplate code, creating an incentive for users to just pass data in flat arrays, subverting type safety.  

Cheers,

Andrew

[Uwe Fechner]

Hi,
I am working an airborne wind energy as well. I wrote a kite-power system simulator in Python, where also one of the controllers (the winch controller) is
implemented in Python. ( https://bitbucket.org/ufechner/freekitesim )

With Python you can reach a jitter of less than 2 ms in the 20Hz control loop quite easily (on low-latency Linux). In my case this is sufficient for prototyping,
but the real flight control system should run at a higher update frequency (perhaps 200 Hz).

In contrast to Julia Python is using reference counting, and in my Python applications I just turn off the garbage collection.

For Julia (and I would love to rewrite the simulator in Julia) this is probably not an option. A better garbage collector
(which is in the pipeline, see: https://github.com/JuliaLang/julia/pull/5227 ) would definitely help.

Generating embedded controllers in LLVM IR would be great!

Best regards:

Uwe

[Andrew Wagner]

Hi Tony!

I'm a bit burned out on software systems that are pieced together out of multiple languages, doing code generation, etc... If there's not a single language that can do everything I need for the project, I would not start it yet.  It's really hard for me to tell at this point whether it is more likely in the future for Julia to become suitable for systems programming, or for rust to become suitable for interactive use...  Those are explicitly non-goals for the main developers of the two languages, so it's hard to predict.  

Cheers,

Andrew

[Tony Kelman]

You don't write in assembly, do you? Every stack is implicitly doing multiple languages and some form of code generation in the process of compilation, you just don't have to know whether it's happening.

"Systems programming" as intended by Rust and as a software engineer would mean the term is a rather different thing than what you want for the purposes of embedded real-time control. There are plenty of embedded environments where if you're allowed to use C++ at all, it's only a limited subset, anything involving exceptions or RTTI is often not supported. It's tough to audit 3rd-party libraries for these kinds of restrictions, and achieve any kind of code reuse or non-trivial complexity.

I'd say reducing the number of mandatory dependencies and making it possible to statically compile Julia code into minimal standalone executables and libraries is absolutely an explicit goal of the main Julia developers, just check the 0.4-projects milestone on Github. It's not there yet, but progress is being made.

[Andrew Wagner]

Hi Tony and Uwe!

Sorry, I'm more aware of these issues than I indicated in my post.  Of course one or two steps of code generation / specialization is necessary to get from human readable to machine executable code.  

I was actually sitting here reading the thread about the improved garbage collector that is in development.   Compared to the stack, RAII, and reference counting, this still sounds like a mess if you want deterministic timings... 

Thanks for the info about the standalone executables, Tony; I'll go read that too later.  If it's just packing up everything into one executable that still has very non-deterministic timings when you run it, it's not a win for control, of course, but maybe the plan is to also do more aggressive specialization of parts of the code (no gc? static binding? stack only?) at the same time; I will go read!

Thanks for the anecdote about your experience using Python in the loop Uwe; that's interesting!

Cheers,

Andrew

[Tony Kelman]

The initial goal is packaging up conventional Julia code with the conventional runtime and GC, so no you don't get determinism from that. Even with explicit memory management you're unlikely to get true hard real-time determinism unless your code is running on a specialized RTOS anyway, and those are very restricted environments where nothing aside from C or a limited subset of C++ is likely to be allowed anyway. Unless you want to write at that low level, you'll need a DSL to design the allocation-free purely computational parts of a controller, and the communication and synchronization algorithms. Galois has done a lot of work on this kind of thing hosted in Haskell, see their Ivory and Tower DSL's. I don't know of anyone doing this kind of work in Julia yet, but it would be cool to see, and in my non-expert opinion I think it should be feasible.

[Andrew Wagner]

Another quick note, Tony:

 There are plenty of embedded environments where if you're allowed to use C++ at all, it's only a limited subset, anything involving exceptions or RTTI is often not supported. It's tough to audit 3rd-party libraries for these kinds of restrictions, and achieve any kind of code reuse or non-trivial complexity.

At least the "auditing for restrictions" part of that problem ~seems like it should be easy in a well designed language.  I want to just declare an environment and have the compiler throw errors if anything inside it violates the restrictions I care about for whatever my personal definition of what a "realtime" or "typesafe" or "pure functional" language subset is.  

Something along the lines of: "#[deny(managed_heap_memory)]":

https://github.com/rust-lang/rust/issues/9984

Of course as you point out there is the other part of the problem "achieving code reuse and complexity", which is much harder. 

[Uwe Fechner]

Ivory looks interesting. But what does DSL mean (in your post)?

[Tony Kelman]

Domain specific language. Sometimes with an E in front for "embedded" domain specific language, meaning a DSL embedded within a different general-purpose language as opposed to a standalone DSL that only does one thing. (not the type of embedded that the rest of this conversation has been about)

[Andrew Wagner]

RE Ivory and Tower, and similar efforts in Haskell, I am aware of them and I do find them really interesting.  Since Rust is based on the same type theory as Haskell, I'm hoping similar things will be possible in Rust, without having an additional layer of code generation.  I'm still trying to work out how much of the special sauce in Haskell is in the type system, and how much is in the "functional purity."  

[Andrew Wagner]

(E)DSL is a buzzword functional programming people use that really just means "API".  

[Tony Kelman]

I didn't really mean by way of compiler flags or language pragmas. I can try -fno-rtti or -fno-exceptions with g++ today, it doesn't do me much good to spend a week getting half a dozen dependency libraries built with the obscure proprietary embedded board compiler only to find the very last thing I need won't work. The type of control I do is pretty sophisticated - optimization-based, nonlinear, large-scale MIMO systems, incorporating a prediction model of the system and satisfying state and input constraints - takes a bunch of libraries to do properly, not the kind of thing that's easy to throw together from scratch in C. It would be nice to get guarantees by construction that my controller and all the code it uses would be deployable to an embedded environment from the very beginning.

Luckily microcontrollers are getting much more powerful these days and the line is starting to blur between embedded RTOS and lightly tweaked Linux. You can fit lots more code and do more interesting things with the same power/thermal footprint, getting lots more flops and IO in soft-but-pretty-damn-good realtime at the same or better speeds.

Though what this thread was originally about was tools for doing offline control design, where Matlab/Simulink absolutely dominate. You don't want to do simulation, analysis, testing, and tuning in the exact same low-level restricted language that the realtime controller gets deployed to, the requirements are completely different.

[Patrick O'Leary]

On Monday, September 15, 2014 3:25:07 AM UTC-5, Uwe Fechner wrote:

With Python you can reach a jitter of less than 2 ms in the 20Hz control loop quite easily (on low-latency Linux). In my case this is sufficient for prototyping,
but the real flight control system should run at a higher update frequency (perhaps 200 Hz).

Semi-off-topic: 200 Hz seems really fast to me. What kind of high-frequency dynamics do these things have? I'm not familiar with this particular design space. Any good (open-access) papers?

Patrick

[Uwe Fechner]

more informations on kite control you can find in the following papers:

Fechner, U., & Schmehl, R. (2012). Design of a Distributed Kite Power Control System. In Proceedings of the IEEE Multi - Conference on Systems and Control (p. 800-806). October 3-5, 2012. Dubrovnik, Croatia.

http://www.kitepower.eu/images/stories/publications/fechner12b.pdf

U. Fechner and R. Schmehl, “Feed-Forward Control of Kite Power Systems,” Journal of Physics, 2014.

http://iopscience.iop.org/1742-6596/524/1/012081

Uwe Fechner

[Andrew Wagner]

Hi Tony!

I just skimmed your web page; looks like you're doing some interesting stuff with NMPC in matlab/Simulink with your group's BLOM library:

http://www.mpc.berkeley.edu/software/blom

so it looks like you're the right guy to be working on something similar for Julia :)  

Off topic: Since you're also at the intersection of programming language and optimal control nerd-dom, you may also be interested in work Greg Horn is doing here in Moritz Diehl's group; he has written a Haskell wraper around casADi (developed mainly by Joel and Joris, two other guys in our group), which in turn wraps a handful of solvers, i.e. ipopt.  

https://github.com/ghorn/dynobud

Cheers,

Andrew

[Patrick O'Leary]

On Monday, September 15, 2014 9:56:23 AM UTC-5, Uwe Fechner wrote:

more informations on kite control you can find in the following papers:

Fascinating! Thanks for sharing.

[James Crist]

I think Jim Crist spent the summer doing a Python GSoC, so progress on control packages for Julia has been mostly stalled.

Ha, yeah, was working on symbolic dynamics solver stuff - more applicable to my research. I have some unpushed commits for Control.jl, but for the most part this project has stalled until I finish my degree. I just don't have the use for simple linear systems routines right now, when my system has nonlinearities, and i'm implementing it in discrete time in C. This project started out as me just playing around with Julia, and wishing it had a controls toolbox. I still do, but just don't have the time.

A Julia replacement for "realtime workshop" is a good long-term goal.

That would be awesome. I hate doing *almost* everything opensource, and then still turning back to simulink in the end to test on hardware. Not cool.

more informations on kite control you can find in the following papers

This is super cool.

- Jim

 

[Steven Sagaert]

GC will always be non-deterministic. For "hard" real time you just need to manage memory yourself. That's the approach used by real time Java http://www.rtsj.org/

[Uwe Fechner]

Event though pre-allocation is preferred for real-time
application, often there are some parts of the code
that are hard to implement without any garbage
collection.

Hard real-time is possible even if you are using a garbage
collector.

Some references for this point of view:
http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html

https://lwn.net/images/conf/rtlws-2011/proc/Klotzbuecher.pdf

Best regards:

Uwe Fechner

[Steven Sagaert]

Hi Uwe, 

In the Java world, Azul Zing is something along the lines of the first ref but I think it is still only soft real time. If you want that kind of garantees it's probably better not to keep garbage lying around to be collected later but free the memory immediately when no longer needed like via smart pointers as in C++. In fact that gives you almost everything a GC does except for collecting cycles but circular datastructures are rare and you can always break the cycles yourself so this isn't a big deal in practice.

[Simon Kornblith]

Manually managing memory is far easier than implementing a hard real-time garbage collector, but hard real-time garbage collectors do exist: the Staccato paper claims worst-case pause times of under 1 ms.

Simon

[Uwe Fechner]

For me it would be important to reach the real-time performance of Python/ Numba with Julia:

I would like to port my flight simulator (https://bitbucket.org/ufechner/freekitesim) to Julia,
to improve the performance, make maintenance easier and to start working with automated
differentiation.

I think this performance (max. 2-4 ms time for a call of an incremental garbage collector) should
be possible to achieve by implementing an improved garbage collector for Julia.

This would not be hard real-time, but already very useful for many practical applications.

Uwe

[Simon Kornblith]

A collector with a hard constraint on the worst-case GC time is a hard real-time collector. I don't think many collectors can guarantee 2-4 ms worst case GC times (although evidently Staccato can). There is also a tradeoff between having a real-time collector and having the fastest possible collector for non-real-time applications that has been discussed elsewhere.

Simon

[Uwe Fechner]

Jeff Bezanson suggested in the following discussion ( https://github.com/JuliaLang/julia/pull/5227 ):
> It would be great to have the option to build with a low-pause GC for users who might want that.

This is exactly what I am looking for: To have two different garbage collectors for Julia, a fast collector for non-real-time applications and a low-latency GC
for real-time applications. Uwe

[Stefan Karpinski]

On Mon, Sep 29, 2014 at 4:21 PM, Uwe Fechner <uwe.fec...@gmail.com> wrote:

Jeff Bezanson suggested in the following discussion ( https://github.com/JuliaLang/julia/pull/5227 ):
> It would be great to have the option to build with a low-pause GC for users who might want that.

This is exactly what I am looking for: To have two different garbage collectors for Julia, a fast collector for non-real-time applications and a low-latency GC
for real-time applications. Uwe

Yeah, that would be great. 

[Spencer Russell]

I'm looking forward to some sort of flag or option to turn on the incremental GC, and trying to understand a bit more about the design space. My naive thought process goes something like this:

1. The total time to collect garbage probably grows with number of objects and total size to be freed (though maybe size doesn't matter much here?)
2. An incremental GC will collect until it runs out of time, then hand control back to the application until it's time to run again
3. It seems like there's a rate of garbage generation where you're building up garbage faster than the GC can collect it without missing its deadline
4. It seems like if you stay below this rate you can consider your maximum pause time to be bounded and memory won't be leaking. We hold hands and sing songs.
5. So the issue is what to do when you're above that rate. Either you:
1. make sure memory consumption doesn't grow indefinitely by having some heuristic for when the GC decides to give up on the deadline, OR
2. make sure the GC never violates its deadline and run the risk of running out of memory
   

Are there other options besides those two?

I would definitely welcome an actual hard-realtime bounded-pause-time GC, but it also seems valuable (and possibly more feasible) to have a GC where the pause time is bounded with caveats and more careful programming. I'm not sure whether this qualifies as hard realtime, though it seems like it might if you can make those guarantees about your application code.

It's also worth mentioning for other folks interested in latency that that JIT compilation is a killer as well, so you need to guarantee that you're pre-compiled all the possible methods that might get dispatched to.

peace,

s

[Uwe Fechner]

I created the following issue to track the progress on this:
https://github.com/JuliaLang/julia/issues/8543

[Fredrik Bagge Carlson]

For those finding this page in search for a control systems toolbox:
The package ControlSystems.jl has seen extensive developement recently, and developement is still ongoing

https://github.com/JuliaControl/ControlSystems.jl

[Cedric St-Jean]

Do you have any book/website to recommend for getting started on control systems? My background is in reinforcement learning.

[Tony Kelman]

I highly recommend Astrom and Murray - http://www.cds.caltech.edu/~murray/amwiki/index.php/Main_Page

[Uwe Fechner]

Very nice!

Is the time coming for a JuliaControl organization?

I am thinking of wrapping the ACADO toolkit: http://acado.github.io/

Regards:

Uwe

[krisztian kosi]

I suggest to look RFPT based adaptive nonlinear controllers, it is a very easy method, don't need to much computing power to implement it. 

I started a github repo, for give example codes to my students.

https://github.com/krisztiankosi/Control

Regards: 

Krisztián