Scheduling Analysis of UAV Flight Control Workloads using Raspberry Pi 5 Using PREEMPT_RT Linux

This paper demonstrates that while the standard Linux kernel is unsuitable for high-frequency UAV flight control on a Raspberry Pi 5 due to excessive latency, the PREEMPT_RT kernel significantly reduces worst-case jitter by nearly 88%, though residual timing variance remains primarily driven by hardware memory contention.

The Gist

The Big Picture: Can a Smartphone Brain Fly a Drone?

Imagine you are building a drone. Traditionally, you needed two brains:

1. The Pilot: A tiny, super-fast, simple computer (like a microcontroller) that does only one thing: keeps the drone from crashing. It reacts in microseconds.
2. The Navigator: A powerful computer (like a Raspberry Pi or Jetson) that does the "cool stuff": recognizing faces, planning complex routes, and swarming with other drones.

The problem is that having two brains adds weight, wires, and complexity. The dream is to put both jobs on one powerful brain (a single System-on-Chip). But here's the catch: powerful brains usually run "General Purpose" operating systems (like standard Linux on your laptop). These systems are great at doing many things at once, but they are terrible at being precise. They are like a busy restaurant manager who is great at serving 50 tables but terrible at timing a soufflé that must come out of the oven at exactly 3:00 PM.

This paper asks: Can we make a powerful, single-board computer (the Raspberry Pi 5) fly a drone safely using a "Real-Time" version of Linux?

---

The Experiment: The "Stress Test"

The researchers set up a simulation where a drone needs to adjust its balance 250 times every second. That's a heartbeat of a control loop. If the computer takes even a tiny fraction of a second too long to say "tilt left," the drone could wobble or crash.

They tested two versions of the operating system on the Raspberry Pi 5:

1. Standard Linux: The "Normal" version you'd find on a desktop.
2. PREEMPT_RT Linux: A "Hardened" version where the system is forced to stop whatever it's doing immediately if a critical task (like keeping the drone stable) needs attention.

They also threw a "stress test" at the system: they made the computer do heavy math, fill up the memory, and juggle thousands of background tasks to simulate a real-world scenario where the drone is also doing computer vision and path planning.

The Results: The "Traffic Jam" vs. The "Express Lane"

1. The Standard Linux Disaster (The Traffic Jam)

When the standard Linux kernel was stressed, it behaved like a chaotic city intersection with no traffic lights.

• The Problem: When the timer said "It's time to fly!", the standard kernel didn't wake up the drone task immediately. Instead, it put the request in a "to-do" list (called a SoftIRQ) and said, "I'll get to that when I'm done with this other thing."
• The Result: Under heavy load, the drone task waited over 9 milliseconds to wake up.
• The Analogy: Imagine you are a pilot in a cockpit. You press the button to fire a missile. Instead of firing instantly, the button sends a note to the janitor, who puts it in a pile, walks to the break room, gets coffee, and then tells the pilot to fire. By the time the missile fires, the target is gone. The drone would crash.

2. The PREEMPT_RT Success (The Express Lane)

When they switched to the PREEMPT_RT kernel, the system changed its behavior completely.

• The Fix: This version treats the drone task like a VIP. As soon as the timer rings, the system immediately stops everything else, clears the desk, and wakes up the drone task.
• The Result: The worst delay dropped from 9,000 microseconds down to 225 microseconds.
• The Analogy: Now, when you press the button, a dedicated security guard (the Real-Time Kernel) immediately clears the hallway, pushes everyone else out of the way, and escorts the pilot straight to the controls. The drone flies smoothly.

The Twist: It's Not Just the Software (The "Noisy Neighbor")

Here is the most interesting part of the paper. Even with the "VIP Express Lane" (PREEMPT_RT), the drone wasn't perfectly smooth. There was still a tiny bit of jitter (wobble).

Why?
The researchers realized that even though the software was doing its job perfectly, the hardware was getting crowded.

