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.
Posez votre question
Compte gratuit requisLes réponses sont rédigées par un modèle de langage à partir des seuls documents de cette base, avec leurs sources numérotées. Elles peuvent être inexactes et ne constituent pas un conseil juridique, médical ou financier : vérifiez les sources avant toute décision importante.
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.
Questions fréquentes
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.
Intégrer / API / MCP
Branchez cette base à Claude, Cursor, ChatGPT ou votre propre application. Chaque requête API ou MCP coûte 0,10 €, débitée de votre crédit Kopik (non facturée si rien n'est trouvé). Il vous faut une clé API : créez-la depuis votre tableau de bord.
MCP pour vos agents
Adresse du serveur MCP de cette base (outils ask_base et search_base) :
https://kopik.io/api/mcp?base=ros2-robotics-documentationClaude Code, Cursor et autres 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_…"
}
}
}
}API REST pour vos applications
mode vaut "answer" (réponse rédigée + sources) ou "passages" (passages bruts seulement). Ajoutez un maxPriceCents facultatif pour plafonner le prix : si la base coûte plus cher, l'appel est refusé sans rien débiter.
curl -X POST https://kopik.io/api/v1/bases/ros2-robotics-documentation/query \
-H "Authorization: Bearer kpk_…" \
-H "Content-Type: application/json" \
-d '{"question": "Votre question ici", "mode": "answer"}'Pour commencer
- Créez une clé dans votre tableau de bord et rechargez votre crédit.
- Remplacez
kpk_…par votre clé. - Tout le détail (réponses, erreurs, exemples JS et Python) : documentation développeurs.