Adaptive Edge-AI Controller

Thermal-Aware Closed-Loop Workload Control for Long-Running YOLO Inference on NVIDIA Jetson

The full source code, experiment data, visualizations, and implementation details are available in the, and the complete technical report can be read here:

[embed]GitHub - fatihaybsn/Adaptive-Edge-AI-Controller: Adaptive thermal-aware controller for NVIDIA… Adaptive thermal-aware controller for NVIDIA Jetson Orin NX. Eliminates thermal throttling in real-time AI inference by…github.com

Running a YOLO model on a Jetson device for a short demo is straightforward. Keeping it running for hours — reliably, without throttling, freezing, or shutting down — is a fundamentally different engineering problem.

Adaptive Edge-Inference Controller is a closed-loop thermal control system that monitors GPU temperature in real time, predicts near-future thermal pressure, and dynamically adjusts YOLO inference workload on NVIDIA Jetson devices — before sustained heat causes system degradation. The system was validated with a 130-minute continuous run on real Jetson hardware, producing 3,900 telemetry samples while autonomously managing thermal state across safe, warning, and critical regions — without a single emergency shutdown or human intervention.

[embed]

Full demonstration: Adaptive Edge-Inference Controller running a YOLO human-detection pipeline on Jetson hardware for over 2 hours, showing real-time thermal adaptation with on-screen HUD.

The Problem: Why Long-Running Edge AI Fails

Real-time object detection models such as YOLO continuously exercise GPU, CPU, memory, and image-processing resources. On compact edge devices like NVIDIA Jetson, this sustained computational load generates significant heat within a small form factor with limited cooling capacity and constrained power budgets.

A YOLO pipeline may start correctly and run at full speed — but after 15 to 60 minutes of continuous operation, heat accumulates and the system begins to degrade through a predictable cascade:

• Thermal throttling and unstable FPS — The OS triggers Dynamic Voltage and Frequency Scaling (DVFS), reducing clock speeds unpredictably and causing inference latency to fluctuate
• Latency accumulation — Video pipeline latency grows as the GPU struggles under sustained thermal pressure
• Dropped frames — Detection responsiveness decreases as frames are skipped or delayed
• System freezes — The device locks up entirely, requiring a physical manual restart
• Thermal shutdowns — The device shuts down to protect hardware, losing all operational state

This failure pattern is especially critical for unattended deployments where human intervention is costly, delayed, or impossible: security cameras monitoring a facility 24/7, traffic analytics nodes at intersections, drones performing autonomous survey flights, mobile robots in warehouses, and industrial monitoring sensors in remote locations.

This Problem Is Documented — Real Users Are Reporting It

These failures are not theoretical. Developer forums and open-source issue trackers consistently document these exact scenarios in production Jetson and edge AI deployments:

Additional field evidence: detectnet-camera crashes and 5W mode workarounds TensorFlow over-current throttling long-running Jetson Nano overheating jetson-inference high temperature / shutdown further confirm this is a widespread, recurring problem across different frameworks and Jetson generations.

NVIDIA’s own documentation acknowledges this reality: the Jetson BSP uses fan management and clock throttling for thermal cooling, and reducing clock frequency directly affects performance and user experience (Jetson Power and Thermal Management).

Why a Cooling Fan Alone Is Not Sufficient

A cooling fan is an important component of any thermal management strategy for Jetson devices, and this project does not minimize its value. However, relying solely on a fan — particularly a fixed-speed or manually controlled fan — has inherent limitations:

• Changing workload intensity: GPU load fluctuates depending on scene complexity, model size, and frame rate. A fan running at a constant speed cannot adapt to these variations.
• Ambient temperature: In outdoor deployments or enclosed installations, the ambient temperature can rise significantly, reducing the fan’s cooling effectiveness.
• Enclosure and airflow constraints: Many field deployments use sealed or semi-sealed enclosures for weather protection. These enclosures restrict airflow and can trap heat, regardless of fan speed.
• Sudden thermal spikes: Rapid increases in GPU utilization (e.g., when many objects appear in frame) can cause temperature spikes faster than fan-based cooling can compensate.
• Fan wear and failure: In long-running deployments, fans are mechanical components subject to wear, dust accumulation, and potential failure — introducing a single point of failure in the thermal management chain.

