构建可验证、可维护且以人为中心的机器人产品体验体系

Question

Introduction

面向机器人与复杂数字产品的工程设计，真正的挑战并非单一工具或界面的选型，而是如何在控制可靠性、软件架构、仿真验证与用户体验之间建立可追踪、可验证的系统边界。本报告围绕这一问题展开综合评估，首先分析 Win11 原生操作员界面中 Rust、eframe/egui 与 C++/ROS 2 的职责划分，明确图形界面适合承担操作与可视化功能，但不应替代实时控制器或安全系统。随后，报告考察 Win11—Linux 容器环境下 ROS 2 Jazzy 桥接节点的 DDS 发现、网络配置、生命周期管理、QoS 与硬件无关控制协议，揭示跨平台通信中的级联失效风险。

在仿真与执行层面，报告进一步界定 OpenRAVE、MuJoCo、ROS 2/ros2_control 与 Rerun 的协同关系：规划、动力学验证、统一控制接口和数据观测必须分层实现，并通过故障注入与分阶段 sim-to-real 测试建立证据链。最后，报告将视角扩展至 UI/UX 方法论，讨论用户研究、任务流程、原型验证、设计系统、色彩、排版、品牌一致性与无障碍设计如何共同塑造可持续的真实产品体验。整体论证坚持区分架构可行性、工程推论与实证结论，为后续系统落地、测试验收和长期治理提供审慎而可执行的依据。

Main Idea

背景与理论基础

面向机器人与工业设备的操作员软件，正在从“能够发送命令的控制面板”转变为融合人机交互、分布式通信、实时控制、仿真验证和运维审计的复杂产品系统。其工程难点不在于单独选择某一种编程语言、GUI 框架或仿真器，而在于如何使用户意图经过一条可理解、可验证、可追踪且不越过安全边界的技术链路，最终转化为设备行为。

本研究综合分析的系统包含五个相互依赖的层次：第一，Win11 上运行的操作员界面；第二，以 Rust 和 eframe/egui 为基础的应用与交互层；第三，基于 ROS 2、DDS 和生命周期节点的通信及能力管理层；第四，由 ros2_control、C++ 组件、硬件接口和实时控制器构成的执行层；第五，由 OpenRAVE、MuJoCo、真实机械臂和安全硬件共同组成的规划、仿真与物理执行环境。Rerun 等工具则位于观测、记录与审计层，为系统提供可回放的证据，但不应进入实时安全闭环。

这一体系可以由四个理论框架解释。

第一是分层控制与抽象边界理论。ROS 2 Control 的工程模型将系统划分为硬件驱动、硬件接口、控制器和上层应用，强调越靠近硬件，代码越具有设备特异性；越靠近应用，逻辑越应具有通用性[1][2]。这一分层不仅是软件工程上的模块化，也对应不同的风险边界、时序边界和验证责任。GUI 应表达操作员意图，控制器应负责周期性执行，安全硬件则承担最终保护。若任一层越权，系统便会出现职责混淆。

第二是分布式系统的可见性与状态一致性理论。ROS 2 基于 DDS 进行节点发现和通信，Domain ID 用于划分逻辑通信域[3]。然而，节点“进程存在”、节点“已被发现”、节点“已配置”、设备“可控”以及命令“已执行”是不同层次的事实。Win11、Docker Desktop、WSL2、Linux 容器、防火墙和无线网络共同构成多个网络边界，可能使 DDS 多播发现失败，即使基础 IP 连通性正常[4][5][6]。因此，系统可靠性不能由单一连接布尔值表示，而必须同时建模网络可见性、生命周期状态和业务执行结果。

第三是用户中心设计与认知负荷理论。经典 UX 规律，如费茨定律、希克定律、米勒定律、心智模型、一致性、邻近性和峰终定律，分别解释操作目标可达性、选项选择成本、短期记忆负担、用户预期及体验记忆等问题[7][8]。但这些规律并非可以机械套用的自然定律，而是用于提出设计假设的启发式工具。对于工业控制界面，用户中心设计尤其必须关注高压力、低容错和异常状态场景，而不应仅优化正常流程中的点击速度。

第四是仿真—真实迁移理论。OpenRAVE 更适合承担离线规划、逆运动学、可达性与几何碰撞分析；MuJoCo 更适合承担动力学、接触、摩擦、执行器与故障注入仿真；ros2_control 则应作为仿真与真实硬件之间的执行接口[9][10][11]。接口一致是 sim-to-real 的必要条件，但不是充分条件。真实系统仍会受到摩擦、回差、通信延迟、控制周期抖动、传感器量化和安全硬件行为差异的影响。

现有知识通常分别讨论 GUI 设计、ROS 2 部署、控制架构、仿真或 UX 方法，却较少说明这些因素如何形成级联失效。例如，DDS 发现失败可能被误判为驱动故障；驱动状态不明确可能被界面显示为“设备空闲”；界面上的红色停止按钮又可能被用户误解为与急停等价。本研究的核心贡献，正是把这些孤立问题整合为一个统一的人机—通信—控制—仿真可靠性框架。

