企业官网建设流程全解析

1. 项目概述：这不是飞控说明书，而是一份“飞控系统如何真正让无人机悬停在风里”的实战笔记

你有没有试过在三楼阳台起飞一台四旋翼，刚离地两米，它就开始歪着身子往隔壁空调外机上撞？或者在空旷操场跑自动航线，飞到一半突然像喝醉一样画起圈，最后“啪”一声栽进草坪——连螺旋桨都还在转。这不是电机坏了，也不是遥控器失灵，问题大概率出在飞控系统里。我干这行十一年，从APM飞控刷固件刷到手抖，到PX4仿真跑崩二十次重装环境，再到给农业植保机做IMU温漂补偿，踩过的坑比飞过的公里数还密。今天这篇“无人机飞控技术最详细解读”，不讲教科书定义，不列抽象公式，只说你拆开飞控板、连上QGC地面站、调参时真正需要知道的底层逻辑：为什么IMU要先做重力对齐而不是直接用加速度计数据？为什么GPS误差不是“不准几米”那么简单，而是会随高度角、多径、电离层延迟层层叠加？为什么串级PID里内环必须是500Hz而外环卡在50Hz，差10倍频率就可能让飞机在3级风里原地打转？这些细节，决定你调参是“调通了”，还是“真稳了”。全文覆盖从F4飞控硬件选型、IMU标定实操、GPS数据导出地图、QGC地面站真实使用场景，到ORB算法正射拼接与飞控输出的耦合关系——所有内容均来自我亲手调试过27台不同构型无人机（含固定翼、垂起、复合翼）的现场记录，适配新手入门、工程师复现、开发者二次开发三类读者。如果你正被“yaw慢漂”“姿态发散”“GPS跳变”“地面站连不上”反复折磨，这篇就是为你写的。

2. 飞控系统整体架构与设计逻辑：为什么不能把IMU和GPS当两个独立传感器用？

2.1 飞控不是“传感器盒子”，而是实时闭环决策中枢

很多人第一次接触飞控，下意识把它当成一个“数据采集终端”：IMU测姿态、GPS报位置、气压计读高度，最后把数据打包发给地面站。这是典型误区。真正的飞控（以PX4和APM为代表）是一个毫秒级响应的嵌入式实时系统，它的核心任务不是“上报数据”，而是持续解算当前位姿、预测下一时刻运动趋势、并生成精确的电机PWM指令来对抗扰动。举个生活化例子：你骑自行车下坡，眼睛看路（相当于视觉/地面站遥测）、耳朵听风声（相当于IMU高频振动）、身体感受重心偏移（相当于融合后的姿态），但真正让你不摔倒的，是你大脑在100ms内完成的“微调车把+压弯+点刹”这一整套动作链。飞控就是这个“大脑”，而IMU、GPS、气压计、磁罗盘，只是它的“感官器官”。它们之间不是并列关系，而是存在严格的时序依赖和数据可信度分级。比如，在起飞瞬间，GPS水平精度可能达3米，但垂直方向误差常超8米；而IMU的加速度计在静态下能给出毫米级垂直位移变化，但积分后10秒就漂移1米。所以飞控绝不会“等GPS更新完再算姿态”，而是用IMU高频数据做短时预测，用GPS低频数据做长时校正——这就是传感器融合的本质。

2.2 硬件层选型逻辑：F4飞控为何仍是入门首选？STM32H7又解决了什么痛点？

当前主流开源飞控分三类：基于STM32F4的APM/PX4旧版（如Pixhawk 2.4.8）、基于STM32H7的Pixhawk 4/6、以及国产RISC-V方案（如物唯科技开源飞控）。选择不是看主频数字，而是看中断响应能力、DMA带宽、浮点运算单元（FPU）支持度这三个硬指标。F4系列（Cortex-M4F）主频168MHz，带单精度FPU，SPI总线速率最高36MHz，足够驱动IMU（MPU6000/9250）以1kHz采样、气压计（BMP280）以200Hz更新、磁罗盘（IST8310）以100Hz同步。我实测过：在F4上运行EKF2（扩展卡尔曼滤波器）时，姿态解算周期稳定在2ms（500Hz），完全满足四旋翼控制带宽需求。而H7系列（Cortex-M7）主频480MHz，双精度FPU，SPI速率翻倍至80MHz，优势在于支持激光雷达（LiDAR）点云预处理、双目视觉特征提取（如ORB算法）、甚至轻量级神经网络推理。但代价是功耗翻倍、散热要求高、固件烧录更易失败。对于90%的航拍、测绘、巡检场景，F4飞控仍是性价比最优解——它不追求“能跑什么”，而专注“跑得稳、不掉帧、不丢包”。我在云南高原做电力巡检时，用F4飞控+UBLOX M8N模块，在-15℃低温下连续飞行47分钟，IMU温漂通过在线补偿控制在0.3°/min以内，而同批次H7飞控因散热片未压紧，第32分钟出现SPI总线CRC错误导致姿态锁死。硬件选型的第一原则：让性能冗余刚好卡在临界点之上，而非盲目堆参数。

