Real time does not simply mean fast
In robot control, calling a task real-time does not simply mean that it runs quickly. It means that its result must be available within a deadline that matters to the application. If a control task must read sensors, calculate a response, and update actuators before a particular limit, both its execution time and the variability of that time matter, as does the possibility of missing the deadline. A low average is not enough to demonstrate predictable behavior.
This distinction matters because a task can be fast in most executions and still take too long in others. An average describes typical behavior, but on its own it does not show what happens in the slowest cases or how often they occur. To assess the timing requirement, observe the response in relation to the deadline it must meet; do not simply compare average speeds. The relevant question is whether the task completes in time under the conditions being assessed, not whether it is usually quick.
The specific requirement changes with the function. A supervisory interface may tolerate delays that would be unacceptable in a control loop. Data acquisition, processing, and communication with actuators may also have different deadlines. Before choosing an architecture, therefore, define which task must respond, its deadline, how often it repeats, and the consequence of responding late. Without those requirements, “real time” risks becoming an imprecise label rather than a verifiable criterion. Defining them separately also prevents stages with different functions and timing needs from being treated as equivalent.
What ROS 2 contributes to execution
ROS 2 documentation addresses real-time programming as a matter involving requirements and implementation challenges, not as a property obtained automatically by using the framework. It is therefore useful to distinguish the tools ROS 2 provides from proof that a particular application meets its deadlines. Technical documentation can guide configuration and analysis, but it cannot replace defining the robot’s requirements or testing the chosen implementation.
In particular, the presence of configuration mechanisms should not be taken as a guarantee that a result will arrive within an end-to-end deadline. A data path may include communication, scheduling, processing, and an actuator response; the observed time depends on the path under evaluation and the conditions in which it runs. The right interpretation is conditional: each mechanism must be assessed within a specific configuration and alongside the rest of the application.
When evaluating a configuration, describe which components participate in the relevant path and what timing limit is being checked. This description helps make sense of measurements and avoids attributing the result to a single configuration option. The documentation consulted treats real-time programming as an implementation issue; it does not establish a global guarantee applicable to every robot. A useful assessment therefore keeps the scope of each measurement and conclusion clear.
Executors, callbacks, and scheduling
Executors are part of the ROS 2 execution architecture. Academic research on scheduling processing chains in a multithreaded ROS 2 executor examines scheduling and response time as questions to study in the context of the chain, rather than by measuring the speed of an isolated node alone. This supports the need to evaluate how work is organized and how tasks depend on one another in the specific configuration being considered.
In practical terms, evaluating an executor means looking at how work is organized, not only at how long a function takes when it runs without other tasks. Callback handling is part of the path from an input to a response, so decisions about how work is distributed and executed must be considered together with the rest of that path. The number of threads alone does not describe the entire scheduling behavior; what matters includes how it relates to the tasks the application actually runs.
For a processing chain, the analysis may cover the different stages involved and the relationships between them. The executor structure and dependencies between tasks are part of the system under evaluation. An analysis or experiment associated with one version and configuration should not automatically be transferred to other versions, workloads, or platforms. The cited research addresses a specific multithreaded configuration; it is not a guarantee for all ROS 2 systems.
What lies outside the framework
ROS 2 does not eliminate the influence of the operating system or the platform on which it runs. The project’s documentation on real-time programming presents the topic as a set of requirements and implementation challenges, not as a property enabled simply by using ROS 2. As one specific example, the ROS 2 driver documentation for Universal Robots recommends an Ubuntu system with real-time capabilities for its driver and notes that a low-latency kernel may be sufficient in many of the situations described in that guide. That recommendation applies to that driver and should not be generalized to all robots or applications.
This means that two implementations using ROS 2 need not exhibit the same timing behavior if they differ in platform or workload. Observations must be tied to the conditions under which they were obtained: system components and configuration matter when interpreting a result. Without that information, an isolated figure cannot show whether it represents the conditions the application will face.
It is also not enough to verify that messages arrive or that a demonstration works under controlled conditions. A test should represent the application’s workload and work sequence, record relevant times, and pay attention to slow cases, not only averages. Measure end to end, from the event that starts the work to the response that matters to the robot. If the requirement is safety-critical or mission-critical, performance evidence should form part of a broader assessment of architecture and risk; an isolated performance test is not the same as certification.
A useful check before adopting ROS 2
Start by documenting every deadline: what event starts it, what response satisfies it, how often it recurs, and what margin is available. Then draw the processing chain connecting sensors, nodes, and actuators. For each segment, note the components involved, the work they perform, and their dependencies on other tasks. This description turns a general expectation into questions that can be checked and helps identify whether a delay comes from communication, scheduling, or application work.
The description of each deadline should also clearly distinguish the start of the work from the response considered valid. That precision makes it possible to compare measurements with the corresponding requirement, rather than measuring a different stage for convenience. When there are several stages, preserving their relationship within the chain makes it easier to interpret where time accumulates and avoids confusing a component’s local performance with the complete response the robot needs.
Next, fix the ROS 2 version, middleware, operating system, hardware, and configuration to be evaluated. Test the expected workload and plausible adverse conditions, measure both individual stages and the complete response, and keep the configuration with the results. Repeat tests after significant changes and check any conclusion against the documentation applicable to that version. The goal is not to prove that ROS 2 is “real time” in the abstract, but to determine whether a defined implementation meets defined requirements under documented conditions. The sources consulted support configuration and analysis capabilities, but do not establish a universal guarantee that every robot will meet its deadlines.