M7-T8 — Real-Time Performance and Resource Constraints

Learning objectives

After this lesson, you should be able to:

• Compute the utilisation of a processing node from its compute time and the message period, and explain why p99 matters.
• Estimate message bandwidth and map memory and relate them to the budget.
• Use ros2 topic hz, bw and delay and system tools to find the bottleneck.
• Apply the main levers: throttling, resolution, range limits, window sizes, QoS and DDS settings, and process placement.

The problem and the intuition

A cashier who takes 60 seconds per customer, with a customer arriving every 100 seconds, has plenty of slack. If customers arrive every 50 seconds, the queue lengthens without end. A SLAM node is the cashier and the scans are the customers. If the node needs 60 ms per scan and scans arrive every 100 ms, it is idle 40% of the time; any hiccup (a long loop-closure search, a garbage collection, another process starting) is absorbed. If it needs 120 ms, every scan waits longer than the last, the oldest data is discarded, and the transform published for the map is based on stale information.

What matters is the tail, not the average. A node with a mean of 60 ms but a 99th percentile of 250 ms drops one scan in a hundred and, since loop closures and map updates are exactly the heavy operations, the drops come at the worst moments.

Budget for the worst 1%, not the mean. Utilisation near 1 means unbounded delay; keep it below about 0.7.

The budget and the levers

Problem. Keep a SLAM and navigation stack within the CPU, memory, bandwidth and latency limits of the robot’s computer, with enough headroom for peaks, while keeping the map quality that the task needs.

Assumptions. Sensor rates are fixed by hardware; the computer has a known number of cores and memory; the workload varies with the environment (large open spaces and long loops are heavier); other processes (perception, drivers, logging) share the machine.

The quantities

For ρ well below 1, delay is the compute time plus a small queueing wait; as ρ approaches 1 the wait diverges (the standard single-queue result: mean wait ∝ ρ / (1 − ρ)). Budget with the 99th percentile of the compute time, because that decides the worst delay.

Measuring

Levers, from cheapest to most invasive

• Throttle the input. SLAM Toolbox throttle_scans: 2 processes every second scan, halving the load. Scan matching does not need 10 Hz at walking speed.
• Reduce what is computed per scan. A lower max_laser_range (do not exceed the useful range), a larger minimum_travel_distance (fewer keyframes), a smaller correlation search window.
• Reduce the map cost. Raising resolution from 0.05 to 0.1 m cuts cell count by four; raising map_update_interval reduces how often the full map is built and published.
• Use async mode so that the latest scan is processed and older ones are skipped, instead of a growing queue.
• Choose QoS for sensors as best effort with a small depth, so that a slow consumer drops old data rather than accumulating it.
• Place nodes sensibly. Keep high-bandwidth data (3D point clouds, images) on the robot; use intra-process composition where possible; send only maps, paths and status over the network. Consider shared-memory transports in Fast DDS or Cyclone DDS for large local messages.
• Isolate the work. Pin critical nodes to cores, lower the priority of logging and visualisation, and run RViz on a workstation, not on the robot.
• Change the hardware or the algorithm only after the above: a faster computer, or a lighter SLAM (fewer keyframes, 2D rather than 3D).

ρ

utilisation: fraction of time a node is busy handling messages.

p99

99th percentile of a measured quantity (the value exceeded 1% of the time).

composition

running several nodes in one process so that messages are passed by pointer (intra-process communication).

DDS

the data distribution service middleware under ROS 2; vendors (Fast DDS, Cyclone DDS) differ in performance and settings.

Failure modes

A worked example: budgeting a small robot