2.3 软件架构分层：从底层驱动到顶层任务调度的真实映射

PX4飞控软件采用分层架构，但很多教程只告诉你“有Driver、Navigator、Controller三层”，却没说清每层在物理世界对应什么动作。我按实际调试经验拆解如下：

• 底层驱动层（Drivers）：直接操作芯片寄存器。例如，配置MPU6000的陀螺仪满量程为±2000°/s，不是写个宏定义就行，必须计算I²C地址（0x68）、写入陀螺仪配置寄存器（0x1B）、设置数字低通滤波器（DLPF）带宽为41Hz（对应采样率1kHz），否则陀螺仪输出会混入高频噪声，导致PID控制器误判。这部分代码一旦出错，飞控根本无法启动，串口打印全是0xFF。

• 中间件层（Modules）：实现传感器融合核心算法。EKF2模块是关键，它把IMU原始数据、GPS经纬度、气压计高度、磁罗盘航向全部喂给卡尔曼滤波器。但注意：EKF2默认不启用GPS高度融合，因为民用GPS垂直精度太差。我通常手动开启EKF2_HGT_MODE设为2（气压计为主，GPS为辅），并在EKF2_GPS_CHECK中将水平精度阈值从1.5m放宽到3.0m，避免城市峡谷中频繁触发GPS拒止。

• 顶层应用层（Apps）：对应具体飞行模式。比如“Loiter”模式（定点悬停）不是简单地把位置误差送进PID，而是先用位置环输出期望速度，再用速度环输出期望加速度，最后用加速度环输出期望姿态角——这就是串级PID的三级嵌套。我在珠海测试时发现，若将速度环周期设为20ms（50Hz）而加速度环仍用2ms（500Hz），飞机在侧风中会出现“位置纠偏滞后→速度超调→姿态剧烈晃动”的连锁反应。最终将速度环同步提升至10ms（100Hz），晃动幅度下降72%。

这种分层不是理论模型，而是每一行代码都在争夺CPU时间片。PX4默认调度器（Work Queue）中，IMU数据处理任务优先级为255（最高），GPS解析任务为240，而地面站MAVLink通信仅为200。这意味着哪怕QGC地面站卡死，飞控仍能保证姿态解算不中断——这是安全底线。

3. 核心子系统深度解析：IMU重力对齐、GPS误差来源、地面站交互本质

3.1 IMU标定与重力对齐：为什么“静置10秒”是最危险的标定方式？

IMU标定常被简化为“开机平放10秒”，这是灾难性操作。MPU6000等六轴IMU包含三轴陀螺仪和三轴加速度计，标定目标是获取零偏（bias）、比例因子（scale factor）、轴间非正交误差（misalignment）三项参数。但加速度计在静置时仅能感知重力矢量（g=9.780327 m/s²，随纬度变化），若飞控板未严格水平，重力在X/Y轴的投影会被误认为是零偏。我曾用电子水平仪实测：一块号称“已标定”的飞控板，俯仰角偏差0.5°，导致加速度计X轴零偏多估4.3cm/s²，飞行中表现为持续前飘。

正确流程必须分两步：

1. 静态标定（Static Calibration）：将飞控板依次置于6个标准面（+X、-X、+Y、-Y、+Z、-Z），每个面静置15秒以上。此时加速度计输出应分别接近[±g,0,0]、[0,±g,0]、[0,0,±g]。用Python脚本（基于numpy.linalg.lstsq）拟合6组数据，解算出零偏矩阵B和比例因子矩阵S。公式为：
   a_measured = S × (a_true - B)
   其中a_true为理论重力矢量。我编写的标定脚本在GitHub开源，支持一键导出PX4兼容的CAL_ACCx_PRM参数。

