知言的博客

底层通信参考资料

更新于 16分钟阅读

Reference

全文由 Opus 4.6 生成

一、必须了解

1. DDS + QoS

在你工作栈的位置：

  • ROS 2 的底层通信：ROS 2 没有自己的传输层，它的 rclcpp / rclpy 通过 rmw（ROS middleware 抽象层）调用具体 DDS 实现。你用 CycloneDDS 就是选了 rmw_cyclonedds_cpp
  • Unitree SDK2 的底层：G1 的 rt/lowstate、rt/lowcmd、rt/sportmodestate 全是 DDS topic，你用 unitree_sdk2_python 的 ChannelSubscriber 本质就是创建 DDS DataReader
  • Psi0 的三层通信之一：机器人状态流用的就是 DDS
  • Franka 的 franka_ros2：也是 DDS
  • GR00T N1.6 部署：NVIDIA 的示例大量用 ROS 2 topic，背后还是 DDS

官方/权威资料

推荐读物

重点掌握

概念要点你会在哪遇到
DomainParticipant / Topic / DataWriter / DataReader四件套的关系读 Psi0 robot_body.py 时直接对应
Discovery (SPDP + SEDP)为什么 DDS 无 broker：每个 participant multicast 广播自己排查 G1 连不上”能 ping 通但 ddsls 看不到”的问题
QoS 的 Requested ≤ Offered 规则Reader 要求不能比 Writer 承诺更高，否则 matching 失败95% 的”topic 发现了但收不到数据”原因
4 个核心 QoS：Reliability / Durability / History / Deadline见下表宇树 topic 每个都有特定 QoS
ROS 2 的 5 个预定义 QoS Profilesensor_data / reliable / services_default / parameters / system_default写 ROS 2 节点时选 profile
rmw 层ROS 2 ↔ DDS 的适配层切换 CycloneDDS / FastDDS / Connext 的位置
CYCLONEDDS_URI 配置XML 配置文件调 domain、network interface、debug logG1 连接配置每天都在改

4 个核心 QoS（再重复一遍，这个必须背下来）：

QoS选项你机器人栈里的例子
ReliabilityBEST_EFFORT / RELIABLErt/lowstate 500Hz 用 BEST_EFFORT；action 指令用 RELIABLE
DurabilityVOLATILE / TRANSIENT_LOCAL/tf_static、机器人描述用 TRANSIENT_LOCAL（晚订阅也能拿到）
HistoryKEEP_LAST(n) / KEEP_ALL控制环一律 KEEP_LAST(1)，只要最新
Deadline周期时间心跳检测：2ms 没收到 lowstate 就判定掉线

必练的 3 个调试命令：

ddsls -t dcpspublication          # 谁在发什么 topic
ddsls -t dcpsmatchedpublication   # Writer/Reader 有没有配对成功
ros2 topic info /topic_name -v    # ROS 2 视角看 QoS（注意 -v）

加一个 Psi0 专属的调试场景：

# 当 Psi0 policy 发出 lowcmd 但机器人不动时，按这个顺序查：
# 1. policy 进程是不是真的在发
ddsls -t dcpspublication | grep lowcmd
# 2. 机器人侧有没有 Reader 订阅，QoS 是否匹配
ddsls -t dcpsmatchedpublication | grep lowcmd
# 3. 如果前两步都 OK，开 Wireshark filter rtps 看有没有真的发出去
# 4. 如果都有，那问题在机器人控制板没接收 —— 超出 DDS 范畴

不用深入：OMG 规范全文、22 个 QoS 全部、自己实现 DDS、DDS-Security（除非做产品化部署）。

预估时间：4 小时（和你之前提的 4 小时规划一致）。

2. gRPC + Protocol Buffers

在你工作栈的位置：

  • π0 / π0.5 policy server 的主流部署方式：Physical Intelligence 的 openpi 仓库里 server 端就是 gRPC/WebSocket 混合
  • NVIDIA GR00T 的 inference endpoint：官方 Isaac Lab 和 GR00T 的 deployment 用 gRPC
  • OpenVLA、RT-2 等 VLA 模型的标准服务化方式
  • Psi0 如果要把 inference 抽出来做独立服务，大概率会选 gRPC 替代部分 ZMQ

官方资料

推荐读物

重点掌握

概念要点你会在哪遇到
.proto 文件写法message / service / rpc读 openpi / GR00T 的 proto 定义
四种 RPC 模式unary / server-stream / client-stream / bidiVLA 常用 server-streaming 返回 action chunk
Deadline / Cancellation超时必须能取消不阻塞机器人控制环绝不能卡在 RPC 上
向后兼容规则field number 不能改、新字段必须 optionalpolicy 模型升级时保持 client 不破坏
gRPC vs REST 选择延迟敏感 / schema 严格 → gRPC决定何时从 HTTP 迁移到 gRPC

