摘要

面向机器人研发与工业自动化的应用软件，既要为操作员提供直观、稳定的交互界面，又要适应不同品牌机器人、驱动器和传感器形成的硬件异构环境，同时还需要支持规划验证、动力学仿真、运行记录和故障追溯。本文提出一种分层架构：在 Win11 上使用 Rust 与 eframe/egui 构建操作员界面，以与硬件无关的控制协议表达设备连接、控制请求、任务状态和故障语义；由 ROS 2 Jazzy 桥接节点负责协议校验、命令映射、状态反馈以及仿真与实机隔离；通过 Docker 封装 ROS 2 图、设备驱动、规划、仿真和记录环境；使用 OpenRAVE 承担几何规划、逆运动学和碰撞检查，使用 MuJoCo 承担动力学、接触和控制器仿真，使用 Rerun 进行运行数据记录、可视化与回放。急停、门禁、限位、STO 等安全功能则置于独立安全域，不依赖 Win11、Docker、普通 ROS 2 通信或 Rerun。

需要特别强调，上述技术栈的价值在于职责分离和接口解耦，而不是把桌面应用、通信中间件或可视化工具直接升级为硬实时控制器。本文中的总体分层属于既定架构结论；具体组件版本、设备接口、实时性能和 Seeed Studio 产品兼容性，则应以项目选型、官方资料和现场测试为准。

1. 背景与总体架构

工业机器人系统通常同时存在五类需求。第一，操作员需要在设备连接、模式切换、Jog、轨迹任务和故障处理之间快速完成操作，界面必须能够清晰展示设备状态，并降低误操作概率。第二，机器人本体、伺服驱动器、末端执行器和传感器可能来自不同供应商，如果上层界面直接绑定厂商私有接口，后续替换硬件将导致大量软件重构。第三，轨迹和控制器需要在进入实机前经过逆运动学、碰撞检查和动力学验证。第四，系统应保留任务、状态、传感器、故障及软件版本信息，以支持调试、复盘和质量追溯。第五，安全停机必须具有独立性，不能因界面崩溃、容器重启或网络中断而失效。

据此，系统可划分为六个相互协作但边界明确的层次。最上层是 Win11 操作员交互层，由 Rust 应用和 eframe/egui 界面组成，负责显示状态、组织任务和提供操作入口。Rust 可用于实现客户端内部的状态管理、协议客户端和传输适配，但 Win11 界面刷新、用户输入和普通网络通信均不应被视为确定性控制周期。

第二层是 硬件无关的控制协议层。该层描述连接会话、控制权、伺服使能、运动许可、Jog、轨迹、停止、故障、心跳和审计等领域语义，向上承接操作员意图，向下屏蔽不同设备驱动的实现差异。第三层是 ROS 2 Jazzy 桥接层，负责协议校验、命令转换、任务反馈、会话管理、超时与重连，并将抽象命令映射到 Docker 内 ROS 2 图中的驱动或执行节点。

第四层为 ROS 2 运行环境。其中可部署机器人驱动、状态聚合、传感器节点、规划适配器、仿真适配器和记录节点；Docker 的作用是封装依赖和部署环境，而不是自动提供硬实时能力。第五层为 规划与仿真层：OpenRAVE 面向几何规划、IK 和碰撞检查，MuJoCo 面向动力学与控制仿真。第六层为 记录与分析层，Rerun接收状态、轨迹、坐标系、传感器和事件数据，用于查看与事后分析，但不参与实时控制闭环。

在所有软件层之外，还应设置独立的 安全域。急停、门禁、限位、STO、驱动保护和安全状态机由安全控制器、继电器或驱动器安全功能承担。软件系统可以报告、解释和记录安全状态，却不能替代这些独立安全机制。Seeed Studio 的相关硬件在本文中仅作为可替换的边缘计算、视觉或传感器集成节点；具体型号、接口、性能及 ROS 2 兼容性均属于待核验事项，不在缺少来源时作确定性承诺。

2. 与厂商和现场总线无关的控制协议设计

控制协议的核心不是复述某一类机器人控制器的寄存器或通信帧，而是定义上层“操作意图”、设备“能力状态”和任务“执行结果”。因此，协议应将设备驱动的厂商接口、现场总线及电气实现隐藏在适配层之后，对上提供稳定且可审计的领域模型。具体硬件支持的关节范围、速度限制、使能条件和故障复位方式属于项目待验证项，不应在通用协议中预设为统一实现。

2.1 会话、身份与状态语义

客户端首先通过 Connect 建立逻辑会话，提交 client_id、用户身份、协议版本、软件版本、目标设备标识和能力声明。服务端返回唯一的 session_id、允许的权限集合、设备能力摘要和会话有效期。协议版本必须显式协商；对于不兼容的主版本，应拒绝建立控制会话，而不是静默降级。

连接状态与设备状态必须分开表示。至少应区分：

• Disconnected：没有有效会话；
• Connected：通信会话已建立；
• Degraded：通信仍在，但状态不完整或部分能力不可用；
• Lost：心跳超时或连接中断；
• DeviceOffline：目标设备本身未被驱动确认在线。

同样，以下条件不能互相替代：连接成功只表示协议端点可通信；获得控制权表示当前客户端有权提交控制命令；伺服已使能表示驱动器接受了使能请求；允许运动则还必须满足安全链路、模式、限位、故障状态和设备约束等条件。控制权释放、会话断开或权限撤销后，系统应禁止新的运动命令，既有任务如何暂停或停止则由设备策略和项目验证结果确定。

会话应采用心跳机制维护。每次命令和心跳均携带 session_id、序列号及发送时间；连续超时后，桥接服务应将会话标记为失效并拒绝其后续控制请求。重连不得默认恢复控制权、伺服使能或原任务执行权，客户端必须重新完成身份确认、权限检查和控制权获取。

2.2 命令生命周期与运动操作

