第281篇故障诊断与处理——机器人坏了怎么办-平芜编程栈

调试方法论讲的是怎么找bug。故障诊断与处理讲的是系统在生产环境里出了状况怎么应对。两者有交集，但侧重点不一样——调试是开发阶段的事，故障处理是上线之后的事。

机器人部署在客户现场，出了问题不能像开发时那样慢慢排查。客户在等着，产线在停着，你得快速判断故障原因、快速恢复服务。至于深入分析根因，那是恢复服务之后的事。

面试聊到项目经验，能把故障处理机制讲清楚，说明你做过真正的产品。很多团队在开发阶段从不考虑故障处理，等上线了才手忙脚乱地补。

一、故障分类与分级

故障处理的第一步是分类。不同类型的故障，处理策略完全不同。

传感器故障：激光雷达不返回数据、相机图像全黑、IMU数据跳变。这类故障通常有明确的检测手段——检查数据是否有效、检查时间戳是否更新、检查数据范围是否合理。

通信故障：网络断开、DDS丢包、话题断连。这类故障表现为数据延迟增大或者完全收不到数据。需要监控通信状态，设置超时检测。

计算资源故障：CPU过载、内存不足、GPU显存溢出。这类故障表现为系统变慢或者进程被杀。需要监控资源使用率，设置阈值报警。

算法故障：定位丢失、路径规划失败、检测结果异常。这类故障最棘手，因为算法没有"报错"，只是输出不合理。需要设计合理性检查机制。

class FaultLevel: INFO = 0 # 信息，不影响运行 WARNING = 1 # 警告，性能下降但可继续 ERROR = 2 # 错误，部分功能不可用 CRITICAL = 3 # 严重，系统必须停止

分级处理很关键。不是所有故障都需要停机。传感器偶尔丢一帧数据，降级运行就行；激光雷达彻底挂了，必须停机。把故障分成INFO/WARNING/ERROR/CRITICAL四个等级，每个等级对应不同的处理策略。

实际操作中，故障分级要结合业务场景来定。同样是相机故障，在巡检机器人上可能是WARNING（降低检测能力但能继续走），在抓取机器人上就是CRITICAL（没法干活了必须停）。不能脱离业务谈故障等级。

还有一个容易忽略的点：故障告警的收敛。如果激光雷达每秒都报一次故障，你的告警系统会被淹没。要对同类故障做合并和限流——同一种故障5分钟内只告警一次，但记录故障持续时间和发生频次。

二、故障检测机制

故障处理的前提是能检测到故障。常见的检测手段有三种。

心跳检测：每个模块定期发布心跳信号。如果超过一定时间没有心跳，就认为这个模块挂了。ROS2里可以用lifecycle node的生命周期管理来实现。

# 心跳检测示例 class HealthMonitor(Node): def __init__(self): super().__init__('health_monitor') self.heartbeats = {} self.timer = self.create_timer(1.0, self.check_health) def check_health(self): now = self.get_clock().now() for module, last_hb in self.heartbeats.items(): if (now - last_hb).nanoseconds > 5e9: self.report_fault(module, 'heartbeat_timeout')

数据有效性检测：检查传感器数据是否在合理范围内。激光雷达的点云密度不能低于某个阈值、IMU的加速度值不能超过物理极限、相机的图像不能全黑或全白。这些检测逻辑要放在数据接收的第一时间执行，越早发现问题越好。

合理性检测：检查算法输出是否合理。定位结果不能跳到地图外面去、规划的路径不能穿过障碍物、检测到的目标数量不能突然暴增。这类检测需要结合业务逻辑来设计。

def validate_pose(pose, map_bounds): if not is_inside_bounds(pose, map_bounds): return False, 'pose_out_of_map' if pose_confidence(pose) < 0.3: return False, 'low_confidence' return True, 'ok'

三、故障恢复策略

检测到故障之后怎么处理？不同等级的故障有不同的恢复策略。

自动恢复：对于可恢复的故障，系统自动尝试恢复。比如通信断连后自动重连、定位丢失后自动重新初始化、进程崩溃后自动重启。自动恢复要设置重试次数上限，避免无限重试。重试策略推荐用指数退避——第一次1秒后重试，第二次2秒，第三次4秒，间隔越来越长。这样既给了系统恢复的时间，又不会太频繁地重试导致资源浪费。

降级运行：部分功能不可用时，系统降级运行。比如一个激光雷达挂了，用另一个雷达继续工作（精度下降但能用）。深度相机挂了，切换到纯视觉方案。降级运行要明确告知用户当前状态。

安全停机：严重故障时，系统必须安全停机。注意是"安全"停机，不是直接断电。移动机器人要先刹车停稳、机械臂要回到安全姿态、夹爪要松开或保持当前状态。

def emergency_stop(robot): robot.set_velocity(0, 0) # 速度归零 robot.enable_brakes() # 启用制动 robot.report_status('estopped') # 通知运维人员 send_alert('CRITICAL: Emergency stop triggered')

故障恢复之后要做故障记录。记录故障发生时间、故障类型、恢复耗时、影响范围。这些数据对后续改进系统可靠性非常有价值。

四、故障日志与根因分析

故障处理完不代表事情结束了。事后要做根因分析（Root Cause Analysis），找到故障的根本原因，防止同类问题再次发生。

常用的根因分析方法是"5个为什么"。故障现象：机器人突然停了。为什么？因为紧急停车被触发了。为什么？因为激光雷达数据断了。为什么？因为网线松了。为什么？因为线缆固定夹没装好。为什么？因为装配工艺没有这个步骤。根因是装配工艺缺陷，修复方案是增加线缆固定工序。

故障日志要结构化存储，方便后续统计分析。哪些故障出现频率最高？哪些故障导致的停机时间最长？这些数据能指导你优先改进什么。

# 故障记录结构 fault_record = { 'timestamp': '2024-03-15T14:30:00', 'fault_type': 'sensor_disconnect', 'fault_module': 'lidar_front', 'severity': 'CRITICAL', 'recovery_time': 45, # 秒 'root_cause': 'cable_loose', 'action_taken': 'replaced_connector' }

定期做故障统计分析，计算MTBF（平均无故障时间）和MTTR（平均恢复时间）。这两个指标是衡量系统可靠性的核心数据。