这篇文章解决的不是“机器人会不会撞到人”这么窄的问题，而是更实际的事：当 humanoid 要和人共享一块空间时，你到底该怎样把危险动作限制住、把失败变得可预测、把接管和复盘做成工程闭环。对多数原型团队来说，最关键的判断不是先把感知做得多聪明，而是先把安全链和智能链分开，把保护区、限速、降级、急停、恢复流程和日志证据先立住。
这篇适合谁
- 正在做 humanoid 样机，希望让机器人进入有人共处的实验区、工位或演示环境。
- 已经有视觉、控制、操作能力，但一到“人靠近怎么办”就只剩下急停按钮的团队。
- 需要给客户、场地、安全负责人或自己团队一个可验证的共享空间安全方案的人。
先纠正几个很常见的误区
误区 1：安全就是多上一套视觉避障
不是。共享空间安全首先是“限制能量和限制状态”，其次才是“更早看见人”。如果执行器力矩、关节速度、停止距离、跌倒姿态、恢复流程都没管住，单靠视觉看见人并不能让系统真正可控。
误区 2：等动作跑通了，再慢慢补急停和限速
这条路最容易把系统做歪。因为你前面的轨迹生成、控制参数、硬件选型、供电余量、恢复逻辑，都会默认自己可以“放开跑”。后面再补安全，经常意味着整条控制链要返工。
误区 3：普通深度相机检测到人，就等于安全链成立
不等于。普通感知可以做辅助减速、预警、意图识别，但不能偷换成安全闭环。真正进入共享空间时，你至少要明确哪部分是“可参考的智能感知”，哪部分是“必须可靠触发的保护机制”。两者混在一起，出事时最难定位责任边界。
误区 4：Protective Stop 解除后继续跑就行
不行。像 Universal Robots 的 stop recovery 文档就明确提醒，Protective Stop 是接近限制条件后的控制器主动停机，若反复出现，应先追根因，而不是把它当作一个普通暂停键。对 humanoid 来说同理，任何保护停机都应该留下可回放证据，并经过带确认的恢复流程。
关键实现判断
如果你的 humanoid 要在人旁边工作，我更建议按下面这个顺序做设计，而不是先堆功能：
- 先定义危险边界，再定义能力边界。先写清楚哪些动作绝不能在人近距离时发生。
- 先分离安全链和智能链。安全链负责急停、功率切断、速度上限、模式切换、保护区触发。智能链负责识人、理解场景、预测意图、优化动作。
- 先把降级路径做出来。不是所有异常都要直接断电，有些要减速，有些要保持姿态，有些要锁臂并请求人工接管。
- 先把恢复条件写死。谁能恢复、恢复前要检查什么、恢复后从哪一步继续，都应该是明确流程，不该靠现场拍脑袋。
这套顺序的好处是，即使感知和策略还不够成熟，你的系统也已经有了“不会无限放大错误”的底座。
分步实践指南
第 1 步，先按任务划共享空间，而不是按机器人半径划圈
不要直接说“机器人周围 1.5 米都是危险区”。先从任务拆起：
- 机器人什么时候只是站立等待。
- 什么时候执行大范围摆臂。
- 什么时候需要前倾、转身、伸手或搬运。
- 什么时候允许人靠近示教、装夹、补料、接管。
你会发现，不同任务下的危险体积完全不同。真正该冻结的是“动作模式 + 环境区域 + 人员角色”的组合，而不是一个固定半径。
第 2 步，把保护机制分成四层
第一层，硬件强制层。 包括急停回路、STO/断使能、主电源继电器、制动释放条件、跌倒后安全姿态。这一层的目标是，控制器发疯时你还有最后的硬刹车。
第二层，控制约束层。 对每个关节、末端、底盘或身体段设置速度、加速度、电流、力矩、功率和姿态边界。不要只做全局上限，要区分“空载摆臂”和“抓着物体转身”两种模式。
第三层，区域与接近层。 做保护区、减速区、提醒区。NIST 关于 speed and separation monitoring 的资料很值得参考，核心不是“看见人就停”，而是把人的接近速度、机器人当前速度、系统响应时间和停止距离一起算进最小保护距离。
第四层，监督与恢复层。 包括人工接管、告警确认、事件记录、根因分析和恢复门禁。没有这一层，前面三层再好也很难长期进场。
第 3 步，保护区一定要和停止能力一起标定
很多团队画保护区只看传感器视野，不看机器人真实停止距离，这很危险。你至少要测出：
- 不同动作模式下，从触发减速到速度降下来要多久。
- 从触发停机到实际停止要多久。
- 满电、低电、热降额、不同负载时停止距离差多少。
- 网络抖动、时间同步误差、感知丢帧会把保护边界吃掉多少。
如果要用外部 3D 安全感知做保护区，像 SICK safeVisionary2 这类安全 3D 相机的工程资料就很有参考意义。它强调了保护区评估并不等于整幅画面都可用，视场、安装高度、遮挡和俯仰角都会改变你真正能依赖的覆盖范围。换句话说，先做盲区审计，再谈“看见了人”。
第 4 步，别把“人在旁边”简化成一个布尔值
更实用的做法是把人相关状态拆成三级：
- 观察到人：允许继续低风险动作，但限制速度和摆幅。
- 人进入协作近场：切到保守模式，只允许低能量、低速度、可预测动作。
- 人进入危险区或姿态异常：立即停机或进入受控安全姿态，并要求人工确认。
这样做的好处是，你不会把系统做成“要么全速、要么硬停”这种很难用的二值逻辑。
第 5 步，把人工接管设计成流程，不是按钮
共享空间里真正经常救命的，通常不是急停本身，而是接管流程够不够清楚。建议至少有这几件东西：
- 本体可触达的急停。
- 远程监督端可发起的 hold / safe stop / reset。
- 当前模式、任务目标、受限原因、谁触发停机的可视化状态。
- 恢复前检查项，比如人是否离开危险区、负载是否脱落、关节是否超温、是否发生跌倒。
Universal Robots 的恢复文档有一个值得直接借鉴的判断：Protective Stop 解除前，必须先把安全弹窗关闭、确认状态回到正常，再重新启动程序。你未必照搬它的接口，但“恢复是一个带前置条件的流程”这个思想非常适合 humanoid。
第 6 步，把事故证据链默认打开
如果每次停机后你只能靠现场回忆“刚才好像是有人走近了”，那后面一定会反复踩坑。建议从第一天起就统一记录：
- 关节状态、末端命令、底盘命令、模式状态。
- 保护区占用、人体检测结果、急停与保护停机事件。
- 关键视频流或低帧率截图。
- 时间同步信息和恢复操作日志。
像 MCAP 这类面向多通道时间序列数据的格式，非常适合做 ROS 2 环境下的统一记录、回放和问题复盘。重点不是“换个日志格式”，而是让感知、控制、告警、人工操作能放在同一条时间轴上对齐。
最容易翻车的地方
- 只测正常工况，不测异常工况。 真正危险的往往是掉帧、低电、网络抖动、负载滑脱、脚底打滑、操作员误入区。
- 保护区做得很好看，但有大盲区。 尤其是本体近身、后方、桌下、遮挡物后方。
- 停机逻辑太激进或太迟钝。 太激进会造成频繁误停，现场最后一定有人想绕过它。太迟钝则根本不安全。
- 跌倒后没有安全姿态。 humanoid 和固定机械臂最大的区别之一，就是失稳本身就是风险源。
- 恢复权限过宽。 谁都能 reset，最后就没人愿意追根因。
怎么验证你真的搭对了
最低限度，我建议你把下面这些测试变成每次版本变更后的必跑项：
- 人从不同方向进入提醒区、减速区、危险区，验证模式切换延迟。
- 机器人在空载、额定负载、低电量、热态下重复测停止距离。
- 拔掉或遮挡关键传感器，确认系统进入降级模式，而不是继续盲跑。
- 模拟网络中断、时钟漂移、日志掉写，验证接管和证据链是否还完整。
- 连续做 20 次以上保护停机与恢复，确认不会出现“前 3 次正常，后面越来越乱”的状态污染。
- 对每次停机生成事件包，检查能否在 10 分钟内回放并定位触发原因。
如果这些测试做不稳，就别急着把机器人放到更复杂的人类环境里。
下一步怎么做
如果你现在还在原型阶段，优先顺序我建议是：
- 先冻结共享空间任务边界和人员角色。
- 再补齐急停、限速、保护区、降级和恢复流程。
- 然后建立统一日志回放和异常复盘。
- 最后才去追求更自然的交互、更快的动作和更复杂的协作。
对 humanoid 来说，真正让人放心的不是“它有多聪明”，而是“它出了问题以后会不会按你预期的方式变得保守、停下、可接管、可复盘”。把这件事做扎实，后面的能力迭代才有资格进入真实场景。
Sources / Further Reading
- NIST, Implementing Speed and Separation Monitoring in Collaborative Robot Workcells
- SICK, safeVisionary2 Safe 3D Camera
- Universal Robots, Stop recovery
- MCAP, ROS 2 guide