主题
真实机器人任务的安全要求
RLark 可以通过 robot 标签和扩展设备资源调度机器人节点，也可以在任务中运行镜像和脚本。正确配置的 Device Plugin 能在 Kubernetes 调度时分配设备资源；设备系统还需要把资源 ID 映射到具体设备，并提供设备独占、上电与 arming、人工确认、动作限制、急停、通信超时、断连保护和恢复授权。
未完成安全确认时不要提交
节点显示为端真机、设备出现在资源列表、Job 为 Running 或网络可达，都不代表可以安全控制设备。任何可能向真实设备发送命令的任务，都必须先通过设备团队的书面审批和现场检查；否则只能在仿真或隔离测试环境中运行。
提交前还需确认的安全措施
为每项措施指定可以执行检查、停止或恢复操作的人员或系统，并在提交前完成确认。
| 安全措施 | 负责人 |
|---|---|
| 物理设备独占和并发冲突防护 | 设备平台或现场负责人；除检查调度请求外，还要确认 Device Plugin 的资源 ID、实际硬件映射和控制器所有权 |
| 上电、arming 与操作员二次确认 | 机器人控制系统和现场操作员 |
| 速度、力、行程和工作空间限制 | 机器人安全控制器与任务负责人 |
| 硬件急停、软件停止和断能 | 现场安全负责人 |
| 心跳、超时、网络断连安全状态 | 设备驱动和控制应用负责人 |
| 故障后复位与恢复授权 | 指定责任人和审批系统 |
| 命令、视频、传感器和操作审计 | 组织批准的外部系统 |
提交前检查
- 固化机器人型号、序列号、固件、驱动、SDK、控制模式和镜像 digest。
- 在隔离环境验证同一命令、配置和网络故障行为。
- 指定现场操作员、安全责任人、隔离区和人员进入控制。
- 实测急停、断能、超时、断连、进程崩溃和 RLark 失联后的设备安全状态。
- 审批动作、速度、力、行程和工作空间限制，并让机器人自身执行这些限制。
- 建立设备租约或其他独占机制；RLark 的节点选择器本身不提供独占保证，扩展资源请求也只证明调度层分配，不证明物理控制权已经安全移交。
- 准备不依赖 RLark 控制台可用性的停止与恢复方案。
- 确认 Header 恰好 1 个副本，而且任务重建、再次启动或工作流重跑时不会重复执行危险命令。
运行和停止
- 运行期间由现场操作员持续观察设备和隔离区。Job 详情中 Worker 的延迟、FPS 和节点类型不是设备真实遥测，“具身实时通道”也不能用作传感器、视频、控制或安全通道。
- 出现异常动作、传感器失真、网络抖动、重复 Worker、日志停滞或状态不一致时，优先使用设备级安全停止，不要等待 Job 状态协调。
- RLark 的停止只把受控工作负载缩容为 0；它不能证明机器人已经断能、制动、释放租约或清除外部控制进程。
- 恢复前必须重新走现场授权和设备复位流程；不要仅选择启动。
继续了解设备接入
只有已经取得设备接入授权，并确认资料版本与目标环境一致后，才能使用下面的源码资料。链接默认指向 main 分支；实际接入时，请改用与目标环境相同的 Git tag 或 commit。
需要部署或调用 RLark 的机器人与摄像头运行时，可以查阅：
使用这些资料部署或调用设备前，请先完成本页列出的安全审批、现场检查和设备级保护。Python SDK 文档介绍的是源码用法，不代表对应软件包已经公开发布。
只有在真实设备上完成上述检查并保存结果后，才能提交对应任务。否则请继续使用仿真或隔离测试环境，并在场景实战中选择可用于规划的流程。