A camera publishes a frame. Your perception callback sees it late. The delay could come from serialization, a full queue, transport, or an executor that has not scheduled the callback yet. Those are different problems, even when they appear in the same end-to-end measurement.
Start by identifying the path the message takes. Then measure the expensive part.
What DDS actually is
ROS 2 uses an abstract middleware interface, rmw, between its client libraries and the communication implementation. Fast DDS and Cyclone DDS are DDS implementations. rmw_zenoh is a separate RMW implementation built on Zenoh; it is not a DDS implementation.
DDS provides discovery, publish-subscribe communication, and quality-of-service policies. The selected RMW and its configuration determine which implementation your nodes use. ROS 2 Jazzy documents Fast DDS as its default; a deployment can select another installed RMW. ROS 2 middleware implementations, rmw_zenoh.
The useful question is specific: which RMW, transport, message type, and delivery path are active in this run? “ROS 2 latency” alone does not identify them.
The RTPS wire protocol
DDS implementations commonly exchange network data through DDSI-RTPS, the Real-Time Publish-Subscribe protocol. RTPS carries information that lets endpoints identify writers, order samples, and manage reliable delivery. Its messages can contain data, heartbeats, and acknowledgements.
That wire protocol is only part of the journey. A message can also wait in application or middleware queues before any bytes travel. A local optimized path may avoid work that a network path needs. The ROS 2 DDS design explains the separation between the middleware API, DDS, and RTPS.
CDR serialization: where a copy can enter
On a serialized DDS path, a message is encoded into Common Data Representation (CDR). The receiving side reconstructs the application message. Traversing fields and moving a large image buffer can cost CPU time and memory bandwidth.
The conceptual path looks like this:
publisher message
→ encode a CDR buffer
→ send through the configured transport
→ decode into a subscriber message
→ schedule the subscription callbackCount the copies on your actual path. Loaned samples, data sharing, and intra-process delivery can change it. Fast DDS, for example, documents a zero-copy path that combines application loans with data-sharing delivery for supported types. Its shared-memory transport and data-sharing delivery are distinct mechanisms. Fast DDS zero-copy communication, data-sharing delivery.
A transport using shared memory does not, by itself, prove that the application avoided every copy.
Participant discovery at startup
Before exchanging samples, endpoints need to discover one another. In RTPS SIMPLE discovery, participant discovery establishes which participants are present; endpoint discovery exchanges information about their publishers and subscribers.
Peer configuration, network reachability, and the chosen discovery mechanism affect startup behavior. A topic appearing in the graph is useful evidence, but it does not establish that every expected endpoint has matched or that callbacks are running. Fast DDS SIMPLE discovery.
Keep startup and steady-state measurements separate. Waiting for discovery is a different cost from delivering the next frame after the graph is ready.
QoS mismatches can prevent delivery
A publisher offers a quality of service; a subscriber requests one. The relevant policies must be compatible before that pair exchanges messages.
A best-effort publisher cannot satisfy a reliable subscriber. A reliable publisher can serve a best-effort subscriber. Durability, deadline, and liveliness settings can also prevent a match. ROS 2 documents these requested-versus-offered compatibility rules.
Inspect the endpoint profiles before treating an empty callback as a performance problem:
ros2 topic info /camera/image --verboseA missing connection is different from a slow connection. Incompatibility events and client-library warnings can help distinguish them. For the policies and a diagnostic sequence, see the QoS field guide.
Reliability and backpressure
Reliable delivery adds recovery behavior for missing samples. History limits, resource limits, and a slow reader still matter. Depending on the implementation and delivery mode, a write may block, time out, or encounter a resource limit.
For example, Fast DDS data sharing can block a writer while all reusable sample slots are still held, up to its configured blocking time. A short writer history does not automatically remove this constraint. Data-sharing history and sample reuse.
Choose policies around the workload: whether old samples remain useful, whether loss is acceptable, and how the application responds to overload. Reliable transport is not an acknowledgement that a robot controller has completed an action.
Measure the latency breakdown
Record both the configuration and the endpoints of each measurement. A publish() duration, a transport round trip, and time until the subscription callback starts answer different questions.
| Stage | What to investigate |
|---|---|
| Message preparation | Allocation, image conversion, and copies before publishing |
| Middleware write | Serialization, history insertion, and time spent waiting for resources |
| Transport | The actual network, shared-memory, or data-sharing path |
| Subscriber handling | Deserialization, queue occupancy, and executor scheduling |
| Application work | Time inside the callback and downstream processing |
Change one factor at a time: payload size, subscriber count, CPU load, QoS, or process layout. Keep the others recorded so that a faster result has an explanation.
Our published benchmarks provide measurements with their configurations. Use them to frame a comparison, then profile the graph and timing boundary that matter to your robot.
What zero-copy shared memory changes
A zero-copy exchange lets a publisher and subscriber work with shared payload storage instead of copying the payload between their private buffers. It can reduce data movement on the local path. Ownership, lifetime, capacity, and scheduling still need to be managed.
Support is implementation-specific. Cyclone DDS's documented iceoryx integration has message-type and QoS requirements. Fast DDS has its own loan and data-sharing requirements. Iceoryx2 provides a separate shared-memory IPC model. These are related approaches, not interchangeable configurations. Cyclone DDS shared memory, iceoryx2.
Follow one frame through the system. Establish which path it used, where it waited, and what changed when you adjusted the configuration. That makes the next optimization a testable decision.