标签：#dds

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

Building a High-Performance Robot Communication System with DDS Modern robots may have dozens of processes distributed across CPUs, edge computers, and embedded devices. ROS 2 uses DDS (Data Distribution Service) as its underlying communication technology. Understanding DDS helps you design robot systems that remain responsive as message traffic grows. The Communication Model Instead of connecting every process directly: Camera ---> Perception LiDAR ---> Perception IMU ---> Localization | v Planning | v Control ROS 2 nodes communicate through DDS topics and discovery. A simplified model is: Publisher | v DDS DataWriter | v Topic | v DDS DataReader | v Subscriber Why DDS Is Useful for Robotics DDS provides mechanisms for: Discovery Reliability Durability Deadline management History Resource limits Data delivery policies These features are important because different robot data has different requirements. A camera stream may prioritize low latency. A configuration message may prioritize reliability. High-Performance Design Avoid treating every topic identically. For example: Data Typical Priority Camera frames Low latency LiDAR scans High throughput IMU Low latency Robot commands Reliability Configuration Reliability + durability Diagnostics Reliability Reduce Copying Large sensor messages can consume substantial CPU and memory bandwidth. Good practices include: Avoid unnecessary serialization/deserialization. Reuse buffers where possible. Keep image resolution appropriate for the workload. Compress only when bandwidth savings justify CPU cost. Separate high-rate sensor topics from low-rate metadata. Separate Data Paths A useful architecture is: +--> Vision Camera ----------+ | LiDAR -----------+--> Perception --> Planning --> Control | IMU -------------+ Diagnostics ---------------------> Monitoring Configuration ------------------> Lifecycle Manager Not all traffic needs the same QoS or processing path. Measuring Performance Do not optimize based on intuition alone.