文献综述与相关工作

现有相关工作可以分为四条发展脉络。

第一条脉络是 GUI 框架与桌面应用工程。egui 是基于 Rust 的即时模式 GUI 库，eframe 负责窗口、输入和渲染，并支持 Windows、Linux、macOS、Web 和 Android 等平台[12][13][14]。即时模式的基本思想是应用根据当前状态重新生成界面，而不是长期维护大量控件对象。这一机制有利于构建状态灯、参数面板、日志视图和诊断界面，也降低了早期原型的开发成本。然而，现有资料主要是入门教程、项目文档和中文说明，能够证明框架的可用性与跨平台潜力，却没有提供 Win11 环境下输入延迟、GPU 驱动稳定性、失焦行为、无障碍能力或长期运行可靠性的系统基准。

第二条脉络是 ROS 2 与工业控制架构。ROS 2 通过 DDS 支持分布式发现、跨平台通信、网络连接和多机器人协作；生命周期节点则允许系统区分未配置、未激活、已激活、停用和最终化等状态[3][15]。ROS 2 Control 进一步提供硬件接口和控制器管理模型[1][2]。相关工程资料说明，ROS 2 的部署不仅包括编译节点，还包括可执行文件、launch 文件、环境路径、RMW 实现、DDS 配置和网络接口选择[16]。但社区案例也显示，ROS 2 的“支持实时性”并不意味着普通 Windows 节点天然拥有硬实时保证；Docker Desktop 的网络语义也不能简单等同于 Linux 原生 Docker[4][5][6]。

第三条脉络是机械臂规划和物理仿真。OpenRAVE、MoveIt 2 及相关规划器通常用于 IK、路径规划、可达性与碰撞检测；MuJoCo 则提供动力学、接触和执行器仿真。mujoco_ros2_control 通过 hardware_interface::SystemInterface 将 MuJoCo 接入 ros2_control，使 ROS 2 控制器能够面向仿真机器人运行[10]。相关项目进一步展示了真机驱动、Fake Driver 与 MuJoCo 后端共享控制接口的可能性[9]。这一方向的重要进展在于：仿真器不再只是独立的可视化工具，而可以成为与真实执行链共享控制契约的验证后端。

不过，当前相关工作仍存在明显缺口。首先，许多资料证明的是“存在某种实现”，而不是“该实现具有可重复的性能”。其次，仿真与真实系统之间通常只验证消息类型和关节名称的一致性，较少验证时间语义、错误状态、控制模式切换和故障行为的一致性。再次，Rerun 等观测工具通常被讨论为可视化手段，而较少被放入系统级审计和故障重建框架中。

第四条脉络是用户体验与设计系统。用户中心设计、原型、可用性测试和持续迭代被普遍认为能够提前发现问题、降低返工成本并提高产品质量[17][18][19]。设计系统则从传统品牌指南扩展为包含颜色、排版、组件、内容、代码规范和无障碍要求的组织基础设施[20][21]。移动结账研究表明，真实产品中仍有大量基础交互问题；Baymard 的 2025 年基准显示，评估移动网站中有 63% 处于“中等或更差”水平，仅 2% 被评为“良好”，移动应用中有 46% 处于“中等或更差”水平[22]。这些数据表明，经典 UX 理论具有现实商业价值，但行业基准和案例研究仍不能替代因果实验。

综合而言，既有研究已经分别建立了 GUI、ROS 2、控制、仿真和 UX 的局部知识，但缺少一套贯穿“操作员意图—应用协议—DDS 通信—生命周期—控制器—物理执行—反馈审计”的系统评价框架。本研究试图填补这一整合性空白。

问题定义与研究问题

本研究所处理的正式问题是：

在 Win11 主机、Rust/eframe/egui 操作员界面、ROS 2 Jazzy 或其他 ROS 2 环境、Linux 容器、C++/硬件驱动、ros2_control 与 MuJoCo/OpenRAVE 仿真共同存在的条件下，如何构建一套具有清晰职责边界、可观测通信状态、可验证控制语义、可迁移仿真接口和可持续用户体验的机器人操作系统？

该问题包含三个层面的矛盾。

第一，桌面交互的即时性与运动控制的确定性之间存在边界。用户希望按钮、Jog 和停止操作具有即时反馈，但 Win11 GUI 线程不能承担硬实时闭环。

第二，跨语言和跨进程复用与系统复杂性之间存在张力。Rust 可提供类型安全、状态建模和并发约束，C++ 与 ROS 2 生态则更适合复用成熟控制器和硬件接口。语言数量本身不是复杂性的根源，边界不稳定才是。

第三，仿真接口一致性与真实行为等价之间存在鸿沟。同一消息类型不能保证同一时间语义、同一故障行为或同一物理响应。

研究围绕以下问题展开：