The Adaptive Edge-Inference Controller operates complementarily to the fan. Instead of replacing the fan, it adds a software-level control layer that manages the heat source itself — the inference workload — by reducing the computational demand before thermal limits are reached. This dual approach (hardware cooling + software workload management) provides a more robust thermal strategy than either mechanism alone.

The Solution: Application-Level Thermal Control

Adaptive Edge-Inference Controller addresses the thermal reliability gap by adding a closed-loop control layer above the YOLO inference pipeline. Instead of passively waiting for kernel-level thermal throttling to degrade performance unpredictably, the application proactively manages its own workload.

The controller operates through a continuous five-step cycle running in a background thread:

Operating Modes

The controller defines four thermal operating regions with distinct behaviors:

• Safe Mode: Below ~70 °C — Full-quality inference: imgsz=640, percentage=1.0
• Warning Mode: ~70 °C and above — Gradual workload reduction through fuzzy control
• Critical Mode: ~80 °C and above — Aggressive workload reduction through fuzzy control
• Emergency Mode: 85 °C hard limit — Force minimum workload: imgsz=320, percentage=0.25

System Architecture

High-level system architecture. The controller runs as a background thread alongside the YOLO inference loop, reading sensor data, computing control decisions, and publishing workload parameters that the inference loop applies on each frame.

The runtime data flow follows this path:

How the Controller Works

The closed-loop control mechanism. The controller continuously reads sensor data, predicts thermal trends, computes a fuzzy-logic workload decision, applies safety constraints, and publishes the result for the inference loop — forming a complete feedback loop.

FOPDT Thermal Prediction

The controller uses a First-Order Plus Dead-Time (FOPDT) inspired model to predict near-future GPU temperature based on the current temperature and its rate of change. The FOPDT model is a standard process-control technique used in industrial thermal systems.

The prediction accounts for:

• Time constant (τ): How quickly the thermal system responds to workload changes (default: 60 seconds, experimentally identified as 82–119 seconds depending on the actuator)
• Dead time (θ): The delay between a workload change and its thermal effect (experimentally identified as 0–5.2 seconds)
• Prediction horizon: How far ahead the controller looks (default: 30 seconds)
• Clamping: Prediction delta is clamped to ±10 °C to prevent over-reaction to noisy sensor readings

The control temperature — the value actually used for decision-making — is defined as max(current_temp, predicted_temp), ensuring the controller always reacts to the worse-case scenario between present measurement and predicted trend.

The FOPDT model parameters were identified offline from experimental step-response data using scipy.optimize.least_squares with robust fitting (soft L1 loss), achieving:

• FPS percentage step response: K = 3.96 °C/u, τ = 119.1 s, R² = 0.936
• Resolution step response: K = 2.50 °C/u, τ = 82.3 s, θ = 5.2 s, R² = 0.963

Fuzzy Logic Decision System

Instead of rigid threshold-based switching, the controller uses a Mamdani-type fuzzy inference system with two inputs and two outputs to produce smooth, graduated workload decisions:

Inputs:

• temp_error: The difference between current control temperature and target temperature (65 °C), mapped to linguistic variables: safe, warning, critical
• temp_delta: The rate of temperature change (°C/s), mapped to: falling, stable, rising

Outputs:

• imgsz_level: Resolution setting, mapped from fuzzy output to discrete values {320, 480, 640}
• fps_level: Frame-processing ratio, mapped from fuzzy output to discrete values {0.25, 0.50, 0.75, 1.00}

The fuzzy system uses 9 rules covering all input combinations. For example:

• If temperature is in warning range and rising, the controller reduces both resolution and frame rate
• If temperature is in warning range but falling, the controller maintains resolution and only moderately reduces frame rate
• If temperature is in safe range, all levers remain at full capacity regardless of trend

A minimum action interval (10 seconds) prevents rapid oscillation between states, providing stable control behavior.

Safety Guard

The SafetyGuard module adds a defense-in-depth layer on top of fuzzy-logic decisions:

• Emergency override: If measured GPU temperature reaches the hard critical threshold (85 °C), the controller immediately forces minimum workload (imgsz=320, percentage=0.25) regardless of the fuzzy output
• Recovery with hysteresis: After emergency mode, the controller does not immediately restore full workload. It waits until temperature drops below a recovery threshold (80 °C) and remains there for a configurable hold period (30 seconds) before exiting emergency mode — preventing thermal oscillation
• Mode determination: Every control cycle, the SafetyGuard independently determines the current operating mode (safe / warning / critical / emergency) based on the control temperature, providing a clear operational status for logging and monitoring

