A first look at ROS 2 applications written in asynchronous Rust

Martin \v{S}koudlil; Michal Sojka; Zden\v{e}k Hanz\'alek

REVIEW 3 major objections 5 minor 16 references

A first look at ROS 2 applications written in asynchronous Rust

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read ROS 2 applications written in asynchronous Rust can achieve bounded, analyzable response times if sampling and callback execution are separated into high- and lower-priority threads.

desk verdict A solid first look at R2R's async execution model and a sensible real-time structure, but the bounded-response-time claim is conditional on fixing fixed-capacity channel drops and on reporting worst-case statistics rather than 99th percentiles. read the letter →

arxiv 2505.21323 v3 pith:XTY2655W submitted 2025-05-27 cs.SE

Martin Škoudlil , Michal Sojka , Zdeněk Hanzálek This is my paper

classification cs.SE

keywords ROS2RustasynchronousprogrammingR2Rreal-timesystemsresponse-timeanalysisfixed-priorityschedulingfuturesexecutor

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper sets out to show that ROS 2 applications written in asynchronous Rust can be given deterministic real-time behavior if the programmer follows a particular structure. It analyzes the execution model of the R2R client library, where a sampling loop pushes events into per-entity asynchronous channels and an external Rust async runtime executes callbacks, and compares this with C++ ROS 2 executors. The proposed structure runs the sampling loop in the highest-priority thread and executes callbacks in separate lower-priority threads, each running a `futures` local executor. End-to-end latency measurements on a synthetic five-topic workload match the predictions of classical uni-processor response-time analysis, and only this structure and its C++ equivalent meet all deadlines. A three-node autonomous-driving case study shows the same bounded latencies across a multi-node processing chain.

What carries the argument

The load-bearing mechanism is the proposed `futures-rt` application structure: a single main thread at the highest scheduling priority runs `Node::spin_once` in a loop, while each callback (or callback group) runs in its own dedicated OS thread executing a `futures` local executor at a rate-monotonic lower priority. This turns callback execution into ordinary fixed-priority preemptive scheduling on dedicated CPU-bound threads, so the classical uni-processor response-time analysis from the paper's reference [1] predicts the measured end-to-end latencies. The structure also keeps the RMW/DDS middleware threads at the high priority, since they inherit the priority of the thread that creates them.

What would settle it

Publish a burst to a low-priority subscription in the proposed structure so that more than 11 messages arrive in one sampling period before the callback thread runs, then count callback executions against published messages in the LTTng trace; the fixed-capacity channels will drop events and the response-time bound will be violated, showing the bound depends on channel capacity rather than on the thread structure alone.

Watch

Extended reading notes

Core claim

The central claim is that, under the proposed `futures-rt` structure, an R2R node behaves like a set of ordinary fixed-priority tasks rather than like a black-box async runtime, so classical response-time analysis applies unchanged. In R2R, `Node::spin_once` samples all ROS entities for a node and pushes each ready event into a per-entity bounded MPSC channel; the attached async callback wakes when the channel receives a message. The paper's structure gives the sampling thread the highest priority and maps each callback (or callback group) to its own OS thread running a `futures` local executor with priority set in rate-monotonic order. With this layout, measured 99th-percentile end-to-end latencies for a 90%-utilization synthetic workload match the worst-case bounds computed by uni-processor RTA, and the `futures-rt` variant is the only Rust structure, together with the analogous C++ `rclcpp-rt`, that meets all deadlines. The ALKS implementation shows deterministic timing through a chain spanning three nodes, including a heavy 300 ms-period model-predictive controller running in a separate timer thread without disturbing the odometry chain.

Load-bearing premise

The bounded-response-time claim assumes that R2R's fixed-capacity per-entity MPSC channels never fill up; the channels hold only 11 events and silently drop new events when full, so a slow lower-priority callback thread can cause unbounded response time by losing messages.

Editorial extensions

If this is right