预估时间：3–4 小时。

3. HTTP/2 与 WebSocket

在你工作栈的位置：

  • Psi0 三层通信的 HTTP 那层：配置、RESTful 查询，目前大概率是 HTTP/1.1
  • openpi 的 server：是 WebSocket 而不是纯 gRPC，所以你部署 π0 时一定会碰
  • Jupyter / TensorBoard / Weights & Biases：都是 WebSocket 实时推送
  • 你的 timlin15.github.io / openise.pages.dev：GitHub Pages 和 Cloudflare Pages 都已经是 HTTP/2 / HTTP/3
  • Telegram Bot API（arXiv 推送）：HTTP 长轮询或 webhook
  • 遥操作界面：如果你以后做 teleoperation dashboard，WebSocket 是双向实时通道的标准选择

官方/权威资料

重点掌握

概念要点
Binary framing二进制分帧，每帧有 stream id
Multiplexing单 TCP 连接多并发 stream，解决应用层队头阻塞
HPACK 头部压缩为什么中间代理变复杂
TCP 队头阻塞仍存在这是 HTTP/3 (QUIC) 出现的原因
WebSocket handshakeUpgrade: websocket 从 HTTP 升级
WebSocket vs HTTP/2 streamingWS 真双向；HTTP/2 stream 本质 client-initiated
WebSocket vs SSESSE 单向 server → client，场景更轻量

预估时间：HTTP/2 2 小时 + WebSocket 1 小时。

4. 共享内存 IPC 与零拷贝

在你工作栈的位置：

  • 4090 上同机跑多进程时的性能关键：比如相机采集进程 → 预处理 → π0.5 inference，三个进程传图像走 TCP/DDS 就是浪费
  • ROS 2 intra-process communication：同一个 component container 内 zero-copy
  • iceoryx + CycloneDDS：ROS 2 的标准 zero-copy 方案，配置后同机 DDS topic 走 shm
  • CUDA IPC：多 policy ensemble、或 inference 进程和 data loader 进程共享 GPU tensor
  • PyTorch DataLoader 的 num_workers：背后用 shm 传 tensor 到主进程
  • vLLM / SGLang 等 LLM 推理框架：内部广泛使用 shm 做 KV cache 共享

官方/权威资料

重点掌握

概念要点
为什么 shm 快避免 kernel ↔ user 拷贝、绕过协议栈
同步原语shm 本身无同步，需配 futex / semaphore / atomic
iceoryx Loaned Sample发送方 loan 内存写入，接收方直接读，引用计数管理生命周期
在 ROS 2 启用 iceoryxCycloneDDS 配置 + roudi daemon 运行
CUDA IPC 场景同一 GPU 两进程共享 tensor，省掉 D→H→D 拷贝
何时不用 shm跨机器、跨容器（除非 mount /dev/shm）

和你工作的一个具体联系：如果你跑 π0.5 时发现 “4090 显存够但 inference 延迟高”，很可能是图像从 camera driver 进程到 inference 进程走了 DDS + numpy 反序列化。改成 iceoryx zero-copy 能直接省掉几 ms。

预估时间：概念 1h + iceoryx demo 1h + CUDA IPC 按需另学。

二、强烈建议了解

5. CAN / EtherCAT

在你工作栈的位置：

  • Unitree G1 内部总线：EtherCAT 连接各个关节电机驱动器，然后通过网关暴露为 DDS topic 给你。你看到的 rt/lowstate 500Hz 频率就是 EtherCAT 周期决定的
  • Franka Panda/FR3：内部是自己的 FCI 协议（基于 UDP）而非 EtherCAT，但思路类似
  • Dex3 灵巧手：很多灵巧手（包括宇树 Dex3）用 CAN 连接手指电机
  • 现场调试：当 rt/lowstate 数据异常或某个关节”死机”时，问题可能在 EtherCAT 从站掉线而非 DDS 层

官方/权威资料

推荐读物

重点掌握

概念要点
CAN 帧结构11/29-bit ID、DLC、CAN 最大 8 字节 / CAN-FD 64 字节
CAN 仲裁非破坏性位仲裁，ID 小的优先
EtherCAT “处理帧” 机制帧在总线跑一圈，每个从站 on-the-fly 改自己那段。µs 级同步的关键
Distributed Clocks (DC)从站时钟同步 < 1µs
PDO vs SDOPDO 周期实时数据（电机指令）；SDO 非周期配置
与 DDS 的分工EtherCAT 管 µs 级底层同步，DDS 管 ms 级上层分发

