64  Processes & Systems: Labs and Review

In 60 Seconds

PID controller labs teach hands-on tuning: start with P-only (fast response, steady-state error), add I (eliminates offset but risks overshoot), add D (dampens oscillation but amplifies noise). For IoT temperature control, typical gains are Kp=2-10, Ki=0.1-1.0, Kd=0.5-5.0 with sample periods of 1-10 seconds. Always simulate before deploying to hardware – a poorly tuned PID can cause dangerous oscillation in physical actuators.

64.1 Learning Objectives

By the end of this section, you will be able to:

  • Construct Python PID simulations to experiment with control systems
  • Differentiate how each P, I, and D parameter affects system response
  • Evaluate control performance by measuring overshoot, settling time, and steady-state error
  • Design temperature, motor, and position control loops for smart IoT devices
  • Diagnose controller weaknesses under external disturbance conditions
  • Verify control designs through simulation before hardware deployment

Process control in IoT is about automatically adjusting systems to maintain desired conditions. Think of cruise control in a car: it continuously measures your speed, compares it to your target, and adjusts the throttle to keep you on track. IoT systems use similar feedback loops to control everything from room temperature to industrial manufacturing processes.

64.2 Chapter Overview

This comprehensive lab and review section has been organized into three focused chapters for more effective learning:

Chapter Structure

This content covers practical labs, understanding checks, and decision guidance for IoT control systems. Each sub-chapter focuses on a specific learning goal:

  1. Hands-on simulation and implementation
  2. Scenario-based understanding checks
  3. Decision frameworks and practical guidance

64.3 Sub-Chapters

64.4 Prerequisites

Required Chapters:

Technical Background:

  • Control loop concepts
  • PID controllers
  • System response characteristics

Control System Elements:

Element Function Example
Sensor Measurement Temperature probe
Controller Decision PID algorithm
Actuator Action Valve, motor
Process System HVAC, tank

Lab Requirements:

  • Arduino/ESP32 board
  • Temperature sensor
  • LED or motor for actuation

Total Estimated Time: 2.75 hours (all sub-chapters)

64.5 Learning Path

Learning path diagram for Processes and Systems Labs showing three sequential sub-chapters: PID Control Simulation Lab (1.5 hours, intermediate), Control Systems Understanding Checks (45 minutes, advanced), and Control Systems Decision Guidance (30 minutes, intermediate), with arrows indicating recommended progression.

Recommended Approach

For hands-on learners: Start with the PID Simulation Lab to build intuition through experimentation.

For conceptual learners: Begin with Understanding Checks to see how concepts apply to real scenarios.

For decision-makers: Jump to Decision Guidance for practical frameworks.

64.6 Quick Reference

64.6.1 Key Concepts Summary

Concept Definition IoT Application
Process Algorithm transforming inputs to outputs PID control logic
System Physical + software components ESP32 + sensor + actuator
Open-Loop No feedback from output Timer-based irrigation
Closed-Loop Feedback enables self-correction Temperature control
P-term Proportional to current error Fast response
I-term Integral of accumulated error Zero steady-state error
D-term Derivative of error rate Overshoot reduction

64.6.2 Decision Quick-Reference

Use Open-Loop when:

  • Environment is predictable
  • Accuracy is not critical (±20%)
  • Cost < $50/unit
  • No safety implications

Use Closed-Loop when:

  • Disturbances are expected
  • Precision required (±2%)
  • Life-safety critical
  • Value > $500 per failure

PID Term Selection:

  • P-only: LED dimming, non-critical positioning
  • PI: HVAC, industrial process control (most common)
  • PID: Ovens, motors, precision robotics
  • Skip D: High-noise environments

64.7 Cross-Hub Connections

Learning Resources

Interactive Tools:

Assessment:

Exploration:

64.8 Key Takeaways

  • PID tuning is progressive: Start with P-only for fast response, add I to eliminate steady-state error, add D to reduce overshoot
  • Always simulate before deploying: A poorly tuned PID on real hardware can cause dangerous actuator oscillation
  • Typical IoT temperature PID values: Kp=2-10, Ki=0.1-1.0, Kd=0.5-5.0, with 1-10 second sample periods
  • PI control covers 80% of cases: Most IoT applications do not need the derivative term
  • Use the decision matrices provided to systematically choose between open-loop, closed-loop, and PID configurations

