机器人调度通讯，UDP 还是 MQTT？选型踩坑实录

做机器人调度平台，第一个绕不开的问题：机器人和云端之间用什么协议通信？

很多人第一反应是 UDP——“快啊，延迟低，实时控制就该用它”。这个想法很诱人，但现实会狠狠教育你。

为什么不用 UDP：快是快，但不可靠

🔹 丢包无感知——UDP 发了就不管，丢了就丢了。行业里有过险情：现场一台配送机器人前面突然走过一个人，后台点"急停"，结果急停指令通过 UDP 丢包，机器人没收到，继续往前走。事后一查，就是当时 WiFi 干扰、丢包率飙升。在控制场景里，"可靠"比"快几毫秒"重要一万倍。
🔹 企业防火墙拦 UDP——工厂、园区的防火墙往往默认拦所有 UDP，只放行标准端口的 TCP。你总不能每个客户都去走两周审批吧。
🔹 为了可靠，你等于重新实现 TCP——给 UDP 加序号、加确认、加重传、加去重，加着加着发现，这不就是 TCP 吗？而且做得还没 TCP 成熟。

结论很干脆：与其用 UDP 自己造轮子，不如直接用 TCP，成熟、稳定、验证了几十年。

纯 WebSocket 也不够：遥测和任务要分开

基于 TCP 的 WebSocket 确实好用——双向、可靠、浏览器原生支持。但只靠它，又冒出新问题：

🔹 高频遥测"淹没"低频指令——遥测（位置、速度、电量）每百毫秒一条，任务指令几分钟才一条。走同一个通道，高频数据把低频指令堵在队尾。就像马路上自行车和救护车混行，救护车被堵死
🔹 可靠性要求不一样——遥测丢一帧没事，任务指令（急停、取消、开始）丢一条就是事故
🔹 离线消息没有——机器人进电梯断网那几秒，任务下发就收不到了，重连后也没补，两边状态对不上

这时候就需要一个支持 QoS 和离线消息的协议来管任务通道——MQTT 正好。

最终方案：双通道分工

🔹 WebSocket 通道——传实时遥测。高频、可容忍偶尔丢包、追求低延迟
🔹 MQTT 通道——传任务下发、控制指令、配置变更。低频、必须可靠送达、要 QoS 和离线消息

就像马路分车道：自行车走非机动车道，救护车走应急车道，互不干扰。

双通道的好处：

🔹 职责分离，任务延迟有保障
🔹 可靠性分级，遥测不确认省资源，任务用 QoS 保证送达
🔹 故障隔离，一个通道挂了不影响另一个
🔹 技术栈独立，WebSocket 网关和 MQTT 集群可以分开扩容

光选对协议还不够，还得补可靠性机制

协议只是第一步，生产环境稳定运行靠的是一整套机制：

🔹 心跳——双方定期发"我还活着"，WebSocket 靠 ping/pong，MQTT 靠 Keep Alive + 遗嘱消息。间隔别太短也别太长
🔹 重连——指数退避（失败后间隔翻倍重试，别把服务器打垮），重连后恢复状态、本地缓存断线期间的数据
🔹 幂等——网络抖动会让消息重复，每条带唯一 ID，重复的直接丢弃；状态单向流转天然约束；尽量让操作本身幂等
🔹 超时与回执——三层回执（受理、步骤、终态），像寄快递的"已揽收、运输中、已签收"，每个环节都有确认，不会石沉大海

选型总结

🔹 别为"快"用 UDP，控制场景可靠性第一
🔹 遥测和任务一定要分通道
🔹 MQTT 的 QoS、遗嘱消息、离线消息是真的香，能省掉大量造轮子的活
🔹 心跳、重连、幂等、回执，一个都不能少，而且一开始就要做
🔹 关键指标（连接数、延迟、重连次数、丢包率）要监控，别等客户投诉才知道出问题

通讯架构是调度平台的"血管"，血管不通，再聪明的大脑也指挥不了身体。

关于作者：越微智能（Yuewell）专注具身智能与工业 AI 视觉落地，基于自研 VLA 多模态大模型，提供全品牌机器人二次开发（适配宇树/优必选/智元/傅利叶）与工业级视觉算法定制，支持从算法、硬件到产线实机部署的全栈交付。