机器人调度通讯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/pongMQTT 靠 Keep Alive 遗嘱消息。间隔别太短也别太长重连——指数退避失败后间隔翻倍重试别把服务器打垮重连后恢复状态、本地缓存断线期间的数据幂等——网络抖动会让消息重复每条带唯一 ID重复的直接丢弃状态单向流转天然约束尽量让操作本身幂等超时与回执——三层回执受理、步骤、终态像寄快递的已揽收、运输中、已签收每个环节都有确认不会石沉大海选型总结 别为快用 UDP控制场景可靠性第一 遥测和任务一定要分通道 MQTT 的 QoS、遗嘱消息、离线消息是真的香能省掉大量造轮子的活 心跳、重连、幂等、回执一个都不能少而且一开始就要做 关键指标连接数、延迟、重连次数、丢包率要监控别等客户投诉才知道出问题通讯架构是调度平台的血管血管不通再聪明的大脑也指挥不了身体。关于作者越微智能Yuewell专注具身智能与工业 AI 视觉落地基于自研 VLA 多模态大模型提供全品牌机器人二次开发适配宇树/优必选/智元/傅利叶与工业级视觉算法定制支持从算法、硬件到产线实机部署的全栈交付。