所有改变设备状态的请求都应具有唯一 command_id，并遵循“请求—确认—执行中—完成/拒绝/失败”的生命周期。确认仅代表服务端已接收并通过初步格式检查，不代表动作已经发生；执行结果必须由设备或任务执行节点反馈。对于网络重试，服务端应依据 command_id 实现幂等处理，重复请求返回原命令状态，不得因重传造成重复运动。

Jog 命令建议分为 JogStart、JogUpdate 和 JogStop。请求中应包含目标设备、关节或坐标系、方向、速度限制、操作者、会话和有效期。服务端必须重新检查控制权、使能状态、运动许可及软限位；失去心跳、命令过期或安全条件不满足时，应拒绝新请求，并按项目定义结束当前 Jog。Jog 不应只依赖界面按钮释放作为停止条件。

轨迹操作可分为 UploadTrajectory、ValidateTrajectory、ExecuteTrajectory、Pause、Resume、Cancel 和 Stop。轨迹对象至少包括任务 ID、版本号、坐标系、工具信息、关节位置以及可选的速度和加速度约束。上传成功不等于允许执行；执行前必须完成格式、时间参数、关节范围、碰撞、设备能力和当前状态检查。暂停表示任务暂不继续，恢复必须重新确认状态；取消表示放弃未完成任务；停止则表示要求尽快结束运动，其具体减速方式、保持方式和故障后果属于设备与安全策略的待验证内容。

2.3 故障、权限与审计

故障对象应包含 fault_id、来源、严重等级、发生时间、关联设备、任务 ID、是否锁存、是否需要复位及恢复提示。ResetFault 只能清除协议层允许复位的故障，不能绕过安全回路或强行解除驱动保护。急停、门禁、限位、STO 和安全状态机必须位于独立安全域，由其决定最终安全动作；软件协议最多报告这些状态，并据此拒绝运动。

权限至少应覆盖观察、Jog、轨迹执行、参数修改和故障复位等操作。每次请求及结果都应记录用户、客户端、会话、目标设备、命令 ID、参数摘要、时间戳、协议版本、结果码和软件配置版本。对过期命令、权限不足、模式不符、状态冲突、通信超时和设备拒绝应使用可区分的错误码，便于界面提示、自动恢复和事后审计。具体超时阈值、复位流程及硬件安全条件则必须通过项目测试和现场验收确定。

3. Win11 操作员界面、ROS 2 Jazzy 桥接节点与 Docker 部署

在前述控制协议中，连接、控制权、伺服使能、运动许可和任务执行已经被定义为相互独立的语义。落到系统实现时，推荐采用如下端到端链路：

Win11 Rust/eframe/egui 客户端
↓ 外部双向传输
ROS 2 Jazzy 桥接节点
↓ ROS 2 Topic / Service / Action
Docker 内 ROS 2 图
├── 设备驱动与状态节点
├── 规划、IK 适配节点
├── MuJoCo 仿真适配节点
└── 记录与诊断节点
↓
机器人、驱动器、传感器及其他设备

其中，Win11 客户端负责操作员交互，桥接节点负责协议边界和接口转换，Docker 负责运行环境封装，ROS 2 图负责组织节点通信。设备厂商协议、现场总线和具体硬件访问方式应被限制在驱动或设备适配层内，避免上层界面直接依赖某一家厂商的私有接口。

3.1 Win11 客户端与外部传输

Rust/eframe/egui 客户端适合实现设备选择、状态总览、Jog 面板、轨迹任务管理、故障提示、参数编辑和命令反馈。界面中的按钮或输入框只产生操作意图，不应直接操作电机寄存器、驱动器控制周期或安全输入。尤其不能把窗口刷新频率、按钮状态或网络往返时间当作运动安全条件。

客户端内部宜划分为四层：

eframe/egui 视图
↓
应用状态 / ViewModel
↓
控制协议客户端
↓
TCP、WebSocket、gRPC 或其他传输适配器

UI 层处理绘制和用户输入，ViewModel 维护显示状态，协议客户端负责请求封装、响应匹配和命令状态管理，传输适配器则负责连接、收发和断线报告。会话认证、权限校验、命令去重、超时与重连不能被归因于 eframe/egui 的固有能力，而应由客户端与桥接节点共同实现，且以桥接节点的校验结果为准。

外部传输可以根据项目约束选择。TCP 依赖较少，但需要自行定义消息边界、双向事件、认证和重连语义；WebSocket 适合持续双向连接和状态推送，但需验证长连接、代理及断线恢复；gRPC 便于定义结构化请求、响应和流式反馈，但会引入相应运行库和部署依赖；自定义协议则适合特殊审计和时序要求，却增加开发、测试及长期维护成本。无论采用何种方式，传输可达性都不等于硬实时控制能力。

3.2 桥接节点职责与 ROS 2 接口映射

桥接节点不是简单的消息转发器。在请求进入 ROS 2 图之前，它应检查协议版本、会话有效性、用户权限、目标设备、仿真或实机模式、命令有效期、参数范围和 command_id 是否重复；在请求执行后，还要将 ROS 2 的接受、执行、完成、拒绝或失败状态转换为控制协议中的统一反馈。

其处理流程可概括为：

接收请求 → 协议解析 → 会话/权限检查
→ 参数和设备状态检查 → 幂等与超时检查
→ 映射 ROS 2 接口 → 汇总反馈与结果 → 审计记录

桥接节点还应管理断线重连。客户端重新连接后，必须重新认证并同步设备状态，不能使用旧会话自动恢复控制权、伺服使能或未完成轨迹。仿真与实机应使用不同的设备标识、命名空间、配置和权限；必要时进一步使用不同的 ROS 域或网络分区，防止仿真命令误达真实驱动。

ROS 2 接口的选择应由业务生命周期决定：

