You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A **playground** for experimenting with **PID**and **machine-learning-based controllers**.
9
+
A **playground** for experimenting with **PID**, **model‑predictive**, and **machine‑learning–based controllers**.
10
10
DeepPID provides both **traditional** and **neural adaptive controllers** in a single, consistent framework, complete with a live **Tkinter + Matplotlib GUI** for interactive benchmarking.
11
11
12
-
Through extensive simulation and real-time tests on **nonlinear**, **coupled**, and **time-varying plants**, it is demonstrated that the **ML-based adaptive models** (*GRU*, *MLP*, and *Transformer* variants) consistently **outperform conventional PID and Cascade-PID controllers** in both transient and steady-state performance.
12
+
Through extensive simulation and real-time tests on **nonlinear**, **coupled**, and **time‑varying plants**, it is shown that the **ML‑based adaptive models** (*GRU*, *MLP*, *Transformer*) and the **Hybrid MPC** consistently **outperform conventional PID and Cascade‑PID controllers** in difficult regimes while preserving safety.
13
13
14
14
The adaptive models achieve:
15
15
- ⚡ **Faster convergence** with minimal overshoot
16
-
- 🎯 **Near-zero steady-state error** across diverse process conditions
17
-
- 🧩 **Robustness** to parameter drift and actuator limits without manual re-tuning
16
+
- 🎯 **Near‑zero steady‑state error** across diverse process conditions
17
+
- 🧩 **Robustness** to parameter drift and actuator limits without manual re‑tuning
18
18
19
-
These results confirm that **data-driven adaptation—when combined with physical constraints—generalizes PID control** beyond fixed-gain heuristics while maintaining interpretability and stability.
19
+
These results confirm that **data‑driven adaptation—combined with physical constraints—generalizes PID control** beyond fixed‑gain heuristics while maintaining interpretability and stability.
20
20
21
21
</div>
22
22
<divstyle="margin-left: 20px; flex-shrink: 0;">
@@ -27,37 +27,56 @@ These results confirm that **data-driven adaptation—when combined with physica
A gated recurrent unit (GRU) network that directly predicts actuator speeds based on recent state history.
33
-
It embeds **PID-like control objectives**—composition matching, total flow regulation, smoothness, and bounded actuation—into its online loss function.
34
-
While not using explicit PID equations, it behaves as a **hybrid adaptive controller**, combining physical constraints with data-driven prediction.
35
-
This approach consistently **outperforms fixed-gain PID** under nonlinear, coupled, or drifting plant conditions, achieving **near-zero steady-state error** and **smoother transients**.
32
+
| Approach | Best For | Strengths | Trade-offs | What it Needs |
33
+
|---|---|---|---|---|
34
+
|**PID / Cascade PID**| Well-behaved, weakly coupled plants with modest drift | Simple, interpretable, tiny footprint, fast response | Retuning under drift/nonlinearity, cross-coupling fights, limited look‑ahead | A rough time constant + sensible bounds; optional feed‑forward |
35
+
|**Deep Learning (MLP / GRU / Transformer)**| Nonlinear, coupled, time‑varying plants; unknown physics; multi‑objective shaping | Learns mappings PID can’t; adapts online; smooth under constraints; minimal modeling | Needs careful safety layer; online training budget; behavior depends on loss design | Physical bounds/slew; losses for composition/total/smoothness; optional PID reference |
36
+
|**Model Predictive Control (Hybrid MPC)**| Constraint‑heavy problems needing short look‑ahead; competing objectives | Plans over horizon; handles constraints explicitly; blends physics + learned residuals | Heavier compute; relies on model quality; horizon/weights tuning | Discrete plant update (α / k), bounds, small horizon, good normalization |
37
+
38
+
**When to pick what**
39
+
- Start with **PID / Cascade PID** for near‑first‑order dynamics, mild couplings, or when you need a **tiny, explainable** controller.
40
+
- Choose **MLP / GRU / Transformer** for **persistent nonlinearity/coupling** or frequent operating‑point changes—especially if constant re‑tuning is painful.
41
+
- Use **Hybrid MPC** when you need **explicit constraint handling** and **short‑horizon look‑ahead** (e.g., avoiding actuator banging while meeting a tight total/spec).
42
+
43
+
> **Stability slider**: System inconsistencies and model mismatch can be **simulated** in the GUI via the **Stability** slider. Setting it **below 100%** injects drift/noise to benchmark robustness under uncertain conditions.
A gated recurrent unit (GRU) network that directly predicts actuator speeds from recent history. It embeds **PID‑like control objectives**—composition matching, total flow regulation, smoothness, and bounded actuation—into its online loss. It behaves as a **hybrid adaptive controller**, combining physical constraints with data‑driven prediction. Achieves **near‑zero steady‑state error** and **smoother transients** under nonlinear, coupled, or drifting plants.
40
51
41
-
A feed-forward multilayer perceptron that maps system state directly to actuator commands.
42
-
It incorporates a **physics-aware loss**, penalizing composition and total flow errors, actuator smoothness, and saturation proximity.
43
-
This model is **lightweight yet powerful**, excelling in steady-state precision and smooth transitions, ideal for slower or more stable plants.
A feed‑forward multilayer perceptron mapping the state to actuator commands. Uses a **physics‑aware loss** (composition, total, smoothness, and saturation barriers). **Lightweight yet strong** for steady‑state precision and smooth transitions—great baseline for slower or more stable plants.
54
+
55
+
### HybridMPCController — Predictive Optimizer with Learned Residuals
56
+
A **short‑horizon optimizer** that rolls out a simple plant model while a **learned residual network** patches model mismatch. It enforces bounds/slew on the applied action and balances composition/total/smoothness with horizon costs. High **robustness + interpretability**, outperforming fixed‑gain and static MPC baselines in constraint‑heavy tasks.
44
57
45
58
---
46
59
47
-
### HybridMPCController — Gradient-Based Predictive Optimizer with Learned Residuals
60
+
## Other controllers in the zoo
61
+
62
+
-**PIDController** — IMC‑style single‑loop PID with derivative on measurement, setpoint‑weighting, conditional integrator, anti‑windup, and **online τ (alpha) refinement**.
63
+
-**CascadePIDController** — Inner IMC‑tuned PID per channel plus **outer PI loops** for total and composition (zero‑sum trim).
64
+
-**TransformerCtrl** — Causal Transformer that consumes a recent feature window; trains online with the same physics‑aware objective.
65
+
-**PINNCtrl** — MLP variant that adds **physics barriers** (positivity, soft limit barrier) to increase consistency.
66
+
-**RLSafetyCtrl** — Actor network wrapped by the same **slew + clamp safety layer**; uses a supervised objective in the demo (swap for PPO/SAC in a full RL setup).
67
+
-**PIDResidualNN** — Classic PID with a small NN that proposes **delta speeds**; residual is rate‑limited and tightly clamped.
68
+
-**AdaptiveHierCtrl** — Cascade PID with a **tiny NN tuner** that adjusts inner‑loop gains in **log‑space** relative to baselines (safe, slow drift).
48
69
49
-
A **short-horizon optimizer** that blends classical MPC with a **learned residual dynamics model**.
50
-
It predicts future trajectories using a simplified plant model and refines them using a small neural correction network.
51
-
The result is a **model-predictive controller that adapts online**—providing high robustness and interpretability while outperforming both PID and static MPC approaches.
70
+
> All controllers output **speeds** and are passed through the **same** slew limiter + clamps for apples‑to‑apples comparisons. Neural models train **online** with physics‑aware losses; MPC plans a short sequence but applies only the **first safe action** each tick.
52
71
53
72
---
54
73
55
74
The GUI (`examples/test.py`) lets you:
56
-
- Choose different **plant problems** (tank, flow, quadcopter-like, etc.)
57
-
- Set the stability / random noise in the system.
58
-
- Switch between **controllers** (PID, CascadePID, MLP, GRU, Transformer, etc.)
> Add your own problems in `deeppid/envs/problems.py` and register them in `AVAILABLE_PROBLEMS`.
124
+
125
+
---
76
126
77
127
## Install (editable)
78
128
@@ -99,7 +149,7 @@ This launches the controller shoot‑out app. Choose any plant from the dropdown
99
149
```text
100
150
deeppid/
101
151
controllers/
102
-
controllers.py # PID, CascadePID, MLP, GRU, Transformer, etc.
152
+
controllers.py # PID, CascadePID, MLP, GRU, Transformer, MPC, etc.
103
153
utils/
104
154
utils.py # Utility functions
105
155
envs/
@@ -111,27 +161,17 @@ tests/ # (optional) put your pytest tests here
111
161
112
162
## How the GRU controller works (and why it’s different from PID)
113
163
114
-
**Conventional PID** computes the next actuation using fixed (or slowly tuned) gains `Kp, Ki, Kd`
115
-
around an interpretable structure with anti‑windup and filters. It’s great when the plant can be
116
-
reasonably approximated by first/second‑order dynamics and the operating point doesn’t move too much.
164
+
**Conventional PID** uses fixed/slowly tuned gains `Kp, Ki, Kd` around an interpretable structure with anti‑windup and filters—great when the plant is near first/second order and the operating point doesn’t move much.
117
165
118
166
**GRU controller (adaptive & live)** takes a different tack:
119
167
120
168
-**State** each tick: `[target ratio, total set‑point, recent measured flows, previous speeds]`
121
-
-**Sequence model**: a GRU processes the recent context to estimate the next speeds in one shot
169
+
-**Sequence model**: a GRU processes the recent context to estimate next speeds in one shot
122
170
-**Hard safety layer**: speeds are **slew‑limited** and **clamped** to `[min, max]`
123
-
-**Online objective** (optimized every few steps):
124
-
- match **composition** (fractions) to target
125
-
- match **total** output to the requested value
126
-
- keep **smooth** changes (actuator wellness)
127
-
- stay inside bounds with a **soft barrier**
128
-
- optionally track a reference/baseline (e.g., PID suggestion)
129
-
-**Why it helps**: when the plant is nonlinear, coupled, or operating conditions drift, the GRU
130
-
can “learn” mappings PID would need re‑tuning for. You still keep the same safety rails as PID.
131
-
132
-
You can inspect all loss terms and constraints in `controllers.py` (classes `GRUController`, `MLPController`).
133
-
Everything is implemented to be **stable‑by‑construction**: we never bypass slew/clamp and we bias to
134
-
baseline allocations when signals are missing or become non‑finite.
171
+
-**Online objective** (optimized every few steps): composition, total, smoothness, bound barrier, optional reference
172
+
-**Why it helps**: with nonlinear, coupled, or drifting plants, the GRU learns mappings PID would need re‑tuning for—keeping the **same safety rails**.
173
+
174
+
You can inspect all loss terms and constraints in `controllers.py` (`GRUController`, `MLPController`). Everything is implemented to be **stable‑by‑construction**: we never bypass slew/clamp and we bias to baseline allocations when signals are missing or non‑finite.
0 commit comments