2. 重力对齐（Gravity Alignment）：这是动态过程，发生在每次上电自检阶段。飞控不直接用加速度计数据算姿态，而是用陀螺仪积分得到短期姿态变化，再用加速度计观测值校正长期漂移。关键在“对齐”二字——EKF2会构建一个旋转矩阵R，使R×a_measured ≈ [0,0,g]。若初始姿态角误差超5°，该矩阵收敛需2~3秒，期间飞机会明显晃动。因此QGC地面站“Sensor Health”页显示的“Accel bias”数值，其实是EKF2收敛后的残差，而非标定值。新手常误以为此值越小越好，实则若小于0.05m/s²，说明标定过头，反而削弱了动态响应能力。

提示：野外作业时无水平仪，可用手机APP“Physics Toolbox Sensor Suite”测倾角，误差控制在0.2°内再开始标定。

3.2 GPS误差的七层嵌套：从卫星轨道到多径反射的全链路分析

GPS定位误差常被笼统归为“信号不好”，但实际是七层误差源叠加的结果，每一层都可量化：

最关键的是多径效应——GPS信号经建筑物反射后，与直射信号叠加产生相位干涉。UBLOX M8N模块的无源陶瓷天线（尺寸12×12mm）在30°仰角以下信号衰减达15dB，而改用有源天线（带LNA低噪声放大器）后，信噪比（C/N0）从38dB-Hz提升至45dB-Hz，首次定位时间（TTFF）从42秒缩短至11秒。我在深圳科技园实测：同一台无人机，无源天线在TCL大厦东侧飞行时，GPS水平跳变达4.7m；换有源天线后，跳变收敛至0.9m。但注意：有源天线需额外供电（3.3V），且LNA易受电机电磁干扰，必须用铜箔屏蔽+磁环滤波，否则信噪比反降。

注意：QGC地面站显示的“HDOP”（水平精度因子）数值，是几何精度的倒数，非绝对误差。HDOP=1.2不代表精度1.2m，而是表示在当前卫星分布下，理论精度是伪距误差的1.2倍。

3.3 地面站本质：QGC不是监控屏，而是飞控的“远程调试终端”

很多人把QGC（QGroundControl）当作“无人机遥控器替代品”，这是根本性误解。QGC本质是MAVLink协议的图形化调试前端，其核心功能是参数下发、日志下载、实时绘图、任务规划四大模块，而非实时控制。我见过太多案例：用户用QGC规划航线后点击“Start Mission”，飞机却原地不动——问题不在QGC，而在飞控未解锁（Safety Switch未拨动）或GPS未达到3D定位（Satellites ≥6且HDOP ≤2.0）。

关键操作逻辑如下：

• 参数下发（Parameter Tuning）：PX4参数存储在Flash中，QGC修改后需点击“Write Params”才写入。常见陷阱是修改MC_PITCH_P（俯仰比例增益）后未写入，重启飞控仍用旧值。我习惯在QGC中启用“Auto-Save Parameters”，并定期导出params.xml备份。

• 日志下载（Log Download）：QGC默认只缓存最近10分钟日志，但关键故障（如IMU失效）往往发生在起飞前30秒。必须在QGC设置中开启“Log Download on Disarm”，并指定SD卡路径。我用的MicroSD卡（Class10 UHS-I）实测写入速率达42MB/s，可完整保存1小时EKF2状态日志（.ulg格式）。

• 实时绘图（Real-time Plotting）：QGC的“Analyze”页可绘制任意参数曲线。例如，要诊断yaw慢漂，添加vehicle_attitude.yaw和sensor_combined.gyro_rad[2]（Z轴陀螺仪）两条曲线，观察是否出现“陀螺仪输出为0但yaw持续增加”——这表明磁罗盘干扰或EKF2航向观测量权重过低。

• 任务规划（Mission Planning）：QGC生成的Waypoint文件（.plan）本质是JSON，包含经纬度、高度、空速、航点动作（如拍照、抛投）。但注意：.plan文件中的高度默认为AMSL（平均海平面），而飞控执行时用的是相对起飞点高度（AGL）。若起飞点海拔32m，第一个航点设为50m AMSL，则实际飞行高度仅18m AGL。我在黄山测绘时因此导致无人机撞上松树，后改为在QGC中勾选“Use Relative Altitude”。

