{
  "id": 4695447,
  "title": "ROS 2 QoS Profiles: Reliable vs Best-Effort Robot Communication",
  "url": "https://urgent.news/2026/08/31/ros-2-qos-profiles-reliable-vs-best-effort-robot-communication",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-31T18:52:21.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/vmodal_ai/ros-2-qos-profiles-reliable-vs-best-effort-robot-communication-1cph"
  },
  "original_language": "en",
  "account": "Robot systems require constant data exchange with varying needs. Dropped camera frames are usually fine, but missing emergency commands may not be. ROS 2 Quality of Service (QoS) allows expressing these needs. There are two primary reliability modes: Reliable and Best Effort.\n\nReliable communication strives to ensure samples reach compatible subscribers. It's useful for commands, configuration, important state transitions, and critical application data. On the other hand, Best Effort prioritizes timely delivery and might tolerate lost samples. Best suited for camera frames, LiDAR, high-frequency IMU streams, and other continuously refreshed sensor data.\n\nConsider a camera capturing 30 frames per second. Losing frame 100 might still allow processing frame 101. However, for a command like MOVE_FORWARD, losing the message can be unacceptable. Hence, a camera would typically use Best Effort, while a command would use Reliable.\n\nQoS (Quality of Service) settings in ROS 2 encompass more than just reliability. Other important policies include durability, history, depth, deadline, lifespan, and liveliness. The following C++ example demonstrates setting sensor data QoS:\n\nauto sensor_qos = rclcpp::SensorDataQoS();\nauto publisher = create_publisher <sensor_msgs::msg::Image> (\"/camera/image\", sensor_qos);\n\nFor important application data, you could explicitly configure reliable communication:\n\nauto qos = rclcpp::QoS (rclcpp::KeepLast (10)). reliable();\nauto publisher = create_publisher <std_msgs::msg::String> (\"/robot/status\", qos);\n\nFor a publisher and subscriber to communicate effectively, they must have compatible QoS settings. A frequent error is using Best Effort on the publisher and Reliable on the subscriber, or vice versa, causing message loss. Always verify the effective QoS on both ends.\n\nRemember, a publisher and subscriber need to have matching QoS settings. Starting points for QoS settings include:\n\n- Camera image: Best Effort\n- Point cloud: Best Effort\n- IMU: Best Effort\n- Navigation command: Reliable\n- Robot state: Reliable\n- Diagnostics: Reliable\n\nThese are starting points, not strict rules. Debugging QoS involves checking topic existence, QoS, reliability, durability, history/depth, network discovery, and testing with a compatible subscriber. QoS is a crucial part of the application contract. It should be treated as an architectural decision rather than a random setting when communication fails.",
  "summary": "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…",
  "key_points": [
    "Reliable QoS ensures samples reach compatible subscribers, ideal for commands and critical data.",
    "Best Effort QoS prioritizes timely delivery, suitable for sensor data like camera frames and LiDAR.",
    "Proper QoS matching between publisher and subscriber is crucial to avoid message loss."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}