An R2R application that follows the proposed structure can be analyzed with classical uni-processor response-time analysis rather than with new executor-specific models.
Only the proposed `futures-rt` structure and its C++ counterpart `rclcpp-rt` met all deadlines in the synthetic 90%-utilization workload; default Rust async runtime configurations missed short deadlines.
Priorities must be ordered so that the sampling thread and the middleware threads it spawns run above all callback threads; reversing or equalizing this order caused callbacks to miss their periods.
The ALKS case study shows the structure preserves deterministic timing across a chain of three nodes even when a model-predictive controller with a long execution time runs concurrently in another thread.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The structure alone does not bound response times for workloads that overflow R2R's fixed 11-slot channels; making channel capacity configurable and dimensioning it with schedulability analysis is a necessary next step, as the paper itself notes.
Once channel capacities are controllable, each subscription can be modeled as a sporadic task with a bounded backlog, which would let existing ROS 2 processing-chain response-time analyses carry over to Rust nodes; this is an extension of the paper's uni-processor result rather than something it proves.
The results suggest that the real-time hazard in async Rust comes from the runtime's scheduling policy, not from the async model itself: the deterministic `futures` local executor on dedicated threads restores predictability that Tokio's work-stealing policy lacks.
For practitioners, the practical implication is that Rust's memory-safety benefits are compatible with hard real-time ROS 2 only if the recommended structure is used and verified against channel overflow; default examples from the R2R documentation do not provide the same guarantee.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Two things to know up front. The paper's real contribution is a careful analysis of R2R's async execution model and a sensible proposal for structuring R2R nodes for real-time work: a high-priority sampling loop feeding dedicated lower-priority futures local executors. The synthetic benchmark is the strongest part. It pins all threads to one isolated CPU, uses SCHED_FIFO with rate-monotonic priorities, and shows futures-rt tracking rclcpp-rt and the classical RTA bound at the 99th percentile. That is real evidence that the proposed structure avoids the irregular scheduling of Tokio and default futures setups.

The second thing is that the headline 'bounded response times' is stronger than the evidence. Section 2.5 states that R2R's per-entity MPSC channels have fixed capacity 11 and that when a channel is full new events are dropped, leading to unbounded response time. Section 3 repeats this and says R2R should be extended to make channel capacity configurable. The proposed structure does not remove that limitation; it only prioritizes the sampling thread, which can push a burst of events faster than a lower-priority callback thread drains them. The experiments do not report drop counts. So the boundedness claim holds only under a no-drop assumption the current implementation does not enforce. This is the load-bearing caveat, and the abstract and conclusion don't carry it.

Three smaller soft spots. First, the match with uni-processor RTA is shown with 99th percentile latencies, not maxima or even 999th; RTA is a worst-case bound, so a percentile comparison demonstrates consistency but not boundedness. Second, the ALKS case study removes warm-up samples and uses histograms; fine for a demonstration, not a guarantee. Third, the Zenodo repository has no commit hash and no one-command reproduction, which makes re-running the experiments harder than it should be. None of these are fatal, and the paper explicitly flags the channel issue, which is honest.

Who this is for: real-time ROS 2 researchers who care about Rust as a future client language, and practitioners wanting a pattern for R2R. It deserves a serious referee. I would send it out, with requests to either fix channel capacity or relabel the central claim as conditional, add drop counters and worst-case statistics, and tighten the reproducibility notes. If those land, the paper's core engineering result will hold.

Referee Report

3 major / 5 minor

Summary. The paper analyzes the execution model of the R2R asynchronous Rust client library for ROS 2 and compares it with the C++ rclcpp execution model. It proposes a structured approach (called futures-rt) in which a high-priority sampling thread calls node.spin_once in a loop while each callback runs in a dedicated lower-priority thread executing a futures local executor, all under SCHED_FIFO on a single isolated CPU. The authors evaluate this structure in a synthetic benchmark with five periodic topics against seven other Rust/C++ variants, and in an autonomous driving case study (ALKS) implemented in R2R. The main claims are that the proposed structure achieves bounded response times for time-critical tasks, that measured response times match classical uni-processor response-time analysis, and that the structure is practically applicable.

