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 requiredAnswers 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.
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):
https://kopik.io/api/mcp?base=ros2-robotics-documentationClaude Code, Cursor and other clients
claude mcp add --transport http kopik-ros2-robotics-documentation "https://kopik.io/api/mcp?base=ros2-robotics-documentation" --header "Authorization: Bearer kpk_β¦"{
"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 -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
- Create a key in your dashboard and top up your credit.
- Replace
kpk_β¦with your key. - Full details (responses, errors, JS and Python examples): developer docs.