QoS、队列深度、可靠性、时间戳和发现配置应按状态广播、控制确认、任务反馈和故障事件分别评估。具体消息类型、QoS 组合及驱动兼容性属于项目待验证项，不能仅凭节点能够发现或消息能够传输，就推断已经具备确定性实时性能。

3.3 Docker 部署与软实时限制

Docker 的合理定位是封装 ROS 2 Jazzy、驱动、规划、仿真和记录环境，便于固定依赖、复现部署和区分测试配置，但容器本身不自动提供硬实时调度。部署时需要验证 DDS 发现范围、ROS_DOMAIN_ID 或其他域隔离配置，以及主机网络和桥接网络对组播、端口、跨主机通信和防火墙的影响。主机网络可能简化发现配置，却会扩大网络暴露面；桥接网络便于隔离和管理，但必须实测发现、重连、延迟、抖动和丢包行为。

驱动容器还可能需要映射 USB、串口、相机、CAN 或其他现场设备。应逐项确认设备节点权限、热插拔、断线重连、主机内核依赖和多节点访问冲突。GPU、特权容器和额外 capability 也只能按需启用，优先采用最小权限原则；仿真和记录容器不应获得真实执行器的设备权限。上述硬件兼容性、现场总线访问方式、GPU 配置和网络模式均须结合目标主机验证。

容器与主机的时间、仿真时间、传感器时间戳和日志时间应统一规划。配置、日志、录包、审计记录和任务恢复信息不能只保存在容器可写层，应通过明确的数据卷或主机目录持久化，并制定容量、轮换和权限策略。容器或桥接节点重启后，系统应重新发现设备、校验会话、同步状态并确认控制权；自动重启不应自动继续未完成的运动任务。

最后，Docker、Win11、普通 ROS 2 通信和桥接节点都只能承担软件控制与集成职责，不能替代急停、门禁、限位、STO、驱动保护或独立安全状态机。网络延迟、抖动、队列积压、容器调度和实时控制指标必须通过项目测试确定，不能由框架、通信机制或容器化部署方式推导得出安全结论。

4.4 OpenRAVE、MuJoCo 与 Rerun 协同

在前述 ROS 2 Jazzy 分层架构中，规划、仿真和记录系统不应直接共享真实设备的执行权限，而应通过适配器和验证器与控制链路连接。本文将 OpenRAVE、MuJoCo 和 Rerun 分别定位为几何规划与 IK 组件、动力学仿真组件以及运行观测与记录组件。三者可以共同提高机器人任务的验证效率，但任何规划结果、IK 解或仿真输出，都不能未经约束检查和现场确认直接驱动真实机器人。

4.4.1 组件职责边界

架构设计： OpenRAVE 位于规划侧，主要处理机器人几何模型、目标位姿、逆运动学、路径规划和碰撞检查等问题。它产生的是候选关节解或候选路径，用于离线规划、模型验证和任务准备，不拥有真实设备的控制权。其具体版本、模型格式、求解器配置、维护状态以及与 ROS 2 Jazzy 的适配方式，属于项目待验证项。

MuJoCo 位于动力学仿真侧，用于在给定模型和控制参数下观察刚体运动、接触、摩擦、执行器响应、传感器输出和轨迹跟踪行为。工程推断： 它可以帮助发现几何规划无法揭示的动态问题，例如控制输入过大、跟踪误差、接触冲击或负载变化下的响应异常，但仿真结果依赖模型参数，不能等同于真实驱动器和机械系统的实际表现。其模型接口、控制器接入方式及 ROS 2 适配关系同样需要结合目标版本核验。

Rerun 处于观测链路，用于记录关节状态、规划轨迹、实际轨迹、TF、传感器数据、任务事件和故障上下文，并提供查看、回放和事后对比分析。推荐的数据流为：

规划器 / 仿真器 / 实机驱动
↓
ROS 2 状态与事件
↓
Rerun 记录适配器
↓
查看、回放与离线分析

Rerun 不应向桥接节点或驱动器反向发布运动命令，也不应参与安全停机、实时控制决策或执行反馈闭环。

4.4.2 规划结果的多层验证

规划或 IK 输出进入 ROS 2 执行链路前，应先形成带有任务编号、目标设备、关节名称、坐标系、工具参数、模型版本和软件版本的候选轨迹对象，再由独立验证模块处理。检查内容至少包括：

1. 轨迹格式、关节顺序、单位、时间戳和数据完整性；
2. 关节位置、速度、加速度，必要时包括 jerk；
3. 自碰撞、环境碰撞、禁入区域和工具碰撞；
4. 基坐标、工件坐标、工具坐标及 TF 版本；
5. 当前设备位置、模式、控制权、使能状态和任务占用状态；
6. 目标设备能力、驱动器轨迹格式及参数限制；
7. 急停、门禁、限位、STO、故障和运动许可状态；
8. 轨迹版本、内容校验值和有效期。

验证结果可分为 Valid、Invalid、RecheckRequired 和 SimulationOnly。其中，SimulationOnly 表示结果只允许进入仿真或离线分析链路，不得发送到实机执行接口。工程推断： 即使 OpenRAVE 已通过几何检查，仍需经过设备能力和当前状态检查；即使 MuJoCo 跟踪效果良好，也仍需进行低速、受限条件下的现场验证。因此，任何仿真输出都不能未经约束复核直接驱动真实设备。

4.4.3 仿真与实机隔离

仿真模式和实机模式应采用多层隔离，而不能只依赖 UI 上的模式开关。两者至少应在以下方面区分：

架构设计： 仿真适配节点不得伪装成真实驱动节点，也不得获得串口、现场总线或真实执行器设备映射。Win11 界面应始终显示当前模式和设备来源，桥接节点则在服务端再次校验目标设备、命名空间和权限。

4.4.4 ROS 2 适配与记录模型

