UDP 适合六自由度平台的实时位姿流，不是因为它比 TCP“更可靠”，而是因为实时运动控制更看重固定节奏和最新数据。每一帧目标位姿都会被下一帧覆盖，迟到的旧指令反而没有价值；因此 UDP 常用于高频轨迹下发，可靠性则通过状态反馈、序号、超时保护和安全策略共同保证。
一、为什么是 UDP 不是 TCP
工业控制不是应该用 TCP 保证可靠吗，UDP 丢包怎么办？这是客户初次集成最常问的问题。简短回答是：在实时运动控制场景下，TCP 的”可靠”反而是负担。
六自由度运动控制按固定高频周期下发位姿指令，每一帧都是一个完整、独立的目标。这种数据流有三个特点，决定了它更适合 UDP：
- 一条迟到的指令没有价值。如果某帧丢包，TCP 会等 ACK 再重传，等它到达时，它代表的姿态早已是”过去时”，拿到反而会引起姿态跳变。
- TCP 的拥塞控制会主动降速。带宽紧张时它放慢发送，这对要求节奏稳定的实时控制是灾难。
- 运动指令本就是连续覆盖的。丢一帧的成本只是这一瞬间错过更新，下一帧立刻覆盖回来。
机器人遥操作领域把这个取舍总结成一句话：一条过期的指令比丢掉一帧更糟（a stale command is worse than a skipped one）。所以这类系统普遍采用”最新者胜”（latest-wins）的无状态推流——带序号、新帧覆盖旧帧、过期即丢，而不是像 TCP 那样为了不丢包而引入队头阻塞（head-of-line blocking）和重传延迟。UDP 开销小、不等重传，还能给出更稳定的发送节奏，正好契合运动控制的需要。
实时位姿流追求的是“最新目标尽快生效”，不是“每一帧都排队送达”。过期指令被可靠送达，反而可能破坏运动连续性。
二、命令-反馈模型
彦控 UDP 接口采用单向命令加周期反馈的极简模型，没有复杂的握手或会话状态：
这样设计有它的道理：上位机不必关心”指令送达了没”，发出去就当生效、下一帧重新覆盖；控制器持续推反馈，上位机可随时比对真实位姿与命令位姿的偏差；急停、超限这类安全策略由控制器本地判断，不依赖上位机在线。
落到客户的实际价值，是三件事：集成链路简单，任何支持 UDP 收发的语言或平台都能对接；网络抖动或上位机卡顿不会让平台跑飞，因为控制器有本地安全网；多平台、多上位机协同也很简单，因为命令本身是无状态的。
UDP 接口开放的是应用层运动语义；急停、限位、超限保护和本地安全状态，仍应留在平台控制器内部处理。
三、五类典型集成场景
同一套 UDP 接口，覆盖了下面五类最常见的集成方式：
| 集成场景 | 数据流向 | 典型工具 / 框架 |
|---|---|---|
| PC 上位机 | 命令下发 + 反馈读取 | C# / Python / C++ 自研软件 |
| 游戏引擎 | 姿态实时推流 | Unity / Unreal |
| 机器人栈 | 话题订阅转 UDP | ROS / ROS2 · Gazebo / Carla |
| 影视文旅 | 同步信号驱动多台（支持组播） | 影片服务器 + 多座椅 |
| HIL 半实物 | 实时模型逐帧推流 | Simulink · dSPACE / Speedgoat / NI |
PC 上位机（C# / Python / C++）
最常见的一类。客户已有自研测试软件，想加一个”按下按钮启动平台运动”的能力。典型步骤是：在上位机里建立 UDP 收发通道，按协议文档组织位姿或状态命令，发送到控制器，再监听反馈端口读取位姿、状态与安全信息。具体字段和异常处理以项目接口文档为准。
Unity / Unreal 游戏引擎
驾驶、飞行模拟器和 VR 体验最常用的组合。在引擎脚本里建 UDP client，把虚拟场景里车辆或飞机的姿态实时推给平台，平台跟随渲染同步运动，玩家的身体感受就与画面对上了。每帧推送量很小，一个项目加一个 IP 配置即可，典型应用包括赛车模拟器、飞行训练器、地震体验馆。
ROS / ROS2 节点
机器人和自动驾驶团队的标准开发栈。写一个 ROS 节点，订阅位姿话题、转成 UDP 包推给平台，平台反馈也可以发布回 ROS 话题，与 Gazebo、Carla、Webots 等仿真环境天然兼容。彦控 SDK 提供 Python 示例脚本，复制即用。
VR 体感设备 / 4D 影院
影视与文旅项目。多个观影座椅需要与影片同步运动：影片服务器发同步信号、转成 UDP 命令、驱动多平台同步，并支持组播，一条命令同时发给多台平台。
HIL 半实物仿真
汽车、航空的整车级控制器测试。Matlab/Simulink 模型实时计算车辆动力学，通过实时 UDP 把位姿命令推给平台，平台运动加上真实控制器在环测试。dSPACE、Speedgoat、NI VeriStand 的用户都能平滑接入。
四、项目接口管理方式
正式项目会在技术协议和接口文档中确认命令字段、反馈格式、控制周期、异常处理和版本边界。接口扩展通常优先保持向后兼容，避免客户已有上位机在项目升级中被迫大改。
对客户来说，关键不是把所有命令细节提前公开，而是在立项和联调阶段把接口版本、字段含义、异常码和验收方式固定下来。
五、获取项目接口资料
完整的命令表、错误码、反馈机制和集成示例，按项目需求提供。其他应用层协议（TCP / WebSocket / HTTP）见 开放通信协议。
参考资料
- IETF, RFC 768: User Datagram Protocol, 1980, https://www.rfc-editor.org/rfc/rfc768
- IETF, RFC 9293: Transmission Control Protocol, 2022, https://www.rfc-editor.org/rfc/rfc9293
延伸阅读
- 开放接口怎么选（应用层 vs 内部总线）→ 运动平台开放接口怎么选
- 三种运动模式的选型（PT 流式推送）→ 三种运动模式的选型
- 配套能力：开放通信协议 · 多语言 SDK