ROS 2 QoS Profiles: Reliable vs Best-Effort Robot Communication

Robot systems continuously exchange data with very different requirements. A dropped camera frame is usually acceptable. A dropped emergency command may not be.

ROS 2 Quality of Service (QoS) lets you express these requirements.

The Two Common Reliability Modes

Reliable

Reliable communication attempts to ensure that samples reach compatible subscribers.

Useful for:

• Commands
• Configuration
• Important state transitions
• Critical application data

Best Effort

Best effort prioritizes timely delivery and may tolerate lost samples.

Useful for:

• Cameras
• LiDAR
• High-frequency IMU streams
• Other continuously refreshed sensor data

Example

Imagine a camera producing 30 frames per second.

If frame 100 is lost, the system can often process frame 101 immediately.

For a command:

MOVE_FORWARD

losing the message may be unacceptable.

Therefore:

Camera  -> Best Effort
Command -> Reliable

is often a sensible starting point.

QoS Dimensions

Reliability is only one QoS policy.

Important policies include:

• Reliability
• Durability
• History
• Depth
• Deadline
• Lifespan
• Liveliness

C++ Example

auto sensor_qos =
    rclcpp::SensorDataQoS();

auto publisher =
    create_publisher<sensor_msgs::msg::Image>(
        "/camera/image",
        sensor_qos);

For important application data, you might explicitly configure reliable communication:

auto qos = rclcpp::QoS(rclcpp::KeepLast(10))
    .reliable();

auto publisher =
    create_publisher<std_msgs::msg::String>(
        "/robot/status",
        qos);

QoS Compatibility

A publisher and subscriber need compatible QoS settings.

A common mistake is:

Publisher: Best Effort
Subscriber: Reliable

and then wondering why messages are not received as expected.

Always inspect the effective QoS of both endpoints.

A Practical Decision Table

Topic	Suggested Starting Point
Camera image	Best Effort
Point cloud	Best Effort
IMU	Best Effort
Navigation command	Reliable
Configuration	Reliable
Robot state	Reliable
Diagnostics	Reliable

These are starting points, not universal rules.

Debugging QoS

When a topic appears to have no data:

1. Check that the topic exists.
2. Check publisher/subscriber QoS.
3. Inspect reliability.
4. Inspect durability.
5. Inspect history/depth.
6. Check network discovery.
7. Test with a compatible subscriber.

QoS is part of the application contract. Treat it as an architectural decision rather than a setting to change randomly when communication fails.

Useful Links

• Website: https://www.v-modal.com
• SDK Flutter: https://github.com/v-modal/vmodal_sdk_flutter
• SDK Android: https://github.com/v-modal/vmodal_sdk_android
• Discord: https://discord.gg/K72z28KU