OpenRAVE 的规划结果、MuJoCo 的仿真状态和真实驱动反馈，均应通过 ROS 2 适配节点进入统一数据层，再分别提供给 Win11 界面和 Rerun。每条重要数据至少关联：设备或仿真来源、设备 ID、任务 ID、采样时间戳、接收时间戳、坐标系、机器人模型版本、工具参数版本、软件版本、命令 ID 和故障上下文。仿真时间、设备时间和显示时间应分开保存，避免把界面到达时间误认为真实采样时间。

推荐将规划轨迹与实际轨迹分开记录，并为故障事件关联发生前后的状态窗口。这样既能比较“规划目标—仿真结果—实机结果”，也能复盘命令拒绝、轨迹取消、通信中断和设备故障。上述记录字段和适配关系属于本文架构设计；Rerun 的具体数据接口、版本能力、资源占用和长期记录稳定性属于项目待验证项。

最终应保持如下边界：OpenRAVE 负责提出几何上可行的候选路径，MuJoCo 负责检验模型条件下的动力学行为，验证器负责执行前约束检查，ROS 2 适配层负责数据转换与任务传递，真实驱动负责设备执行，而 Rerun 只负责记录和分析。急停、门禁、限位、STO 及其他安全状态仍由独立安全域决定，任何软件组件异常都不应削弱其安全功能。

4.5 Seeed Studio 集成案例

本文将 Seeed Studio 仅作为可替换的边缘硬件与传感器集成对象，用于说明第三方视觉、传感器或辅助计算设备如何接入 ROS 2 机器人系统。由于当前没有可追溯的 Seeed Studio 产品资料、官方案例或搜索来源，本文不对具体产品型号、处理器、GPU/NPU、接口数量、操作系统、性能指标、ROS 2 原生兼容性、Docker 能力和工业认证作确定性承诺。以下内容属于架构设计，其中涉及目标设备实际能力的部分均为架构假设，最终结果应列入项目待验证项。

4.5.1 案例角色与系统链路

以视觉辅助抓取或工业检测工作站为例，Seeed Studio 节点可以有三种候选部署位置。第一，作为传感器采集与预处理节点，负责获取图像、距离或其他测量数据，并进行格式转换、滤波和时间戳整理。第二，作为边缘推理节点，输出目标类别、检测区域、测量值、置信度或候选目标位姿。第三，作为机器人辅助计算节点，完成工件筛选、坐标辅助计算、任务前处理或环境信息整理。

无论采用哪种角色，Seeed 节点都不应被定义为机器人实时控制器。推荐的数据流为：

Seeed 节点
↓
设备/硬件适配层
↓
ROS 2 图像、测量、目标位姿和状态节点
├── ROS 2 Jazzy 桥接节点 → Win11 Rust/eframe/egui
└── Rerun 记录适配器 → 查看、回放与事后分析

设备适配层负责访问具体相机、传感器或边缘设备接口，将原始数据转换为统一消息，并上报设备在线状态、数据质量、错误和重连事件。ROS 2 节点再根据任务需要发布图像、测量结果、检测结果、目标位姿和设备状态。Win11 egui 只显示这些经过桥接节点转换的状态，不直接读取 Seeed 设备或机器人驱动器。

4.5.2 规划流与执行边界

当感知节点生成目标位姿后，规划流可表示为：

目标位姿
↓
OpenRAVE：IK、几何规划与碰撞检查
↓
候选轨迹
↓
MuJoCo：动力学、接触和轨迹跟踪仿真
↓
轨迹格式、关节范围、速度和碰撞等约束检查
↓
桥接节点：会话、权限、模式和设备状态检查
↓
ROS 2 Action 或设备驱动接口
↓
机器人控制器执行

目标位姿必须携带任务 ID、来源设备、采集时间戳、坐标系、标定版本和有效期。OpenRAVE 输出的是候选 IK 解或候选轨迹，MuJoCo 输出的是特定模型条件下的仿真结果；二者均不自动获得真实设备执行权限。只有在轨迹验证器确认关节范围、速度/加速度、碰撞、坐标系、工具参数、设备能力和数据有效期均满足要求，并且桥接节点确认控制权、权限、运行模式和运动许可有效后，才可提交实机执行请求。

Rerun 在上述过程中记录图像或测量数据、目标位姿、规划轨迹、仿真结果、实际轨迹、任务状态和故障上下文。记录应包含 task_id、设备或仿真来源、设备 ID、时间戳、坐标系、模型版本、标定版本和软件版本。Rerun 只位于观测链路，不参与执行决策、实时反馈或安全停机。

4.5.3 分阶段接入与验证

案例实施应按风险递进顺序进行。首先完成硬件接入和单机驱动联调，核验目标 Seeed 型号的供电、接口、设备访问、原始数据格式和断线检测。随后验证 ROS 2 Topic、Service 和 Action 的名称、类型、QoS、任务 ID、序列号和错误状态，确认感知数据能够进入 Docker 内 ROS 2 图。

第三阶段应重点检查时间戳、单位、frame_id、TF 链、坐标变换和数据来源，拒绝过期位姿、错误标定版本或来源不明的数据。第四阶段验证 Win11 egui 的状态显示，包括传感器在线状态、目标质量、规划阶段、仿真结果、执行权限和故障提示，确保 UI 状态来自桥接节点和设备反馈，而不是本地按钮推断。

完成数据和界面验证后，再进行 OpenRAVE 与 MuJoCo 联调，确认关节顺序、模型版本、工具参数和坐标系一致，并保存规划、仿真及失败结果。之后必须执行仿真/实机隔离测试，使用不同设备 ID、命名空间、配置、权限或网络分区，证明仿真命令无法到达真实驱动。实机测试只能从低速、低负载、有限范围和受控工作区开始。

最后应进行网络延迟、丢包、断线、重连、容器重启、Seeed 节点重启、长时间运行和异常恢复测试，并在现场核验供电、散热、温度、振动、EMC、网络和维护流程。硬件规格、接口能力、容器部署、现场环境适应性及实时性能均属于项目待验证项，须以目标型号资料、实验记录和现场验收结果为准。