预估时间：概念 2–3 小时，不动手硬件暂时够用。

6. MQTT

在你工作栈的位置：

  • 当前直接用到的概率较低，但重要——因为它是 DDS 的对照组
  • 机器人车队 / 远程监控场景：一旦要做”多台 G1 的云端 dashboard”，MQTT 比 DDS 合适
  • IoT / 智能家居集成：你做技术博客写类似科普时会用到
  • Home Assistant / ROS-MQTT bridge：研究机器人社区的常见组合

官方/权威资料

重点掌握

概念要点和 DDS 的对照
Broker 模型中心化DDS 去中心化
Topic 层级与通配符 + #DDS 也有 partition 但不一样
QoS 0/1/20 最多一次 / 1 至少一次 / 2 恰好一次对应 DDS 的 Reliability
Retained messagebroker 保留最后一条对应 DDS TRANSIENT_LOCAL
Last Will (LWT)客户端异常断开 broker 代发DDS 的 Deadline QoS
Keepalive适合不稳定网络DDS 的 Liveliness QoS

学习方式：读完 HiveMQ Essentials 就够。

预估时间：2 小时。

7. WebRTC

在你工作栈的位置：

  • Unitree 官方 app 遥操作：G1/Go2 app 的视频流和控制都是 WebRTC
  • VLA demo 的远程录屏 / 展示：Physical Intelligence、Figure 这些公司的发布视频背后常是 WebRTC
  • 如果你做 HITL 数据采集管道：远程操作员通过浏览器看机器人视角 + 发控制指令，WebRTC 的 video track + DataChannel 是标准方案
  • GitHub Pages 博客里嵌入实时机器人 demo：WebRTC

官方/权威资料

重点掌握

概念要点
三大组件getUserMedia / RTCPeerConnection / RTCDataChannel
SDPoffer/answer 协商编解码和端口
ICE / STUN / TURNNAT 穿透三件套
信令不在 WebRTC 标准里得自己用 WebSocket 传 SDP，很多人踩坑
RTP / SRTP媒体实际走的协议，UDP 之上
DataChannel基于 SCTP over DTLS，传任意数据，遥操作指令走这条

预估时间：读 “for the Curious” 前 5 章，3–4 小时。

三、用一张表总结”哪个协议出现在你工作栈的哪里”

协议你工作栈中的具体位置
DDS + QoSROS 2 底层、Unitree SDK2、Psi0 机器人状态通信、Franka ROS2、GR00T 部署
gRPCπ0 / openpi serving、GR00T inference endpoint、VLA 模型服务化标准
HTTP/2 + WebSocketPsi0 HTTP 层、openpi WebSocket server、Jupyter/TensorBoard、博客托管、Telegram Bot
Shared Memory / iceoryx / CUDA IPC4090 上多进程传图像/tensor、ROS 2 zero-copy、PyTorch DataLoader
EtherCAT / CANG1 内部总线（EtherCAT），rt/lowstate 500Hz 的物理来源；Dex3 手指可能 CAN
MQTT未来机器人车队监控；对照学习巩固 pub-sub 理解
WebRTCUnitree app 遥操作、HITL 数据采集的远程操作员界面、博客实时 demo
ZMQ（你已经在用）Psi0 policy ↔ body_ctrl 的高频指令通路
Protobuf（你已经在用）unitree_hg IDL 本质上和 protobuf 同类、gRPC 的序列化
Tailscale / WireGuard你的 laptop ↔ tensor ↔ A100 组网（VPN 层，L3）

四、推荐学习顺序（结合优先级）

顺序内容时间驱动理由
1DDS + QoS 4 小时规划4h你每天都在用，ROI 最高
2HTTP/2 + WebSocket（HPBN 第 12、17 章）3h后面 gRPC 的基础、openpi server 用 WS
3gRPC + protobuf（官方 QuickStart + blog）4hVLA 部署标准
4Shared Memory + iceoryx2h直接影响 4090 上 inference 性能
5MQTT（HiveMQ Essentials）2h和 DDS 对照巩固
6WebRTC（for the Curious 前 5 章）4h遥操作必备
7CAN + EtherCAT（概念层）3h理解 rt/lowstate 背后物理层
8动手穿插：写 VLA gRPC client + ROS 2 zero-copy demo4h固化

总计约 26 小时，按每周 6–8 小时的投入，3–4 周能完整过一轮。

五、长期参考书签

这些站点的共同点是长期维护 + 高权威，不会像随机博客那样几年后失效。先把它们加到书签，遇到具体问题再回来精读比随手 Google 高效得多。

关系图谱