Quality of Service (QoS)
Quality of Service (QoS) policies allows us to tune communication between nodes.
Setting the right policies can make ROS2 as reliable as TCP or as best-ffort as UDP.
ROS1 primarily supports TCP while ROS2 allows flexibility of underlying DDS transport in environment with lossy wireless networks where "best effort" policy is more suitable.
ROS2 can also be configured in real-time applications where there are strict deadlines.
ROS 2 provides a set of predefined QoS profiles for common use cases (e.g. sensor data). At the same time, developers are given the flexibility to control specific policies of the QoS profiles.
QoS Policies
History
- Keep Last
- Keep All
Keep Last: Only stores the last N messages (defined by Depth).
Keep All: Stores all messages (limited by system resources).
Depth
Integer value
Size of the message queue.
Only applies when History = Keep Last.
Reliability
- Best Effort
- Reliable
Best Effort: May drop messages on weak networks.
Reliable: Ensures all messages are delivered, with retries.
Durability
- Volatile
- Transient Local
Volatile: Only new messages are received.
Transient Local: Subscribers can receive old messages sent before they joined.
Deadline
Duration (e.g., 100ms)
Max allowed time between messages.
If exceeded, a missed deadline is reported.
Lifespan
Duration
Max time a message remains valid after being published. Expired messages are dropped.
Liveliness
- Automatic
- Manual by Topic
Automatic: System manages liveliness when any message is published.
Manual: Publisher must actively signal it is still alive.
Lease Duration
Duration
Time limit for a publisher to assert it is alive. If exceeded, it's considered "not alive."
QoS Profiles
Read more here
Default (Pub/Sub)
Reliable
Volatile
Keep Last
10
System Default
Matches ROS 1 behavior.
Service
Reliable
Volatile
Keep Last
10
System Default
Volatile avoids server getting old requests.
Sensor Data
Best Effort
Volatile
Keep Last
Small (e.g., 5)
System Default
Prioritizes timeliness over reliability.
Parameters
Reliable
Volatile
Keep Last
Large (e.g., 100)
System Default
Large queue to prevent lost requests.
System Default
RMW-dependent
RMW-dependent
RMW-default
RMW-default
RMW-default
Uses underlying middleware’s built-in defaults.
Click here for the specific policies in use for the above profiles. The settings in these profiles are subject to further tweaks, based on the feedback from the community.
QoS Compatibility
All QoS policies must be compatible for a connection to form. If even one is incompatible, no messages will be exchanged.
For more info: click here
Compatibility of reliability QoS policies:
Best Effort
Best Effort
✅ Yes
Both willing to accept lossy delivery.
Best Effort
Reliable
❌ No
Publisher can’t meet reliability.
Reliable
Best Effort
✅ Yes
Publisher offers more than needed.
Reliable
Reliable
✅ Yes
Fully matched.
Durability Compatibility
Volatile
Volatile
✅ Yes
Only new messages
Volatile
Transient Local
❌ No
No communication
Transient Local
Volatile
✅ Yes
Only new messages
Transient Local
Transient Local
✅ Yes
New + previously published
Last updated