# \[ANN\] ModelPredictiveControl.jl

**URL:** <https://discourse.julialang.org/t/ann-modelpredictivecontrol-jl/100147>\
**Category:** Package Announcements\
**Tags:** control, jump, controlsystems, nmpc\
**Created:** [June 10, 2023, 6:10pm UTC](https://discourse.julialang.org/t/ann-modelpredictivecontrol-jl/100147 "2023-06-10T18:10:43Z")\
**Posts on this page:** 1\
**Showing post:** 65

<div class="post-metadata">

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\
**Post date:** [January 26, 2026, 9:59pm UTC](https://discourse.julialang.org/t/ann-modelpredictivecontrol-jl/100147/65 "2026-01-26T21:59:30Z")

</div>

> [@franckgaga](#):
>
> My main priority is to provide a user interface that is easy to use, meaning it is more restrictive in what can be accomplished in terms of objectives and constraints.

The expressiveness of the linear MPC framework is already very limited and the current syntax limits it further. As long as my expression is mathematically valid within the linear MPC framework I think I should be able to define it.

> [@franckgaga](#):
>
> Currently, if you have complex constraint or objective structures, there is always the `NonLinMPC` object that allows custom nonlinear constraints (`gc` and `nc` kwargs) and objectives (`Ewt` and `JE` kwargs). But it will obviously not be the most computationally efficient algorithm if these structures are truly linear and quadratic. And code generation is not supported for `NonLinMPC`.

Unfortunately for commercial embedded systems every kilobyte matters so C codegen is a must. I think it’s already a modern miracle we can do MPC with a \<200 kB solver (thanks Boyd!).

> [@franckgaga](#):
>
> This feature is not supported by code generation (i.e. there is no C code equivalent of calling `setconstraint!` online).

Yeah this is very tricky but I think a requirement for practical applications. Between mild and cold weather with high supply temperatures maximum output power can drop from 5 to 3 kW.

Maybe you know this already, but cvxpygen will generate a function `cpg_update_<param>(idx, val)` to update each parameter in your problem. For that to work you would first need to know where the parameters are and there are some rules as to how parameters can enter the problem (DPP compliance).

Now for LinearMPC.jl, you could say everything that is a constant in my problem is a parameter and thus could be updated and included in the codegen. Having both an expressive API and efficient codegen is even more tricky and you’re halveway to a DSL already.

Really thinking out loud here so feel free to shoot this down, but why not use JuMP as the main problem creation interface instead? There’s a DSL, and there is `MOI.Parameter`.

ps. It goes without saying but I appreciate your work on these packages.

---

_[View the full topic](https://discourse.julialang.org/t/ann-modelpredictivecontrol-jl/100147)._