Significance. If the claims hold, the paper is a valuable first step toward using Rust's async programming model in real-time ROS 2 applications. The synthetic benchmark is carefully designed and reproducible: all threads are pinned to a single isolated CPU, SCHED_FIFO priorities are set explicitly, LTTng tracing is used, and the RTA prediction is an external parameter-free bound rather than a fit to the measured data. The comparison with C++ rclcpp variants is informative, and the proposed futures-rt structure is shown empirically to meet deadlines while other Rust configurations do not. The source code is provided in supplementary material. The paper's main weakness is that the headline bounded-response-time claim is conditional on a property of the R2R implementation that the paper itself acknowledges is not guaranteed: the per-entity MPSC channels have a fixed capacity and drop messages when full, which would lead to unbounded response times.

major comments (3)

[Section 2.5 and Section 3 (Listing 4)] The central claim that the proposed structure achieves bounded response times is not supported by the current R2R implementation. Section 2.5 states that R2R's per-entity MPSC channels have a fixed capacity of 11 events and that 'new events are dropped, leading to unbounded response time' when a channel is full. Section 3 repeats this caveat and says R2R 'should be extended to make channel capacity configurable.' The proposed futures-rt structure does not remove this limitation: the high-priority sampling thread can push more than 11 events into a channel before a lower-priority callback thread runs, and any overflow silently discards callback invocations. The plotted match with RTA therefore holds only under an implicit no-drop assumption that the implementation does not enforce. To make the claim defensible, the authors should either (a) modify R2R to support configurable channel capacities and dimension them with a schedulability analysis, or (b) explicitly restrict the bounded-response-time claim to workloads with no channel overflow and verify experimentally that no drops occurred, e.g., by counting dropped events. As written, the abstract's statement that the structure 'achieves bounded response times' is too strong.
[Section 4.1.4, Figure 7; Contribution 3] The paper claims that 'the response times of the synthetic application match the theoretical results of a uni-processor response-time analysis' (Contribution 3). This is only partially supported. The RTA model in Section 4.1.4 does not include the execution times of the sampling thread or the RMW/DDS threads, and the paper acknowledges that topic 5, the lowest-priority callback, exhibits latencies above the RTA bound because of those overheads. Since the match with the theoretical bound is a central quantitative contribution, the authors should either incorporate these overheads into the analysis (for example, as highest-priority tasks with measured execution times) or quantify the mismatch and state explicitly that the RTA prediction is a lower-order approximation. Without this, the claim that the results 'match' RTA is not fully demonstrated.
[Section 4.2, Table 3, Figure 10] The ALKS case study is presented as showing that 'deterministic timing is maintained' in a multi-node chain, but the evaluation consists of histograms and observed percentiles without defined deadlines or a formal timing analysis. The text reports that about 99% of odometry-chain latencies are below 0.8 ms and that long MPC executions do not affect the chain, but no deadline or end-to-end response-time bound is specified. To support the determinism claim, the paper should either specify the intended deadlines and show they are met, or soften the claim to 'low and stable observed latencies.' This is a load-bearing point because the ALKS study is used in the abstract and conclusion to support practical applicability.

minor comments (5)

[Section 4.1.4, Figure 7] The text states that 'standard deviations of different runs were calculated and reported in graphs with error bars,' but it is not clear whether the error bars represent the standard deviation of the 99th percentile values across the 10 runs or the standard deviation of individual latencies. Please clarify in the caption or text.
[Table 3] The table labels the 99th percentile of measured execution times as 'WCET,' which is not a worst-case execution time. This is misleading in a real-time systems context; consider renaming the column to 'p99 execution time' or 'observed max (p99)'.
[Section 2.5] The fixed channel capacity of 11 events is mentioned without explanation. A sentence describing why the value 11 was chosen, or noting that it is an implementation constant, would help readers understand the overflow risk.
[Section 4.1.3] The description of the futures-join variant says that all callback tasks are joined and the resulting single task runs in the thread pool, but the relationship between this and the join! macro behavior described in Section 2.2.1.3 and Figure 4 could be made more explicit.
[Section 2.2.1.2] The statement that a task that becomes ready during execution 'is not added to the end of the ready queue but continues executing' is an important behavioral detail of the futures thread-pool executor; a reference to the relevant source code or documentation would strengthen the analysis.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the RTA comparison is an external, falsifiable empirical check and the channel-overflow caveat is a stated limitation, not a circular step.