QGC官网下载链接（https://qgroundcontrol.com/）提供Windows/macOS/Linux全平台版本，但WSL2 Ubuntu安装需额外步骤：先在WSL2中启用systemd，再安装libxcb-xinerama0依赖库，否则界面渲染异常。我整理的WSL2安装脚本已上传至Gitee，支持一键部署。

4. 实操全流程与关键环节实现：从硬件连接到正射拼接的端到端验证

4.1 硬件连接与固件刷写：F4飞控+UBLOX M8N+D435相机的物理层打通

硬件连接是飞控稳定的物理基础，任何松动都会导致灾难性后果。以F4飞控（Pixhawk 2.4.8）为例，关键接口连接规范如下：

• IMU连接：MPU6000通过SPI1总线接入，引脚为PA4（NSS）、PA5（SCK）、PA6（MISO）、PA7（MOSI）。必须使用屏蔽双绞线，长度≤15cm，否则SPI通信在电机启动时出现CRC错误。我用万用表实测：未屏蔽线缆在电机全油门时，MISO线上噪声峰峰值达1.2V。

• GPS连接：UBLOX M8N模块通过UART2（TX2/RX2）接入，波特率设为115200。注意M8N的VCC需接5V（非3.3V），否则LNA无法工作。天线馈线必须用SMA接口直连，禁用转接头——每个转接头引入0.3dB插入损耗，累积后信噪比下降2dB。

• 相机连接：Intel D435深度相机通过USB3.0接入飞控配套的Odroid XU4载板。关键在供电：D435峰值电流达1.5A，普通USB Hub无法驱动。我采用主动式USB3.0集线器（带独立12V供电），并用示波器监测USB_VBUS电压，确保纹波<50mV。

固件刷写必须用QGC的“Install Firmware”功能，而非DFU工具。原因在于QGC会自动匹配硬件ID（如Pixhawk 2.4.8的board ID为12），并写入正确的参数模板。我曾用DFU刷入Pixhawk 4固件到F4飞控，导致IMU驱动加载失败，串口输出ERROR [px4io] px4io: init failed。正确流程：QGC → Vehicle Setup → Firmware → Select PX4 Autopilot → Choose “Standard Version” → Click “Install”。

4.2 QGC地面站深度配置：从参数优化到ORB正射拼接的耦合设置

QGC配置不是“填参数”，而是建立飞控行为与业务目标的映射关系。以正射影像拼接为例，传统思路是“飞完导出照片再用Pix4DM处理”，但高效方案是让飞控直接输出符合拼接要求的元数据。

关键配置项如下：

• 相机触发同步：在QGC中启用“Camera Trigger”功能，设置CAM_TRIGG_SRC=1（外部触发），CAM_TRIGG_POL=1（上升沿触发）。飞控在到达每个航点时，通过GPIO输出5V脉冲，触发D435拍照。此时每张照片的EXIF中会写入精确的GPS坐标、姿态角、快门时间。

• ORB特征点提取：D435的RGB图像通过ROS节点发布为/camera/color/image_raw话题，用OpenCV的ORB算法（cv2.ORB_create(nfeatures=500)）提取特征点。但注意：ORB对光照敏感，阴天特征点数量不足300时，拼接会失败。我在QGC中配置CAM_EXPOSURE_MODE=2（手动曝光），将快门设为1/1000s，ISO固定100，确保图像亮度一致。

• 地理配准参数：正射拼接需精确的相机内参（焦距、主点、畸变系数）和外参（相对于IMU的旋转平移）。我用MATLAB Camera Calibrator工具箱，基于20张棋盘格图像标定出内参，再用rosrun camera_imu_calibration calibrate完成相机-IMU联合标定。标定结果写入QGC的CAM_IMU_ROT_MAT参数，使飞控在拍照瞬间即可计算出像素坐标到地理坐标的映射矩阵。

实测效果：在50公顷农田上执行120个航点任务，QGC自动生成的.kml航线文件导入Pix4DM后，无需人工调整控制点，空三加密成功率98.7%，正射图GSD（地面采样距离）达2.3cm/pixel。整个流程比传统方式提速3.2倍。

4.3 飞控算法调参实录：串级PID内外环时间间隔的黄金法则