Technology Stack

Technology stack organized by functional layer: hardware platform, sensor interface, control algorithms, inference pipeline, and user interface.

The system integrates technologies across multiple layers:

• Hardware Platform: NVIDIA Jetson, CUDA, GStreamer — GPU computing, camera capture pipeline
• Sensor Interface: Jetson sysfs (/sys/class/thermal/, /sys/devices/gpu.0/), psutil — Real-time GPU temperature, GPU load, CPU load
• Inference Engine: Ultralytics YOLO, PyTorch, OpenCV — Object detection with dynamically adjusted resolution
• Control Logic: scikit-fuzzy, NumPy, custom FOPDT implementation — Thermal prediction, fuzzy decision-making, safety enforcement
• Telemetry: Custom ring buffer, CSV logger, threading — Data collection, logging, and concurrent operation
• Configuration: PyYAML — Externalized, validated configuration management

Experimental Validation

The controller’s design is backed by three structured experiments conducted on real Jetson hardware with live camera input. Each experiment serves a specific purpose: two isolated step-response experiments characterize the individual control levers, and one closed-loop experiment demonstrates the complete system operating autonomously for over two hours. All telemetry data is included in the repository as CSV files for full reproducibility.

Experiment 1: FPS Percentage Step Response

Purpose: Isolate the thermal effect of changing the frame-processing ratio (percentage) while keeping resolution fixed at 640.

Method: The system ran YOLO inference at percentage=1.0 (every frame processed) until thermal equilibrium, then switched to percentage=0.25 (1 in 4 frames processed). Temperature, GPU load, CPU load, and FPS were logged at 0.5-second intervals.

GPU temperature over time during the FPS percentage step experiment. Red region: percentage=1.0; blue region: percentage=0.25. The temperature drop after reducing the frame-processing ratio is clearly visible, confirming that frame-percentage reduction provides significant thermal relief.

GPU load over time. Reducing the processed-frame ratio from 1.0 to 0.25 drops GPU utilization from ~73% to ~26% — the single strongest workload reduction available to the controller.

Key finding: Frame-percentage reduction is the strongest thermal actuator in the system. GPU load drops by 46.5 percentage points and temperature decreases by ~1.85 °C. However, it carries an explicit throughput cost (FPS drops from 24 to 8.3), which is why the controller reserves this lever primarily for critical thermal situations where stability must take priority over detection frequency.

Experiment 2: Resolution Scaling Step Response

Purpose: Isolate the thermal effect of changing the YOLO input resolution (imgsz) while keeping the frame-processing ratio fixed at 1.0.

Method: The system ran YOLO inference at imgsz=640 until thermal equilibrium, then switched to imgsz=320. Telemetry was logged at 0.5-second intervals.

GPU temperature over time during the resolution scaling step experiment. Red region: resolution=640; blue region: resolution=320. The thermal reduction is milder than the FPS percentage experiment, but resolution scaling uniquely preserves or slightly improves throughput.

GPU load over time. Resolution reduction lowers peak GPU utilization modestly, with a more consistent load pattern compared to the FPS percentage experiment.

Key finding: Resolution scaling provides a milder but cost-efficient thermal reduction. Unlike frame-percentage limiting, reducing imgsz actually increases FPS slightly (from 23.75 to 25.87) because per-frame compute cost decreases. This makes resolution scaling the controller's preferred fine-tuning lever: it provides thermal relief without sacrificing throughput — an ideal first-stage response before stronger measures are needed.

Experiment 3: Closed-Loop Autonomous Demo

Purpose: Validate the complete controller operating autonomously on real Jetson hardware with a live YOLO human-detection pipeline.

Method: The full system — camera input, YOLO inference, adaptive controller, telemetry logging, and live overlay — ran continuously for ~130 minutes. The controller managed all thermal transitions autonomously, with no manual intervention at any point. Telemetry was logged every 2 seconds.

Key findings:

• The controller prevented emergency shutdown despite running for over 2 hours with sustained YOLO inference — where uncontrolled systems have been reported to fail within 15–60 minutes.
• The system successfully traversed all active thermal regions (safe → warning → critical), demonstrating genuine adaptive behavior rather than a short startup snapshot.
• After reaching the critical region, the controller’s aggressive workload reduction caused a measurable cooling rate of ~0.61 °C/min, actively pulling the system back from the emergency boundary.
• The system operated in warning mode for 71.4% of the run, confirming that proactive thermal management can sustain useful operation in a thermally stressed but controlled state.
• Every control decision, sensor reading, and mode transition is recorded in the CSV for full transparency and reproducibility.

FOPDT Parameter Identification

The FOPDT model parameters used by the runtime predictor were identified offline from the step-response experiments using scipy.optimize.least_squares with robust fitting:

Real-World Applications

Adaptive Edge-Inference Controller is designed for scenarios where an AI-powered edge device must remain operational for extended periods under constrained cooling, without relying on human intervention to manage thermal state.

Security Cameras and Smart Surveillance

Continuous human, vehicle, or license-plate detection at building perimeters, parking lots, or transit stations. These systems are expected to run 24/7 without interruption. A thermal shutdown at 3 AM when no operator is present means a gap in coverage — exactly when monitoring is most critical. The controller ensures the inference pipeline remains active and thermally stable throughout the deployment, even in elevated ambient temperatures or enclosed camera housings.

Robotic Systems

Mobile robots in warehouses, logistics centers, and manufacturing floors run continuous perception pipelines for navigation, obstacle avoidance, and task execution. A thermal freeze during a robot’s operation can halt an entire production line or create safety hazards. The controller provides autonomous thermal management that keeps the vision system operational without requiring the robot to pause for cooldown cycles.

Drones and Autonomous Platforms

Autonomous UAVs performing survey, inspection, or search-and-rescue missions cannot land to restart a frozen inference pipeline. The controller maintains thermal stability during flight, adapting inference quality to balance computational load against the limited cooling capacity of an airborne platform with restricted airflow.

Outdoor and Field-Deployed Edge AI

Traffic analytics nodes at intersections, environmental monitoring sensors, agricultural imaging systems, and remote infrastructure inspection devices — all face high ambient temperatures, solar heating, sealed enclosures, and minimal access for maintenance. The controller provides a software-based thermal safety net that operates regardless of external cooling conditions.

Industrial Safety Monitoring

Factory floor monitoring for safety compliance (PPE detection, restricted area monitoring) requires continuous, reliable operation. The cost of a missed detection due to system freeze or shutdown can be measured in workplace injuries. The controller ensures the monitoring system maintains its detection capability even under sustained thermal stress.

About the Author

Fatih Aybasan — Computer Engineering graduate.

This project was developed as a graduation thesis in Computer Engineering. It reflects a complete engineering workflow: identifying a real-world problem through user-reported failures, researching the domain, designing a multi-layered control system, implementing it as a modular software package, validating it with structured experiments on real hardware, and documenting the process with quantitative results.

The project demonstrates skills across multiple engineering disciplines:

Community Reports and Field Evidence

• F1 NVIDIA Forum YOLOv8 on Jetson Nano — temperature rises to ~70 °C after ~10 min
• F2 NVIDIA Forum Jetson Nano shuts down after 15–20 min of RTSP object detection
• F3 Ultralytics Community System freeze under multi-camera YOLO inferencing (1–2 hours)
• F4 NVIDIA Forum DeepStream nvinfer delay and latency accumulation
• F5 GitHub Issue jetson-inference high temperature / shutdown
• F6 NVIDIA Forum — Long-running Jetson Nano overheating
• F7 NVIDIA Forum — Detectnet-camera crashes; 5W mode workaround
• F8 NVIDIA Forum — TensorFlow over-current throttling
• F9 NVIDIA Forum — Jetson Nano freezes during YOLO + OpenCV detection
• F10 NVIDIA Forum — DeepStream thermal throttling at 68–70 °C on Jetson Orin Nano Super

NVIDIA Official Documentation

• W1 Jetson Orin Nano Developer Kit User Guide — Positions Jetson for AI robots, drones, and smart cameras
• W2 NVIDIA Autonomous Machines / Jetson Platform — Jetson for robotics, drones, video analytics, autonomous machines
• W4 tegrastats Utility — Memory and processor statistics reporting on Jetson
• W5 Jetson Power and Thermal Management — Fan management, clock throttling, and thermal cooling documentation