RQ1： Win11 与 eframe/egui 是否适合作为非安全、非硬实时的机器人操作员界面？
RQ2： Rust 与 C++/ROS 2 应如何划分职责，才能降低 FFI、生命周期和故障传播风险？
RQ3： 在 Win11—Docker—Linux 边界中，DDS 发现、Domain ID、RMW、QoS 和生命周期如何协同，形成可诊断的通信体系？
RQ4： OpenRAVE、MuJoCo、ros2_control 和 Rerun 如何形成职责互补而非功能重叠的验证链？
RQ5： 用户研究、任务流程、原型、可用性测试和设计系统如何共同降低操作员认知负担和系统误操作风险？
RQ6： 如何设计一套能够衡量性能、可用性、故障恢复、仿真迁移和维护成本的综合验收框架？

据此提出五项工作假设：

H1： 只要界面与控制循环解耦，eframe/egui 足以支持大多数状态展示、参数编辑和非实时操作员任务。
H2： 稳定的应用层控制协议比单纯减少编程语言数量更能降低系统维护成本。
H3： 显式 DDS 网络配置和启动自检比默认自动发现更适合跨主机生产部署。
H4： 复用 ros2_control 接口的仿真系统，比单纯提高物理模型保真度更能降低早期 sim-to-real 风险。
H5： 将 UX 原则转化为可测试假设，并纳入状态机、设计系统和验收指标，能够比孤立的视觉规范更有效地降低操作错误。

研究范围限定为软件架构、交互模型、部署可靠性、仿真—控制接口和 UX 验证，不涉及具体设备的安全认证、功能安全等级认定或某一型号机械臂的性能证明。

方法论与分析框架

本研究采用多来源系统综合方法，而非将各类材料简单平均。分析对象包括项目文档、技术教程、官方框架说明、社区故障报告、设计方法文章、行业基准和案例材料。证据被分为三类：

直接证据：来源明确描述的功能、接口、架构或工程步骤，例如 eframe 负责窗口输入与渲染[13]，ROS 2 使用 DDS 和 Domain ID[3]，mujoco_ros2_control 实现 SystemInterface[10]。
结构性推论：由多个来源共同支持的系统判断，例如 GUI 不应承担硬实时控制，规划器不应绕过 ros2_control 直接控制硬件。
工程建议：在已有原则基础上提出的协议、测试和部署方案。这些建议不是原始资料直接报告的实验结果，必须通过后续验证。

分析过程包含四个步骤。

首先进行主题编码，将材料归入界面与交互、网络与 DDS、生命周期与控制、仿真与规划、设计系统与无障碍、研究方法与组织治理六个主题。其次进行跨来源比较，识别一致发现、矛盾陈述和证据缺口。例如，部分案例报告 Jazzy 与 Humble 可以通信，另一些社区回复则警告发行版与 CycloneDDS 配置可能存在问题[23][24]。本研究不将其简化为“兼容”或“不兼容”，而将兼容性拆分为消息、RMW、DDS 配置、QoS、网络和 CLI 工具六个维度。

第三步是进行风险链分析，追踪一个底层故障如何向上传播。例如，多播被阻断会导致 DDS Participant 无法发现，继而导致 ROS 2 图不完整、服务不可见、应用超时，最终被误判为设备离线。第四步是建立分层评价矩阵，分别从用户体验、应用协议、通信可靠性、控制实时性、仿真迁移、部署维护和安全隔离七个维度评价方案。

访谈和备忘录材料的优势在于覆盖真实工程问题，但存在来源异质性、样本不可见、版本信息不完整和成功案例偏差等限制。设计机构文章往往强调实践价值，社区报告偏向失败案例，项目 README 能证明实现存在，却不能证明其在所有环境中稳定。为降低偏差，本研究明确区分事实、推论与建议，并不将 ArXiv 检索失败信息视为文献证据。

实施与运营细节

推荐采用“操作员站—应用协议—ROS 2 适配—控制器—硬件”的部署拓扑。

操作员站运行 Win11、Rust 应用和 eframe/egui。其职责包括连接状态展示、设备能力查看、参数输入、权限确认、Jog 操作、轨迹任务提交、故障解释、日志检索和实验回放。GUI 线程只处理输入、模型读取与绘制，不直接调用硬件驱动，也不承担固定周期命令发送。

应用协议层采用 Rust 实现，维护领域对象和显式状态机。连接、使能、Jog、轨迹、停止与故障应被建模为具有版本、序列号、时间戳、来源和有效期的结构化命令。例如：

JogCommand {
    device_id,
    axis,
    direction,
    velocity,
    duration,
    deadman,
    sequence,
    timestamp,
    valid_until
}

协议应区分请求已生成、已排队、已接受、执行中、已完成、已取消、被拒绝和执行状态未知。对于轨迹任务，应优先使用 ROS 2 Action 或等价的长事务机制，以支持反馈、取消和最终结果；持续遥测使用 topic；短时状态转换使用 service。

ROS 2 适配层负责将领域协议转换为 topic、service、action、参数和生命周期操作。它不应暴露寄存器地址、厂商私有错误码或具体驱动线程模型。设备连接时应首先进行能力协商，发布轴数、最大速度、支持的控制模式、轨迹格式和故障复位条件。

