多机器人路径协调聊完了，CBS、优先级规划、死锁处理这些方案应该有了基本的认识。从这篇开始，我们正式进入机器人产品化的话题。

机器人做得再厉害，用户不会用也是白搭。人机交互（HRI）设计决定了用户能不能顺畅地和机器人协作。扫地机器人好不好用，很大程度上不取决于清扫算法，而取决于APP界面设不设得明白、定时任务好不好配、错误提示看不看得懂。

面试问到交互设计，很多人觉得这是前端的事。但对机器人工程师来说，交互逻辑的设计直接影响系统的状态管理和错误处理架构，是必须掌握的知识。

一、交互模式分类

机器人的交互模式大致可以分为三种：

示教交互——用户直接"教"机器人怎么做。拖拽示教（协作机械臂）、遥控操作（无人机手柄）、关键点引导（扫地机器人建图后手动设置禁区）。

命令交互——用户发指令，机器人自己执行。语音指令（"去厨房"）、APP按钮（"开始清扫"）、API调用（调度系统发任务）。

自主交互——机器人自己决策，不需要用户输入。自动回充、自动避障、自动规划巡检路线。用户只需要监控状态。

大部分产品是三种模式的组合。协作机械臂用示教交互来编程，用命令交互来启动任务，用自主交互来处理安全保护。

示教交互里最有代表性的是拖拽示教。用户用手直接搬动机械臂到目标位置，机械臂的力矩传感器检测到外力，进入柔顺模式跟随运动。到达位置后用户按"记录"按钮，这个关节角度就被保存下来。一系列示教点连起来就是一个完整的运动轨迹。

这种交互方式对用户的机器人知识要求最低——不需要写代码，不需要懂坐标系，只要会搬东西就行。但精度有限，适合精度要求不太高的场景（比如喷涂、打磨）。高精度的任务（比如装配）还是需要用命令交互来精确指定位置。

二、状态反馈设计

用户最焦虑的事情是"不知道机器人在干嘛"。好的状态反馈能大幅地降低用户的不安全感。

状态反馈要做到三点：当前在做什么、做到什么程度了、下一步是什么。

状态示例：
"正在前往3号会议室" → "已到达，正在开门" → "门已打开，进入中"

进度条：
[████████░░░░] 65% - 预计2分钟后到达

异常提示：
"前方通道被阻塞，正在绕行。预计延迟3分钟。"

ROS2里常用的状态反馈方案是用Action服务端发布进度。客户端（APP或网页）订阅进度信息并展示。

# ROS2 Action服务端发布进度
class NavigateAction(ActionServer):
    def execute_callback(self, goal_handle):
        while not reached:
            feedback = NavigateFeedback()
            feedback.distance_remaining = calc_distance()
            feedback.eta = estimate_time()
            goal_handle.publish_feedback(feedback)
        
        result = NavigateResult()
        result.success = True
        goal_handle.succeed()
        return result

三、错误处理与恢复

机器人出错是必然的。传感器偶尔失灵、路径偶尔被堵、网络偶尔断开。关键是出错后怎么和用户沟通、怎么恢复。

错误处理的原则：能自动恢复的不要打扰用户，需要用户介入的要给清楚的操作指引。

错误等级设计：
INFO:  "电量降至30%，将自动回充" → 自动处理
WARN:  "前方有临时障碍，正在绕行" → 自动处理，通知用户
ERROR: "激光雷达数据异常，请检查传感器连接" → 需要用户操作
FATAL: "底盘电机故障，已紧急停止" → 需要人工维修

交互界面上的错误提示要避免技术术语。"TF树断裂"用户看不懂，"定位系统异常，请重启机器人"用户能理解。

错误恢复的设计也很重要。好的错误恢复是：机器人先尝试自动恢复（比如重新连接传感器、重新规划路径），如果自动恢复失败再通知用户。通知时要告诉用户"发生了什么"和"你可以做什么"。

差的错误提示："Error code 0x3F2A: Navigation failed"
好的错误提示："无法到达目标位置，可能路径被阻挡。
您可以：1) 清除路径上的障碍物 2) 选择其他位置 3) 重试"