Seeed 节点不得绕过控制协议直接驱动真实执行器，也不替代机器人驱动、实时控制器或独立安全域。急停、门禁、限位、STO、驱动保护和安全状态机必须由独立安全机制承担，不依赖 Win11、egui、Docker、普通 ROS 2 通信或 Rerun。

4.6 工业化评价、实时性与安全验证

从架构分析看，职责分离和接口解耦有利于提高系统的可维护性。控制协议不绑定具体机器人品牌，能够将厂商差异集中在设备适配层；驱动、规划器、仿真器和 Seeed Studio 边缘节点可以通过明确接口替换或独立演进；Win11 操作员界面、ROS 2 桥接节点和 Rerun 也能够分别开发、测试和部署。OpenRAVE 与 MuJoCo 提供的分层验证能力，以及 Rerun 对任务、状态、故障和版本信息的记录，有助于提前发现部分问题并支持事后定位。上述判断属于架构分析或工程推断，不代表已经获得确定的成本、性能或维护收益。前期仍需投入协议抽象、设备适配、验证器、权限审计和运维体系建设，长期收益必须通过项目工时、故障记录和设备替换数据验证。

系统应明确划分三层实时性。Win11/Rust/eframe/egui 属于非实时交互层，允许存在界面刷新延迟、卡顿、断线或进程崩溃，但不得承担硬实时控制和安全停机。ROS 2 Jazzy、DDS、Docker、桥接节点及驱动适配器属于软实时集成层，其端到端延迟、周期抖动、消息丢失、乱序、队列积压、时间戳一致性和断线恢复能力必须实测。急停、门禁、限位、STO、驱动保护和安全状态机属于独立安全层，不依赖 Win11、Docker、普通 ROS 2 通信或 Rerun。验证时应覆盖网络中断、DDS 发现异常、节点退出、容器重启、Rerun 停止以及 UI 卡顿或崩溃后的降级行为，具体阈值由目标设备和项目风险要求确定。

实施应采取逐级验证路线：首先进行接口、协议、权限、命令幂等性、时间戳、坐标系和仿真/实机隔离测试；随后开展网络、容器、节点和客户端故障注入，确认系统能够拒绝新命令、标记任务中断并避免自动恢复未确认运动；再进行长时间运行测试，检查资源增长、队列、磁盘、日志和记录完整性；通过后，才在低速、低负载、受限范围和可人工立即停机的条件下开展实机测试；最后完成现场环境、安全功能、升级回滚和维护流程验收。

主要风险包括 GUI 失效、DDS 或网络抖动、Docker 权限过大、设备映射错误、模型与实机不一致、Rerun 数据量失控、协议授权不足、过期或重复命令、配置版本不一致以及 Seeed Studio 具体硬件能力尚未核验。对此应采用最小权限、仿真/实机多层隔离、控制面与观测面分离、配置和日志持久化、软件与模型版本追溯、命令审计及故障可恢复设计。Rerun 只负责记录与查看，不参与实时控制或安全停机；Seeed Studio 节点只提供视觉、传感器或边缘计算结果，不直接驱动真实执行器。

需要限制性说明的是，软件架构、ROS 2 通信、Docker 部署和测试结果，不能直接等同于工业安全认证、功能安全、网络安全或现场合规。具体标准、认证范围、风险等级、验证方法和责任边界，应由项目结合目标市场、设备类别和安全方案另行确认，并通过合格的工程与验收流程完成。总体而言，本方案的核心价值在于职责分离、接口解耦、可观测和可验证，而不是把 Win11/egui、普通 ROS 2 节点、Docker 或 Rerun 当作硬实时安全控制器。

egui、Rust 与 Rerun 在 ROS 2 机器人及工业自动化中的分层应用报告

摘要

机器人研发和工业自动化系统同时面临操作员交互、硬件异构、任务执行、仿真验证、运行追溯和安全隔离等要求。单一软件框架难以同时承担桌面界面、设备驱动、规划计算、动力学仿真、数据记录和功能安全职责，因此系统设计的重点不应是堆叠工具，而应是建立清晰、稳定且可验证的接口边界。

本文提出一种面向 Win11 和 ROS 2 机器人系统的分层架构：在 Win11 上使用 Rust 与 eframe/egui 构建原生操作员界面，负责设备选择、状态展示、Jog、轨迹任务、参数管理和故障提示；通过与机器人品牌、驱动器和现场总线无关的控制协议，统一表达连接、身份、控制权、伺服使能、运动许可、轨迹执行、心跳、故障和审计语义；由 ROS 2 Jazzy 桥接节点连接 Win11 客户端与 Docker 内的 ROS 2 graph，并完成协议校验、命令映射、任务反馈、重连及仿真/实机隔离。OpenRAVE 主要承担几何规划、逆运动学、碰撞检查和离线验证，MuJoCo 主要承担动力学、接触、执行器及控制器仿真，Rerun 则负责运行数据记录、可视化、回放和事后分析。

本文特别讨论 Seeed Studio 作为可替换边缘计算、视觉或传感器集成节点的架构案例。由于当前未提供可追溯的官方资料，相关具体型号、接口、计算资源、ROS 2 兼容性、性能和工业认证均不作确定性承诺。急停、门禁、限位、STO、驱动保护和安全状态机属于独立安全域，不依赖 Win11、egui、Docker、普通 ROS 2 通信、OpenRAVE、MuJoCo 或 Rerun。

1. 背景、范围与总体架构

1.1 工业机器人软件的系统需求

工业机器人软件通常包含三个相互关联但不能混同的目标。第一是可操作性：操作员需要快速完成登录、设备连接、模式确认、伺服使能、Jog、轨迹执行和故障处理。界面不仅要显示位置、速度、任务阶段和故障信息，还应明确区分“设备在线”“获得控制权”“伺服已使能”和“允许运动”等不同状态。