控制与硬件层运行在 Linux、实时控制器、MCU 或其他专用执行环境中，负责轨迹插补、控制周期、资源管理、最终限位检查和安全停机。ROS 2 资料所描述的毫秒级运动周期目标[25]，不能迁移为 Win11 GUI 的性能承诺。

仿真与验证层采用 OpenRAVE 或其他规划器生成候选路径，MuJoCo 验证动力学、接触、摩擦和执行器响应，ros2_control 统一控制接口，Rerun 进行旁路记录和可视化。Rerun 进程崩溃、磁盘不可写或记录延迟不应改变控制器的安全行为。

部署过程必须固化以下版本信息：

Win11 版本和系统策略；
Rust 工具链；
MSVC 与 Visual C++ 运行库；
ROS 2 发行版；
RMW 实现；
DDS XML 配置版本；
Docker 镜像摘要；
GPU、USB、串口、CAN 和厂商驱动版本；
机械臂固件和模型版本；
控制协议版本。

启动脚本应先执行环境自检，包括网络接口、Domain ID、RMW、DDS 配置、节点发现、QoS 兼容性和设备健康状态。只有在自检完成且生命周期状态达到允许条件后，系统才可进入 Active。不能依赖开发者终端中的临时环境变量，也不能把反复执行 ros2 daemon restart 当作根因修复方案[16][24]。

实验设计与评估

为验证上述假设，建议采用分阶段、分层次的实验设计。

1. GUI 响应性实验

在 Win11 不同硬件、GPU 后端、电源策略和显示缩放配置下，测量四类延迟：

[
T_{ ext{total}} =
T_{ ext{input}}+
T_{ ext{model}}+
T_{ ext{submit}}+
T_{ ext{device}}
]

其中，T_input 为输入事件到应用模型更新时间，T_model 为状态机生成命令的时间，T_submit 为命令进入通信队列的时间，T_device 为控制器或设备实际响应时间。应报告 P50、P95、P99、最大值和异常事件比例，而不能只报告平均帧率。

测试条件应包括 CPU 高负载、GPU 驱动重置、DDS 流量增加、窗口失焦、最小化、锁屏、显示器热插拔、通信断开和 Jog 按钮释放。关键评价问题包括：释放事件是否可靠捕获，停止命令是否有界到达，失联后界面是否进入明确的未知或失效状态。

2. 网络与 DDS 实验

建立正交测试矩阵，比较：

Linux 原生 Docker、Docker Desktop、WSL2 和虚拟机；
host、bridge 和自定义网络模式；
CycloneDDS 与 Fast DDS；
有线、Wi-Fi 和热点网络；
不同 ROS 2 发行版组合；
不同 Domain ID 和 QoS 配置；
防火墙开放与受限状态。

评价指标包括 Participant 发现成功率、首次发现时间、重连时间、主题与服务可见率、双向多播成功率、消息丢失率和节点重启后的恢复时间。基础 ping 成功不能作为 ROS 2 发现成功的替代指标[4][5]。

3. 生命周期与协议实验

对 Connect、Configure、Enable、Jog、ExecuteTrajectory、Stop、ResetFault 进行状态转换测试。每个命令应分别测试正常、重复、过期、乱序、超时、取消和执行状态未知等情况。

重点指标包括：

非法状态下的拒绝率；
重复命令的幂等性；
过期 Jog 的拒绝率；
Stop 命令的最大收敛时间；
反馈丢失后进入安全状态的时间；
驱动器重启后状态机是否能够恢复；
执行状态未知时是否避免盲目重试。

特别需要测试“命令已发送但结果未知”的情况，因为这比明确失败更危险。协议必须能够返回 UNKNOWN_EXECUTION_STATE，并要求系统进入人工确认或安全恢复流程。

4. 仿真—真实一致性实验

使用相同控制器、相同轨迹和相同初始状态，分别在 Fake Driver、MuJoCo 和真实机械臂上执行任务。评价指标包括：

轨迹完成率；
末端位置和姿态误差；
关节位置、速度和加速度峰值；
控制周期抖动；
状态—命令端到端延迟；
接触冲击和力矩峰值；
软限位与硬限位触发一致性；
故障响应时间；
真实系统与仿真结果的误差分布。

仿真模型参数应通过质量、惯量、摩擦、阻尼、回差、工具质量和接触参数辨识逐步校准，而不是预先假定高保真模型天然可靠。

5. UX 与操作员评估

用户研究应覆盖新手、熟练操作员、维护人员和具有不同无障碍需求的用户。典型任务包括连接设备、确认能力、使能、低速 Jog、提交轨迹、取消任务、处理故障和恢复通信。

评价指标包括任务完成率、首次点击正确率、完成时间、误操作率、重复提交率、错误恢复成功率、状态理解度、主观信心和认知负荷。对于颜色与设计系统，还应测试深色模式、色觉差异、动态字号、键盘操作、焦点状态和中英混排。经典 UX 规律应被写成可检验假设，而不是直接作为设计规范[7][8][17][18]。

