机器人状态机设计时如何考虑异常状态？｜网易机器人测开面经解析

60 秒回答模板

我会把机器人状态机拆成正常主状态和异常安全状态。正常状态覆盖 Idle、Init、Ready、Running、Paused、Completed；异常不要只叫 Error，而是按可恢复和不可恢复拆，比如定位丢失、传感器故障、障碍阻塞、执行器超时、急停和人工接管。设计时抓五点：SafeStop 能从任意状态抢占；每个状态有进入/退出条件、允许动作、超时和日志；可恢复异常先降级或重试，不可恢复进入安全停机；恢复动作要幂等并防状态振荡；最后用故障注入和日志回放覆盖每条异常转移。

考点 异常分类

难度 真实面经题

回答目标 说明机器人状态机如何把异常分级、安全抢占、恢复策略和测试覆盖设计清楚。

深入解析

状态要分正常和异常

正常状态描述任务生命周期，例如待机、初始化、就绪、执行、暂停、完成。异常状态描述系统不能继续按原计划运行的原因，应该按风险和可恢复性拆分，不能所有问题都塞进一个 Error。

异常要有优先级

急停、碰撞风险、人员闯入这类安全事件应能从任意状态抢占到 SafeStop；定位丢失、传感器短时异常、执行器超时可以按风险降级。优先级避免多个异常同时出现时状态转移混乱。

每个状态定义契约

状态契约包括进入条件、退出条件、允许指令、禁止指令、超时、重试次数、安全输出和日志字段。比如 LocalizationLost 状态应限制速度、停止规划更新、尝试重定位，失败后进入人工接管或故障停机。

恢复动作要幂等

异常恢复常发生在通信抖动和传感器间歇失效中。恢复动作要可重复执行而不产生副作用，状态转移要有 hysteresis 或稳定窗口，避免在 Fault 和 Running 之间来回抖动。

可观测性是状态机一部分

每次转移都要记录事件、原状态、新状态、触发条件、关键传感器值、控制输出和时间戳。没有日志的状态机很难排查偶发故障，也无法在测试中证明异常路径被覆盖。

测试用故障注入覆盖

测试要覆盖传感器断流、定位跳变、障碍阻塞、执行器不响应、通信超时、低电量、急停、人工接管和恢复成功/失败。每条异常转移都应有仿真或实机用例，并验证安全输出。

text

异常状态转移伪代码

state Running:
  on obstacle_too_close -> SafeStop(reason="collision_risk")
  on localization_lost -> Degraded(reason="localization")
  on actuator_timeout -> Fault(reason="actuator")
  on task_done -> Completed

state Degraded:
  action limit_speed(); request_relocalization()
  on localization_ok stable_for 2s -> Running
  on timeout 5s -> SafeStop(reason="relocalization_timeout")
  on emergency_stop -> SafeStop(reason="manual_estop")

易错点

只画正常任务流程，没有考虑急停、定位丢失、传感器失效和执行器超时。
所有异常都进入一个 Error，无法区分降级、重试、停车和人工接管。
状态没有进入退出条件和超时，导致边界行为不可测。
忽略状态转移日志，偶发故障无法复现。
异常恢复动作不可幂等，重复触发可能造成二次故障。

面试官追问

为什么不能只用一个 Error 状态？

不同异常的安全动作和恢复策略不同。传感器短时丢帧可能可降级，急停必须立即停车，执行器故障可能需要锁止和人工处理，混成一个 Error 会让恢复和测试都不清晰。

如何避免状态机振荡？

用稳定窗口、hysteresis、重试次数、冷却时间和事件优先级，避免传感器值在阈值附近抖动时反复进出异常状态。

状态机怎么做自动化测试？

把事件序列、初始状态和期望状态转移写成用例，通过仿真或日志回放注入故障，验证状态、控制输出、报警和日志。