ROS2 Topic 和 MQTT

相机节点只用 ROS2 Topic 而不用 MQTT这是正确的设计一、先看代码中的实际数据流在 [video_push_node.h#L106-107](file:///d:/city_code/video_push-master/src/video_push/include/video_push/video_push_node.h#L106-L107)rclcpp::Subscriptionsensor_msgs::msg::CompressedImage::SharedPtr main_image_packet_msg_sub_;rclcpp::Subscriptionsensor_msgs::msg::CompressedImage::SharedPtr sec_image_packet_msg_sub_;在 [video_push_node.cpp](file:///d:/city_code/video_push-master/src/video_push/src/video_push_node.cpp) 中视频数据通过 ROS2 回调处理voidVideoPushNode::Callback(Instanceinstance,StreamType stream_type,constsensor_msgs::msg::CompressedImage::SharedPtr msg){// 处理视频帧数据...// 通过 FFmpeg 推送到 RTSP}二、为什么视频数据用 ROS2 Topic 而不是 MQTT2.1 核心原因数据特征完全不同对比项视频流数据MQTT 适合的消息数据量大2-8 Mbps小 1 KB频率高频30 fps低频事件触发实时性要求高延迟 50ms要求较低 300ms可靠性允许丢帧best-effort要求可靠送达QoS 1/2数据类型连续二进制流离散控制指令2.2 详细分析① 数据量对比视频流数据量: - 分辨率: 1920x1080 (Full HD) - 帧率: 30 fps - 编码: H.264 - 码率: 8 Mbps 1 MB/s - 单帧大小: ~35 KB (压缩后) MQTT 消息大小限制: - 协议规范: 最大 256 MB - 实际建议: 1 KB (高效传输) - 控制指令: ~100 bytes如果用 MQTT 传视频帧每帧 35 KB超过 MQTT 推荐的消息大小即使允许大包Broker 转发效率会急剧下降网络带宽被 Broker 内部处理占用② 实时性要求ROS2 (基于 DDS): - 中间件: FastDDS / CycloneDDS - 延迟: 1ms (同机器) - 特点: 专为实时系统设计 MQTT: - 中间件: Broker 转发 - 延迟: 5-10ms (同机器) - 特点: 为物联网低频事件设计视频数据要求帧间隔稳定33ms ± 1msROS2 DDS 能更好地保证这一点。③ 可靠性模式视频流的 QoS 需求: - 允许偶尔丢帧网络抖动时 - 不能积压延迟旧帧无意义 - best-effort 模式 MQTT 的 QoS 模式: - QoS 0: 最多一次类似 best-effort但无顺序保证 - QoS 1: 至少一次可能重复不适合视频 - QoS 2: 恰好一次开销太大不适合高频④ 设计对比使用 ROS2 Topic (当前方案): ┌──────────────┐ Topic ┌──────────────┐ │ 相机捕获节点 │ ──────────► │ 视频推流节点 │ └──────────────┘ └──────────────┘ 优点: 低延迟、高吞吐、专为实时数据流设计 使用 MQTT (假设方案): ┌──────────────┐ Publish ┌──────────────┐ Subscribe ┌──────────────┐ │ 相机捕获节点 │ ─────────► │ MQTT Broker │ ───────────► │ 视频推流节点 │ └──────────────┘ └──────────────┘ └──────────────┘ 缺点: 增加中转延迟、Broker 成为瓶颈、消息大小受限三、两种通信方式的设计定位3.1 ROS2 Topic 设计用于场景示例高频数据流视频帧、激光雷达点云、IMU 数据实时控制关节状态、速度指令同机器节点间所有 ROS2 节点QoS 灵活配置best-effort / reliable3.2 MQTT 设计用于场景示例低频事件消息控制指令、状态上报、告警跨网络通信车端 ↔ 云端多系统集成与 Python/Node.js 后端交互持久化需求断线消息保留四、项目中的实际分工┌─────────────────────────────────────────────────────────────────────┐ │ 远程驾驶系统通信架构 │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ 视频数据通道 (ROS2 Topic) │ │ │ │ │ │ │ │ 相机捕获节点 ──topic──► 视频推流节点 │ │ │ │ (高频、大数据量、实时性要求高) │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ 控制指令通道 (MQTT) │ │ │ │ │ │ │ │ 远程控制节点 ──cmd──► 本地Broker ──cmd──► 视频推流节点 │ │ │ │ (低频、小消息、需要可靠送达) │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ 状态反馈通道 (MQTT) │ │ │ │ │ │ │ │ 视频推流节点 ──status──► 本地Broker ──status──► 控制节点 │ │ │ │ (低频、小消息、需跨系统) │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘五、为什么不统一用一种通信5.1 假设全部用 ROS2 Topic问题: ❌ 控制指令需要跨机器通信车→云ROS2 默认不支持公网 ❌ 云平台用 Python/Node.js 开发与 ROS2 C 生态不兼容 ❌ 状态上报需要持久化ROS2 没有内置持久化机制5.2 假设全部用 MQTT问题: ❌ 视频帧数据太大超过 MQTT 推荐的消息大小 ❌ 30fps 高频数据会让 Broker 成为瓶颈 ❌ MQTT 延迟较高5-10ms不适合实时视频 ❌ QoS 模式不适合视频流best-effort 下可能大量丢帧5.3 混合方案的优势需求选择原因视频数据传输ROS2 Topic低延迟、高吞吐、实时性好控制指令下发MQTT可跨网络、可靠送达、多语言支持状态反馈上报MQTT可跨网络、持久化、易于扩展六、代码中的验证6.1 视频数据通过 ROS2 Topic在video_push_node.cpp中节点通过 ROS2 订阅接收视频数据// 创建 ROS2 订阅者instance.main_image_packet_msg_sub_this-create_subscriptionsensor_msgs::msg::CompressedImage(topic_name,10,// QoS depth 10std::bind(VideoPushNode::Callback,this,std::placeholders::_1,stream_type));6.2 控制指令通过 MQTT在video_push_node.cpp中节点通过 MQTT 接收控制指令// 初始化 MQTT 客户端并订阅控制指令mqtt_client_std::make_sharedmqtt::async_client(...);mqtt_client_-set_callback(mqtt_callback_);mqtt_client_-connect(connOpts)-wait();mqtt_client_-subscribe(/video_stream/cmd,1);// QoS 16.3 状态反馈通过 MQTT// 发布状态消息voidVideoPushNode::PublishStreamStatus(...){mqtt::message_ptr pubmsgmqtt::make_message(topic,jsonString);mqtt_client_-publish(pubmsg);}七、总结问题答案设计合理吗✅ 非常合理为什么视频用 ROS2大数据量、高频、实时性要求为什么控制用 MQTT跨网络、可靠送达、多语言混合通信是最佳实践吗✅ 是充分利用两种中间件的优势一句话总结这是一个混合通信架构的经典示例——用 ROS2 Topic 处理高频大数据量的视频流用 MQTT 处理低频小数据量的控制指令。这种设计充分发挥了两种中间件的优势是远程驾驶系统的最佳实践。