Tech & productVerified by Kopik: Official sources reviewed and answers tested by Kopik

ROS 2 QoS compatibility: why a publisher and subscription do not connect

A publisher and a subscription only connect if their Quality of Service profiles are compatible. This page explains the rules from the ROS 2 documentation so you can diagnose silent topics.

Ask your question

Free account required

Each question stands alone Β· 1 free a month, then with a subscription.

Answers are written by a language model solely from this base's documents, with numbered sources. They can be wrong and aren't legal, medical or financial advice: check the sources before any important decision.

The Request vs Offered model

Subscriptions request a minimum quality they are willing to accept, and publishers offer the maximum quality they can provide. A connection is made only if no requested policy is more stringent than the offered one.

For reliability, a best effort publisher and a reliable subscription will never connect, while a reliable publisher works with both kinds of subscription. For durability, a volatile publisher with a transient local subscription gives no communication. The same rules apply to service servers and clients.

Default and predefined profiles

By default, publishers and subscriptions use keep last history with a queue size of 10, reliable delivery, volatile durability and system default liveliness, with deadline, lifespan and lease duration left at default.

The sensor data profile uses best effort reliability and a smaller queue, because timely readings matter more than receiving every sample. Parameters use a much larger queue depth so requests are not lost when, for example, the parameter client cannot reach the parameter service server.

Frequently asked questions

How do I get latched topic behaviour?

Both the publisher and the subscription must use transient local durability. The publisher then keeps samples for late-joining subscriptions, which receive new and old messages.

Can several subscriptions with different QoS share one publisher?

Yes. Multiple subscriptions can connect to one publisher even if their requested profiles differ, and each pair is evaluated independently of other publishers and subscriptions.

Why should services keep volatile durability?

Otherwise a service server that restarts may receive outdated requests. The client is protected from multiple responses, but the server is not protected from side effects of old requests.

What happens to expired messages under the lifespan policy?

Messages older than the lifespan duration are considered stale and are silently dropped, so they are effectively never received.

For developers and agents

Embed / API / MCP

Connect this base to Claude, Cursor, ChatGPT or your own app. Each API or MCP request costs €0.10, charged to your Kopik credit (not charged if nothing is found). You need an API key: create one from your dashboard.

MCP for your agents

This base's MCP server URL (tools ask_base and search_base):

MCP URL
https://kopik.io/api/mcp?base=ros2-robotics-documentation
Claude Code, Cursor and other clients
Claude Code
claude mcp add --transport http kopik-ros2-robotics-documentation "https://kopik.io/api/mcp?base=ros2-robotics-documentation" --header "Authorization: Bearer kpk_…"
JSON config (mcpServers)
{
  "mcpServers": {
    "kopik-ros2-robotics-documentation": {
      "url": "https://kopik.io/api/mcp?base=ros2-robotics-documentation",
      "headers": {
        "Authorization": "Bearer kpk_…"
      }
    }
  }
}

REST API for your apps

mode is "answer" (written answer + sources) or "passages" (raw passages only). Add an optional maxPriceCents to cap the price: if the base costs more, the call is refused and nothing is charged.

curl
curl -X POST https://kopik.io/api/v1/bases/ros2-robotics-documentation/query \
  -H "Authorization: Bearer kpk_…" \
  -H "Content-Type: application/json" \
  -d '{"question": "Your question here", "mode": "answer"}'

Getting started

  1. Create a key in your dashboard and top up your credit.
  2. Replace kpk_… with your key.
  3. Full details (responses, errors, JS and Python examples): developer docs.