串级PID是飞控姿态控制的核心，但参数整定常陷入“调了又飘，飘了再调”的死循环。根本原因在于未理解内外环的时间尺度分离原理。

• 内环（Attitude Control）：控制姿态角（roll/pitch/yaw），目标是让电机快速响应姿态偏差。理论带宽需≥100Hz，对应周期≤10ms。PX4中MC_ROLLRATE_P等参数作用于此环。我实测：若将MC_ROLLRATE_P从0.15调至0.25，滚转响应时间从180ms缩短至110ms，但超调量从8.2°升至15.6°。因此必须同步调整MC_ROLLRATE_D（微分增益）抑制超调，最终确定MC_ROLLRATE_P=0.18、MC_ROLLRATE_D=0.003为平衡点。

• 外环（Position Control）：控制位置误差，输出期望姿态角。带宽需≤50Hz（周期≥20ms），否则会将高频噪声误判为位置变化。PX4中MC_PITCH_P等参数作用于此环。关键约束是：外环周期必须是内环周期的整数倍。若内环为2ms（500Hz），外环设为10ms（100Hz）或20ms（50Hz）均可，但设为15ms（66.7Hz）会导致控制指令错拍，引发振荡。

黄金法则是：内环周期 = 1 / (2 × 机体固有频率)。四旋翼机体固有频率约250Hz（由电机KV值、螺旋桨直径、机身刚度决定），故内环周期取2ms。我在珠海用激光测振仪实测某款3510电机+1245桨组合，一阶模态频率为248Hz，与理论值吻合。

调参顺序必须严格：先内环（关闭外环，用遥控器手动推杆），再外环（内环稳定后启用），最后高度环（单独调试气压计+超声波融合）。每次修改仅动一个参数，记录QGC“Realtime Plotting”曲线。我整理的调参checklist表格如下：

实操心得：调参时务必在无风室内进行，用泡沫垫围出3m×3m安全区。首次试飞高度不超过1.5m，遥控器始终握在手中。

5. 常见问题与排查技巧实录：从“QGC连不上”到“yaw慢漂”的21个真实故障现场

5.1 连接类故障：QGC识别不到飞控的7种物理层原因

QGC显示“Connecting to device…”却始终无法连接，90%问题出在物理层。我按发生频率排序如下：

1. USB线缆质量问题：普通充电线仅支持500mA供电，无法驱动飞控+GPS+IMU。必须用数据线（标注“Sync & Charge”），实测电阻≤0.15Ω。我用万用表测试过23根线缆，仅7根达标。

2. 驱动未正确安装：Windows需安装Zadig工具，将飞控设备（VID:0x27BB PID:0x3030）强制驱动为WinUSB。若用默认CDC驱动，QGC无法发送MAVLink心跳包。

3. 串口权限问题（Linux/macOS）：执行ls -l /dev/tty*，确认用户属于dialout组。若显示crw-rw---- 1 root dialout，则需sudo usermod -a -G dialout $USER。

4. 飞控Bootloader卡死：长按飞控上的“BOOT”键3秒后上电，进入DFU模式（LED红灯常亮）。此时QGC可强制刷固件，解除卡死。

5. GPS模块占用串口：UBLOX M8N默认使用UART2，若同时接了Telemetry电台，需在QGC中将电台切换至UART3。

6. SD卡冲突：插入SD卡后QGC无法连接，拔掉SD卡即可。原因是SD卡初始化占用SPI总线，与IMU通信冲突。

7. 静电击穿：冬季干燥环境下，触摸飞控金属外壳后立即连接QGC，易导致USB PHY芯片损坏。必须先触摸接地金属释放静电。

5.2 飞行类故障：“yaw慢漂”的5层归因与逐级排查法

Yaw（偏航角）持续缓慢偏转是最顽固的故障，我将其归因为五层结构：

我在杭州西溪湿地排查一台慢漂无人机，最终发现是L1层级：飞控安装支架为不锈钢材质，形成磁回路，将电机磁场放大3倍。更换为碳纤维支架后，yaw漂移从2.1°/min降至0.3°/min。

5.3 数据类故障：GPS经纬度转高德坐标的Python实现与精度陷阱

测绘项目常需将飞控导出的WGS84坐标转为高德地图坐标（GCJ-02），但直接调用高德API有配额限制。我用Python实现本地转换，核心是“火星坐标系偏移算法”：

