arxiv: 2604.19275 · v1 · submitted 2026-04-21 · 📡 eess.SY · cs.OS· cs.RO· cs.SY

Recognition: unknown

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

Luiz Giacomossi , H{\aa}kan Forsberg , Ivan Tomasic , Baran \c{C}\"ur\"ukl\"u , Tommaso Cucinotta

Authors on Pith no claims yet

Pith reviewed 2026-05-10 02:09 UTC · model grok-4.3

classification 📡 eess.SY cs.OScs.ROcs.SY

keywords real-time LinuxPREEMPT_RTUAV flight controlRaspberry Pi 5scheduling latencymulti-core SoCmemory contentionSoftIRQ

0 comments

The pith

PREEMPT_RT Linux reduces worst-case latency for 250 Hz UAV control from over 9 ms to under 225 microseconds on Raspberry Pi 5.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper tests whether the PREEMPT_RT patch set can make a standard Linux kernel reliable enough to run both high-level autonomy and low-level flight control on the same multi-core chip inside a UAV. It measures a 250 Hz control loop under heavy stress on a Raspberry Pi 5 and compares the standard kernel to the real-time version. The real-time kernel cuts the longest observed delay by nearly 88 percent by forcing a direct wake-up path that avoids deferred kernel work. This matters because modern UAV designs want to eliminate separate microcontrollers for the safety-critical loops. The work shows that once operating-system noise is removed, the remaining timing variation comes from shared hardware resources on the chip.

Core claim

The analysis shows that the standard Linux kernel on Raspberry Pi 5 produces worst-case latencies exceeding 9 ms for a 250 Hz control loop under heavy stress, rendering it unsuitable for UAV flight control. In contrast, the PREEMPT_RT kernel reduces this latency by nearly 88 percent to under 225 microseconds by enforcing a direct wake-up path that bypasses SoftIRQ deferred execution and mitigates OS noise. The paper concludes that while PREEMPT_RT resolves scheduling variance, the residual jitter on modern multi-core SoCs is primarily driven by hardware memory contention.

What carries the argument

PREEMPT_RT's direct kernel-thread wake-up path that avoids SoftIRQ deferred execution, used to isolate hardware memory contention as the remaining source of jitter.

Load-bearing premise

The chosen heavy stress workloads and latency measurement approach on the Raspberry Pi 5 accurately represent real UAV flight control conditions and isolate the claimed causes without unaccounted hardware or software confounders.

What would settle it

Repeated measurements of the 250 Hz loop on the Raspberry Pi 5 with PREEMPT_RT that show worst-case latencies consistently above 225 microseconds under the heavy stress workloads would falsify the reported reduction and the attribution to hardware contention.

Figures

Figures reproduced from arXiv: 2604.19275 by Baran \c{C}\"ur\"ukl\"u, H{\aa}kan Forsberg, Ivan Tomasic, Luiz Giacomossi, Tommaso Cucinotta.

**Figure 1.** Figure 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. Control Allocator Position Controller Attitude Controller F rr ψr r , v α , ωb τr ωi ∀i ∈ {1, 2, 3, 4} UAV [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗

**Figure 2.** Figure 2: Box plots comparing scheduling latency on the [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 3.** 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). 0 2000 4000 6000 8000 10000 Iteration 5 10 25 50 100 1000 L a t e n c y ( 7 s ) Latency for Scheduler: SCHED RR p50 Stress No Stress 0 2000 4000 6000 8000 10000 Iteration … view at source ↗

**Figure 6.** 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). 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 contras… view at source ↗

**Figure 7.** 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). 0 2000 4000 6000 8000 10000 Iteration 5 10 25 50 100 L a t e n c y ( 7 s ) Latency for Scheduler: SCHED FIFO p50 Stress No Stress 0 2000 4000 6000 8000 10000 Iteration 5 … view at source ↗

**Figure 8.** 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. The traces also revealed a secondary effect: the computational execution time of the control algorithm itself (excluding scheduling delay) increased from ≈ 3.8 µs … view at source ↗

read the original abstract

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 percent to under 225 microseconds, 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

The paper gives useful Pi 5 latency numbers for PREEMPT_RT in UAV control but falls short on methods and causal evidence for the jitter source.

read the letter

This paper reports that PREEMPT_RT Linux on the Raspberry Pi 5 brings worst-case latency for a 250 Hz UAV flight control loop down from over 9 ms to under 225 microseconds under heavy stress, an 88% reduction. It attributes the remaining jitter mainly to hardware memory contention after the RT kernel removes scheduling variance. What stands out is the concrete platform data. Measuring the impact of direct wake-up paths versus SoftIRQs on this specific SoC and frequency gives engineers a data point they can compare against their own setups. The choice of Raspberry Pi 5 is timely as more people look at commodity hardware for UAVs. The soft spots are in the execution. No details on how latencies were measured, how many samples, what the stress workloads included, or any statistical summary. That leaves the headline numbers hard to evaluate. The memory contention conclusion also lacks support from targeted experiments. The abstract mentions heavy stress but does not describe controls that would rule out other SoC effects like interconnect contention or DMA activity. The stress-test note is on target here. This is the kind of paper that might interest embedded systems people working on real-time Linux for drones. A reader looking for numbers on Pi 5 viability would find it relevant, though they would want the full methods section before relying on it. I would recommend sending it to peer review. The core measurement is worth a referee's time to check the setup and see if the jitter analysis can be strengthened. It is not groundbreaking but it is a solid incremental report if the details hold up.