第二是可替换性。实际系统中的机器人本体、驱动器、末端执行器、相机和传感器可能来自不同供应商。如果 Win11 界面直接调用某一家设备的私有 API，硬件替换将导致界面、任务逻辑和测试系统同时修改。因此，需要将厂商协议和现场总线访问限制在设备驱动及适配层内，由上层采用稳定的领域协议。

第三是可验证性与可追溯性。轨迹在进入真实设备前需要经过关节范围、速度、加速度、碰撞、坐标系和设备能力检查；运行期间还应记录命令、反馈、故障、传感器数据、模型版本和软件版本，以支持问题复盘和维护决策。与此同时，急停、门禁、限位和 STO 等安全动作必须脱离普通软件链路，确保界面崩溃、网络中断或容器重启不会使安全功能失效。

1.2 技术栈定位

本文采用的总体架构可划分为以下层次：

以上分层属于本文的架构设计。具体组件版本、部署平台、设备兼容性和实时性能，应通过官方资料与项目测试进一步确认。

2. 与硬件无关的控制协议设计

2.1 连接、身份与会话

控制协议应描述操作员意图和设备状态，而不应复制某个机器人控制器的寄存器、报文或私有 API。客户端通过 Connect 请求建立逻辑会话，提交 client_id、用户身份、协议版本、软件版本、目标设备 ID 及必要的能力声明。服务端返回 session_id、权限范围、设备能力摘要和会话有效期。

连接状态与设备状态必须分开。建议至少定义：

• Disconnected：没有有效协议会话；
• Connecting：正在建立会话；
• Connected：协议端点可通信；
• Degraded：通信存在，但状态或能力不完整；
• Lost：心跳超时或连接中断；
• DeviceOffline：驱动未确认目标设备在线。

连接成功并不代表可以运动。控制协议应分别维护 ControlGranted、ServoEnabled、MotionPermitted 和 SafetyChainHealthy 等状态。只有在会话有效、控制权属于当前客户端、设备已使能、运动许可成立、故障条件允许且安全域没有禁止运动时，执行侧才可接受运动任务。

心跳用于维护会话有效性。命令和心跳均应携带会话 ID、序列号、发送时间及客户端标识。发生连续超时后，桥接节点应使会话失效并拒绝后续控制请求。重连后不能自动恢复控制权、伺服状态或未完成任务，必须重新认证、同步设备状态并再次获取控制权。

2.2 Jog 与轨迹任务

所有改变设备状态的请求都应有唯一 command_id，并采用“请求、确认、执行中、完成、拒绝或失败”的生命周期。确认只表示服务端接收并通过初步检查，不代表动作已经完成。对于因网络重试造成的重复请求，服务端应依据命令 ID 实现幂等处理，避免同一运动被执行两次。

Jog 可抽象为 JogStart、JogUpdate 和 JogStop。请求应包含目标设备、关节或坐标系、方向、速度限制、加速度限制、操作者、会话 ID 和有效期。桥接节点或执行管理模块需要再次检查控制权、伺服状态、运动许可、软限位和设备模式。命令过期、心跳丢失或安全条件消失时，应拒绝新的 Jog 请求，并按照项目策略结束当前 Jog。不能仅依赖 UI 按钮释放作为停止保障。

轨迹任务可分为：

UploadTrajectory
ValidateTrajectory
ExecuteTrajectory
Pause
Resume
Cancel
Stop

轨迹对象应包含任务 ID、版本号、关节名称和顺序、位置数据、时间参数、坐标系、工具参数、模型版本及必要的速度和加速度限制。上传成功不等于允许执行；执行前还需验证轨迹格式、单位、关节范围、碰撞、设备能力、当前状态和安全条件。

Pause 表示任务暂时停止推进，Resume 必须重新检查设备状态和控制权；Cancel 表示取消未完成任务；软件协议中的 Stop 是运动或任务层停止请求。Emergency Stop 和 STO 属于独立安全功能，在触发路径、确定性和安全责任上不能与普通 Stop 混同。

2.3 故障、权限与审计

故障对象应记录故障 ID、来源、严重等级、发生时间、设备 ID、任务 ID、是否锁存、是否需要复位及恢复提示。故障可来自通信、驱动、传感器、规划、参数、软件或安全状态。ResetFault 只能复位协议和设备策略允许复位的故障，不能绕过急停、门禁、限位或 STO。

权限至少应区分观察、Jog、轨迹执行、参数修改和故障复位。每次控制请求和结果都应记录用户、客户端、会话、设备、命令 ID、参数摘要、时间戳、协议版本、配置版本和结果码。过期命令、重复命令、权限不足、模式不符、状态冲突、通信超时和设备拒绝应使用不同错误类型，便于 UI 解释和事后审计。

3. Win11 操作员界面、ROS 2 桥接与 Docker 部署

3.1 Win11 Rust/eframe/egui 客户端

Win11 上的 Rust 应用适合承担操作员登录、设备选择、状态总览、Jog 面板、轨迹任务管理、参数查看、故障提示和命令反馈。eframe/egui 负责窗口、输入和显示，Rust 应用则可组织应用状态、协议请求封装和传输管理。

建议客户端内部划分为：

eframe/egui 视图
↓
应用状态与 ViewModel
↓
控制协议客户端
↓
TCP、WebSocket、gRPC 或其他传输适配器

这种划分有助于避免把界面回调直接写成设备控制逻辑。UI 产生的是操作意图，最终命令是否被接受，应由桥接节点根据会话、权限、模式、设备状态和运动许可决定。

工程推断是，TCP、WebSocket、gRPC 或自定义传输均可满足不同部署需求，但选择应综合考虑双向通信、认证、断线恢复、部署复杂度和测试难度。无论采用哪一种方式，网络可达性都不能等同于硬实时能力。Win11、egui 和普通网络链路不应直接操作电机寄存器或承担安全停机。