full rationale

The paper's central claim is empirical: in Section 4.1.4, 99th-percentile end-to-end latencies of the proposed futures-rt structure are compared against a classical uniprocessor response-time bound [1] computed from the Table 2 periods and fixed emulated execution times. This prediction is external and parameter-free relative to the measured latencies; it is not fitted to the data. The paper even reports a discrepancy for topic 5 caused by unmodeled sampling and RMW/DDS overheads, confirming that the comparison is falsifiable rather than tautological. Section 2.6's statement that the C++ response-time analysis of [2] can be applied to R2R 'as is' is an execution-model mapping based on comparing wait-set sampling and callback queues, not a definitional identity, and [2] is independent prior work by other authors. The only self-reference is ref. [19], the first author's master's thesis, cited for tracepoints being submitted to R2R; this is provenance for the instrumentation, not a load-bearing premise of the schedulability argument. The paper itself flags a genuine limitation in Sections 2.5 and 3: R2R's fixed-capacity MPSC channels can overflow, causing dropped messages and 'unbounded response time', and 'R2R should be extended to make channel capacity configurable'. This makes the bounded-response-time claim conditional on a no-drop assumption that the current implementation does not enforce; however, that is a correctness/assumption caveat, not a circular reduction. Nothing in the paper defines the predicted response times in terms of the measured outcomes, imports a uniqueness theorem from the authors' own prior work, or fits a parameter and then relabels it as a prediction. The derivation chain is self-contained against external benchmarks, so no significant circularity is present.

Assumptions & free parameters 0 free parameters · 6 assumptions · 0 invented entities

No fitted parameters or invented entities. The proposed structure is a software configuration using known scheduling theory. Its hidden costs are the assumptions about R2R internals, the futures runtime, DDS thread creation, and channel capacity, listed in axioms.

assumptions (6)

domain assumption R2R's spin_once samples all node entities and pushes at most one event per ready entity into fixed-capacity per-entity MPSC channels, waking subscriptions before timers.
Invoked in Section 2.5 and used by the proposed structure in Section 3; this behavior is tied to the current R2R implementation and could change.
domain assumption DDS and RMW threads created during ROS initialization inherit the SCHED_FIFO priority and policy of the creating thread.
Relied on in Section 3 and Section 4.1.2 to keep DDS threads ahead of callback threads; Figure 8 shows that when this does not hold, deadlines are missed.
domain assumption The futures LocalPool executor schedules ready tasks in FIFO order without starvation and without reordering ready tasks.
Described in Section 2.2.1 and depended on in Section 4.1.3 for the futures-rt variant; it is an implementation property of futures crate v0.3.31, not a language guarantee.
standard math Classical fixed-priority uniprocessor response-time analysis (Audsley et al.) is applicable to the synthetic benchmark.
Used in Section 4.1.4 to compute expected worst-case response times; assumes preemptive fixed-priority scheduling on one CPU with known worst-case execution times and negligible overhead.
domain assumption The fixed-capacity MPSC channels in R2R do not overflow during the reported experiments.
Required for the bounded-response-time claim; Section 3 admits that channel capacity is fixed at 11 and that overflow drops messages, and the experiments avoid overflow via QoS keep-last-100 and the sampling/execution loop.
domain assumption Running benchmark threads on an isolated CPU with pinned affinity prevents interference from other cores and system activity.
Configured in Section 4.1.1 via isolcpus and taskset; the ALKS case study does not use this isolation, so its latency data is less controlled.