• The Analogy: Imagine the drone task is a VIP sitting in a private room (Core 2). The VIP is served instantly. However, the VIP's room shares a single water cooler and a hallway with the other three rooms (Cores 0, 1, and 3). When the other rooms are throwing a massive party (running heavy computer vision tasks), they are fighting over the water cooler and clogging the hallway.
• The Consequence: Even though the VIP gets the "go" signal instantly, they have to wait a split second because the hallway is jammed with data traffic. This is called Memory Contention.

The Verdict: Is It Good Enough?

The researchers compared this "Single Brain" approach to the traditional "Dual Brain" approach (using a tiny microcontroller).

• The Microcontroller: Is like a Swiss Army knife. It's tiny, cheap, and incredibly precise (jitter is almost zero). But it can't do complex math or see faces.
• The Raspberry Pi 5 (with PREEMPT_RT): Is like a supercomputer. It's 10 times "noisier" (less precise) than the microcontroller, BUT it is precise enough to fly a drone safely.
  • The drone needs to react every 4 milliseconds.
  • The Raspberry Pi 5's worst delay was 0.225 milliseconds.
  • That leaves plenty of safety margin.

Conclusion: The Future of Drones

This paper proves that we can finally ditch the "two brains" setup for many drones. We can put the heavy lifting (AI, vision, planning) and the delicate flying (stabilization) on the same chip.

• What works: Using a "Real-Time" version of Linux (PREEMPT_RT) turns a chaotic computer into a reliable pilot.
• What's left to fix: The hardware itself (the memory and cache) still gets a bit crowded when doing heavy AI tasks. Future engineers will need to build better "traffic management" for the hardware to make it even smoother.

In short: You can now fly a drone using a powerful computer that does everything, as long as you tell that computer to be polite and stop what it's doing when the drone needs to fly.

Technical Summary

1. Problem Statement

Modern Unmanned Aerial Vehicles (UAVs) are evolving toward unified architectures where a single high-performance System-on-Chip (SoC) handles both high-level autonomy (e.g., SLAM, computer vision) and low-level flight control. While this reduces Size, Weight, and Power (SWaP) constraints compared to traditional dual-processor setups, it introduces significant timing indeterminism.

