ROS2 QoS Compatibility Starts With What Each Endpoint Offers and Requests

Start with the direction of the endpoint contract

For a robotics-AI feed, identify a particular producer and the subscription meant to consume its samples. This makes the decision concrete: does that producer offer the behavior this consumer requires? A topic-wide label such as reliable data leaves that relationship unspecified.

The Jazzy documentation treats a subscription's request as its acceptance threshold and a publisher's offer as what it can provide. The offer must meet the request. Exact equality is unnecessary.

A QoS profile groups policies. Best-effort reliability attempts delivery while allowing loss; reliable delivery provides a stronger delivery contract and can use retries. These descriptions explain the two reliability choices, without ranking their suitability for every application. The older ROS2 design document supplies this background; the named Jazzy source governs the compatibility comparison here.

References: [ROSJ][ROSD]

RQ-61: two publishers and two subscriptions

RQ-61 is an original fictional relationship example. Publisher P_B offers best effort; publisher P_R offers reliable. Subscription S_R requests reliable; subscription S_B requests best effort. All four endpoints use the same appropriate topic and message type, and every other policy affecting compatibility is stipulated compatible. These are declared premises, with no discovered graph, match observation or received samples supplied.

The four possible publisher-to-subscription pairs yield the comparison below. Read each row as an endpoint relationship, rather than as a packet, a sample or a completed task.

References: [ROSJ]

Three compatible pairs can still omit the required source

Count the compatible relationships in RQ-61: P_B to S_B, P_R to S_R and P_R to S_B. The missing relationship is P_B to S_R. Its request exceeds the behavior that P_B offers. By contrast, P_R's offer is sufficient for S_B's less demanding reliability request.

Now give the comparison a buyer requirement: S_R is intended to receive distinct inputs from both P_B and P_R. The example identifies a specific contract gap for P_B's input. P_R's compatible relationship with S_R supplies no substitute for P_B's distinct samples. The existence of another compatible producer does not repair the missing relationship.

For a different requirement limited to P_R supplying S_R, that same missing pair would fall outside the required source set. The policy facts have not changed; the buyer's required coverage has. This is why a useful proposal names the producers each consumer needs rather than merely counting publishers, subscriptions or compatible pairs.

Three out of four is a count of relationships in this example. Calling it 75% delivery would introduce a sample population, observation period and receipt result that the premises never supplied. It also weights every relationship equally, even though one missing required input could determine whether the intended task has enough information.

References: [ROSJ]

Carry the complete profile into the comparison

Jazzy requires all policies affecting compatibility to pass. A durability mismatch can block otherwise compatible reliability; other endpoint pairs cannot repair the mismatch.

The other-policy premise in RQ-61 matters. If an actual proposal leaves those policies unresolved, the example's three positive rows remain reliability results; they cannot establish three complete profile matches for that proposal. The appointed ROS software owner needs to explain the effective endpoint contracts for the named platform and middleware.

The Jazzy rclpy compatibility documentation adds a useful qualification: system-default or unknown policy values can leave a profile comparison indeterminate and produce a warning. An unspecified value cannot safely be treated as an explicit reliable or best-effort declaration. Ask for the effective policy evidence underlying the conclusion, rather than filling that gap from an assumed default.

References: [ROSJ][RCL]

Network capacity answers a different requirement

Suppose two proposals retain exactly RQ-61's endpoint contracts. One describes a larger network-capacity allowance than the other. That difference provides no change to the requested/offered comparison: the missing P_B-to-S_R contract remains missing. Capacity is not an additional reliability offer from P_B.

Conversely, a compatible pair still leaves the intended workload's capacity and timing requirements to evaluate. The relationship count contains no sample sizes, publication rates, concurrent traffic or processing demand. It therefore yields no throughput, latency or successful-sample estimate.

This separates two useful purchase questions. The endpoint comparison asks whether the stated producer and consumer contracts permit the required relationship. A workload-capacity assessment asks whether the proposed resources can support the intended traffic and timing. Evidence for either question should retain its own assumptions and measured or promised boundary. A larger capacity number cannot serve as the missing endpoint explanation.

Follow the evidence from discovery to completed processing

A declaration of compatible policies describes a possible relationship. Evidence that the endpoints were discovered establishes their visibility in the reported context. It still leaves the actual matching relationship to identify. Jazzy distinguishes matched events, incompatible-QoS events and received-message handling.

A positive match record concerns a connection between identified endpoints at its reported time. To answer whether the required input arrived, the buyer then needs evidence of receipt of the relevant samples by the intended subscription. To answer whether the AI task used them, the evidence must reach the application's accepted input or completed result. The useful record names which source, samples, recipient and observation period it covers.

For example, a later report might document a match and receipt of one sample from P_R by S_R, while supplying no application result. That would add evidence for the P_R path. It would leave P_B's required input unresolved and would leave the documented sample's processing outcome unknown. Counting one observed receipt as one completed inference would add an unsupported outcome.

These are comparisons of claims and evidence. A compatible policy declaration is neither a historical receipt record nor evidence of exactly-once application effects. The example provides no basis for choosing a universal QoS profile or authorizing robot operation.

References: [ROSJ]

Request an explanation that reaches the required consumer

A useful feed proposal connects the required source set, the effective endpoint profiles and the evidence promised for the intended task. Have the appointed software owner explain which publisher-to-subscription relationships support that task, how the full profile comparison was established and what separately demonstrates the required input and application result. Keep the deployed ROS distribution, middleware context and observation period attached to that explanation.

RQ-61 gives three possible dispositions without prescribing a configuration change. A required relationship may fail the stated contract, may remain unresolved because effective policies are missing, or may pass the policy comparison while still needing runtime and application evidence. Treating all three as a generic network-performance question hides the decision the buyer actually needs to make.

Use the related PointCloud2 article for the separate question of field offsets, point strides and row padding inside a supplied message. Use the MQTT article for its own broker and subscriber delivery boundaries. Its subscription-grant arithmetic is a different mechanism and should not be imported into this ROS2 compatibility comparison.

Connect an independent physical cabling requirement to its service

If the selected compute or network equipment also needs physical connections, Leviathan's Structured Cabling & Fiber Installation service provides a route to discuss agreed fiber and copper installation, endpoint labels and connection records. Share a nonconfidential outline of the approved equipment endpoints and routes, specified assemblies, materials responsibilities and required physical handoff through the related project inquiry.

ROS software integration, middleware policy selection and application acceptance remain with their appointed owners. The physical cabling scope is defined by the separate installation requirement.

References: [L1]