Referee Report

2 major / 1 minor

Summary. The paper analyzes scheduling performance of the PREEMPT_RT Linux kernel versus the standard kernel on a Raspberry Pi 5 for 250 Hz UAV flight control workloads. Under heavy stress, it reports that the standard kernel exhibits worst-case latencies exceeding 9 ms while PREEMPT_RT reduces this by nearly 88% to under 225 μs via direct wake-up paths that mitigate OS noise; the residual jitter is attributed primarily to hardware memory contention on modern SoCs.

Significance. If the measurements hold, the results would offer practical value for real-time embedded control on multi-core SoCs, showing that PREEMPT_RT can make GPOS viable for UAV flight loops but that hardware contention remains the limiting factor. The direct empirical approach (latency traces under stress) is a strength as it supplies concrete, falsifiable numbers rather than fitted models.

major comments (2)

[Abstract] Abstract: the central quantitative claims (88% reduction, 225 μs bound, 9 ms baseline) are stated without any accompanying description of measurement methodology, number of trials, data exclusion rules, timing source, or how the 250 Hz loop and stress workloads were implemented. This prevents verification of the performance numbers that support the entire contribution.
[Abstract] Abstract and concluding discussion: the claim that 'residual jitter on modern SoCs is primarily driven by hardware memory contention' is presented as a finding, yet the manuscript supplies no differential experiments (cache partitioning, DRAM bandwidth saturation versus CPU-only stress, or hardware performance counter data) that isolate memory contention from other SoC factors such as interconnect contention, DMA, or thermal throttling.

minor comments (1)

[Abstract] The abstract refers to 'heavy stress workloads' without specifying their composition or intensity; a brief table or paragraph in the experimental section would improve reproducibility.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed comments. We address each major comment point-by-point below, indicating planned revisions to the manuscript where appropriate.

read point-by-point responses

Referee: [Abstract] Abstract: the central quantitative claims (88% reduction, 225 μs bound, 9 ms baseline) are stated without any accompanying description of measurement methodology, number of trials, data exclusion rules, timing source, or how the 250 Hz loop and stress workloads were implemented. This prevents verification of the performance numbers that support the entire contribution.

Authors: The full experimental methodology—including latency measurement via cyclictest with CLOCK_MONOTONIC, the 250 Hz periodic task implementation, stress workloads (stress-ng for CPU/memory/I/O contention), sample count (>10^6 iterations), and worst-case analysis—is detailed in Sections 3 (Experimental Setup) and 4 (Results). To make the abstract more self-contained and address verification concerns, we will add a concise clause describing the measurement approach and stress conditions. revision: yes
Referee: [Abstract] Abstract and concluding discussion: the claim that 'residual jitter on modern SoCs is primarily driven by hardware memory contention' is presented as a finding, yet the manuscript supplies no differential experiments (cache partitioning, DRAM bandwidth saturation versus CPU-only stress, or hardware performance counter data) that isolate memory contention from other SoC factors such as interconnect contention, DMA, or thermal throttling.

Authors: We agree the manuscript lacks dedicated isolation experiments. The attribution is an inference drawn from the elimination of OS noise by PREEMPT_RT (leaving variability correlated with memory stress) plus known Raspberry Pi 5 SoC characteristics. We will revise the abstract and discussion to present this as a hypothesized primary source supported by the results and literature, rather than a definitively isolated conclusion, and note it as an avenue for future work involving performance counters. revision: partial

Circularity Check

0 steps flagged

No circularity: purely empirical latency measurements

full rationale

The paper reports direct experimental results from running 250 Hz control loops and heavy stress workloads on Raspberry Pi 5 hardware under standard and PREEMPT_RT kernels. No equations, derivations, fitted parameters, or predictions appear in the provided text or abstract; claims about latency reduction (88% to <225 µs) and residual jitter sources are inferences from measured traces rather than any self-referential reduction or self-citation chain. The analysis is self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests entirely on experimental observations under unspecified stress conditions; no free parameters, mathematical axioms, or invented entities are introduced.

axioms (1)

domain assumption The applied stress workloads and latency measurement method on Raspberry Pi 5 accurately reflect UAV flight control timing requirements and isolate OS versus hardware effects.
Invoked implicitly to interpret the 88% improvement and residual jitter attribution.

pith-pipeline@v0.9.0 · 5493 in / 1226 out tokens · 34230 ms · 2026-05-10T02:09:52.268081+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

22 extracted references

[1]

State-of-the-art and future research chal- lenges in uav swarms.IEEE Internet of Things Jour- nal, 11(11), 2024

Sadaf Javed, Ali Hassan, Rizwan Ahmad, Waqas Ahmed, Rehan Ahmed, Ahsan Saadat, and Mohsen Guizani. State-of-the-art and future research chal- lenges in uav swarms.IEEE Internet of Things Jour- nal, 11(11), 2024