• The Core Challenge: Standard General-Purpose Operating Systems (GPOS) like Linux are optimized for throughput, not determinism. On modern heterogeneous multi-core SoCs (like the Raspberry Pi 5's ARM Cortex-A76), shared resource contention (L3 cache, DRAM bandwidth) and complex interrupt routing cause unpredictable scheduling latencies.
• The Risk: Flight control loops typically run at 250 Hz (4 ms period). Latencies exceeding a fraction of this period (e.g., >500 µs) or high jitter can destabilize the control loop, leading to loss of flight stability.
• The Gap: Existing literature on real-time Linux often focuses on older, simpler single-board computers (e.g., Raspberry Pi 3). There is a lack of architectural analysis regarding how modern Out-of-Order (OoO) execution and deep cache hierarchies impact real-time guarantees in unified UAV systems.

2. Methodology

The authors conducted an empirical architectural analysis to isolate the impact of the OS scheduler from hardware I/O delays.

• Platform: Raspberry Pi 5 (8GB RAM) featuring the Broadcom BCM2712 SoC (Quad-core ARM Cortex-A76, 2.4 GHz).
• Kernel Configurations:
  • Standard Kernel: Mainline Linux 6.8.0-raspi.
  • Real-Time Kernel: Fully preemptive PREEMPT_RT patch (6.8.0-raspi-realtime).
• Workload Model:
  • A 250 Hz (4 ms period) attitude control loop was implemented as a periodic real-time task.
  • Isolation Strategy: The critical task was pinned to a dedicated CPU core (Core 2) using isolcpus and pthread_setaffinity_np to prevent interference from the OS scheduler's load balancing. Lower-priority tasks were pinned to Core 3.
  • Stress Testing: The stress-ng tool was used to simulate heavy autonomy workloads, including:
    • Compute: Matrix multiplication (simulating path planning).
    • Memory: 75% RAM usage (simulating computer vision/cache thrashing).
    • Kernel: High-frequency context switches and interrupts.
• Scheduling Policies Tested:
  • SCHED_OTHER (Standard, with various nice levels).
  • SCHED_FIFO, SCHED_RR, and SCHED_DEADLINE (Real-time policies with various priorities/runtime budgets).
• Measurement: 10,000 iterations per configuration were measured using high-resolution timers to capture scheduling latency, jitter, and worst-case execution times.

3. Key Contributions

1. Quantitative Benchmark: Provided the first detailed performance benchmark of a 250 Hz control loop on a modern multi-core SoC (RPi 5), isolating scheduler behavior from bus latency.
2. Architectural Mechanism Identification: Identified that the Deferred Execution Path (SoftIRQs) in standard kernels is the primary cause of massive latency spikes (>9 ms). Conversely, PREEMPT_RT enforces a Direct Activation Path, reducing worst-case latency by 88% (from ~1.84 ms to <225 µs).
3. Hardware Contention Analysis: Demonstrated that while PREEMPT_RT effectively bounds scheduling latency, residual jitter on modern SoCs is primarily driven by hardware memory contention (L3 cache thrashing and DRAM bandwidth saturation) caused by "noisy neighbor" threads.
4. Feasibility Baseline: Established that unified GPOS architectures are viable for UAV flight control, offering a trade-off between microsecond-level precision (MCUs) and massive computational headroom for autonomy.

4. Key Results

Metric	Standard Kernel (Stressed)	PREEMPT_RT Kernel (Stressed)
Worst-Case Latency (Max)	> 9,400 µs (9.4 ms)	225 µs
SCHED_FIFO (P99) Max	1,848 µs	224 µs
SCHED_RR (P99) Max	472 µs	182 µs
SCHED_DEADLINE Max	443 µs	197 µs
Jitter (StdDev)	High (hundreds of µs to ms)	Low (< 30 µs for most policies)

• Activation Path Analysis: Tracing revealed that the standard kernel uses a "Deferred Path" where timer interrupts trigger a SoftIRQ (ktimers), which then wakes the task. This adds >100 µs of delay and multiple context switches. PREEMPT_RT converts interrupt handlers to preemptible threads, allowing direct wake-up (IRQ → Task) with ~7 µs latency.
• Cache Pollution: The execution time of the control algorithm itself increased 13x (from ~3.8 µs to ~51 µs) on the standard kernel under stress due to L1/L2 cache eviction by kernel housekeeping threads.
• Comparison to MCU: While PREEMPT_RT on RPi 5 has ~10x higher jitter than a bare-metal RTOS on an STM32 (224 µs vs. ~10–20 µs), the jitter represents only 5.6% of the 4 ms control period. This is generally considered acceptable for flight stability, whereas the standard kernel's 9.4 ms latency (2.3x the period) would cause a control blackout and crash.

5. Significance and Implications

• Viability of Unified Architectures: The study confirms that a single-board computer running PREEMPT_RT Linux is a viable alternative to dual-processor architectures for many UAV applications, provided the control loop frequency is managed (e.g., 250 Hz) and the system is properly configured.
• Hardware Limitations: The research highlights a critical bottleneck: memory hierarchy contention. Even with perfect software scheduling, modern SoCs suffer from "noisy neighbor" effects in shared caches and memory buses. Achieving MCU-level jitter (<50 µs) on these platforms requires hardware-level solutions (e.g., cache coloring) which are not yet standard in Linux.
• Design Guidelines:
  • Do not use Standard Linux for safety-critical flight control loops.
  • Use PREEMPT_RT with real-time scheduling policies (SCHED_FIFO/SCHED_DEADLINE).
  • Isolate CPU cores and pin critical tasks.
  • Future Work: The study isolated CPU scheduling from I/O. Future implementations must address I/O latency (drivers, SPI/UART) which can introduce unbounded delays, potentially requiring Userspace I/O or DMA to maintain end-to-end determinism.

In conclusion, the paper provides a rigorous validation that PREEMPT_RT on modern edge-AI hardware can support high-frequency flight control, bridging the gap between the computational power needed for autonomy and the timing guarantees required for safety.