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

The Thesis

Modern drones increasingly try to run both high-level autonomy software and low-level flight control on one general-purpose chip — a cost-saving design that only works if the operating system can meet strict timing deadlines. This paper measures, on a Raspberry Pi 5, how much a real-time Linux patch called PREEMPT_RT (which forces the OS to respond to urgent tasks immediately rather than batching them) improves the worst-case response time for a 250 Hz control loop — the kind of fast, repetitive calculation that keeps a drone stable in flight. The results are striking: worst-case latency drops from over 9 milliseconds with the standard Linux kernel to under 225 microseconds with PREEMPT_RT. The catch is that even with the OS fixed, timing jitter — small, unpredictable variations in when tasks run — persists because multiple CPU cores share memory hardware, creating contention that software alone cannot eliminate.

Catalyst

The Raspberry Pi 5 introduced a new system-on-chip (the BCM2712) with multiple high-performance cores and a more complex memory subsystem than its predecessors, making the timing behavior of real-time software on this hardware an open and practically important question. Simultaneously, the drone industry is actively consolidating flight stacks onto single-board computers running Linux, making latency characterization on affordable, widely available hardware directly relevant to commercial product decisions. PREEMPT_RT's recent integration path toward the Linux mainline kernel has also renewed practitioner interest in its real deployment limits.

What's New

Earlier timing studies of PREEMPT_RT on drones typically used older single-core or simpler multi-core boards — or characterized latency under light load without isolating which specific kernel code path (deferred SoftIRQ execution versus direct real-time wake-up) was responsible for the variance. This paper isolates the kernel activation path as the primary OS-level variable and deliberately applies heavy system stress to surface worst-case rather than typical behavior. The authors' key contribution is pinning residual jitter, after the OS fix is applied, specifically on hardware memory bus contention among cores — a finding that shifts the engineering problem from software configuration to chip architecture.

The Counter

This paper essentially confirms what the embedded Linux community has known for over a decade: PREEMPT_RT dramatically improves worst-case latency, and shared-memory multi-core hardware is the next problem. Neither finding is new. The drone industry's serious players — those building certified or high-reliability platforms — have long used dedicated real-time microcontrollers (running NuttX or ChibiOS) alongside a companion computer for autonomy, precisely because no Linux configuration can yet offer the hard real-time guarantees that safety-critical flight demands. A Raspberry Pi 5 in a lab, stressed with synthetic loads and measured with cyclictest, is very far from FAA or EASA certification evidence. The residual jitter from memory contention the authors identify is not a solvable software problem — it requires cache partitioning, memory bandwidth reservation, or hardware redesign, none of which are addressed here. Practitioners evaluating this for real deployments will still need dedicated flight-control silicon, making this a useful academic datapoint rather than a design recommendation.

The Paper