Then we’ve effectively recreated the two-language problem. It also directly contradicts the title “C codegen considered unnecessary: go directly to binary, do not pass C”
C codegen isn’t necessary but it is an option (and may be the best option for some users)
Absolutely. If I look at the projects at my place of work that run on embedded hardware, they have 100K+ LOC written in C already. And that’s on top of an already existing RTOS like zephyr or threadx. My current work flow consists of generating C code and passing that off to the dev team. That way everything is checked into version control, and easily maintainable and compilable because it just more C code.
I think calling that c code from Julia is an acceptable way to have a digital twining environment as there may be other reliability and safety concerns that Julia is not able to tackle right now.
I like the initiatives some people are taking to realize PID and other controllers written in Julia directly to hardware, especially for academic and prototyping settings.
Some of the systems I’d be interested in modeling are complicated systems of systems with not only a control loop, but also kalman filtering and state estimators, perhaps machine learning elements, and other arbitrary state machines, sensor fusion, yada yada yada. A concise way to tackle this in a Julia Environment would be golden.
Hi @Allan_Baker
and …
Only two yada, yadas but what you just said was what I did in Julia. This was just over three years ago now and I was only a one-man-band but the door was always open for the deep learning (DL) stuff. Actually, my biggest problem was getting to grips with multi-threading races.
I really like the way @ChrisRackauckas suggests the uncertainty can be handled by embedding DL into classical code using MTK.jl but I didn’t have the time.
State estimators can be made to reject bad data by using re-weighting techniques as well as smooth out Gaussian stuff. I am still somewhat biased against the use of machine learning for on-line, real-time use.
BTW: I ran the Julia-only code on a (I think it was) 48 virtual-core Concurrent Machines computer running a deterministic real-time OS, RedHawk Linux. Julia was perfect for this as the OS allowed one to choose which cores were 100% available and Julia made it a snap to run code specifically on those dedicated cores. Julia and an RTOS is a match made in heaven.
The dimension (i.e. order) of the MIMO system TF was way to big/unstable/interacting for PID although I did investigate using a diagonalising precompensator, which potentially would have exposed the TF matrix diagonal elements as suitable for individual PIDs. But, too complicated and long-winded to explain why I didn’t! 
That sounds pretty cool. For the applications I’m talking about they could be on severely limited SWAP hardware like DSPs or FPGA based socs. Many times without an OS and running bare metal in a deterministic fashion.
For completeness, there’s also GitHub - janneshb/SimpleSim.jl: A minimalist Julia package for modular dynamical systems simulation. Work in Progress :-) that potentially satisfies your requirements, unfortunately also in the group of packages that appear to be unmaintained
This might be relevant.
Dyad now has both a GUI and support for discrete-time (synchronous) modelling. I just gave a webinar demoing some of these capabilities
and a shorter form video with essentially the same material https://www.youtube.com/watch?v=ePi8pYe_pVU
There was also a talk by Tim and Kiran at this year’s juliacon that details some of the compiler stack that compiles the synchronous programs in a ModelingToolkit model
(starts at 2:41:09)
The last resource I’d point at is our synchronous programming docs Discrete-Time Modeling | Dyad and the standard library of discrete-time components DiscreteComponents | Dyad
Amazing stuff! Seems like a lot of progress has been made on the graphical interface as well, looks great.
Just a question, how is the support for uncertainty quantification now? I recently tried your package MonteCarloMeasurements.jl, which surprisingly ‘just works’ with most of the MTK stuff I tried (amazing!). But maybe you have other plans for that?
Seems like a lot of progress has been made on the graphical interface as well, looks great.
Thanks 
Just a question, how is the support for uncertainty quantification now? I recently tried your package MonteCarloMeasurements.jl, which surprisingly ‘just works’ with most of the MTK stuff I tried (amazing!). But maybe you have other plans for that?
I do have some tests in place to make sure MonteCarloMeasurements.jl works with MTK, like here
and with the ControlSystems packages, like here
Apart from that, we have first-class support for ensembles and parameter sweeps in Dyad. Dyad models and simulations end up as ModelingToolkit models so anything applicable to MTK models are usable also with Dyad models, such as the ongoing work in
The package for MPC components in Dyad that I’m working on further has some WIP support for different kinds of uncertainty representations, there are quite many to choose from out there 
Which version of Dyad is required to use these components? Does it work locally?
You need the latest version 3.3 and you additionally need to opt out of the Dyad system image to use the latest and greatest right now. Upcoming Dyad 3.4 will have it included in the dyad system image as well.
Yes, this is all running locally in your vscode