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 On Mon, Sep 15, 2014 at 2:26 PM, Tony Kelman <t...@kelman.net> wrote: > 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. > > > On Monday, September 15, 2014 3:13:32 AM UTC-7, Andrew Wagner wrote: >> >> 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. >> >