结果与发现

综合各类材料后，可以形成七项主要发现。

发现一：架构可行性高，但实时性不能由 GUI 框架推导

Rust、eframe/egui、ROS 2、C++ 和 MuJoCo 在功能上可以组成完整系统。eframe/egui 适合构建状态面板、参数编辑、日志和诊断页面[12][13][14]；ROS 2 提供跨进程、跨主机和跨语言通信基础[3][25]；ros2_control 提供仿真与真实硬件共享控制接口的路径[1][10]。

但资料没有提供 Win11 上的输入延迟分布、GPU 异常数据或确定性调度证明。因此，可以支持“适合作为操作员界面”的结论，不能支持“适合作为硬实时控制器”的结论。界面视觉上立即变化，只能说明输入与渲染路径较快，不代表设备已经执行命令。

发现二：网络发现是桥接系统的首要前置条件

跨 Win11、Docker Desktop、Linux 容器和外部设备的 ROS 2 通信，最脆弱的环节往往是 DDS 多播发现，而不是业务逻辑。虚拟网络、Docker utility VM、WSL2、无线接入点和 Windows 防火墙可能阻断发现报文[4][5][6]。

一个具有解释力的失效链是：

多播被阻断
→ DDS Participant 无法发现
→ ROS 2 图不完整
→ 服务或主题不可见
→ 应用层超时
→ 故障被误判为驱动或设备异常。

因此，启动前的网络验证不是运维附加项，而是控制链路的安全前提。显式指定 DDS 网络接口、统一 Domain ID、验证双向多播以及固化防火墙规则，比依赖默认自动发现更适合生产环境[3][6]。

发现三：版本兼容性必须分维度验证

材料中出现 Jazzy 与 Humble 能够通信的案例，也出现 CycloneDDS 配置可能不兼容的社区判断[23][24]。表面上的矛盾说明“ROS 2 版本兼容”不是二元属性。

至少应分别验证：

消息与服务定义是否一致；
RMW 实现是否一致；
DDS 配置语法是否匹配；
DDS-XTypes 或序列化机制是否兼容；
QoS 是否兼容；
网络发现是否成功；
CLI 工具是否正确读取图状态。

因此，DDS XML 配置必须像源代码一样进行版本控制、语法校验和升级测试。Jazzy 环境中出现旧式网络接口配置弃用警告的案例[3]进一步说明，部署配置具有版本语义，不应长期依赖复制粘贴的历史文件。

发现四：生命周期状态是安全能力模型

进程运行不等于设备可控。桥接节点至少应区分 Unconfigured、Inactive、Active、Deactivating 和 Error/Finalized 状态[15]。连接、使能、Jog 和轨迹执行必须受到状态机约束。

其中，Enable 不应被实现为按钮点击后立即假定成功，而应经过设备连接、急停状态、权限、控制器激活和健康检查。Jog 需要死手机制、短时有效期、控制器端超时和失焦停止策略。轨迹任务则应采用可反馈、可取消的长事务模型。

这一发现将生命周期从“启动管理功能”重新解释为“能力授权和故障隔离机制”。它能够有效防止界面继续显示“已连接”或“已使能”，而底层设备实际上已经失联。

发现五：稳定协议比语言统一更重要

Rust 和 C++ 并不是必然冲突的技术路线。Rust 在应用层适合实现状态机、错误传播和并发约束；C++ 与 ROS 2 Control 生态适合复用成熟控制器和硬件驱动。真正决定维护成本的是边界是否稳定。

最危险的设计是 UI 回调直接调用硬件驱动，或通过共享可变对象实现复杂双向 FFI。这会把窗口生命周期、线程调度、驱动资源和错误处理耦合在一起。更稳健的方式是采用消息、C ABI 或进程边界，并优先通过稳定的 ROS 2 topic、service 和 action 暴露硬件无关领域语义。

发现六：接口同构比单纯追求仿真保真度更重要

MuJoCo 接入 ros2_control 的价值在于让控制器面对统一硬件接口[10]。这为仿真—真实迁移提供了结构基础。但接口一致不等于行为等价。

必须同时验证语义、时间、状态、物理和故障五个维度。仿真中无碰撞的轨迹可能在真实设备上因回差、摩擦、线缆、延迟或环境模型不完整而失败。相较于一开始追求极高的物理保真度，一个严格复用真实控制接口、生命周期和故障语义的中等保真仿真平台，往往更适合早期验证。

发现七：设计系统应被视为安全与认知基础设施

用户研究、任务流程、原型和可用性测试的共同价值，不只是让界面更美观，而是将高成本的后期错误提前转化为低成本的学习事件[17][18][19]。在机器人控制界面中，UX 质量直接影响操作员是否理解当前状态、是否知道命令结果以及能否在故障中正确恢复。