1. Utilisation. The lidar runs at 10 Hz, a period of 100 ms. SLAM Toolbox’s scan processing takes a mean of 60 ms on the robot’s computer, so ρ = 0.6. The 99th percentile (when a loop closure runs) is 180 ms: sometimes more than the period, so occasionally a scan is skipped. With throttle_scans: 2 the period becomes 200 ms; the mean utilisation falls to 0.3 and the p99 of 180 ms fits within the period.
2. Bandwidth. A 2D scan of 720 beams with ranges and intensities (4 bytes each) is about 5.8 kB, so 58 kB/s at 10 Hz. A 3D lidar of 100 000 points at 16 bytes is 1.6 MB, or 16 MB/s at 10 Hz (128 Mbit/s): too much for typical Wi-Fi. The solution is not to compress harder but to keep the point cloud on the robot.
3. Map memory and traffic. A 100 m × 100 m site at 0.05 m resolution: 2 000 × 2 000 = 4 × 10⁶ cells, 4 MB per map message. Published every 5 s that is 0.8 MB/s, acceptable; at 1 s it is 4 MB/s. At 0.1 m resolution it is 1 MB per message. RViz and the Nav2 static layer both receive it, so double the traffic.
4. Graph growth. A keyframe every 0.5 m over a 5 km patrol is 10 000 keyframes. Each stores a scan (about 5.8 kB for 720 beams) so 58 MB of scans, plus the constraints. The loop-closure search is over a neighbourhood, but the solver cost grows with the graph. Increasing minimum_travel_distance to 1.0 m halves both.
5. Finding the bottleneck. top -H shows one thread of async_slam_toolbox_node at 100% (one core) while the other cores are idle. The solver and scan matching are single-threaded in parts, so a faster core, not more cores, helps; and the remaining load (RViz, rosbag recording) can be moved off. After moving RViz to the workstation, ros2 topic hz /map stabilises at its nominal rate.

Engineering implications and limitations

Engineering implications

• Benchmark on the target computer under the real load, with all nodes running, in the largest environment, and record p50, p95 and p99 compute times.
• Leave headroom, aiming for utilisation under about 0.7 at p99 to absorb peaks and variation between environments.
• Monitor in operation: log CPU, memory, topic rates, queue drops and scan-to-TF delay; alert when they drift.
• Prefer simple fixes first: throttle, resolution, range, keyframe spacing and process placement, before a code change.
• Mind thermal throttling and power modes on embedded boards; benchmarks on a cool, plugged-in board overstate the performance.
• Keep a degraded mode. If the system detects overload, reduce the scan rate or stop adding keyframes rather than letting the queue run away.

Limits

The queueing relation is an approximation: real workloads are bursty and partly multithreaded. Defaults and thread usage depend on the SLAM package, the DDS vendor and the ROS 2 release, and performance on one machine does not transfer to another. Real-time guarantees (hard deadlines) need a real-time kernel and careful design that ordinary ROS 2 nodes on a general-purpose OS do not provide; the goal here is soft real time: bounded delay with good probability.

Common misconceptions

Engineering takeaways

1. Utilisation ρ = compute time ÷ period; delay diverges as ρ → 1, so budget with the p99 and keep headroom.
2. Know the bandwidth and memory of every topic: 2D scans are small, 3D clouds and large maps are not.
3. Measure with ros2 topic hz/bw/delay, top/htop and tracing before changing anything.
4. The cheapest levers are throttling, resolution, range, keyframe spacing, async mode and moving visualisation off the robot.
5. Test on the target computer under full load; plan a degraded mode.

References and further reading

Primary papers and authoritative documentation.

• Maruyama, Y., Kato, S. and Azumi, T. (2016). Exploring the performance of ROS2. ACM International Conference on Embedded Software (EMSOFT).
• Macenski, S., Foote, T., Gerkey, B., Lalancette, C. and Woodall, W. (2022). Robot Operating System 2: Design, architecture, and uses in the wild. Science Robotics 7(66).
• Bédard, C., Lajoie, P.-Y., Beltrame, G. and Dagenais, M. (2022). Message flow analysis with complex causal links for distributed ROS 2 systems. Robotics and Autonomous Systems 161.
• Kleinrock, L. (1975). Queueing Systems, Volume 1: Theory. Wiley.
• Open Robotics. ROS 2 documentation: DDS tuning, Quality of Service, Intra-process communication. docs.ros.org.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

What’s next

That completes the theory of ROS 2 integration. The five labs of this module are real ROS 2 projects that you run on your own machine, not in the browser; each has setup instructions, expected outputs, troubleshooting and evaluation criteria.

Related content

Nothing below is required to finish this lesson.

• Before
  M7-T7: SLAM and Nav2 Integration

  Connect SLAM outputs to Nav2 costmaps and navigation, and know what Nav2 needs from SLAM.

• Lab
  M7-L1: Debug a ROS 2 SLAM Pipeline

  Bring up a SLAM stack in simulation, find why no map appears and verify with the standard introspection tools.