原型目标
机器人控制原型 正在开发机器人实时数据接入与三轴位置 IK。我先将传输、调度、滤波和求解分开，建立 UE 侧原型：让外部数据进入场景，处理输入中断后的输出变化，并将目标位置转换为关节值。
实时链路的困难不只在于收到 JSON。网络收包和游戏 Tick 并不同步，输入有效也不代表机构一定能够到达目标。因此原型把接收状态与 IK 求解状态分别表达，方便上层判断当前输出的含义。真实机构 URDF 与真实数据测试仍待完成。
数据接入与失联处理
接收线程与 Tick 交接
RoboUdpTransport 在 UDP 工作线程收发 JSON，并保留最新解析帧。游戏 Tick 按数据代次读取更新，网络接收和场景处理各自推进。这个结构用于跟随最新状态，不会将收到的每个数据包排成必须逐项执行的动作队列。
数据新鲜度使用本地接收时间判断。恢复条件中的连续有效包，指连续可解析数据包的数量，不代表发送端序号严格连续；当前也没有序号去重或远端时钟同步。数据格式可解析、消息顺序和时间基准是不同问题，使用时需要区分。
超时、归零与恢复
输入超过超时时间后，协议输出中的位置、旋转和关节值归零，并重置滤波状态。重新满足接收条件后，以新收到的原始姿态恢复处理，避免继续沿用失联前的滤波历史。
这里的归零是协议数据的处理规则。它不能直接解释成物理机构安全回零；真实设备应怎样停机、保持或回到基准位置，需要由设备控制协议和硬件安全设计决定。
按动作快慢调整滤波
原型根据估计的移动速度与角速度调整滤波截止频率：缓慢动作时可以更多地抑制细小波动，快速动作时则需要减少过强平滑带来的跟随滞后。旋转使用归一化后的 Slerp 插值，与位置数据分别处理。
这种自适应处理是在抖动与响应之间作取舍，不能只用“滤得更平滑”判断是否合适。接入实际数据后，要同时观察静止波动、快速移动与恢复时的姿态变化。
目标频率与实际调度
RoboRealtimeSubsystem 在 Tick 中累计经过时间，按配置目标周期调度处理。120 Hz 是这套调度的配置目标，实际执行仍受帧调度与运行环境影响。网络接收频率、数据更新频率和求解执行频率也需要分别观察，不能把一个配置数字当作整条链路的硬实时指标。
三关节位置求解
将外部目标转成机构坐标
RoboThreeAxisIkSolver 复用 URDFForge。目标数据进入求解前处理米到厘米、左右手坐标系，以及旋转轴作为伪向量时的转换。位置向量与旋转轴的转换含义不同，单位和手性应在边界明确，避免数值看似接近但转动方向相反。
当前机构范围是三个转动关节组成的链，加上固定工具点，并受实现支持的关节原点变换限制。求解使用机构定义把目标 XYZ 位置转成三个关节值，不能将它描述成任意 URDF 机构都可直接接入的通用求解器。
区分输入有效与求解有效
| 状态 | 表示什么 | 对输出的影响 |
|---|---|---|
input_valid | 输入满足当前接收有效条件 | 说明输入链路状态 |
ik_valid | 当前目标得到有效位置 IK 结果 | 说明关节结果能否使用 |
| 输入有效但 IK 失败 | 有新数据，但当前求解没有有效结果 | 清空关节输出，保留状态区分 |
这种划分避免把“网络还在发数据”误当成“关节值可用”。当前求解目标只有位置，末端姿态约束不在这套三轴原型中；机构尺寸、关节限制和工具点定义还需要用真实模型确认。
开发状态
目前已有 UDP 传输、最新帧交接、超时恢复、自适应滤波与三关节位置求解的软件原型。真实机构 URDF、真实数据链路和设备表现仍需测试，本文按开发中记录。协议归零和求解状态可供上层处理，最终设备行为仍需设备侧规则配合。
如果要评估类似需求，可以先提供机构结构、关节范围、数据格式和目标位置约束，再判断原型中哪些部分可以复用。
欢迎联系我聊聊。
项目展示
动捕与机器人控制