设计系统也不应仅包含颜色、字体和按钮。完整系统需要包括交互状态、反馈语义、错误等级、无障碍规则、内容规范和代码实现约束[20][21]。颜色必须与文字、图标或形状共同表达状态，不能仅依赖红绿区分成功与失败[21]。排版系统则需要特别处理中文字体、动态字号、中英混排和长文本错误提示，这些内容在现有材料中明显不足。

建议将结果呈现为三类可视化：

端到端时序图：展示输入、应用命令、DDS 传输、控制器接受、设备执行和状态回传的时间关系；
状态转换图：展示连接、使能、Jog、轨迹和故障的合法与非法转换；
仿真—真实差异图：比较相同轨迹下的位置误差、控制周期、命令延迟和故障响应时间。

批判性分析与讨论

现有证据支持该技术路线的结构性可行性，但不支持其已经达到工业成熟、硬实时或功能安全认证水平。eframe/egui 的资料主要证明开发便利与平台支持；ROS 2 的官方资料证明通信和生命周期机制存在；项目仓库证明 MuJoCo 可以接入 ros2_control；UX 行业材料证明研究、原型和设计系统具有实践价值。它们共同构成了合理的工程基础，却没有提供统一条件下的性能基准、统计重复实验或安全验证数据。

最重要的因果机制可以概括为四条链路。

第一，网络可见性影响控制可用性。如果 DDS 发现失败，应用便无法获得可信设备状态。此时继续显示最后一次有效状态，会形成信息危险；正确做法是进入失联或状态未知。

第二，状态机影响命令安全性。若 Enable、Jog 和 Trajectory 只是按钮回调，系统无法表达前置条件、执行反馈和取消语义。显式状态机能够把非法操作转化为可解释拒绝，并使故障收敛路径可测试。

第三，协议边界影响维护风险。如果界面暴露设备寄存器或厂商错误码，硬件替换将波及上层；如果协议只返回布尔值，维护人员又无法判断命令究竟是网络失败、状态拒绝还是硬件故障。稳定协议必须同时支持能力协商、错误分类、幂等性、超时和执行状态未知。

第四，UX 表达影响人因风险。即使底层状态机正确，若界面将通信失联显示为“设备空闲”、将软件停止设计为红色急停按钮，或通过颜色单独传递故障等级，仍可能诱导错误判断。由此，UX 并非控制系统外部的装饰层，而是系统可解释性和人因安全的一部分。

材料之间的矛盾也具有方法论价值。关于 Jazzy 与 Humble、CycloneDDS 配置和容器网络的不同报告，不应被视为谁“说得对”的简单争论，而应转化为正交实验设计。兼容性可能取决于发行版、RMW、网络模式、接口选择、QoS 和防火墙的交互作用。类似地，行业案例中“UX 改进带来商业成功”的叙述不能直接证明因果关系。Baymard 的结账基准具有较高实践价值，但其潜在转化收益估计不等于在任意产品中都能重复获得的实验结果[22]。

本研究的主要限制包括：

原始材料缺少统一访谈协议、参与者数量和样本结构；
缺乏 Win11、Docker 和 DDS 组合下的定量基准；
缺少具体机器人型号、控制周期、负载和安全等级；
仿真—真实比较没有统一任务、参数和统计方法；
UX 材料多为二手文章、行业案例和成功者叙述；
排版、辅助技术、长期运维和组织治理的资料不足；
部分来源存在时间、版本和内容完整性需要进一步核验的问题。

因此，当前结论应被视为高可信工程假设和架构决策依据，而非认证结论。后续研究应采用硬件在环测试、故障注入、纵向用户研究、A/B 实验和跨平台基准测试，建立可重复的证据链。

战略含义与建议

1. 明确产品定位与安全边界

应将 Win11 Rust/eframe/egui 应用明确定位为非安全、非硬实时的操作员站。它可以负责展示、确认、任务提交、诊断和记录，但不应承担轨迹插补、硬实时闭环、最终限位判断或安全急停。安全互锁、控制周期、驱动器保护和最终停止路径必须位于实时控制器、硬件接口或独立安全系统中。

2. 优先建设稳定的应用协议

建议以 Connect、Configure、Enable、Jog、ExecuteTrajectory、Stop、ResetFault 和 FaultReport 作为协议核心。每条命令应具有：

request_id；
device_id；
时间戳和有效期；
预期生命周期状态；
序列号；
参数版本；
结构化结果码；
人类可读诊断信息。

协议不得暴露厂商寄存器、驱动线程或具体语言对象。设备连接时进行能力协商，允许不同型号在同一抽象接口下声明不同功能。

3. 将网络配置纳入产品化交付

部署包应自动检查网卡、Domain ID、RMW、DDS XML、发现范围、QoS 和防火墙。网络测试必须区分 ICMP、UDP、多播、DDS Participant、ROS 2 图和业务健康检查。CycloneDDS 或其他显式接口配置可以作为工程选项，但必须经过目标网络环境的长期压力测试，不能将单次成功视为充分证据[3][4][5]。

4. 建立仿真—真实分阶段路线

推荐四阶段实施：