给用户可操作的选项比单纯报错有用得多。用户看到选项就知道下一步该干什么，而不是对着一个错误码发呆。

四、安全交互设计

机器人和人共享空间时，交互设计直接关系到安全。

意图预告——机器人做动作之前先"告诉"人它要做什么。机械臂移动前先闪灯或发出提示音。扫地机器人转向前先减速。

紧急停止——物理急停按钮必须有，软件急停也要有（APP上的停止按钮）。急停后机器人要完全静止，不能有任何运动。

恢复确认——急停恢复时，需要用户确认"周围环境安全"才能继续。不能自动恢复——万一人还站在机器人运动范围内。

协作机器人还有一些特殊的安全交互设计：

速度限制——检测到人在附近时自动降速。激光雷达或深度相机检测到人在安全距离内，机械臂速度自动降到安全范围（通常250mm/s以下）。人离开后自动恢复正常速度。

功率限制——限制机械臂的输出功率。即使发生碰撞，冲击力也不会超过安全阈值。这是ISO/TS 15066标准的核心要求之一。

接触检测——通过力矩传感器实时检测异常接触。如果机械臂在运动过程中突然检测到意外的力（可能是碰到人了），立即停止运动。这个检测的灵敏度要仔细调——太灵敏会频繁误停影响效率，太迟钝则起不到安全保护作用。

class SafetyInteraction:
    def emergency_stop(self):
        self.robot.stop_all_motion()
        self.notify_user("已紧急停止")
        self.state = "ESTOPPED"
    
    def resume_from_estop(self):
        # 需要用户确认
        if not self.user_confirmed_safe():
            return False, "请确认周围环境安全后按恢复按钮"
        self.state = "IDLE"
        return True, "已恢复，可以重新开始"

五、面试高频追问

Q：机器人的交互设计和其他软件有什么不同？ A：最大区别是机器人有物理运动，涉及安全问题。交互设计必须考虑紧急停止、意图预告、恢复确认。而且机器人的状态更复杂（定位、传感器、电量、任务进度），状态反馈的设计更重要。

Q：怎么设计机器人的多模态交互？ A：多模态就是同时支持语音、触屏、手势、APP等多种输入方式。核心是设计一个统一的意图解析层——不管用户通过哪种方式输入，都解析成统一的意图（"去厨房""停止""回充"），然后交给同一个任务管理器处理。

Q：机器人死机了怎么办？ A：硬件层面要有看门狗（watchdog），软件死机后硬件自动重启。重启后要能恢复到安全状态——不能继续执行死机前的动作。软件层面要做好状态持久化，重启后能从上次的安全点恢复。

Q：怎么测试交互设计的好坏？ A：做用户测试。让没用过机器人的人来操作，看他们在哪一步卡住了、哪个提示看不懂、哪个操作容易误触。交互设计好不好不是工程师说了算，得看真实用户的反馈。

另外可以做启发式评估——对照Nielsen的十大可用性原则逐条检查。比如"系统状态是否可见""用户是否有控制感""错误是否能预防"。

Q：机器人的交互设计和手机APP有什么本质区别？ A：手机APP出错了最多崩溃重启，机器人出错了可能撞伤人。安全是机器人交互设计的第一优先级，这在手机APP里不太需要考虑。另外机器人的反馈延迟更大（物理运动需要时间），交互设计要考虑等待体验——不能让用户干等而不知道在发生什么。

人机交互设计是机器人从"能用"到"好用"的关键一步。状态反馈、错误处理、安全交互，这三个方面做好了，用户体验会有质的提升。下一篇我们聊协作机器人的安全标准ISO/TS 15066。

---

人机交互设计是机器人产品化的核心环节之一。示教/命令/自主三种交互模式、状态反馈三要素、错误分级处理、安全交互设计，这些是面试中常聊的话题。

上一篇：第276篇 多机器人路径协调 下一篇聊协作机器人安全标准ISO/TS 15066。

如果这篇文章对你有帮助，欢迎点赞支持一下，你的鼓励是我持续更新的动力！