how reviews work

0 comments

Cite this review

Pith. "Pith review of A first look at ROS 2 applications written in asynchronous Rust." pith.science (2026). https://pith.science/paper/XTY2655W

@misc{pith2026250521323,
  author       = {Pith},
  title        = {Pith review of: A first look at ROS 2 applications written in asynchronous Rust},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XTY2655W}},
  note         = {Machine review of arXiv:2505.21323}
}

read the original abstract

The increasing popularity of the Rust programming language in building robotic applications using the Robot Operating System (ROS 2) raises questions about its real-time execution capabilities, particularly when employing asynchronous programming. Existing real-time scheduling and response-time analysis techniques for ROS 2 focus on applications written in C++ and do not address the unique execution models and challenges presented by Rust's asynchronous programming paradigm. In this paper, we analyze the execution model of R2R -- an asynchronous Rust ROS 2 bindings and various asynchronous Rust runtimes, comparing them with the execution model of C++ ROS 2 applications. We propose a structured approach for R2R applications aimed at deterministic real-time operation involving thread prioritization and callback-to-thread mapping schemes. Our experimental evaluation based on measuring end-to-end latencies of a synthetic application shows that the proposed approach is effective and outperforms other evaluated configurations. A more complex autonomous driving case study demonstrates its practical applicability. Overall, the experimental results indicate that our proposed structure achieves bounded response times for time-critical tasks. This paves the way for future work to adapt existing or develop new response-time analysis techniques for R2R applications using our structure.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

16 extracted references · 12 canonical work pages

[5]

ieee.org/document/9984791, doi:10.1109/RTSS55097.2022.00013

URL:https://ieeexplore. ieee.org/document/9984791, doi:10.1109/RTSS55097.2022.00013. 11 Tobias Kronauer, Joshwa Pohlmann, Maximilian Matthé, Till Smejkal, and Gerhard Fettweis. Latency Analysis of ROS2 Multi-Node Systems. In2021 IEEE International Conference on Multisensor Fusion and Integration for Intelligent Systems (MFI) , pages 1–7, September

work page arXiv 2022
[6]

doi:10.1109/MFI52462.2021.9591166. 12 G. M. Krukiewicz-Gacek. A Priority-Based Real-Time Scheduling Framework for ROS2. Mas- ter’s thesis, TU Delft,

arXiv 2021
[8]

18 Gerlando Sciangula, Daniel Casini, Alessandro Biondi, Claudio Scordino, and Marco Di Natale

URL:https: //www.sae.org/standards/content/j3016_202104/. 18 Gerlando Sciangula, Daniel Casini, Alessandro Biondi, Claudio Scordino, and Marco Di Natale. Bounding the Data-Delivery Latency of DDS Messages in Real-Time Applications. InDROPS- IDN/v2/Document/10.4230/LIPIcs.ECRTS.2023.9. Schloss-Dagstuhl - Leibniz Zentrum für 22 A first look at ROS 2 applica...

work page doi:10.4230/lipics.ecrts.2023.9
[11]

21 Alberto Soragna

URL: https://ieeexplore.ieee.org/document/10155691, doi:10.1109/RTAS58335.2023.00016. 21 Alberto Soragna. The ROS 2 C++ Executors – General, June

work page arXiv 2023
[12]

ros.org/t/the-ros-2-c-executors/38296

URL:https://discourse. ros.org/t/the-ros-2-c-executors/38296. 22 Yue Tang, Zhiwei Feng, Nan Guan, Xu Jiang, Mingsong Lv, Qingxu Deng, and Wang Yi. Response Time Analysis and Priority Assignment of Processing Chains on ROS2 Executors. In 2020 IEEE Real-Time Systems Symposium (RTSS) , pages 231–243, December

work page 2020
[14]

24 Harun Teper, Daniel Kuhse, Mario Günzel, Georg von der Brüggen, Falk Howar, and Jian-Jia Chen