Practice makes perfect – even for robots and smart devices!

64.8.1 The Sensor Squad Adventure: The Practice Track

The Sensor Squad was preparing for the Big Robot Race. Every robot had to drive around a track and stop EXACTLY at the finish line – not before it, not past it!

“Let’s practice!” said Max the Microcontroller. “I’ll start with just watching how far I am from the finish line.”

Round 1 (P-only): Max drove fast when far from the line and slowed down as he got closer. But he always stopped about 10 centimeters before the line! “I can’t quite reach it,” Max said sadly.

Round 2 (Adding I): Bella the Battery said, “I’ll keep count of how long you’ve been short of the line!” With Bella’s help, Max kept inching forward until he was EXACTLY at the finish line. But… he rolled 5 centimeters past it before backing up! “Oops – overshoot!” laughed Max.

Round 3 (Adding D): Lila the LED watched how fast Max was approaching. “You’re coming in too fast! Slow down MORE as you get close!” With all three helpers (P, I, and D), Max stopped PERFECTLY on the line – no overshoot, no undershoot!

Sammy the Sensor checked the results:

Round Method Where Max Stopped Problem
1 P only 10 cm SHORT Could not reach the exact line
2 P + I 5 cm PAST (then corrected) Went too far before stopping
3 P + I + D EXACTLY on the line Perfect!

“That’s why we practice and tune!” cheered the Squad. “Each helper makes the system a little better!”

64.8.2 Try This at Home!

The Paper Airplane Landing Pad:

  1. Make a paper airplane and mark a target landing spot on the floor
  2. Throw it three times, adjusting each time based on where it lands
  3. First throw = your “P” (just try to aim). Second throw = your “I” (remember if you’ve been short or long). Third throw = your “D” (adjust for how fast the wind is pushing it)
  4. Did your throws get more accurate? That is PID tuning in action!

Scenario: An ESP32-based smart oven controller was deployed to 50 beta testers. After 2 weeks, complaints arose: “temperature overshoots by 15°C then oscillates for 10 minutes before stabilizing.”

System Details:

  • Target: 180°C for baking
  • Heater: 2000W element
  • Sensor: K-type thermocouple, ±2°C accuracy, 1-second updates
  • Initial PID gains: Kp=10.0, Ki=2.0, Kd=0.5 (chosen arbitrarily)

Observed Behavior (Data Log):

T=0s:   Setpoint=180°C, Actual=25°C, Error=155°C, Output=100% (maxed)
T=60s:  Actual=85°C, Error=95°C, Output=100%
T=120s: Actual=145°C, Error=35°C, Output=100%
T=150s: Actual=175°C, Error=5°C, Output=85%
T=165s: Actual=185°C, Error=-5°C, Output=0% (heater off)
T=180s: Actual=195°C, Error=-15°C ← OVERSHOOT!
T=210s: Actual=188°C, Error=-8°C
T=240s: Actual=176°C, Error=+4°C, Output=65%
T=270s: Actual=182°C, Error=-2°C, Output=15%
... oscillates ±5°C for 8 more minutes

Root Cause Analysis:

  1. Excessive P-term (Kp=10.0): At Error=35°C (T=120s), P-output = 10.0 × 35 = 350 → clamped to 100%. Heater stays at full power too long, causing overshoot.

  2. Excessive I-term (Ki=2.0): During 150-second ramp-up, integral accumulates: ∫error ≈ 155+145+135+…+5 ≈ 12,000°C·seconds. I-output = 2.0 × 12,000 = 24,000 → severe windup, keeps heater on past setpoint.

  3. Insufficient D-term (Kd=0.5): As temperature rises rapidly (20°C/min approach rate), D-term = 0.5 × (-20/60) = -0.17 → negligible braking.

Tuning Process:

Step 1: Reduce Kp (Eliminate Primary Overshoot) - Test Kp=2.0, Ki=0, Kd=0 - Result: Reaches 178°C, settles with +2°C steady-state error (acceptable as first step) - Overshoot eliminated!

