六自由度平台 UDP 通信接口设计 — 5 类集成场景

为什么是 UDP，不是 TCP

很多客户初次集成会问：“工业控制不是应该用 TCP 保证可靠吗？UDP 丢包怎么办？”

简短回答：实时运动控制场景下，TCP 的”可靠”反而是负担。

详细原因：

TCP 重传 = 命令过期：六自由度运动控制按 1 kHz 周期下发指令。如果某条指令丢包，TCP 会等 ACK + 重传，等指令到达时它代表的姿态早已是”过去时”——拿到也没用，还会引起姿态跳变
TCP 拥塞控制 = 抖动：TCP 在带宽紧张时主动降速，对实时控制是灾难
运动指令本来就是”连续覆盖”：每帧位姿独立完整，丢一帧的影响只是这一瞬间错过更新，下一帧立刻覆盖回来——丢包成本极低

所以工业实时运动控制几乎都用 UDP：接收即用，过期即丢。

命令-反馈模型

彦控 UDP 接口采用单向命令 + 周期反馈的极简模型，没有复杂的握手或会话状态：

上位机                  控制器
  │                        │
  │ ──── 位姿/缸长命令 ───→ │   （随时下发，无须等 ACK）
  │                        │
  │ ←── 状态反馈包 100 Hz ─ │   （控制器主动周期推送）
  │                        │

为什么这样设计：

上位机不需要管”指令送达了没”——发出去就当成功，下一帧重新覆盖
控制器持续推反馈，上位机可观察到平台真实位姿与命令位姿的偏差
安全策略（紧急停止、超限保护）由控制器本地判断，不依赖上位机

这种模型对客户的实际价值：

上位机代码极简，任何语言能 send + recv UDP 包就能集成
网络抖动 / 上位机卡顿不会让平台跑飞（控制器有本地安全网）
多平台 / 多上位机协同也很简单（命令是无状态的）

5 类典型集成场景

场景 1：PC 上位机（C# / Python / C++）

最常见——客户已有自研的测试软件，想加一个”按下按钮启动平台运动”的能力。

集成步骤：

建立 UDP socket（10 行代码）
按协议表格组装命令字节包
发到平台 IP : 默认端口
监听反馈端口，解析位姿/状态

整个过程从零到跑通 2-4 小时。

场景 2：Unity / Unreal 游戏引擎

驾驶 / 飞行模拟器 / VR 体验最常用的组合。

在 Unity C# 脚本里建 UDP client，把虚拟场景的车辆/飞机姿态实时推给平台
平台跟随渲染同步运动 → 玩家身体感受与画面同步
典型应用：赛车模拟器、飞行训练器、地震体验馆

每帧推送量小（< 100 字节），1 个 Unity 项目 + 1 个 IP 配置即可。

场景 3：ROS / ROS2 节点

机器人 / 自动驾驶团队的标准开发栈。

写一个 ROS Node，订阅 /cmd_pose topic，转 UDP 包推给平台
平台反馈也可发布回 ROS Topic（/platform_state）
与 Gazebo / Carla / Webots 等仿真平台天然兼容

彦控 SDK 提供 Python 示例脚本，复制粘贴即可用。

场景 4：VR 体感设备 / 4D 影院

影视 / 文旅项目。多个观影座椅（每座一个 3-DOF 或共享一个 6-DOF）需要与影片同步运动。

影片服务器发同步信号 → 转 UDP 命令 → 多平台同步运动
支持组播（一条命令同时发给多平台）

场景 5：HIL 半实物仿真

汽车 / 航空整车级控制器测试。

Matlab/Simulink 模型实时计算车辆动力学
通过 Real-Time UDP block 推位姿命令
平台运动 + 真实控制器 ECU 在环测试

dSPACE / Speedgoat / NI VeriStand 用户可平滑接入。

接口稳定性承诺

UDP 协议接口属于彦控长期兼容承诺的部分：

老命令字段永不删除（新增字段向后兼容）
协议文档对外公开（不锁定客户）
历史版本可在 GitHub 文档备份查询

这意味着客户基于彦控 UDP 开发的上位机软件，多年后仍能与新版控制器对接。

下载完整接口手册

📄 yk-controller-udp-protocol.pdf — 含完整命令表、错误码、反馈机制、示例代码

或访问配套软件 & 接口 → /platforms/sw-protocol 了解 TCP / WebSocket / HTTP 等其他应用层协议。

六自由度平台的 UDP 通信接口设计 — 客户集成视角