ThisCalculator

Everyday

ROS 2 Real-Time Performance: Measure & Compare

Updated · Standard formula, shown below

ROS 2 Real-Time Performance: Measure & Compare

This article explains how to measure and compare real-time performance in ROS 2 robotics systems. You will learn the key metrics, tools, and benchmarking methods used to evaluate latency, jitter, and determinism, and how to interpret results for your specific robot.

Why Real-Time Matters in ROS 2

ROS 2 is designed for robotics, but the default Linux kernel and standard ROS 2 communication are not inherently real-time. Real-time means the system can guarantee that a task (like reading a sensor or sending a motor command) completes within a specified deadline, every time. In ROS 2, this is typically achieved using a real-time kernel (PREEMPT_RT), real-time scheduling policies, and careful configuration of the middleware (DDS). Measuring performance tells you if your system meets its timing requirements and where bottlenecks lie.

Key Metrics: Latency, Jitter, and Throughput

When measuring real-time performance, focus on these metrics:

  • Latency – the time from a trigger (e.g., a sensor reading) to the corresponding action (e.g., a control output). In ROS 2, this includes publisher-to-subscriber delivery time plus any processing time.
  • Jitter – the variation in latency. A system with low average latency but high jitter may miss deadlines occasionally. Jitter is often reported as the standard deviation or the maximum deviation from the mean.
  • Deadline misses – the count of times a task exceeded its allowed time. This is the most direct indicator of real-time failure.
  • Throughput – the number of messages processed per second. While less critical for hard real-time, it matters for high-rate sensors (e.g., LiDAR, cameras).

Tools for Measuring ROS 2 Performance

Several tools are available, both built-in and external:

  • ros2 topic hz – measures the rate of message publication. It gives average and standard deviation of the period, but not end-to-end latency.
  • ros2 topic delay – measures the age of a message when it arrives at a subscriber, relative to the timestamp in the message header. This gives a quick estimate of transport latency.
  • ros2 doctor – checks system health, but not timing.
  • tracetools and ros2_tracing – built-in tracing infrastructure based on LTTng. It can record timestamps for message publication, subscription, and callback execution. This is the most accurate way to measure end-to-end latency and jitter.
  • Performance test – a dedicated ROS 2 package that runs configurable experiments with different message sizes, rates, and QoS settings, reporting latency percentiles and jitter.
  • Cyclictest – a general Linux real-time benchmarking tool that measures the latency of a timer interrupt. It is useful for verifying that the base OS is real-time capable.

How to Run a Benchmark: A Step-by-Step Example

Here is a practical procedure to measure end-to-end latency in a ROS 2 system:

  1. Set up a real-time kernel. For Ubuntu, install the `linux-lowlatency` or `linux-realtime` kernel package and boot into it.
  2. Configure the system for real-time: add `isolcpus` and `nohz_full` kernel parameters, assign CPU affinity, and set RT priorities for your nodes.
  3. Write a simple publisher and subscriber pair. The publisher sends a message with a timestamp in the header. The subscriber records the time of arrival and computes the difference.
  4. Run the nodes with `rtprio` 99 and `chrt` to set SCHED_FIFO. Use `taskset` to pin them to isolated CPUs.
  5. Collect data over a fixed duration (e.g., 60 seconds). Use `ros2 topic delay` or a custom script to log latency values.
  6. Analyze the data: compute mean, standard deviation, maximum, and the 99th percentile. Also count any messages that exceeded your required deadline.

Comparing Performance Across Configurations

When comparing different setups (e.g., different DDS vendors, QoS settings, or kernel patches), keep the following in mind:

  • Run the same benchmark multiple times (at least 5) and report the median and variance. Real-time performance is sensitive to background load.
  • Use the same hardware, kernel, and compiler flags. Differences in CPU frequency scaling (governor) can skew results.
  • Test with realistic message sizes and rates. A 1-byte message at 10 Hz is not representative of a 4K camera stream.
  • Monitor system load: use `top` or `htop` to ensure no other processes are interfering.

Common Pitfalls in Real-Time Measurement

Here are mistakes that often invalidate benchmarks:

  • Not using a real-time kernel. The default kernel has high jitter due to scheduling and interrupt handling.
  • Using `ros2 topic hz` for latency. It only measures publication rate, not delivery time.
  • Ignoring QoS settings. Reliability, durability, and history depth affect latency and jitter.
  • Not pinning processes to CPUs. Context switches and cache misses add unpredictable delays.
  • Forgetting to disable CPU frequency scaling. Use `cpupower frequency-set -g performance`.

Interpreting Results and Setting Requirements

There is no universal “good� latency – it depends on your robot. A quadcopter might need a control loop at 1 kHz with under 1 ms latency, while a mobile robot might tolerate 50 ms. Define your deadline first, then measure. If your system misses deadlines, look at the worst-case (max) latency, not the average. Tools like `ros2_tracing` can show where time is spent – in the DDS layer, in the callback, or in the OS scheduler.

Frequently Asked Questions

What is the difference between latency and jitter?

Latency is the total time taken to get from point A to point B. Jitter is the variation in that time. For example, if a message takes 10 ms, then 12 ms, then 9 ms, the average latency is 10.3 ms and the jitter (standard deviation) is about 1.2 ms. Real-time systems care about both: low latency is useless if jitter is high because deadlines can be missed.

Can I measure real-time performance without a real-time kernel?

You can measure, but the results will reflect the standard kernel’s scheduling behavior, which is not deterministic. To get meaningful real-time metrics, you should use a PREEMPT_RT kernel. Otherwise, you are measuring the wrong thing.

What is the best DDS implementation for real-time?

There is no single “best� – it depends on your hardware, message sizes, and QoS needs. Some DDS implementations are optimized for low latency, others for throughput. The official ROS 2 documentation provides a comparison table, but you should benchmark with your own workload. The `performance_test` package can help.

How do I set real-time priorities for my ROS 2 nodes?

You can set the scheduler policy and priority using `chrt` or by writing a small C++ program that calls `sched_setscheduler()`. For example: `chrt -f -p 99 `. You also need to give the user permission to use RT priorities, usually by adding a `rtprio` limit in `/etc/security/limits.conf`.

Why is my measured latency higher than expected?

Common causes include: CPU frequency scaling, other processes on the same core, DDS discovery traffic, QoS settings (e.g., reliable delivery adds retransmission), and non-optimized code. Use `perf` or `ros2_tracing` to profile where the time goes.

Is ROS 2 real-time performance good enough for safety-critical systems?

ROS 2 itself is not certified for safety-critical applications (like medical or aviation). For those, you would need a certified real-time OS and middleware. However, for many industrial and research robots, ROS 2 with PREEMPT_RT can meet hard real-time requirements if properly configured.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.