URL:https://ieeexplore.ieee.org/ document/10568052, doi:10.1109/RTAS61025.2024.00025. 24 Harun Teper, Daniel Kuhse, Mario Günzel, Georg von der Brüggen, Falk Howar, and Jian-Jia Chen. Thread Carefully: Preventing Starvation in the ROS 2 Multithreaded Executor.IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , 43(11):3588–3599,...

work page arXiv 2024
[15]

25 Tokio.rs

URL: https://ieeexplore.ieee.org/document/10745787, doi:10.1109/ TCAD.2024.3446865. 25 Tokio.rs. Multi threaded runtime documentation. URL: https://docs.rs/tokio/1. 43.0/tokio/runtime/index.html#multi-threaded-runtime-behavior-at-the-time-of- writing. 26 UNECE. Uniform provisions concerning the approval of vehicles with regard to Automated Lane Keeping Sy...

work page arXiv 2024
[16]

URL: https://unece.org/transport/documents/ 2023/03/standards/un-regulation-no-157-amend4

work page 2023

Show all 16 references

[1993]

0034, doi:10.1049/sej.1993.0034

URL:https://digital-library.theiet.org/doi/abs/10.1049/sej.1993. 0034, doi:10.1049/sej.1993.0034. M. Škoudlil, M. Sojka and Z. Hanzálek 21 2 Tobias Blaß, Daniel Casini, Sergey Bozhko, and Björn B. Brandenburg. A ROS 2 Response- Time Analysis Exploiting Starvation Freedom and E...

1993
[2019]

URL:http://drops.dagstuhl.de/ opus/volltexte/2019/10743, doi:10.4230/LIPIcs.ECRTS.2019.6

Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik. URL:http://drops.dagstuhl.de/ opus/volltexte/2019/10743, doi:10.4230/LIPIcs.ECRTS.2019.6. 4 Hyunjong Choi, Yecheng Xiang, and Hyoseung Kim. PiCAS: New Design of Priority-Driven Chain-Aware Scheduling for ROS2. In2021 IEEE 27th ...

2019 doi
[2020]

23 Harun Teper, Tobias Betz, Mario Günzel, Dominic Ebner, Georg Von Der Brüggen, Johannes Betz, and Jian-Jia Chen

URL: https://ieeexplore.ieee.org/document/9355523, doi:10.1109/RTSS49844.2020.00030. 23 Harun Teper, Tobias Betz, Mario Günzel, Dominic Ebner, Georg Von Der Brüggen, Johannes Betz, and Jian-Jia Chen. End-To-End Timing Analysis and Optimization of Multi-Executor ROS 2 Systems. ...

2020
[2021]

ieee.org/document/9470466, doi:10.1109/RTAS52030.2021.00028

URL:https://ieeexplore. ieee.org/document/9470466, doi:10.1109/RTAS52030.2021.00028. 5 Martin Dahl. R2R: Easy to use, runtime-agnostic, async Rust bindings for ROS

2021
[2022]

3390/app12115433

URL: https://www.mdpi.com/2076-3417/12/11/5433, doi:10. 3390/app12115433. 7 Alexey Dosovitskiy, German Ros, Felipe Codevilla, Antonio Lopez, and Vladlen Koltun. CARLA: An Open Urban Driving Simulator. InProceedings of the 1st Annual Conference on Robot Learning , pages 1–16. P...
[2023]

ECRTS.2023.9, doi:10.4230/LIPIcs.ECRTS.2023.9

URL: https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs. ECRTS.2023.9, doi:10.4230/LIPIcs.ECRTS.2023.9. 19 Martin Škoudlil. Real-Time schedulability analysis of ROS 2 with nodes using asynchronous Rust. Master’s thesis, Czech Technical University in Prague, January

2023 doi
[2024]

URL: https://web.archive.org/web/20241123211507/https://roscon.ros.org/2024/talks/ The_Multithreaded_Events_Executor.pdf. 14 OMG. Data Distribution Service Specification Version 1.4. URL: https://www.omg.org/ spec/DDS/. 15 Open Robotics. ROS 2 Jazzy, May