Step 2: Add Modest I (Eliminate Steady-State Error) - Test Kp=2.0, Ki=0.1, Kd=0 - Result: Reaches 180°C, minor overshoot to 182°C - Settling time: 6 minutes (improvement!)

Step 3: Add D (Dampen Remaining Overshoot) - Test Kp=2.0, Ki=0.1, Kd=3.0 - Result: Reaches 180°C, overshoot only 0.5°C, settling time 4.5 minutes - Final Gains: Kp=2.0, Ki=0.1, Kd=3.0

Derivative term provides predictive braking: \(D = K_d \frac{de}{dt}\). Worked example: When temperature rises at 20°C/min approaching setpoint, error decreases at \(\frac{de}{dt} = -20°C/60s = -0.333°C/s\). With \(K_d = 3.0\), derivative output is \(D = 3.0 \times (-0.333) = -1.0\%\) (negative = braking). This anticipatory reduction in heater power cuts overshoot from 15°C down to 0.5°C (97% improvement).

Field Test Results (50 Units, 2 Weeks):

Metric Before After Improvement
Overshoot 15°C (8.3%) 0.5°C (0.3%) 97% reduction
Settling time 18 min 4.5 min 75% faster
User complaints 38/50 (76%) 2/50 (4%) 95% satisfaction increase
Burn events 12 (overheating) 0 100% eliminated

Key Lesson: Arbitrary PID gains fail in production. Systematic tuning (start with P-only, add I, add D) combined with real-world testing prevents field failures.

Factor Prioritize Simulation Prioritize Hardware Hybrid Approach
Cost of Hardware Failure Low (<$100 per unit) High (>$1,000 or safety-critical) Medium ($100-1,000)
System Linearity Highly linear (easy to model) Nonlinear, hysteresis, complex Partially linear
Development Timeline Weeks available for iteration Days only (urgent deployment) Moderate timeline
Environmental Variability Lab-controlled conditions Wide variation (field deployment) Some variation

Decision Rule: Simulate first to find ballpark gains, then field-test with 10-20% of fleet before full deployment. Never skip hardware validation for production systems.

Common Mistake: Not Testing PID Under Disturbances

The Mistake: Engineers tune PID in ideal conditions (constant ambient temperature, steady power, no load changes) then deploy to real-world where disturbances are frequent.

Real Example: A smart aquarium heater was tuned to maintain 25°C in a lab with 22°C ambient, no water changes, stable 240V power. Deployed to customer homes: - Customer A performs 50% water change (15L cold water added) → temperature drops to 18°C, takes 45 min to recover - Customer B’s home has voltage sags during AC compressor start (210V for 2 seconds) → heater output drops 18% mid-heating cycle - Customer C places tank near window (sun exposure raises water temp to 27°C naturally) → heater fights to cool (can’t)

The Fix: Test PID under disturbances during tuning: - Simulate water changes (add ice cubes = cold water) - Test voltage variations (adjustable power supply 200-250V) - Test ambient temperature swings (heat gun or fan aimed at tank) - Measure recovery time and adjust I-term to handle disturbances within acceptable time

Rule: If disturbance recovery takes >3× the normal settling time, increase Ki by 50% and re-test.

64.9 What’s Next?

Start with the first sub-chapter:

Begin PID Simulation Lab →

Or navigate directly to: - Understanding Checks - Decision Guidance

After completing all sub-chapters, continue to: - Multi Hop Ad Hoc Networks

Previous Up Next
Processes and Systems Reference Architectures PID Simulation Lab

Common Pitfalls

Starting the lab without writing down what you expect to happen when you change each PID gain. Without a prediction, you cannot distinguish expected from unexpected behavior, and unexpected results become mysterious rather than instructive.

Validating PID performance at the nominal setpoint without testing edge cases (extreme setpoints, large step changes, load disturbances, sensor noise injection). Control systems often behave well in normal conditions but fail at boundaries.

Running only one tuning method (e.g., Ziegler-Nichols) without comparing to other approaches (Cohen-Coon, Lambda tuning, manual tuning). Comparison quantifies the trade-offs between methods and reveals which method best suits the specific process.

Claiming a PID is “well-tuned” because the response curve looks smooth without calculating quantitative metrics (settling time, overshoot percentage, steady-state error, ITAE). Define success criteria numerically before tuning, then verify against them.