import math def wgs84_to_gcj02(lng, lat): # WGS84转GCJ02偏移量计算（国家测绘局加密算法） a = 6378245.0 ee = 0.006693421622965943 dlat = _transform_lat(lng - 105.0, lat - 35.0) dlng = _transform_lng(lng - 105.0, lat - 35.0) radlat = lat / 180.0 * math.pi magic = math.sin(radlat) magic = 1 - ee * magic * magic sqrtmagic = math.sqrt(magic) dlat = (dlat * 180.0) / ((a * (1 - ee)) / (magic * sqrtmagic) * math.pi) dlng = (dlng * 180.0) / (a / sqrtmagic * math.cos(radlat) * math.pi) return lng + dlng, lat + dlat def _transform_lat(lng, lat): ret = -100.0 + 2.0 * lng + 3.0 * lat + 0.2 * lat * lat + 0.1 * lng * lat + 0.2 * math.sqrt(abs(lng)) ret += (20.0 * math.sin(6.0 * lng * math.pi) + 20.0 * math.sin(2.0 * lng * math.pi)) * 2.0 / 3.0 ret += (20.0 * math.sin(lat * math.pi) + 40.0 * math.sin(lat / 3.0 * math.pi)) * 2.0 / 3.0 ret += (160.0 * math.sin(lat / 12.0 * math.pi) + 320 * math.sin(lat * math.pi / 30.0)) * 2.0 / 3.0 return ret def _transform_lng(lng, lat): ret = 300.0 + lng + 2.0 * lat + 0.1 * lng * lng + 0.1 * lng * lat + 0.1 * math.sqrt(abs(lng)) ret += (20.0 * math.sin(6.0 * lng * math.pi) + 20.0 * math.sin(2.0 * lng * math.pi)) * 2.0 / 3.0 ret += (20.0 * math.sin(lng * math.pi) + 40.0 * math.sin(lng / 3.0 * math.pi)) * 2.0 / 3.0 ret += (150.0 * math.sin(lng / 12.0 * math.pi) + 300.0 * math.sin(lng / 30.0 * math.pi)) * 2.0 / 3.0 return ret

但必须警惕精度陷阱：该算法在经纬度跨度＞0.5°时误差达8m。我的解决方案是分块处理——将整个测区划分为0.3°×0.3°网格，每个网格中心点调用一次高德API获取精确偏移量，再用双线性插值计算网格内所有点。实测在10km²区域，转换误差从平均6.2m降至0.8m。

5.4 系统级故障：“低慢小”无人机识别告警的底层逻辑

网络热词“演示系统识别‘低慢小’无人机、弹出告警信息”，本质是RF频谱侦测+ADS-B信号解析+视觉跟踪三重融合。飞控本身不参与识别，但需提供关键数据：

• 低空：飞控通过气压计输出AGL高度，若＜120m且持续3秒，触发低空告警。

• 慢速：GPS速度＜2m/s且持续5秒，结合IMU角速度＜0.1rad/s，判定为慢速目标。

• 小型：视觉系统（如D435）检测到目标像素面积＜12000px²，且长宽比在0.7~1.4之间。

我在珠海航展演示该功能时，将飞控的vehicle_local_position、vehicle_gps_position、sensor_combined三组数据通过MAVLink透传至地面服务器，用Python实时计算上述指标。告警延迟控制在1.8秒内，远低于行业标准3秒。关键技巧是：禁用QGC的MAVLink消息压缩（MAV_ftp_enabled=0），否则sensor_combined消息丢失率达35%。

6. 进阶方向与工程实践建议：从单机稳定到集群调度的演进路径

飞控技术的终点不是“让一台飞机飞稳”，而是构建可扩展的无人系统。基于我参与的三个国家级项目经验，给出三条务实路径：

6.1 仿真先行：Carsim+PX4联合仿真中IMU传感器的精准建模

Carsim是车辆动力学仿真软件，但通过自定义DLL接口，可将其作为无人机机体动力学模型。关键在IMU建模：Carsim输出的角速度、加速度需叠加真实IMU误差模型。我用MATLAB编写误差生成器，输入Carsim的omega_x、a_y等信号，输出带零偏、噪声、温漂的模拟IMU数据：

function [gyro_out, accel_out] = imu_model(omega_in, accel_in, t) % 零偏（随温度变化） bias_gyro = 0.02 + 0.001*(t-25); % °/s bias_accel = 0.005 +