A Quanser rotary pendulum, a Raspberry Pi, and a Julia-based control model: that's all it takes to go from a controller that works in simulation to one running on real hardware, with no manual translation step in between. In the video above, we generate C code directly from a Dyad model of the swing-up controller, ship it to the Raspberry Pi, compile it on the target, and watch the physical pendulum swing itself upright in real time.

From model to hardware in one click

The controller is built as a Dyad model — the same kind of model used earlier in this project for simulation, but pared down to just the parts that matter for deployment: a measurement input, a command output, and logging and diagnostics blocks. That's exactly what the real controller sees once it's running on hardware, reading a sensor value and producing a control signal on a fixed sampling clock.

Generating and deploying code from that model is handled through a Dyad analysis — a configuration with tunable parameters like LQR penalty weights, sampling interval, experiment duration, and a deploy host address (the Raspberry Pi's IP). With the analysis set to run, a single "run" command in VS Code generates C code, ships it to the Pi, compiles it there, and launches the program — all in one step. (Julia code generation is also available as an option, but C is what's shown here.) The result is immediate: the pendulum swings up on the physical hardware, while a live plotting tool streams the logged signals back to the desktop for monitoring.

Looking at the generated code afterward, it's organized cleanly — the controller's entry point lands in top.c — and the function and variable names, though verbose, trace back to the exact Julia expressions they came from. That traceability is what makes generated code trustworthy for deployment to targets that can't run Julia natively, even though (as noted in the video) the Raspberry Pi itself could have run Julia directly.

Beyond swing-up

The same generate-and-deploy workflow also powers two other experiments on this hardware: a system identification run that estimates the pendulum's geometric and mass properties, and a friction/back-EMF experiment that removes the pendulum and estimates motor friction from a velocity-tracking test. One quirk worth mentioning: the estimated Coulomb friction came out negative in that test — not because friction is negative, but because the hardware's own dead-band compensation slightly overcorrects, so the estimate actually captures friction and dead-band compensation combined.

Why this matters

A single Julia-based model can serve every stage of a control engineering workflow — modeling, parameter estimation, controller design, simulation, and now deployment — with no manual re-implementation step between "the controller that works in simulation" and "the controller running on real hardware." The same Dyad model that produced the swing-up behavior in simulation also produced the C code running on the Raspberry Pi.

For more on how Julia's compiler makes this kind of direct-to-hardware deployment possible — including trimming builds down to embedded-friendly binaries and cross-compiling for different target architectures — see JuliaHub's write-up on Julia's alternative to C-code generation.