3.2 ROS 2 Jazzy 桥接节点

桥接节点在逻辑上位于 Win11 客户端与 Docker 内 ROS 2 graph 之间。它不只是转发消息，而应完成：

1. 协议解析和版本检查；
2. 会话、身份和权限校验；
3. 目标设备、仿真/实机模式和参数范围检查；
4. 命令 ID 去重、超时和过期处理；
5. 控制协议到 ROS 2 接口的映射；
6. ROS 2 状态到统一协议状态的转换；
7. 任务反馈、取消、失败和重连处理；
8. 仿真与实机执行接口隔离；
9. 审计事件和诊断信息输出。

ROS 2 接口的选择应由业务语义决定：

Topic 适合持续广播，但不天然表达单次请求的最终结果；Service 适合短事务，不宜单独承载长时间运动；Action 能表达反馈、取消和结果，但仍不等于底层硬实时控制器。具体消息类型、QoS、队列深度和超时策略属于项目待验证项。

3.3 Docker 运行环境

Docker 的架构定位是封装 ROS 2 Jazzy、驱动、规划、仿真和记录环境，以便统一依赖、配置开发和部署流程。它不自动提供硬实时调度，也不自动解决现场总线、设备权限和网络确定性问题。

部署时应核验 DDS 发现范围、ROS 域或命名空间隔离、主机网络与桥接网络的差异，以及端口、组播、防火墙和跨主机发现行为。主机网络可能简化发现配置，但会扩大网络暴露范围；桥接网络便于隔离和管理，但需要测试发现、重连、延迟、抖动和丢包。

驱动容器如需访问 USB、串口、相机、CAN 或其他设备，应逐项确认设备映射、权限、热插拔和断线恢复。GPU、特权容器和额外系统 capability 只能按需启用，仿真或记录容器不应获得真实执行器权限。配置、日志、审计、录包和任务恢复信息应通过数据卷或主机目录持久化，不能仅保存在容器可写层。

容器、主机、传感器和仿真器的时间戳需要统一规划。容器重启后应重新发现设备、恢复状态同步、重新认证并确认控制权，不应自动继续未确认的运动任务。网络延迟、消息丢失、队列积压、容器调度和时间同步能力必须通过目标环境测试。

4. OpenRAVE、MuJoCo 与 Rerun 协同

4.1 规划与 IK

架构设计中，OpenRAVE 位于几何规划侧，负责机器人模型、逆运动学、路径规划和碰撞检查，输出候选关节解或候选轨迹。它不承担真实设备驱动、硬实时控制或安全决策。其具体版本、模型格式、求解器配置和 ROS 2 适配关系属于项目待验证项。

规划结果进入 ROS 2 执行链路前，必须经过多层验证：

• 关节名称、顺序、单位和轨迹格式；
• 位置、速度、加速度及必要的 jerk 限制；
• 自碰撞、环境碰撞和禁入区域；
• 基坐标、工件坐标、工具坐标和 TF；
• 工具参数、标定版本和机器人模型版本；
• 当前设备状态、任务占用和控制权；
• 实机能力、模式、故障和软件运动许可。

4.2 动力学仿真

MuJoCo 位于动力学仿真侧，主要用于刚体运动、接触、摩擦、负载响应、执行器和传感器行为，以及控制器和轨迹跟踪验证。工程推断是，动力学仿真可以补充几何规划无法发现的动态风险，但仿真可信度取决于模型、参数和控制器配置，不能替代实机测试。

OpenRAVE 与 MuJoCo 的输出都只能作为候选结果。推荐链路为：

OpenRAVE：IK 与几何规划
↓
轨迹验证
↓
MuJoCo：动力学与跟踪仿真
↓
再次约束检查
↓
桥接节点：权限、模式和状态检查
↓
真实驱动或仿真驱动

仿真模式与实机模式应至少使用不同设备 ID、命名空间、配置和权限；有条件时进一步使用不同 ROS 域或网络分区。仿真容器不得映射真实执行器设备。

4.3 Rerun 记录与可视化

Rerun 位于观测和分析链路，可记录关节位置、速度、轨迹、TF、传感器、目标位姿、故障事件、命令摘要以及仿真与实机对比数据。每条重要数据应关联：

• 时间戳；
• simulation 或 real 来源；
• 设备 ID；
• 任务 ID；
• 命令 ID；
• 坐标系；
• 模型和标定版本；
• 软件和配置版本；
• 故障上下文。

Rerun 的推荐关系为：

ROS 2 状态、事件和传感器
↓
Rerun Recorder
↓
查看、回放与事后分析

Rerun 不向执行链路反向发布控制命令，不参与实时控制决策、安全停机或执行反馈闭环。记录系统发生故障时，系统可以报警或降级观测，但不能因此削弱独立安全域的功能。

5. Seeed Studio 集成案例

5.1 案例假设

由于当前没有可追溯的 Seeed Studio 官方资料，本文不指定具体型号，也不确认其处理器、GPU/NPU、接口、操作系统、容器能力、ROS 2 兼容性、性能或工业认证。以下内容是架构假设：将选定的 Seeed Studio 设备作为可替换的边缘采集、视觉预处理、传感器融合或辅助计算节点。

案例采用视觉辅助抓取或工业检测工作站。Seeed 节点采集图像或测量数据，经设备适配层完成驱动访问、数据格式统一、质量检查和时间戳处理，再通过 ROS 2 节点发布至 Docker 内 ROS 2 graph：

Seeed Studio 边缘节点
↓
设备适配层
↓
ROS 2 传感器/视觉节点
├── 桥接节点 → Win11 egui 状态展示
├── OpenRAVE → 目标位姿、IK 和路径规划
├── MuJoCo → 动力学和轨迹跟踪仿真
└── Rerun → 数据记录与回放

