arXiv:2604.19275v2 [eess.SY] 2 Jun 2026
S CHEDULING A NALYSIS OF UAV F LIGHT C ONTROL W ORKLOADS ON PREEMPT_RT L INUX U SING A R ASPBERRY P I 5
Luiz Giacomossi Håkan Forsberg Baran Çürüklü Mälardalen University Mälardalen University Mälardalen University Västerås, Sweden Västerås, Sweden Västerås, Sweden [email protected] [email protected] [email protected] Tommaso Cucinotta Ivan Tomasic ReTiS Lab, Scuola Superiore Sant’Anna Mälardalen University Pisa, Italy Västerås, Sweden [email protected] [email protected]
A BSTRACT Modern UAV architectures increasingly aim to unify high-level autonomy and low-level flight control on a single General-Purpose Operating System (GPOS). However, complex multi-core System-on-Chips (SoCs) introduce significant timing indeterminism due to shared resource contention. This paper performs an architectural analysis of the PREEMPT_RT Linux kernel on a Raspberry Pi 5, specifically isolating the impact of kernel activation paths—deferred execution (SoftIRQs) versus real-time direct activation—on a 250 Hz control loop. Results show that under heavy stress, the standard kernel is unsuitable, exhibiting worst-case latencies exceeding 9 ms. In contrast, PREEMPT_RT reduced the worst-case latency by nearly 88% to under 225 µs, enforcing a direct wake-up path that mitigates OS noise. These findings demonstrate that while PREEMPT_RT resolves scheduling variance, the residual jitter on modern SoCs is primarily driven by hardware memory contention. Keywords Real-Time Systems · UAV Flight Control · Real-Time Linux · PREEMPT_RT · Embedded Systems · Raspberry Pi
1
Introduction
Unmanned Aerial Vehicles (UAVs) are evolving from remote-controlled aircraft into autonomous edgecomputing nodes capable of complex onboard tasks including SLAM, computer vision, and swarm coordination [1, 2, 3]. Historically, these systems relied on a dual-processor architecture: a high-performance "companion computer" for autonomy and a reliable low-power microcontroller (MCU) for flight stabilization. However, constraints on size, weight, and power (SWaP) favor unified architectures, where a single high-performance System-on-Chip (SoC) handles both mission logic and the safety-critical Flight Control System (FCS) [4]. The challenge lies in the operating system. While the complexity of autonomy stacks necessitates a General-Purpose Operating System (GPOS) like Linux, standard kernels are optimized for throughput, not the determinism required by 250+ Hz control loops [5]. Unlike MCUs, modern high-performance SoCs (e.g., those based on the ARM Cortex-A76) introduce non-trivial sources of indeterminism, including deep cache hierarchies, out-of-order execu-
tion, and shared memory controllers. On such platforms, unpredictable scheduling latencies and kernel housekeeping tasks can lead to control loop jitter that threatens flight stability [6, 7]. This trade-off motivates the PREEMPT_RT patch-set, which transforms the Linux kernel into a hard real-time system by converting spin-locks into rt-mutexes and forcing interrupt handlers to run as preemptible kernel threads [8]. While the theoretical benefits of PREEMPT_RT are well-established, existing literature [5] predominantly focuses on older, simpler single-board computers (e.g., Raspberry Pi 3). These studies tend to overlook the behavior of modern heterogeneous multi-core architectures where shared resource contention (L3 cache, DRAM bandwidth) and complex interrupt routing significantly impact real-time guarantees. This paper bridges that gap by providing an architectural schedulability analysis of flight control workloads on the Raspberry Pi 5. We select this platform not merely for its popularity, but because its BCM2712 SoC (quad-core Cortex-A76) exhibits the Out-of-Order execution and memory hierarchy complexity typical of modern edge-AI plat-
Real-Time UAV Flight Control Using PREEMPT_RT
2.2
forms. We isolate the CPU scheduler from hardware I/O to answer two fundamental questions:
Embedded FCS architectures have evolved to support the increasing demand for onboard intelligence while managing SWaP (Size, Weight, and Power) constraints:
1. Architectural Mechanism: How do the distinct task activation paths (Deferred SoftIRQ vs. Direct Threaded IRQ) in standard and real-time kernels dictate worst-case latency?
• Microcontroller + RTOS: The standard combines a microcontroller (e.g., STM32) with a RealTime Operating System (RTOS) like FreeRTOS or NuttX. This provides excellent determinism (jitter typically < 10 µs) but lacks the memory and compute throughput required for onboard computer vision or SLAM [13].
2. Resource Contention: To what extent does the PREEMPT_RT kernel mitigate jitter caused by shared cache and memory bandwidth contention under heavy autonomy-like loads?
• Dual-Processor Setup: A high-level companion computer (e.g., Raspberry Pi, Jetson) handles perception and communicates with a separate lowlevel RTOS microcontroller via a serial link (e.g., MAVLink) [14]. While robust, this adds weight, wiring complexity, and inter-process communication (IPC) latency.
The main contributions of this work are: 1) A quantitative performance benchmark of a 250 Hz control loop on a modern multi-core SoC, isolating scheduler behavior from bus latency; 2) An architectural analysis identifying that the standard kernel’s reliance on Deferred Execution (SoftIRQs) is the primary cause of > 9 ms latency spikes, whereas PREEMPT_RT’s Direct Activation path reduces this by 88% (from 1.84 ms to < 225 µs); 3) Empirical validation that while PREEMPT_RT effectively bounds scheduling latency, residual jitter on modern SoCs is driven by hardware memory contention, providing a computational baseline for unified UAV architectures.
2
• Unified GPOS-Based System: Control and highlevel autonomy are integrated onto a single highperformance SoC running a GPOS, typically Linux with real-time extensions [15, 16]. This reduces hardware complexity but introduces the challenge of ensuring real-time determinism on complex multi-core architectures where cache and memory bus contention can cause unpredictable delays. This architecture is the focus of our investigation.
Background and Related Work
This section reviews the fundamentals of real-time UAV control, examines existing software architectures, and contextualizes this work. 2.1
Architectures for Embedded FCS
2.3
Linux Scheduling Policies
The Linux kernel scheduler implements several policies. The default policy, SCHED_OTHER (based on the Completely Fair Scheduler, CFS), is optimized for throughput and fair time-slicing but offers no timing guarantees [17]. For real-time applications, Linux provides alternative policies summarized in Tab. 1. Foundational works [8] have established that standard kernels suffer from priority inversion and non-preemptible sections (kernel locks), necessitating the PREEMPT_RT patch to enforce bounded latencies.
Overview of Real-Time UAV Control Systems
Flight control systems are hard real-time systems. They execute nested control loops, with high-frequency inner loops (200–500 Hz) for attitude stabilization and slower outer loops (50–100 Hz) for navigation [9, 10, 11]. The stability of these loops depends on the timing guarantees provided by the operating system, captured by the principle of determinism. In real-time systems, determinism means that task execution times are bounded so that deadlines can be guaranteed under specified conditions. This relies on two key properties:
Table 1: Linux Kernel Scheduling Policies and Characteristics. Policy SCHED_OTHER SCHED_FIFO SCHED_RR SCHED_DEADLINE
• Bounded Latency: Scheduling latency is the delay between a task becoming ready and its dispatch to the CPU. Large or unpredictable latencies reduce the control phase margin and can destabilize the system [7]. For a 250 Hz loop (4 ms period), latencies exceeding a fraction of the period (e.g., > 500 µs) can destabilize the control loop.
2.4
Type Time-Sharing Real-Time Real-Time Real-Time
Priority Mechanism Dynamic (‘nice‘ value) Static (1-99) Static (1-99) Dynamic (EDF)
Key Feature Fair CPU sharing for throughput Runs until block/yield Round-robin time-slicing Temporal isolation via reservation
Related Work and Gap Analysis
Research into unified Linux-based flight control generally follows three tracks: dual-kernel extensions, virtualization, and native preemption.
• Low Jitter: Jitter is the variation in latency across executions. Excessive jitter makes the control loop period inconsistent, complicates controller tuning (e.g., needs lower gains), and creates unpredictable dynamics [12].
2.4.1
Dual-Kernel (Xenomai) vs. Native Preemption
To overcome Linux’s non-determinism, approaches like Xenomai (Cobalt) use a dual-kernel architecture, running 2
Real-Time UAV Flight Control Using PREEMPT_RT
desired control torque vector, τr . The Control Allocator receives the total commanded force F and the desired torque τr . Its role is to decompose these high-level commands into actuator-level inputs by computing the individual rotor speeds ωi needed to achieve the desired response within actuator limits.
a real-time microkernel alongside Linux. While Xenomai typically offers lower latency than PREEMPT_RT by bypassing the Linux scheduler entirely [18], it requires custom drivers (RTDM) and creates a complex split-system development environment. In the context of UAVs, we prioritize PREEMPT_RT because it maintains the standard Linux programming model. This allows standard robotics frameworks (e.g., ROS 2, MAVROS) and device drivers (e.g., V4L2 for cameras) to be used without modification, simplifying unified autonomy development. 2.4.2
Finally, these actuator commands are applied to the UAV model. In this work, to isolate the performance of the CPU scheduler from hardware I/O, the vehicle’s dynamics are handled by a UAV Simulation Block. This block simulates the vehicle’s dynamics and outputs the state variables— position r, linear velocity v, attitude α, and angular velocity ωb —which are used as feedback signals to close the control loops. For more details on the dynamic equations and control laws behind this architecture, see [22, 10].
Isolation via Virtualization
Yang and Shinjo [19] proposed a compounded RTOS (cRTOS) using Jailhouse to partition hardware between Linux and NuttX. While this ensures isolation, it effectively mimics the dual-processor constraint in software, limiting the flexibility of resource sharing between the autonomy and control layers. 2.4.3
4
To empirically evaluate the architectural determinism of the PREEMPT_RT kernel, we designed a software framework1 that explicitly isolates scheduler activation latencies from peripheral I/O delays. This section details the platform architecture, the task model, and the stress framework used for evaluation.
Hardware Complexity Gap
Most PREEMPT_RT benchmarks focus on older, simpler Single Board Computers (e.g., RPi 3, Cortex-A53), establishing a baseline of approx. 150 µs worst-case latency under moderate load [20]. However, these studies do not account for modern Out-of-Order (OoO) architectures like the Raspberry Pi 5’s Cortex-A76. On these platforms, despite higher clock speeds, shared resource contention (L3 Cache/DRAM) becomes a primary source of timing violation [21]. Our work builds on this by quantifying how the PREEMPT_RT scheduler mitigates interference in these complex, heterogeneous environments.
3
4.1
The FCS of the quadcopter is implemented using the cascaded architecture, as described in [22] and depicted in Fig. 1. The outer loop features a Position Controller, which takes the position reference rr , the current position r, and the current linear velocity v as inputs. It calculates the total desired force vector F, required to track the position reference. Position Controller
ψr r, v
This choice is architecturally significant: the Cortex-A76 employs an out-of-order execution pipeline with a threelevel cache hierarchy (64KB L1, 512KB L2 per core, and a shared 2MB L3). This complexity introduces sources of non-determinism—specifically shared L3 cache contention and DRAM bandwidth saturation—that are not present in simpler in-order microcontrollers. The system runs Ubuntu 24.04 LTS with two kernel configurations: the standard mainline kernel (6.8.0-raspi) and the fully preemptive real-time kernel (6.8.0-raspi-realtime).
F Attitude Controller
τr
Control Allocator
ωi ∀i ∈ {1, 2, 3, 4}
Platform Architecture: Raspberry Pi 5
We selected the Raspberry Pi 5 (8GB RAM) as the target platform. Unlike previous generations of Single-Board Computers (SBCs) evaluated in literature [20], the RPi 5 utilizes the Broadcom BCM2712 SoC featuring a quad-core ARM Cortex-A76 cluster. To preclude thermal throttling during stress testing, active cooling was employed, and the CPU frequency was strictly locked to 2.4 GHz using the performance governor.
Flight Control Architecture
rr
System Model and Methodology
UAV
α , ωb
4.2
Figure 1: Architecture of the UAV Flight Control System. The Position Controller generates the desired force vector F based on position and velocity errors. The Attitude Controller computes the desired torque vector τr from attitude and angular velocity errors. The Control Allocator maps these commands to individual motor speeds ωi for i ∈ {1, 2, 3, 4}.
Real-Time Software Architecture
The Flight Control System (FCS) is implemented as a set of concurrent, prioritized threads mapped to specific CPU cores. We focus our formal analysis on the critical highfrequency attitude control loop, as it represents the system’s worst-case timing constraint. We define this periodic realtime task τatt as: τatt = {Catt , Tatt , Datt , Patt }
The inner loop consists of the Attitude Controller. This controller receives the desired yaw angle ψr , the current attitude α (i.e., Euler angles), and the current body-frame angular velocity ωb . It uses this information to compute the
1 The implementation is available https://github.com/luizgiacomossi/ Real-Time-Flight-Control-With-Linux
3
(1) at:
Real-Time UAV Flight Control Using PREEMPT_RT
5
Where execution time Catt varies based on load, period Tatt = 4000 µs (250 Hz), deadline Datt = Tatt , and priority Patt is a variable determined by the experimental configuration (see Section 5). To mitigate sources of OSinduced jitter, we apply an isolation strategy:
To quantify the performance difference between the standard Linux kernel and its PREEMPT_RT counterpart, we designed an experiment to measure the scheduling latency and jitter of a representative high-frequency UAV control loop. The inner attitude stabilization loop of our FCS was set to 250 Hz (4 ms period), a common and demanding frequency for agile multi-rotor platforms that is fast enough to require real-time determinism but slow enough to be achievable on embedded hardware if the operating system is sufficiently responsive [10, 9]. For all tests, this critical task was pinned to an isolated CPU core (core 2) on the Raspberry Pi 5, with memory locking enabled to prevent swapping delays.
• CPU Isolation: We utilize the boot parameter isolcpus=2,3 to exclude Cores 2 and 3 from the SMP balancing algorithms. • Task Pinning: The critical task τatt is pinned exclusively to Core 2 via ‘pthread_setaffinity_np‘. • Inter-Thread Isolation: Lower-criticality tasks (logging, telemetry, and the position controller τpos ) are pinned to Core 3, ensuring they do not preempt the attitude loop.
Crucially, the experimental matrix detailed in Tab. 3 was executed twice: once on a standard Linux kernel to establish a baseline, and once on a kernel with PREEMPT_RT to evaluate its real-time capabilities. This yields a total of 32 unique test runs. The 16 configurations tested on each kernel were:
The wake-up mechanism relies on clock_nanosleep() using CLOCK_MONOTONIC, which provides high-resolution timing backed by the hardware hrtimer. 4.3
Workload Injection Framework
• SCHED_OTHER (at nice levels 0 and -19) to establish a non-real-time baseline.
To analyze the architectural limits of the scheduler under worst-case conditions, we utilized stress-ng2 tool to synthesize a unified interference profile. This profile concurrently executes distinct stressor components (Tab. 2).
• SCHED_FIFO and SCHED_RR (at static priorities 50 and 99) to assess POSIX real-time policies.
Table 2: Components of the Stress Profile used for Evaluation. Component Compute Memory Kernel
Stressor Mechanism cpu-matrix (4 workers) vm (75% RAM, 2 workers) switch, fork (High rate)
Experimental Evaluation
• SCHED_DEADLINE with runtimes of 400 µs and 800 µs, chosen to represent a tight and a generous budget based on measured task execution time. The period and deadline were set to 4 ms to match the 250 Hz control loop.
Targeted Bottleneck ALU pipeline saturation L3 Cache Thrashing & DRAM Bandwidth Runqueue lock contention & SoftIRQ Latency
The unified profile has three components: Compute, which tests the scheduler’s ability to preempt compute-bound threads; Memory, which triggers L3 cache evictions to simulate interference from memory-heavy autonomy workloads (e.g., Computer Vision) on neighboring cores; and Kernel, which floods the system with context switches and interrupts to evaluate the kernel’s handling of the "Deferred Activation Path" (SoftIRQs) described in Section 6.
Table 3: Experimental configurations executed on each kernel, for a total of 32 tests. For SCHED_DEADLINE, the deadline and period set to 4.0 ms, matching the control loop’s period.
4.4
Each configuration was tested with and without background load using the stress-ng tool. The tool was configured to simulate a realistic system load representative of a modern UAV autonomy stack. To this end, we launched a set of stressors, including four CPU workers executing matrix multiplications to simulate tasks like path planning, two virtual memory stressors allocating 75% of available memory to represent computer vision workloads stressing the system like real autonomy stacks would, without destabilizing the testbed, and multiple inter-process communication (IPC) stressors to mimic the data flow in frameworks like ROS. To ensure maximal determinism for the benchmark, the kernel’s real-time runtime throttling was disabled by setting sched_rt_runtime_us to -1, and all CPU cores were locked to their maximum frequency (2.4 GHz) via the performance governor. Each of the 32 tests executed 10, 000 iterations of the control loop, allowing for a detailed statistical analysis.
Scheduler SCHED_OTHER SCHED_FIFO SCHED_RR SCHED_DEADLINE
Methodological Constraints
A challenge in any real-world FCS is the management of I/O latency (e.g., SPI bus transfers for IMU data). While hardware transfers are deterministic, driver stacks introduce variable delays. However, scheduler determinism is the necessary antecedent condition for real-time control; if the kernel cannot dispatch the control task within the deadline, the speed of the I/O driver is irrelevant. Therefore, this study intentionally decouples scheduler latency from I/O. For the experiments, τatt executes the full control law mathematics but bypasses physical SPI transactions. This ensures that the measured jitter is attributable solely to CPU scheduling and kernel activation paths, enabling a precise architectural comparison of PREEMPT_RT versus standard Linux. 2
The stress-ng
stress-ng:github.com/ColinIanKing/
4
Parameter Values Nice = {0, -19} Priority = {50, 99} Priority = {50, 99} Runtime = {400, 800} µs
Period (ms) 4.0 4.0 4.0 4.0
Stress-ng Off / On Off / On Off / On Off / On Total
Tests per Kernel 2×2=4 2×2=4 2×2=4 2×2=4 16 per kernel
Real-Time UAV Flight Control Using PREEMPT_RT
6.1
It is important to note that, all latency metrics are presented in microseconds (µs). These values were derived from high-resolution timers with nanosecond precision. The conversion to microseconds can introduce a visual quantization effect, observable as discrete steps in the time-series plots. 5.1
Statistical Distribution of Latency
Figure 2 provides a visual comparison of scheduling latency on both kernels when under heavy system stress.
Analysis of Scheduling Determinism
To investigate the origins of the non-determinism observed in the benchmark, particularly for SCHED_OTHER, we designed two follow-up experiments. The objective was to distinguish between interference from high-level system services and fundamental architectural behaviors of the kernel scheduler. The experiments were: 1. System-Level Isolation Analysis: The benchmarks for the SCHED_OTHER policy were reexecuted after disabling the graphical user interface (GUI) by switching the system to the multi-user.target runlevel. This isolates the scheduler’s performance from a primary source of non-deterministic, high-level system load.
Figure 2: Box plots comparing scheduling latency on the standard and PREEMPT_RT kernels under heavy system stress. The red dashed line indicates the deadline for the control loop. (a) On the standard kernel, the logarithmic y-axis to visualize the outliers that surpass the deadline. Even real-time policies exhibit significant jitter. (b) On the PREEMPT_RT kernel, shows the performance of all realtime schedulers, with worst-case latencies remaining an order of magnitude below the deadline.
2. Task Activation Path Analysis: A low-level kernel trace analysis was performed using the perf tool. This analysis was designed to observe and compare the task wakeup latency and the sequence of kernel events for a real-time policy (SCHED_FIFO) versus a standard policy (SCHED_OTHER).
6
Results
On the standard kernel, Fig. 2(a), the default SCHED_OTHER scheduler exhibits very high worst-case latencies. Table 4 shows these latencies reach over 9400 µs, far exceeding the 4000 µs deadline. The real-time schedulers also show significant latency spikes on the standard kernel. For SCHED_FIFO with priority 99, the maximum observed latency was 1848 µs. For SCHED_RR with priority 99, the maximum was 472 µs, and for SCHED_DEADLINE R800, it was 443 µs.
Tab. 4 presents the statistical results of the 32 experiments. While PREEMPT_RT paired with SCHED_OTHER is included for completeness, its fundamental lack of real-time guarantees excludes it from further plots and discussion. The remaining real-time findings are visualized via latency distributions (Fig. 2) and detailed time-series traces (Figs. 39). Table 4: Unified Performance Comparison of Standard vs. PREEMPT_RT Kernels Under a 250 Hz Control Loop Task. All metrics are in microseconds (µs). Note the reduction in worst-case (Max) latency for all real-time policies when using the PREEMPT_RT kernel under system stress. Scheduler OTHER
Parameters Nice 0
OTHER
Nice -19
FIFO
Priority 50
FIFO
Priority 99
RR
Priority 50
RR
Priority 99
DEADLINE
R400, D4000
DEADLINE
R800, D4000
Kernel Standard Standard PREEMPT_RT PREEMPT_RT Standard Standard PREEMPT_RT PREEMPT_RT Standard Standard PREEMPT_RT PREEMPT_RT Standard Standard PREEMPT_RT PREEMPT_RT Standard Standard PREEMPT_RT PREEMPT_RT Standard Standard PREEMPT_RT PREEMPT_RT Standard Standard PREEMPT_RT PREEMPT_RT Standard Standard PREEMPT_RT PREEMPT_RT
Stress No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes
Mean (µs) 58.53 274.01 59.64 196.84 56.59 136.54 64.79 110.81 4.07 58.37 5.29 36.07 4.25 49.37 4.19 31.33 4.56 38.01 4.35 44.09 4.76 43.18 4.14 41.08 6.53 43.77 4.20 44.16 6.17 40.94 4.21 32.30
Median (µs) 54.00 103.00 58.00 97.00 54.00 101.00 58.00 85.00 3.00 39.00 4.00 28.00 4.00 40.00 4.00 25.00 4.00 30.00 4.00 32.00 4.00 36.00 4.00 31.00 7.00 36.00 4.00 33.00 6.00 35.00 4.00 27.00
Max (µs) 2724.00 8626.00 2570.00 9015.00 2451.00 9424.00 2779.00 4351.00 45.00 700.00 135.00 160.00 63.00 1848.00 100.00 224.00 51.00 787.00 76.00 225.00 86.00 472.00 51.00 182.00 33.00 345.00 96.00 209.00 58.00 443.00 84.00 197.00
StdDev (µs) 73.89 563.32 36.78 414.98 45.36 227.57 88.06 186.65 2.90 48.83 4.55 23.78 1.97 40.67 1.90 21.61 2.14 28.30 2.53 31.75 3.40 26.12 1.15 27.01 2.23 27.17 1.86 29.57 1.98 22.67 2.00 18.75
P90 (µs) 57.00 451.00 59.00 290.00 57.00 188.00 60.00 124.00 6.00 137.00 7.00 68.00 5.00 89.00 4.00 50.00 6.00 64.00 5.00 92.00 6.00 76.00 4.00 82.00 8.00 78.00 5.00 90.00 7.00 70.00 4.00 51.00
On the PREEMPT_RT kernel, in Fig.2(b), the maximum latencies are significantly lower for all real-time policies. The data in Tab. 4 quantifies this improvement: the maximum latency for SCHED_FIFO p99 was reduced to 224 µs; for SCHED_RR p99, it was reduced to 182 µs; and for SCHED_DEADLINE R800, it was reduced to 197 µs.
P99 (µs) 72.00 3070.00 66.00 2420.00 70.00 642.00 90.00 669.00 21.00 201.00 21.00 123.00 12.00 156.00 7.00 130.00 13.00 125.00 13.00 152.00 16.00 121.00 6.00 122.00 16.00 137.00 7.00 137.00 14.00 112.00 8.00 116.00
6.2
Iteration-by-Iteration Latency Behavior
To provide a detailed view of system responsiveness, Figs. 3 through 9 depict the latency across 10,000 control loop iterations under different configurations. The standard kernel traces exhibit frequent spikes in execution time, indicating variability and reduced predictability. In contrast, the PREEMPT_RT kernel traces appear markedly more stable, maintaining a consistent baseline with only occasional small outliers, which are less pronounced in comparison. The standard kernel results are presented in Figs. 3-6, while the corresponding PREEMPT_RT results are shown in Figs. 7-9. 5
Real-Time UAV Flight Control Using PREEMPT_RT
Latency for Scheduler: SCHED FIFO p50
Latency for Scheduler: SCHED OTHER n0 1000
1000 100 50 25 10 5
Latency (7s)
Latency (7s)
10000
Stress No Stress 0
2000
4000
6000
8000
Stress No Stress 100 50 25 10 5
10000
0
Iteration Latency for Scheduler: SCHED OTHER n-19
2000
Latency (7s)
Latency (7s)
1000 1000
Stress No Stress 0
2000
4000
6000
8000
10000
4000
6000
Latency for Scheduler: SCHED DEADLINE R400
Latency (7s)
100 50 25 10 5
Stress No Stress 100 50 25 10 5
0 6000
8000
2000
4000
6000
Latency (7s)
Latency (7s)
Stress No Stress 100 50 25 10 5
Stress No Stress 100 50 25 10 5
0 6000
8000
2000
4000
6000
8000
10000
Iteration
10000
Iteration
Figure 6: Time-series latency for SCHED_DEADLINE on the standard kernel, 400 µs runtime (top) versus 800 µs (bottom). Even with this reservation-based scheduler, there are significant latency spikes under stress (red).
Figure 4: Latency for SCHED_RR on the standard kernel at priorities 50 (top) and 99 (bottom). Note the spikes under system stress (red), indicating difficulty in guaranteeing deterministic execution even at the highest static priority. 6.3
10000
1000
1000
4000
8000
Iteration Latency for Scheduler: SCHED DEADLINE R800
10000
Iteration Latency for Scheduler: SCHED RR p99
2000
10000
1000
Stress No Stress
0
8000
Figure 5: Time-series latency for SCHED_FIFO on the standard kernel at priorities 50 (top) and 99 (bottom). Similar to SCHED_RR, the system exhibits latency outliers when under load (red).
Latency for Scheduler: SCHED RR p50
Latency (7s)
2000
Iteration
1000
4000
10000
Stress No Stress
0
Figure 3: Time-series latency under SCHED_OTHER on the standard kernel: standard priority (nice 0, top) and high priority (nice -19, bottom). The plots show increased latency and jitter under system stress (red) compared to the idle state (blue).
2000
8000
100 50 25 10 5
Iteration
0
6000
Iteration Latency for Scheduler: SCHED FIFO p99
10000
100 50 25 10 5
4000
The traces reveal a contrast in the wake-up mechanism. The PREEMPT_RT kernel allows the hardware timer interrupt to wake the user task directly, resulting in a wake-up latency of just 7 µs. In contrast, the standard kernel employs a Deferred Path: the interrupt offloads the timer expiry to the intermediate ktimers thread (softirq). In the trace shown, this indirection introduced a delay of over 100 µs and required three additional context switches before the flight control task was scheduled.
Analysis of SCHED_OTHER Non-Determinism
To investigate the additional latencies with SCHED_OTHER, the follow-up experiments in Section 5.1 were conducted. The first test isolated the impact of system-level services. As shown in Tab. 5, disabling the GUI reduced the worstcase latency for SCHED_OTHER under stress by up to 61.4%. Despite this improvement, the maximum latency for the high-priority task (nice -19) still reached 3635 µs. This demonstrates that while high-level services are a significant source of interference, they do not account for all of the observed non-determinism.
Table 5: Impact of Disabling the Graphical User Interface (GUI) on SCHED_OTHER Worst-Case Latency Under System Stress.
To identify the cause of the remaining latency, we utilized perf to trace the exact activation sequence of the control task. Tab. 6 contrasts the timestamped sequence of events captured during a single control loop activation.
Scheduler (Config) SCHED_OTHER (Nice -19) SCHED_OTHER (Nice 0)
6
Max Latency (GUI Enabled)
Max Latency (GUI Disabled)
Improvement (%)
9424 µs 8626 µs
3635 µs 5993 µs
-61.4% -30.5%
Real-Time UAV Flight Control Using PREEMPT_RT
Latency for Scheduler: SCHED DEADLINE R400 200
Stress No Stress
Latency (7s)
Latency (7s)
Latency for Scheduler: SCHED RR p50 200 100 50 25 10 5
Stress No Stress
100 50 25 10 5
0
2000
4000
6000
8000
10000
0
2000
Iteration Latency for Scheduler: SCHED RR p99
Latency (7s)
Latency (7s)
50 25 10
10000
50 25 10 5
0
2000
4000
6000
8000
10000
0
2000
4000
Iteration
8000
10000
Figure 9: Time-series latency for SCHED_DEADLINE on the PREEMPT_RT kernel, comparing a 400 µs runtime budget (top) with an 800 µs budget (bottom). This policy exhibits the highest stability, with minimal jitter and tightly controlled worst-case latencies under stress (red). Table 6: Kernel Activation Sequence (Trace Data). Timestamps denote ∆t from the physical interrupt arrival. The "Deferred Path" in the standard kernel introduces significant delays (> 100 µs) even before the task begins execution.
Latency for Scheduler: SCHED FIFO p50 Stress No Stress
100
6000
Iteration
Figure 7: Time-series latency for SCHED_RR on the PREEMPT_RT kernel, priority 50 (top) and 99 (bottom). In contrast to the standard kernel, the latency remains tightly bounded with minimal outliers, even when subjected to heavy system stress (red).
Latency (7s)
8000
Stress No Stress
100
5
50 25
PREEMPT_RT (Direct Path)
Standard Kernel (Deferred Path)
10
∆t (µs)
Event
∆t (µs)
Event
5
0 2 4 7 -
irq_handler_entry sched_wakeup (target: fcs) sched_switch (→ fcs) Task Execution Begins -
0 5 17 54 92 93 117
irq_handler_entry irq_softirq_raise (HRTIMER) sched_wakeup (target: ktimers) sched_switch (→ ktimers) timer_expire (ktimers) sched_wakeup (target: fcs) Task Execution Begins
0
2000
4000
6000
8000
10000
Iteration Latency for Scheduler: SCHED FIFO p99 200
Latency (7s)
6000
Iteration Latency for Scheduler: SCHED DEADLINE R800
Stress No Stress
100
4000
Stress No Stress
100 50 25
7
10
Discussion and Architectural Analysis
5 0
2000
4000
6000
8000
The data reveals a distinct separation between the kernel’s ability to schedule tasks (software) and the platform’s ability to serve memory requests (hardware). This section interprets the results through an architectural lens, isolating the sources of determinism and establishing a feasibility baseline relative to traditional microcontroller-based architectures.
10000
Iteration
Figure 8: Latency for SCHED_FIFO on the PREEMPT_RT kernel for priorities 50 (top) and 99 (bottom). It shows a reduction in the magnitude of outliers under stress (red), demonstrating the improved effectiveness of the real-time kernel’s preemption model.
7.1 The traces also revealed a secondary effect: the computational execution time of the control algorithm itself (excluding scheduling delay) increased from ≈ 3.8 µs in the real-time kernel to ≈ 51 µs in the standard kernel. Since the code payload is identical, this 13× slowdown suggests cache pollution. The intermediate execution of kernel housekeeping threads (‘ktimers‘, ‘kworker‘) flushes instructions and data from the L1/L2 caches, forcing the control task to fetch data from slower main memory when it finally runs. This indicates that the standard kernel suffers not only from scheduling latency but also from induced memory hierarchy contention.
Mechanism of Determinism: Direct vs. Deferred Activation
The primary source of the > 9 ms latency spikes observed in the standard kernel (Tab. 4) is the Deferred Activation Path. In standard Linux, a timer interrupt does not immediately wake the user-space task but schedules a Software Interrupt (SoftIRQ), often deferred to ksoftirqd to maintain throughput. Under stress, runqueue lock contention delays this SoftIRQ, decoupling the physical interrupt from the task wake-up. In contrast, PREEMPT_RT enforces a Direct Activation Path. By converting interrupt handlers into preemptible threads, the patch flattens the activation hierarchy. Our traces (Table 7
Real-Time UAV Flight Control Using PREEMPT_RT
VI) show that the critical path becomes IRQ → T ask, bypassing the non-deterministic SoftIRQ layer. This architectural change drives the 87.9% reduction in worst-case latency for SCHED_FIFO, ensuring the sub-millisecond response required for 250 Hz control. 7.2
7.4
Flight stability is contingent on the controller’s ability to react to disturbances within a bounded phase margin. The standard kernel exhibited worst-case latencies of 9.4 ms, exceeding the 4.0 ms period of a 250 Hz attitude loop by a factor of 2.3×. In a physical system, this control blackout forces actuators to hold outdated commands for multiple cycles, effectively opening the control loop. During aggressive maneuvers, such delays lead to state divergence and potential loss of control. Conversely, the PREEMPT_RT kernel bounds the worst-case jitter to 225 µs (5.6% of the period). This ensures that the control law is computed with fresh state estimates in every cycle, maintaining the phase margin required for safe flight even under heavy CPU saturation.
The Residual Jitter: Memory Hierarchy Contention
While PREEMPT_RT bounds OS scheduling latency, a residual worst-case jitter of 200–225 µs persists even on isolated CPU cores. This points to the architectural complexity of the Pi 5’s BCM2712 SoC, rather than the kernel scheduler. Unlike MCUs with dedicated SRAM, the quad-core CortexA76 shares a unified L3 cache and DRAM controller. We hypothesize that under the synthetic memory stress profile, "noisy neighbor" threads on Cores 0–1 induce L3 cache thrashing and memory bus contention. This mechanism is supported by the 13× execution time dilation of the control payload itself (from ≈ 3.8 µs to ≈ 51 µs) observed in the trace analysis. Even with the flight control task pinned to Core 2, it likely suffers memory stall cycles, forced to fetch evicted instructions and data from slower main memory. Consequently, on modern edge-AI SoCs, reducing jitter to MCU-levels (< 50 µs) requires more than just kernel preemption; it needs hardware-level spatial partitioning (e.g., cache coloring), which remains a complex and open challenge in Linux. 7.3
7.5
To contextualize these results for UAV designers, we compare the measured performance of the Raspberry Pi 5 against the industry-standard microcontroller (MCU) baseline, typified by an STM32F7 running an RTOS (e.g., FreeRTOS/NuttX).
8
Conclusion
Our work evaluated the scheduling performance of the PREEMPT_RT Linux kernel against the standard kernel for a 250 Hz UAV flight control task on a Raspberry Pi 5. The results show that the standard kernel is unsuitable for this role. Its default scheduler produced worst-case latencies above 8 ms, and its POSIX real-time schedulers exhibited latency spikes up to 1848 µs under stress, limiting their usage for safety-critical control.
Table 7: Architectural Comparison: RPi 5 (Measured) vs. Typical MCU Flight Controller. RPi 5 values are from our experimental data; STM32 values are reference metrics for Cortex-M7 RTOS implementations from literature [7, 13]. RPi 5 (RT-Linux) 2.4 GHz ≈ 224 µs 4000 µs 5.6% High (Vision/AI)
I/O Latency Considerations
While this study establishes that PREEMPT_RT bounds computational scheduling latency to levels compatible with 250 Hz control (< 225 µs), scheduler determinism is a necessary but insufficient condition for flight stability. Endto-end performance remains dependent on the I/O subsystem. In unified architectures, standard Linux device drivers can introduce unbounded latencies via spinlocks or nonthreaded interrupts, potentially negating the scheduler’s guaranties. Consequently, achieving the theoretical performance demonstrated in this work likely requires bypassing standard kernel driver stacks in favor of Userspace I/O or DMA-based transfer mechanisms. This isolates the highfrequency control loop from the blocking behavior inherent to standard Linux peripherals.
Feasibility Analysis: RT-Linux vs. MCU Baseline
Metric Clock Speed Worst-Case Jitter Control Period (250Hz) Jitter % of Period Compute Headroom
Implications for Flight Stability
STM32F7 (RTOS) [7, 13] 216 MHz ≈ 10 − 20 µs 4000 µs 0.5% Low (Control Only)
In contrast, the PREEMPT_RT kernel, when paired with any of the real-time policies (SCHED_FIFO, SCHED_RR, or SCHED_DEADLINE), consistently bounded worst-case latencies at or below 225 µs, even under heavy load. These findings demonstrate that a properly configured GPOS with PREEMPT_RT provides the timing predictability required for high-frequency control. Moreover, because this behavior is tied to the threaded-IRQ mechanism introduced by the patch, these results suggest similar behavior in recent real-time Linux kernel versions.
As seen in Table 7, the PREEMPT_RT Linux solution exhibits approximately 10× higher jitter than a bare-metal RTOS [13]. However, in the context of a 250 Hz control loop (T = 4000 µs), the 224 µs worst-case jitter represents only 5.6% of the timing budget. For flight control stability, this margin is generally acceptable [6]. This confirms that while Linux cannot match the microsecond-level precision of an MCU, the Raspberry Pi 5 with PREEMPT_RT offers sufficient determinism for the control loop while unlocking orders of magnitude more computational power for integrated autonomy.
The results suggest that unified GPOS architectures on a single board are a viable alternative to dual-processor designs in many UAV applications, especially where constraints are less stringent. However, this study intentionally isolated CPU scheduling from I/O. Future work should integrate real-world sensor and actuator I/O to evaluate the com8
Real-Time UAV Flight Control Using PREEMPT_RT
bined effects of scheduler latency and hardware interrupt handling. The analysis should also extend to more computationally demanding controllers, such as Model Predictive Control (MPC) and Sliding Mode Control (SMC). Finally, the trade-off between real-time performance and power consumption should be explored, as achieving low latency often requires disabling power-saving features essential for battery-powered platforms.
[11] Randal W Beard and Timothy W McLain. Small unmanned aircraft: Theory and practice. Princeton university press, 2012. [12] Kristofer Smeds and Xiaodong Lu. Effect of sampling jitter and control jitter on positioning error in motion control systems. Precision Engineering, 36(2):175– 192, 2012. [13] Lorenz Meier, Dominik Honegger, and Marc Pollefeys. Px4: A node-based multithreaded open source robotics framework for deeply embedded platforms. In 2015 IEEE International Conference on Robotics and Automation (ICRA), pages 6235–6240, 2015. [14] Xuanyao Qu, Ying Wei, Yonghan Liu, and Xuanguang Su. Design of automatic search and rescue uav based on jetson nano combined with px4 pixhawk flight controller and color recognition technology. In 2024 Int. Conf. Electr. Drives Power Electron. Eng., page 460–466, 2024. [15] Anders Mårtensson. Flying penguins: Building and evaluating the viability of a linux-based drone, 2016. Bachelor Thesis in Computer Science, Educational program: DVGDS Computer and System Science. [16] Won Eui Hong, Jae Shin Lee, L. Rai, and Soon Ju Kang. Rt-linux based hard real-time software architecture for unmanned autonomous helicopters. In 11th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA’05), pages 555–558, 2005. [17] Robert Love. Linux kernel development. Pearson Education, 2010. [18] Jeremy H Brown and Brad Martin. How fast is fast enough? choosing between xenomai and linux for real-time applications. In Proceedings of the 12th Real-Time Linux Workshop (RTLWS), pages 1–17, 2010. [19] Chung-Fan Yang and Yasushi Shinjo. Obtaining hard real-time performance and rich linux features in a compounded real-time operating system by a partitioning hypervisor. In Proceedings of the 16th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments, pages 59–72, 2020. [20] George K Adam. Real-time performance and response latency measurements of linux kernels on single-board computers. Computers, 10(5):64, 2021. [21] Dan Iorga, Tyler Sorensen, John Wickerson, and Alastair F Donaldson. Slow and steady: Measuring and tuning multicore interference. In 2020 IEEE RealTime and Embedded Technology and Applications Symposium (RTAS), pages 1–13. IEEE, 2020. [22] Luiz Giacomossi, Angelo Caregnato-Neto, and Marcos R. O. A. Maximo. Optimization of force and torque bounds for the flight control system of a quadcopter using pso. In 2022 Latin American Robotics Symposium (LARS), pages 1–6, 2022.
References [1] Sadaf Javed, Ali Hassan, Rizwan Ahmad, Waqas Ahmed, Rehan Ahmed, Ahsan Saadat, and Mohsen Guizani. State-of-the-art and future research challenges in uav swarms. IEEE Internet of Things Journal, 11(11), 2024. [2] Jorge A. Ricardo, Luiz Giacomossi, João F. S. Trentin, José F. B. Brancalion, Marcos R. O. A. Maximo, and Davi A. Santos. Cooperative threat engagement using drone swarms. IEEE Access, 11:9529–9546, 2023. [3] Luiz Giacomossi, Marcos R. O. A. Maximo, Nils Sundelius, Peter Funk, José F. B. Brancalion, and Rickard Sohlberg. Cooperative search and rescue with drone swarm. In International Congress and Workshop on Industrial AI and eMaintenance 2023, pages 381–393, Cham, 2024. Springer Nature Switzerland. [4] Vemema Kangunde, Rodrigo S Jamisola Jr, and Emmanuel K Theophilus. A review on drones controlled in real-time. International journal of dynamics and control, 9(4):1832–1846, 2021. [5] Alan Carvalho, Cláudio Machado, and Fabiano Moraes. Raspberry pi performance analysis in realtime applications with the rt-preempt patch. In 2019 Latin American Robotics Symposium (LARS), pages 162–167, 2019. [6] Jorge A. Ricardo Jr and Davi A. Santos. Smooth second-order sliding mode control for fully actuated multirotor aerial vehicles. ISA Transactions, 129:169– 178, 2022. [7] Ramón Rico, Javier Rico-Azagra, and Montserrat Gil-Martínez. Hardware and rtos design of a flight controller for professional applications. IEEE Access, 10:134870–134883, 2022. [8] Federico Reghenzani, Giuseppe Massari, and William Fornaciari. The real-time linux kernel: A survey on preempt_rt. ACM Comput. Surv., 52(1), February 2019. [9] Wojciech Giernacki, Mateusz Skwierczyński, Wojciech Witwicki, Paweł Wroński, and Piotr Kozierski. Crazyflie 2.0 quadrotor as a platform for research and education in robotics and control engineering. In 2017 22nd international conference on methods and models in automation and robotics (MMAR), pages 37–42. IEEE, 2017. [10] Samir Bouabdallah. Design and control of quadrotors with application to autonomous flying. PhD thesis, École Polytechnique Fédérale de Lausanne, 2007. 9