2. 无人机系统基础
要建立可用的故障树与诊断策略,首先必须把无人机看作一个由多子系统耦合而成的工程对象,而不是一架“会飞的相机”。从故障诊断视角看,无人机可划分为五大功能域:飞行平台(结构与气动)、动力系统(能源与推进)、导航系统(定位与姿态)、通信链路(遥控、遥测与图传)、任务载荷(作业与感知设备)。每个功能域都有独立的失效模式,又通过供电、数据、机械振动等路径相互影响。理解它们的组成与工作原理,是后续把“现象”映射到“故障源”的前提。
一、飞行平台:一切故障的机械与气动基准
飞行平台是无人机的“骨架”,通常由机身、机臂、起落架、减振组件和紧固件构成。多旋翼平台多采用碳纤维管与工程塑料组合,以在重量与刚度之间取得平衡。平台的核心作用是提供稳定的几何基准:电机安装面必须共面,否则推力方向不一致,会直接表现为悬停漂移或姿态振荡。平台还承担着隔离振动的任务,飞控与IMU通常安装在减振板上,若减振球老化或紧固螺丝松动,振动会耦合进惯性传感器,导致姿态解算发散。因此,在故障树中,平台类故障常以“机臂裂纹”“减振失效”“起落架变形”等底事件出现,其后果往往向上传播到导航与动力系统。
二、动力系统:从电能到推力的能量链
电动动力系统由电池、电调(ESC)、电机和螺旋桨组成,形成一条“电能—转速—推力”的转换链。电池输出直流电,经分电板分配给各电调;电调根据飞控发出的PWM或DShot信号,将直流电逆变为三相交流电驱动无刷电机;电机带动螺旋桨产生拉力。四旋翼通过改变对角电机转速差实现俯仰、横滚和偏航控制。这条链上任何一环异常都会表现为动力失衡:电池内阻增大导致大油门时电压骤降,电调过热触发降额,电机轴承磨损引起异响与效率下降,螺旋桨变形则直接损失推力。诊断时常用“电流—转速—振动”三参数联合判断,例如同一油门指令下某电机电流明显偏高,往往指向该电机或桨叶的机械阻力异常。
典型动力链参数监测点:
电池:总电压、单芯电压、放电电流、温度
电调:输入电压、相电流、MOS温度、转速反馈
电机:三相电阻、空载电流、轴承温升
螺旋桨:动平衡、桨距、表面损伤
三、导航系统:多源融合的姿态与位置估计
导航系统解决两个问题:“我在哪”和“我朝哪”。IMU提供角速度和加速度,磁罗盘提供航向参考,气压计提供高度,GNSS提供绝对位置与速度,RTK进一步把定位精度提升到厘米级,视觉/激光雷达则用于无GPS环境下的相对定位。飞控通过卡尔曼滤波等算法融合这些异构数据,输出姿态角、位置和速度估计。导航故障的典型特征是“数据跳变”或“缓慢漂移”:磁罗盘受电机电流干扰会产生航向偏差,GNSS多路径效应导致位置跳动,气压计受桨叶气流影响出现高度波动。诊断时需关注各传感器的一致性,例如GNSS速度与IMU积分速度长期背离,通常说明其中一路已失效。
四、通信链路与任务载荷:指令与作业的末端
通信链路包括遥控上行链路、遥测下行链路和图传链路,工作频段常见2.4GHz与5.8GHz。链路质量由发射功率、天线增益、距离和遮挡共同决定,链路预算不足时表现为遥控延迟、遥测丢包或图传花屏。任务载荷则是无人机的作业末端,如云台相机、激光雷达、多光谱传感器、喷洒系统或抛投装置。载荷通过机械接口和电气接口与平台连接,其故障既可能来自自身(如云台电机堵转、相机存储卡满),也可能来自平台侧(如供电不足、减振不良导致图像模糊)。在故障树中,载荷故障常与任务失败直接关联,是诊断策略中优先级较高的分支。
| 功能域 | 核心组成 | 典型失效模式 | 常见传播后果 |
|---|---|---|---|
| 飞行平台 | 机架、机臂、减振、起落架 | 裂纹、松动、变形 | 振动增大、姿态漂移 |
| 动力系统 | 电池、电调、电机、螺旋桨 | 电压骤降、过热、轴承磨损 | 推力失衡、失控坠落 |
| 导航系统 | IMU、磁罗盘、GNSS、气压计 | 数据跳变、漂移、失锁 | 定位错误、返航失败 |
| 通信链路 | 遥控、数传、图传、天线 | 丢包、延迟、断连 | 指令失效、超视距失控 |
| 任务载荷 | 云台、相机、雷达、喷洒 | 堵转、存储满、供电不足 | 任务中断、数据缺失 |
五、案例场景:一次悬停漂移的跨域排查
某四旋翼在悬停时持续向右漂移,操作手首先怀疑GNSS。但检查发现GNSS星数与精度因子正常,IMU姿态角也无明显跳变。进一步查看电机转速发现右前电机在相同油门指令下转速偏低,电流偏高。拆检发现该电机轴承轻微卡滞,同时该机臂减振球老化,振动传递到IMU后使姿态估计出现小偏差,飞控不断修正反而加剧了漂移。这是一个典型的“动力—平台—导航”跨域耦合故障:表面现象在导航,根因却在动力与平台。若只按单一系统排查,很容易反复更换GNSS模块而无法解决问题。
因此,在学习无人机系统基础时,应始终带着“组成—工作原理—失效模式—传播路径”这条线索去理解每个功能域。只有把五大系统的边界与耦合关系梳理清楚,后续构建故障树时才能准确设置顶事件、中间事件和底事件,也才能设计出高效的诊断策略。