接口基线：统一 URDF/MJCF、关节名称、单位、控制模式和生命周期语义。
规划—动力学联合验证：规划器生成轨迹，MuJoCo 检验动力学和接触，ros2_control 执行统一控制接口。
故障与安全验证：注入丢包、延迟、传感器冻结、控制器崩溃、时钟异常和碰撞。
受控真实迁移：低速、低负载、软限位和物理隔离条件下逐步提升任务复杂度。

Rerun 应作为旁路记录和审计层，记录状态、命令、轨迹、碰撞和故障事件，但不能成为控制闭环的必要依赖。

5. 把 UX 研究纳入系统工程流程

用户研究应围绕真实任务，而非抽象偏好。重点测试连接、使能、Jog、轨迹取消、故障恢复和通信失联等高风险流程。将费茨定律、希克定律、心智模型和峰终定律转化为具体假设，并以完成率、错误率、状态理解度和恢复成功率验证[7][8][17][18]。

设计系统应包含：

颜色和语义化 Color Token；
状态灯、警告、故障和反馈组件；
中文与英文排版规则；
键盘、焦点、触控和辅助技术支持；
错误信息和恢复文案；
深色模式、高对比度和动态字号规范；
组件与代码之间的实现契约。

6. 建立生产化验收门槛

生产验收不应以“GUI 能启动”“节点能发现”或“仿真轨迹成功”为标准，而应至少包括：

P95、P99 和最大输入—命令延迟；
DDS 首次发现与重连时间；
QoS 兼容性自动检查；
非法状态命令拒绝率；
Jog 释放与通信超时后的停止收敛时间；
执行状态未知时的安全处理；
仿真—真实轨迹误差；
故障注入后的安全状态响应；
可回滚安装和版本锁定；
日志、时间戳和故障事件可重建；
Rerun 失效时控制系统仍能安全运行；
无障碍与多用户群体可用性测试。

总体战略结论是：不要追求单一语言、单一操作系统或单一工具包解决全部问题，而应追求异构系统中的边界清晰、语义稳定、时序可测和故障可解释。 Rust + eframe/egui 适合构建现代操作员应用；ROS 2 与 DDS 适合提供分布式通信基础；生命周期节点适合管理能力状态；ros2_control 适合统一仿真和真实执行接口；OpenRAVE 适合规划与 IK；MuJoCo 适合动力学验证；Rerun 适合记录与审计。该组合的成功与否，最终取决于这些工具能否在统一协议、状态机、测试体系和安全架构下协同工作。

Conclusion

本报告围绕机器人操作员界面、Win11—Linux 容器通信、仿真—控制工具链、UX 方法论及设计系统展开综合评估，形成了一个共同结论：系统成熟度不取决于单一框架或工具的先进性，而取决于职责边界、接口契约、验证机制与故障处理是否清晰可控。

在控制系统层面，Rust + eframe/egui 适合承担非安全、非硬实时的操作员界面；ROS 2、C++ 适配层和专用控制器则应负责通信、生命周期、轨迹执行与硬件控制。Win11 与 Linux 容器之间的可靠通信必须通过 Domain ID、DDS 配置、网络接口、防火墙和 QoS 的协同验证来保证，不能依赖默认发现机制。对于机械臂系统，OpenRAVE适合离线规划与 IK，MuJoCo负责动力学和接触仿真，ros2_control构成统一执行边界，Rerun承担记录、回放与审计，而不应进入安全闭环。

在产品与体验层面，经典 UX 定律、用户研究、原型测试和持续迭代应被组织为证据链；设计系统则应同时服务于品牌一致性、可用性、开发协作和无障碍，而非追求表面统一。由于现有资料以行业文章、项目文档和社区经验为主，尚不足以证明实时性能、仿真—真实等价性或商业因果关系。最终生产化仍需依靠延迟基准、故障注入、硬件在环、可用性测试、版本锁定和分阶段部署加以验证。

Sources

[1] ROS 2 Control， “ros2_control”，官方框架文档，https://control.ros.org

[2] Michael-Jetson， “ros2_control与硬件驱动”，Robotics Tutorial，GitHub，https://github.com/Michael-Jetson/Robotics_Tutorial/blob/main/05_%E8%BF%90%E5%8A%A8%E6%8E%A7%E5%88%B6/20_%E6%9C%BA%E6%A2%B0%E8%87%82/M12_ros2_control%E4%B8%8E%E7%A1%AC%E4%BB%B6%E9%A9%B1%E5%8A%A8.md

[3] Open Robotics， “About Domain ID”，ROS 2 Jazzy Documentation，https://docs.ros.org/en/jazzy/Concepts/Intermediate/About-Domain-ID.html

[4] SakshayMahna， “ROS 2 environment and multicast discovery discussion”，GitHub Discussions，https://github.com/SakshayMahna/ros2env/discussions/26

[5] Docker Community Forums， “Ubuntu Docker container in Windows host cannot match host IP address”，https://forums.docker.com/t/ubuntu-docker-container-in-windows-host-cannot-match-host-ip-address/136516

