I highly recommend Astrom and Murray - http://www.cds.caltech.edu/~murray/amwiki/index.php/Main_Page
On Wednesday, March 23, 2016 at 9:19:05 AM UTC-7, Cedric St-Jean wrote: > > Do you have any book/website to recommend for getting started on control > systems? My background is in reinforcement learning. > > On Wednesday, March 23, 2016 at 10:40:43 AM UTC-4, Fredrik Bagge Carlson > wrote: >> >> 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 >> >> >> On Wednesday, October 1, 2014 at 10:10:56 AM UTC+2, Uwe Fechner wrote: >>> >>> I created the following issue to track the progress on this: >>> https://github.com/JuliaLang/julia/issues/8543 >>> >>> On Tuesday, September 30, 2014 3:29:01 PM UTC+2, Spencer Russell wrote: >>>> >>>> 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 >>>> >>>> On Mon, Sep 29, 2014 at 4:25 PM, Stefan Karpinski <[email protected] >>>> > wrote: >>>> >>>>> On Mon, Sep 29, 2014 at 4:21 PM, Uwe Fechner <[email protected]> >>>>> 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. >>>>> >>>> >>>>