2024
[2025]

20 Hoora Sobhani, Hyunjong Choi, and Hyoseung Kim

URL:https: //dspace.cvut.cz/handle/10467/120369. 20 Hoora Sobhani, Hyunjong Choi, and Hyoseung Kim. Timing Analysis and Priority-driven Enhancements of ROS 2 Multi-threaded Executors. In 2023 IEEE 29th Real-Time and Embedded Technology and Applications Symposium (RTAS), pages ...

2023

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [5]

ieee.org/document/9984791, doi:10.1109/RTSS55097.2022.00013

URL:https://ieeexplore. ieee.org/document/9984791, doi:10.1109/RTSS55097.2022.00013. 11 Tobias Kronauer, Joshwa Pohlmann, Maximilian Matthé, Till Smejkal, and Gerhard Fettweis. Latency Analysis of ROS2 Multi-Node Systems. In2021 IEEE International Conference on Multisensor Fusion and Integration for Intelligent Systems (MFI) , pages 1–7, September

work page arXiv 2022

[2] [6]

doi:10.1109/MFI52462.2021.9591166. 12 G. M. Krukiewicz-Gacek. A Priority-Based Real-Time Scheduling Framework for ROS2. Mas- ter’s thesis, TU Delft,

arXiv 2021

[3] [8]

18 Gerlando Sciangula, Daniel Casini, Alessandro Biondi, Claudio Scordino, and Marco Di Natale

URL:https: //www.sae.org/standards/content/j3016_202104/. 18 Gerlando Sciangula, Daniel Casini, Alessandro Biondi, Claudio Scordino, and Marco Di Natale. Bounding the Data-Delivery Latency of DDS Messages in Real-Time Applications. InDROPS- IDN/v2/Document/10.4230/LIPIcs.ECRTS.2023.9. Schloss-Dagstuhl - Leibniz Zentrum für 22 A first look at ROS 2 applica...

work page doi:10.4230/lipics.ecrts.2023.9

[4] [11]

21 Alberto Soragna

URL: https://ieeexplore.ieee.org/document/10155691, doi:10.1109/RTAS58335.2023.00016. 21 Alberto Soragna. The ROS 2 C++ Executors – General, June

work page arXiv 2023

[5] [12]

ros.org/t/the-ros-2-c-executors/38296

URL:https://discourse. ros.org/t/the-ros-2-c-executors/38296. 22 Yue Tang, Zhiwei Feng, Nan Guan, Xu Jiang, Mingsong Lv, Qingxu Deng, and Wang Yi. Response Time Analysis and Priority Assignment of Processing Chains on ROS2 Executors. In 2020 IEEE Real-Time Systems Symposium (RTSS) , pages 231–243, December

work page 2020

[6] [14]

24 Harun Teper, Daniel Kuhse, Mario Günzel, Georg von der Brüggen, Falk Howar, and Jian-Jia Chen

URL:https://ieeexplore.ieee.org/ document/10568052, doi:10.1109/RTAS61025.2024.00025. 24 Harun Teper, Daniel Kuhse, Mario Günzel, Georg von der Brüggen, Falk Howar, and Jian-Jia Chen. Thread Carefully: Preventing Starvation in the ROS 2 Multithreaded Executor.IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , 43(11):3588–3599,...

work page arXiv 2024

[7] [15]

25 Tokio.rs

URL: https://ieeexplore.ieee.org/document/10745787, doi:10.1109/ TCAD.2024.3446865. 25 Tokio.rs. Multi threaded runtime documentation. URL: https://docs.rs/tokio/1. 43.0/tokio/runtime/index.html#multi-threaded-runtime-behavior-at-the-time-of- writing. 26 UNECE. Uniform provisions concerning the approval of vehicles with regard to Automated Lane Keeping Sy...

work page arXiv 2024

[8] [16]

URL: https://unece.org/transport/documents/ 2023/03/standards/un-regulation-no-157-amend4

work page 2023