Seeed 节点可以输出检测结果、测量值、目标类别、候选区域或目标位姿。所有输出都应带有设备来源、任务 ID、采集时间戳、坐标系、标定版本和数据质量信息。Win11 界面只显示经桥接节点转换后的状态，不直接读取 Seeed 设备或机器人驱动器。

5.2 从感知到执行

当视觉节点输出目标位姿后，OpenRAVE 根据机器人模型计算 IK 解并生成候选轨迹，随后由 MuJoCo 对轨迹跟踪、接触和动力学响应进行仿真。仿真通过后，还必须检查关节范围、速度和加速度、坐标系、工具参数、设备能力、当前状态、控制权和软件运动许可。

桥接节点收到执行请求后，需要再次检查目标设备是否为实机、会话是否有效、用户是否具备权限、轨迹是否过期以及安全状态是否允许运动。Seeed 节点只能提供感知或辅助计算结果，不得绕过控制协议直接驱动机器人执行器，也不替代机器人驱动、实时控制器或独立安全域。

Rerun 可记录原始或处理后的感知数据、目标位姿、规划轨迹、仿真状态、实际轨迹和故障上下文，用于比较“感知目标—规划结果—仿真结果—实机结果”。记录中的仿真数据和实机数据必须明确区分，避免在回放界面中混淆数据来源。

5.3 接入与验收流程

Seeed 节点的接入应采用逐阶段验证：

1. 硬件接入验证：根据具体型号确认供电、设备访问、接口、驱动和原始数据格式；
2. 单机驱动联调：测试采集、预处理、异常检测和断线恢复；
3. ROS 2 数据验证：检查 Topic、Service、消息类型、QoS、时间戳、序列号和错误状态；
4. 坐标与标定验证：确认 frame_id、TF、单位、标定版本和目标位姿有效期；
5. UI 联调：确认 egui 显示的是桥接节点和设备反馈，而不是本地按钮状态；
6. 规划与仿真联调：验证关节顺序、模型版本、工具参数和规划结果；
7. 仿真/实机隔离测试：证明仿真命令无法到达真实驱动；
8. 受限实机测试：从低速、低负载、有限范围和可立即停机条件开始；
9. 故障与长期运行测试：测试断网、节点退出、容器重启、传感器重启和长时间运行；
10. 现场验收：核验供电、散热、网络、环境适应性、维护和升级回滚流程。

具体硬件规格、现场环境适应性、容器部署方式和实时性能均为项目待验证项，必须依据目标型号资料、实验记录和现场验收结果确认。

6. 工业化评价、实时性与安全验证

6.1 架构收益与限制

工程推断是，将厂商差异集中到设备适配层，有利于上层协议、操作员界面和任务逻辑保持稳定；将规划、动力学仿真和记录工具分开，也有助于定位不同类型的问题。Rust 客户端、ROS 2 节点、Docker 环境和 Rerun 记录系统可以相对独立地开发和调试，从而改善模块替换和问题复现条件。

但这些收益不是自动产生的。系统仍需建设协议版本管理、设备适配、权限审计、配置管理、模型管理、故障恢复和现场运维流程。当前没有项目工时、设备数量、故障统计或性能数据，因此不能给出确定的成本降低、效率提升或稳定性承诺。

6.2 实时性分层

系统应划分为三层：

验证内容应包括端到端延迟、周期抖动、消息丢失、队列积压、时间戳偏差、断网、DDS 发现异常、节点退出、容器重启、Rerun 停止和 UI 崩溃。具体阈值必须依据目标机器人控制器、设备能力和项目风险要求确定。

6.3 分阶段安全验证

建议先进行协议、消息、权限、幂等性、坐标系、时间戳和仿真/实机隔离测试，再进行网络、容器、节点和客户端故障注入。故障发生时，系统应拒绝新命令、标记任务中断、保持审计信息，并避免自动恢复未确认的运动任务。之后进行长时间运行测试，检查日志、磁盘、内存、队列和记录完整性，最后才开展低速受限实机测试和现场安全验收。

主要风险包括 UI 卡顿或崩溃、DDS 网络抖动、容器权限过大、设备映射错误、模型与实机不一致、记录数据量失控、命令重复或过期、配置版本不一致，以及 Seeed Studio 目标设备能力未经核验。实施中应采用最小权限、控制面与观测面分离、仿真/实机多层隔离、配置和日志持久化、版本可追溯、命令审计和故障可恢复设计。

软件架构、ROS 2 通信、Docker 部署或测试结果，不能直接表述为已经满足某项工业安全、功能安全、网络安全认证或现场合规要求。适用标准、风险等级、认证范围和责任边界，应由项目依据目标市场、设备类别和安全方案进一步确认。

7. 结论

本文方案的核心价值不是将 Win11、ROS 2、Docker、规划器、仿真器和记录工具放入同一个实时闭环，而是通过职责分离建立可替换、可验证和可追溯的机器人软件架构。Win11 上的 Rust/eframe/egui 负责操作员交互、状态展示和任务入口；硬件无关控制协议负责统一连接、使能、Jog、轨迹、故障、权限和审计语义；ROS 2 Jazzy 桥接节点负责客户端与 Docker 内 ROS 2 graph 之间的协议转换和状态管理；OpenRAVE 与 MuJoCo 分别支持几何规划/IK 和动力学仿真；Rerun 负责记录、查看和事后分析。

Seeed Studio 可作为边缘感知、视觉或辅助计算节点接入该体系，但其具体型号能力、接口、性能、兼容性和工业适用性必须经过资料核验与现场测试。真实设备的最终执行约束和安全动作仍由机器人控制器、驱动保护及独立安全域承担。急停、门禁、限位和 STO 不依赖 Win11、egui、Docker、普通 ROS 2 通信、OpenRAVE、MuJoCo 或 Rerun。只有坚持这一边界，系统才能在功能集成之外，进一步形成可维护、可观测、可验证且风险可控的工业机器人应用基础。

References