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

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.

Reliable 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.

Consider 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.

QoS (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:

auto sensor_qos = rclcpp::SensorDataQoS();

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

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

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

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

For 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.

Remember, a publisher and subscriber need to have matching QoS settings. Starting points for QoS settings include:

- Camera image: Best Effort

- Point cloud: Best Effort

- IMU: Best Effort

- Navigation command: Reliable

- Robot state: Reliable

- Diagnostics: Reliable

These 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.