在多人竞技类机器人赛事（如格斗、足球或巡线对抗）中，通信系统需同时满足三类截然不同的需求：
- 裁判指令的毫秒级可靠下发（如"血量-10"、"禁用武器"）；
- 机器人状态的实时同步（位置、血量、技能冷却）；
- 观战数据的广域分发（供手机、大屏或直播平台展示）。
若统一使用 TCP，无线环境下的丢包重传会导致突发性高延迟与卡顿 ；若全用 UDP，则缺乏可靠性保障。为此，我们设计了一套混合通信架构 ：局域网内采用 UDT（UDP-based Data Transfer Protocol） 保障关键指令低延迟可靠传输；广域网则通过 MQTT 消息队列实现高效状态广播。
一、核心挑战：TCP 在无线环境中的"致命缺陷"
在 Wi-Fi 干扰严重的赛场（20+ 台机器人、大量手机热点），TCP 的拥塞控制机制会因丢包而大幅降低发送窗口，甚至触发超时重传（RTO ≈ 200ms+）。实测显示，TCP 控制指令的 P99 延迟高达 350ms，完全无法接受。
二、局域网通信：UDT 实现确定性低延迟
UDT 是一种基于 UDP 的应用层可靠传输协议，专为高速广域网和高丢包环境设计。其优势在于：
- 自定义拥塞控制：不依赖丢包判断拥塞，而是基于带宽估计；
- 选择性重传（SACK）：仅重传丢失数据包，避免整窗阻塞；
- 固定低延迟 ：即使丢包率 5%，端到端延迟仍稳定在 <15ms。
在赛事局域网中，裁判系统作为 UDT 服务器，所有机器人作为客户端连接。关键指令（如"机器人#05 击杀成功"）通过 UDT 单播发送，确保：
- 有序：指令按发送顺序到达；
- 可靠：丢失包在 5ms 内重传；
- 低抖动：无 TCP 的 RTT 波动。
RobotEX 主控（STM32 + Linux）通过轻量级 UDT C++ 库（如 udt4 移植版）接入，实测在 MT7628 上 CPU 占用 <8%。
三、广域网通信：MQTT 实现高效状态广播
UDT 适合点对点关键指令，但不适合一对多广播。为此，我们引入 MQTT（Message Queuing Telemetry Transport）：
- 每台机器人启动后，连接至赛事 MQTT Broker（如 EMQX 或 Mosquitto）；
- 将自身状态以 JSON 格式发布到主题：
/match/arena_01/robot_05/status； - 观战端（手机 App、大屏系统）订阅通配符主题：
/match/arena_01/+/status，即可实时接收所有机器人状态。
MQTT 的优势：
- 极低带宽：单条状态消息 <100 字节；
- 发布/订阅解耦：新增观战设备无需修改机器人逻辑；
- QoS 支持：关键状态可设 QoS=1（至少送达一次）。
四、网络拓扑与协同工作
每台机器人运行于 OpenWrt AP+STA 模式（见第三篇）：
- STA 接口：连接赛事主路由器，用于 UDT 与 MQTT 通信；
- AP 接口 ：提供本地调试热点（如
Robot_05_Debug），供技术人员紧急接入。
裁判系统可执行高级操作：
- 强制复位 MPU：通过 UDT 发送特殊指令，触发 STM32 硬件看门狗；
- 版本核查：批量查询所有机器人固件版本，防止作弊；
- 紧急停机：一键使能/失能全场机器人电机。
五、观战体验增强
为提升观众体验，我们扩展了 MQTT 数据流：
- 事件推送 ：击杀、复活等事件发布至
/events主题； - 视频同步：图传服务器将 MJPEG 流 URL 与机器人 ID 绑定，观战 App 自动加载对应画面；
- 数据可视化：通过 WebSocket 将 MQTT 数据转发至 Web 前端，实现动态血条、技能 CD 动画。
在实际比赛中，该架构支持 32 台机器人 + 100+ 观战终端 同时在线，关键指令延迟 P99 <18ms，状态更新频率 10Hz，系统零崩溃。
六、总结
这套"UDT + MQTT "混合架构，精准区分了控制平面 与数据平面的需求：前者追求确定性低延迟，后者追求高效广播。它不仅解决了无线环境下 TCP 不可靠的问题，还通过标准化协议（MQTT）打通了从赛场到观众的全链路体验。未来，我们将探索 QUIC 协议替代 UDT，以进一步简化 NAT 穿透与连接迁移，但在当前嵌入式 Linux 生态下，UDT + MQTT 仍是机器人赛事通信的最佳实践。