2024
[2]

Ricardo, Luiz Giacomossi, João F

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

2023
[3]

Luiz Giacomossi, Marcos R. O. A. Maximo, Nils Sun- delius, Peter Funk, José F. B. Brancalion, and Rickard Sohlberg. Cooperative search and rescue with drone swarm. InInternational Congress and Workshop on Industrial AI and eMaintenance 2023, pages 381–393, Cham, 2024. Springer Nature Switzerland

2023
[4]

A review on drones controlled in real-time.International journal of dynamics and control, 9(4):1832–1846, 2021

Vemema Kangunde, Rodrigo S Jamisola Jr, and Em- manuel K Theophilus. A review on drones controlled in real-time.International journal of dynamics and control, 9(4):1832–1846, 2021

2021
[5]

Raspberry pi performance analysis in real- time applications with the rt-preempt patch

Alan Carvalho, Cláudio Machado, and Fabiano Moraes. Raspberry pi performance analysis in real- time applications with the rt-preempt patch. In2019 Latin American Robotics Symposium (LARS), pages 162–167, 2019

2019
[6]

Ricardo Jr and Davi A

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

2022
[7]

Hardware and rtos design of a flight controller for professional applications.IEEE Access, 10:134870–134883, 2022

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

2022
[8]

The real-time linux kernel: A survey on preempt_rt.ACM Comput

Federico Reghenzani, Giuseppe Massari, and William Fornaciari. The real-time linux kernel: A survey on preempt_rt.ACM Comput. Surv., 52(1), February 2019

2019
[9]

Crazyflie 2.0 quadrotor as a platform for research and education in robotics and control engineering

Wojciech Giernacki, Mateusz Skwierczy ´nski, Woj- ciech Witwicki, Paweł Wro´nski, 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

2017
[10]

PhD thesis, École Polytechnique Fédérale de Lausanne, 2007

Samir Bouabdallah.Design and control of quadrotors with application to autonomous flying. PhD thesis, École Polytechnique Fédérale de Lausanne, 2007

2007
[11]

Princeton university press, 2012

Randal W Beard and Timothy W McLain.Small unmanned aircraft: Theory and practice. Princeton university press, 2012

2012
[12]

Effect of sampling jitter and control jitter on positioning error in motion control systems.Precision Engineering, 36(2):175– 192, 2012

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

2012
[13]

Px4: A node-based multithreaded open source robotics framework for deeply embedded platforms

Lorenz Meier, Dominik Honegger, and Marc Polle- feys. Px4: A node-based multithreaded open source robotics framework for deeply embedded platforms. In2015 IEEE International Conference on Robotics and Automation (ICRA), pages 6235–6240, 2015

2015
[14]

Design of automatic search and rescue uav based on jetson nano combined with px4 pixhawk flight controller and color recognition technology

Xuanyao Qu, Ying Wei, Yonghan Liu, and Xuan- guang 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

2024
[15]

Flying penguins: Building and evaluating the viability of a linux-based drone, 2016

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

2016
[16]

Rai, and Soon Ju Kang

Won Eui Hong, Jae Shin Lee, L. Rai, and Soon Ju Kang. Rt-linux based hard real-time software archi- tecture for unmanned autonomous helicopters. In 11th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA’05), pages 555–558, 2005

2005
[17]

Pearson Education, 2010

Robert Love.Linux kernel development. Pearson Education, 2010

2010
[18]

How fast is fast enough? choosing between xenomai and linux for real-time applications

Jeremy H Brown and Brad Martin. How fast is fast enough? choosing between xenomai and linux for real-time applications. InProceedings of the 12th Real-Time Linux Workshop (RTLWS), pages 1–17, 2010

2010
[19]

Obtaining hard real-time performance and rich linux features in a compounded real-time operating system by a parti- tioning hypervisor

Chung-Fan Yang and Yasushi Shinjo. Obtaining hard real-time performance and rich linux features in a compounded real-time operating system by a parti- tioning hypervisor. InProceedings of the 16th ACM SIGPLAN/SIGOPS International Conference on Vir- tual Execution Environments, pages 59–72, 2020

2020
[20]

Real-time performance and re- sponse latency measurements of linux kernels on single-board computers.Computers, 10(5):64, 2021

George K Adam. Real-time performance and re- sponse latency measurements of linux kernels on single-board computers.Computers, 10(5):64, 2021

2021
[21]

Slow and steady: Measuring and tuning multicore interference

Dan Iorga, Tyler Sorensen, John Wickerson, and Alas- tair F Donaldson. Slow and steady: Measuring and tuning multicore interference. In2020 IEEE Real- Time and Embedded Technology and Applications Symposium (RTAS), pages 1–13. IEEE, 2020

2020
[22]

Luiz Giacomossi, Angelo Caregnato-Neto, and Mar- cos R. O. A. Maximo. Optimization of force and torque bounds for the flight control system of a quad- copter using pso. In2022 Latin American Robotics Symposium (LARS), pages 1–6, 2022. 9

2022