[6] NVIDIA Developer Forums， “Intermittent ROS 2 Humble issues in Docker / dustynv on Jetson AGX Orin”，https://forums.developer.nvidia.com/t/intermittent-ros-2-humble-issues-in-docker-dustynv-on-jetson-agx-orin-l4t-34-1-1/363798

[7] 墨刀（MoDao），〈入门必看！UI设计师不可错过的交互设计理论〉，https://modao.cc/ad/blog/UI-design-theory.html

[8] 博客园，〈52 Design Principles of Xiaohongshu〉，https://www.cnblogs.com/88223100/p/52-Design-Principles-of-Xiaohongshu.html

[9] Seeed Projects， “Borot-Arm MuJoCo Project Architecture”，GitHub，https://github.com/Seeed-Projects/Borot-Arm_Mujoco/blob/main/PROJECT_ARCHITECTURE_ZH.md

[10] ros-controls， “mujoco_ros2_control”，GitHub，https://github.com/ros-controls/mujoco_ros2_control

[11] CSDN，〈基于ROS2通信框架与MuJoCo高精度物理引擎的四自由度机械臂仿真系统〉，https://blog.csdn.net/weixin_33506815/article/details/163934656

[12] 技术栈网站，〈Rust GUI：eframe + egui 摄氏度与华氏度互转工具案例〉，https://jishuzhan.net/article/1985894142862491649

[13] Re-Ch-Love，egui-doc-cn：egui 中文文档，GitHub，https://github.com/Re-Ch-Love/egui-doc-cn/blob/main/README_zh-hans.md

[14] Gitblog，〈egui：基于 Rust 的即时模式 GUI 库入门示例〉，2026-01-25，https://blog.csdn.net/gitblog_00643/article/details/157377848

[15] 知乎专栏，〈ROS 2 生命周期节点与 onConfigure 回调〉，https://zhuanlan.zhihu.com/p/682574842

[16] ROS 2 教学视频，〈ROS 2 中可执行文件与 launch 文件的安装和发现机制〉，YouTube 视频转录，https://www.youtube.com/watch?v=UhIh6PUvmkE

[17] TMDesign， “UX Design Principles for Optimal User Experience”，They Make Design，Medium，https://medium.com/theymakedesign/ux-design-principles-for-optimal-user-experience-6fa507b9dffe

[18] Mika, Alex; reviewed by Michael Chu， “Digital Product Design Principles”，Ramotion，https://www.ramotion.com/blog/digital-product-design

[19] Dapth， “Why Is UX Research Important?”，https://dapth.com/insights/why-is-ux-research-important

[20] Constance Tang，〈Design System Ecosystem：品牌指南與設計系統〉，2022-01-15，https://constance-tang.com/2022/01/15/design-system-ecosystem

[21] Constance Tang，〈設計系統｜使用色彩系統創造品牌視覺和無障礙設計〉，2022-05-23，https://constance-tang.com/2022/05/23/color-system

[22] Baymard Institute， “The Current State of Checkout UX”，https://baymard.com/blog/current-state-of-checkout-ux

[23] Open Robotics Discourse， “Build a MuJoCo + ROS2 Robotic Arm Workflow for Embodied AI”，https://discourse.openrobotics.org/t/build-a-mujoco-ros2-robotic-arm-workflow-for-embodied-ai/55012

[24] Husarion Community， “ROS 2 tutorials Dockerized approach: topics not showing locally”，https://community.husarion.com/t/ros-2-tutorials-dockerized-approach-topics-not-showing-locally/2014

[25] Kwan Wai-Pang，ROS2：ROS1 与 ROS2 的架构、通信机制和跨平台能力比较，https://kwanwaipang.github.io/ROS

[26] Nielsen Norman Group， “Mobile Checkout UX”，https://www.nngroup.com/articles/mobile-checkout-ux

[27] The Marketing Agency， “Game-Changing UX Case Studies”，https://themarketingagency.ca/blog/game-changing-ux-case-studies

[28] 杜传虎，〈设计系统中的颜色规范建立方法〉，2019-09-03，http://duchuanhu.com/blog/archives/article06_20190903.html

[29] DFKI Robotics Innovation Center， “Mujoco ROS2 Control”，GitHub，https://github.com/dfki-ric/mujoco_ros2_control

[30] Yangykaifa，〈MoveIt2运动规划与ROS 2控制接口〉，https://www.cnblogs.com/yangykaifa/p/19369735

[31] 人人都是产品经理，〈UI设计中的颜色、布局与排版规范〉，https://www.woshipm.com/pd/4176766.html

[32] “Usability Testing of Sharing Files on Dropbox”，UX Planet，https://uxplanet.org/usability-testing-of-sharing-files-on-dropbox-6fd9bfc0dd6b

[33] Fu, F.， “Usability Test Involving Two Current Popular Cloud File Storage Systems: Google Drive and Dropbox”，University of North Carolina repository，2013，https://cdr.lib.unc.edu/downloads/xk81jq162