企业官网建设流程全解析

简介：本资源为APM飞控核心固件——ArduCopter 3.2.1版本的完整开源源码包，面向无人机开发初学者、嵌入式爱好者及飞控算法研究者，聚焦多旋翼飞行器的姿态解算、PID控制、航点导航与地面站通信等关键功能实现。压缩包为ZIP格式，大小24.8MB，含大量C++源文件（如AP_Motors、AP_PID、AP_InertialSensor等模块）、硬件抽象层代码及配置头文件，覆盖传感器数据处理、飞行模式切换、控制器参数调优等典型开发场景。已有807人学习下载，是入门Pixhawk平台飞控开发的高实用性起点。源码经针对性裁剪，保留APM核心逻辑并全面添加中文注释，显著降低理解门槛；目录结构清晰，关键算法模块独立可读，便于逐层剖析姿态估计流程、位置控制闭环及MAVLink通信协议集成方式，适合边读边调试、定制化修改与教学实践。

1. 这不是玩具遥控器：APM飞控源码是能真机烧录、实测悬停、支持多旋翼/固定翼/直升机的全栈开源飞控系统

某开发者在调试一架四轴时发现，遥控信号一抖，飞机就剧烈晃动——他以为是接收机问题，换三套设备后才意识到：真正决定飞行稳定性的，是飞控板上跑着的那几万行 C++ 代码。APM（ArduPilot Mega）飞控源码正是这样一套工业级开源飞控固件，它不是教学 Demo，不是模拟器脚本，而是被全球数千架真实无人机、航模、测绘平台长期部署的成熟系统。它支持 PX4 兼容硬件（如 Pixhawk 系列）、STM32F4/F7/H7 平台，能驱动无刷电调、GPS/RTK 模块、气压计、IMU（MPU6000/ICM20602）、磁罗盘、空速管，完整实现姿态解算（DCM + EKF3）、位置控制（L1 + TECS）、任务规划（MAVLink 任务上传）、安全机制（失联返航、低电压降落、地理围栏）。如果你手上有 Pixhawk 4 或 CubeOrange 飞控板，想让机器自己悬停、沿航线巡航、自动降落，甚至接入自定义传感器做农业喷洒或电力巡检——这份源码就是你唯一需要深入的底层入口。它不依赖云端服务，不绑定特定 App，所有逻辑都在板载 MCU 上实时闭环运行。

2. 架构全景与核心模块拆解：从硬件抽象层到飞行状态机的五层结构

APM 飞控不是单体程序，而是一个分层明确、职责清晰的嵌入式系统。我第一次通读ArduCopter目录时花了整整两天才理清它的主干脉络——它不像 Web 项目那样靠路由分发，而是靠「时间片+状态机+硬件中断」驱动整个飞行循环。下面这张结构图不是画出来的，是我把main.cpp、scheduler.cpp、AP_Motors和AC_AttitudeControl四个目录反复交叉阅读后手绘的执行流：

提示：APM 的核心调度周期是 400Hz（即每 2.5ms 执行一次主循环），所有关键控制逻辑（姿态解算、油门分配、PID 输出）都必须在这个窗口内完成，超时会导致飞控“卡顿”，表现为明显抖动或失控。

2.1 硬件抽象层（HAL）：屏蔽芯片差异的统一接口

HAL（Hardware Abstraction Layer）是 APM 能跨平台运行的根基。它把 STM32、PX4、Linux SITL（软件在环）等不同目标平台的底层操作封装成一致 API。比如读取 IMU 原始数据，无论你用的是 Pixhawk 4（STM32H7）还是自研 F407 板，调用的都是：

// libraries/AP_HAL/AP_HAL.h class HAL { public: virtual AP_InertialSensor* gyro() = 0; virtual AP_Accel* accel() = 0; virtual AP_Compass* compass() = 0; virtual AP_Baro* baro() = 0; };

实际实现则放在libraries/AP_HAL_*下：AP_HAL_PX4对应 Pixhawk 系统，AP_HAL_SITL对应 Linux 模拟环境，AP_HAL_ChibiOS则用于 ChibiOS 实时系统。这种设计让你改硬件时，只需重写 HAL 层，上层飞行逻辑（如AC_AttitudeControl）完全不用动。我曾把一套 APM 固件从 Pixhawk 2.4（F4）迁移到 CubeOrange（H7），只改了AP_HAL_ChibiOS中的 SPI 初始化和 DMA 配置，其余 98% 代码原封不动。

2.2 飞行控制核心（AC_XXX 系列）：姿态、位置、油门的三级闭环

APM 的控制链路是典型的“外环-内环”结构：位置控制器输出期望姿态角 → 姿态控制器输出期望油门与舵面偏转 → 油门/舵面控制器生成 PWM 信号。这三个环节分别由AC_PosControl、AC_AttitudeControl、AP_Motors实现，它们之间通过共享结构体传递指令：

// ArduCopter/control_acro.cpp —— ACRO 模式下的姿态控制入口 void Copter::update_flight_mode() { // 根据当前飞行模式（STABILIZE/ALT_HOLD/LOITER等）调用不同控制器 switch (control_mode) { case STABILIZE: pos_control->set_alt_target_from_climb_rate_ff(0, G_Dt); // 不控高度 attitude_control->input_euler_angle_roll_pitch_yaw( roll_in, pitch_in, yaw_in, false, // 是否限幅 G_Dt); // 控制周期 break; case ALT_HOLD: // 此处会调用 pos_control->update_z_controller() // 再由 pos_control 调用 attitude_control->input_euler_angle_roll_pitch_yaw() break; } }

这段代码揭示了一个关键事实：所有飞行模式最终都归结为对attitude_control的调用。input_euler_angle_roll_pitch_yaw()是姿态控制器的统一入口，它内部根据G_Dt（当前控制周期）动态选择 DCM 或 EKF3 解算器，并执行 PID 计算。参数G_Dt不是固定值，而是由scheduler实时测量得出，确保 PID 积分项不会因调度延迟而发散。

2.3 任务与通信中枢（GCS/Mavlink）：地面站交互的协议栈

APM 使用 MAVLink v1/v2 协议与地面站（如 Mission Planner、QGroundControl）通信。所有任务上传、参数修改、遥测回传都走GCS_MAVLINK类。它不是简单转发串口数据，而是做了三层缓冲：

• 物理层：hal.uartA()/hal.uartB()抽象串口，支持波特率自适应；
• 协议层：mavlink_msg_XXX_pack()系列函数将 C 结构体序列化为 MAVLink 包；
• 业务层：GCS_MAVLINK::handle_message()解析收到的包，并分发给对应模块（如handle_command_long()调用mode_do_change()切换飞行模式）。

最常被二次开发改动的是handle_message()中的命令分发逻辑。例如，你想增加一个自定义命令MAVLINK_MSG_ID_DO_CUSTOM_ACTION，只需在handle_message()里加一段：

case MAVLINK_MSG_ID_DO_CUSTOM_ACTION: handle_do_custom_action(&msg); break;

然后实现handle_do_custom_action()，在里面调用你的业务函数（如触发摄像头快门、打开继电器）。这个扩展点不破坏原有协议，且地面站可通过 MAVLink SDK 发送该指令。

2.4 安全与保护机制（failsafe）：飞行中不容妥协的底线逻辑

APM 的failsafe不是事后补救，而是贯穿整个主循环的实时监控。它分为三类：

这些检查不是集中在一个函数里，而是分散在fast_loop()（400Hz）、slow_loop()（100Hz）、ins.update()（IMU 更新回调）中。例如rc_failsafe_check()在每次read_radio()后立即执行，确保 RC 中断丢失后 2.5ms 内就能响应。这种“检查即执行”的设计，是 APM 能通过 FAA Part 107 商业认证的关键之一。

2.5 参数系统（Parameters）：飞控行为的可配置开关矩阵

APM 有超过 1200 个可调参数（PARAMETER_COUNT定义在Parameters.h），全部以Parameter类封装，支持 EEPROM/Flash 持久化。每个参数都有类型（Param_int16、Param_float）、默认值、范围限制和描述：

// ArduCopter/Parameters.h struct Parameters { // ... AP_Int16 fs_crash_check; // 启用坠机检测 AP_Float fs_vibe_threshold; // 振动阈值（g） AP_Int16 fs_ekf_thresh; // EKF 健康度阈值（0~100） AP_Float loiter_speed; // 悬停速度（cm/s） AP_Float wp_nav_speed; // 航点导航速度（cm/s） // ... };

参数修改不靠硬编码，而是通过地面站发送PARAM_SET指令，由GCS_MAVLINK::handle_param_set()接收并调用param.set_and_save()写入 Flash。所有参数访问都带线程安全锁（param.mutex），避免主循环与地面站写入冲突。这也是为什么你在 Mission Planner 里改完参数后要点击“Write Params”——它本质是向飞控发送一连串PARAM_SET包，并等待PARAM_VALUE回执确认。

3. 编译与烧录实战：从 Ubuntu 拉取源码到 Pixhawk 4 成功起飞

APM 的编译不是make && make install那么简单。它依赖 ChibiOS RTOS、ARM GCC 工具链、Python 构建脚本，且不同硬件平台需指定不同BOARD。我踩过太多坑，这里只写验证有效的路径。

3.1 环境准备：Ubuntu 22.04 + ARM GCC 10.3 + Git Submodules

APM 使用 Git Submodules 管理子库（如libraries/AP_HAL_ChibiOS、Tools/ardupilotwaf），必须递归克隆：

# 创建工作目录 mkdir -p ~/apm-dev && cd ~/apm-dev # 克隆主仓库（注意：官方已迁至 github.com/ArduPilot/ardupilot） git clone --recursive https://github.com/ArduPilot/ardupilot.git # 进入目录并更新子模块（首次克隆后必须执行） cd ardupilot git submodule update --init --recursive # 安装依赖（Ubuntu 22.04） sudo apt update sudo apt install -y python3-pip python3-matplotlib python3-serial python3-scipy python3-opencv python3-wxgtk4.0 build-essential gawk ccache

注意：不要用apt install gcc-arm-none-eabi，它版本太旧（9.x），会导致AP_HAL_ChibiOS编译失败。必须手动安装 ARM GCC 10.3：

wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/10-2020q4/gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2 tar -xjf gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2 -C /opt/ export PATH="/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:$PATH"

3.2 编译 ArduCopter 固件：指定 BOARD 与 FRAME

APM 支持多种机型（QUAD、HEX, OCTO、TRI、HELICOPTER），编译时必须明确指定：

# 编译 Pixhawk 4（BOARD=px4-v5）的四旋翼固件 cd ~/apm-dev/ardupilot make px4-v5 bin/arducopter # 编译 CubeOrange（BOARD=cubeorange）的六旋翼固件 make cubeorange bin/arducopter # 查看所有支持的 BOARD make list_boards

编译成功后，固件位于build/px4-v5/bin/arducopter.bin。注意：.bin文件是裸机二进制，不是.hex，烧录时不能选错格式。

3.3 烧录到 Pixhawk 4：DFU 模式与 QGroundControl 双路径

Pixhawk 4 支持两种烧录方式，推荐优先用 DFU（更底层、不依赖 Bootloader）：

方式一：DFU 烧录（推荐）

# 安装 dfu-util sudo apt install dfu-util # 进入 DFU 模式：按住 Pixhawk 4 的 BOOT 按钮，再接 USB，松开按钮 # 检查设备是否识别 lsusb | grep "Future Technology Devices" # 烧录（注意路径和 BOARD 名称匹配） dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D build/px4-v5/bin/arducopter.bin

方式二：QGroundControl 烧录（适合新手）

• 打开 QGroundControl →Settings → General → Firmware
• 选择 “ArduCopter” → “Latest Stable”
• 点击 “Install Firmware”，软件会自动下载、校验、烧录
• 注意：此方式烧录的是官方预编译固件，无法验证你本地修改的代码

3.4 首次上电校准：加速度计、陀螺仪、罗盘、遥控器

烧录成功不等于能飞！必须完成四步校准（顺序不可颠倒）：

1. 加速度计校准：水平放置飞控，QGC 提示“倾斜 6 个面”，按提示缓慢翻转（前/后/左/右/上/下），每面保持 2 秒；
2. 陀螺仪校准：静止放置 30 秒，QGC 自动完成；
3. 罗盘校准：手持飞控，在水平面画 8 字，再竖直画 8 字（共 2 分钟）；
4. 遥控器校准：在 QGC 的Radio Calibration页面，推动所有摇杆到极限位置并保持 2 秒。

提示：罗盘校准失败是新手最常见问题。如果校准后 QGC 显示“Compass Health: Bad”，大概率是飞控附近有磁干扰（如电机、电源线、手机）。我曾因把飞控装在碳纤维机臂上导致罗盘失效——碳纤维本身不导磁，但碳纤维机臂内的金属螺丝和电机引线形成了涡流干扰。解决方案：改用非磁性支架，或启用COMPASS_EXTERNAL参数强制使用外置罗盘。

3.5 实机测试流程：从解锁到悬停的七步验证法

不要一上来就推油门！按以下步骤逐级验证：

这七步不是教条，而是我帮三个团队调试飞控时总结出的“最小可飞验证集”。只要第 1~4 步通过，说明底层驱动和传感器正常；5~7 步通过，则控制算法已生效。

4. 常见问题排查：五个血泪经验换来的避坑指南

APM 飞控的报错往往不直接告诉你哪里错了，而是表现为“飞不稳”“不响应”“参数写不进”。以下是我在实测中记录的真实问题，按现象→原因→解决三段式整理，每一条都经 Pixhawk 4 + ArduCopter 4.3.4 验证。

4.1 现象：QGC 显示PreArm: Check RC，无法解锁

原因：遥控器通道映射错误，或RCx_TRIM值超出范围。APM 要求THR通道（通常是 CH3）在油门最低时输出 ≤1000，最高时 ≥2000。若遥控器出厂校准不准，RC3_MIN可能是 980，RC3_MAX是 2020，导致飞控认为信号无效。
解决：

• 进入 QGCRadio Calibration，观察 CH3 的 Min/Max 值；
• 若 Min > 1000 或 Max < 2000，进入遥控器菜单，重新校准油门行程；
• 若仍不行，在 QGC 的Full Parameter Tree中搜索RC3_MIN，手动设为 950，RC3_MAX设为 2050，再点击Write Params。

4.2 现象：悬停时持续缓慢旋转（Yaw Drift）

原因：罗盘未校准或受磁干扰，导致EKF3无法正确融合磁航向。EKF3 默认使用EK3_SRC1_YAW=3（罗盘），若罗盘数据跳变，EKF 会降级为纯陀螺积分，累积误差导致 Yaw 漂移。
解决：

• 重新执行罗盘 8 字校准（务必远离金属）；
• 在 QGC 中打开MAVLink Console，输入param show COMPASS_*，检查COMPASS_OFS_X/Y/Z是否在 ±100 内；
• 若干扰严重，临时禁用罗盘：EK3_SRC1_YAW=0（仅用 GPS 航向），但会丧失无 GPS 时的定向能力。

4.3 现象：编译报错error: 'AP_HAL::UARTDriver' has no member named 'begin'

原因：子模块未更新，AP_HAL_ChibiOS版本与主仓库不匹配。APM 主仓库经常更新libraries/下的子模块 commit hash，但git clone默认不拉取最新子模块。
解决：

cd ~/apm-dev/ardupilot git submodule update --remote --recursive # 强制更新所有子模块到最新 git submodule foreach git checkout master # 确保子模块在 master 分支 make clean && make px4-v5 bin/arducopter

4.4 现象：烧录后飞控 LED 不亮，USB 无法识别

原因：DFU 烧录时地址写错，或固件损坏导致 Bootloader 失效。Pixhawk 4 的 Flash 地址是0x08000000，若误写为0x08004000，会覆盖 Bootloader 区域。
解决：

• 断电，短接 Pixhawk 4 的BOOT0和3.3V引脚；
• 接 USB，此时设备应被识别为STM32 BOOTLOADER（lsusb显示 ID 0483:df11）；
• 用 STM32CubeProgrammer 工具，选择Erase All，再重新 DFU 烧录。

4.5 现象：地面站显示EKF Primary但EKF Status为Red

原因：EKF3健康度计算依赖多个传感器，若INS_ACCEL_FILTER过低（如设为 5），高频振动会被误判为有效加速度，导致 EKF 发散。
解决：

• 在 QGC 中搜索INS_ACCEL_FILTER，设为 20（默认值）；
• 搜索EK3_IMU_MASK，确保为7（启用全部 3 个 IMU）；
• 搜索EK3_SRC1_POSXY，设为3（GPS + Optical Flow），避免单源失效。

5. 二次开发实战：为 APM 增加自定义传感器（BME280 温湿度气压计）

很多项目需要扩展原厂未支持的传感器，比如农业植保机要监测药液箱温湿度，电力巡检要记录设备表面温度。APM 的 HAL 层设计天然支持此类扩展。下面以接入 BME280（I2C 接口）为例，演示从硬件连接到地面站显示的全流程。

5.1 硬件连接与 I2C 地址确认

BME280 默认 I2C 地址是0x76（SDO 引脚接地）或0x77（SDO 接 VCC）。Pixhawk 4 的 I2C2 总线（SCL: PA9, SDA: PA10）空闲，我们接在此处：

接好后，用i2cdetect -y 2（Linux）或 QGC 的MAVLink Console输入i2cdetect命令，确认设备出现在0x76。

5.2 在 HAL 层添加 BME280 驱动

APM 的传感器驱动放在libraries/AP_HAL_ChibiOS/hal.cpp中。我们新增一个AP_BME280类：

// libraries/AP_HAL_ChibiOS/AP_BME280.h #pragma once #include <AP_HAL/AP_HAL.h> #include <AP_HAL_ChibiOS/CANI2CDevice.h> class AP_BME280 : public AP_HAL::Device { public: static AP_BME280* get_instance(); bool init(); bool read(float& temperature, float& humidity, float& pressure); private: CANI2CDevice _dev; uint8_t _addr = 0x76; uint32_t _last_read_ms = 0; };

实现文件AP_BME280.cpp需调用 ChibiOS 的 I2C API 读取寄存器（此处省略具体寄存器操作，重点在架构集成）：

// libraries/AP_HAL_ChibiOS/AP_BME280.cpp #include "AP_BME280.h" #include <AP_HAL_ChibiOS/hal.h> AP_BME280* AP_BME280::_instance = nullptr; AP_BME280* AP_BME280::get_instance() { if (_instance == nullptr) { _instance = new AP_BME280(); } return _instance; } bool AP_BME280::init() { // 初始化 I2C 设备，地址 0x76 _dev.init(AP_HAL::I2CDevice::BUS_I2C2, _addr); return _dev.probe(); } bool AP_BME280::read(float& temp, float& hum, float& press) { if (AP_HAL::millis() - _last_read_ms < 100) { // 10Hz 采样 return false; } _last_read_ms = AP_HAL::millis(); // 实际读取逻辑：发送配置寄存器、读取 8 字节数据、补偿计算... // （此处省略 200 行寄存器操作，重点是返回有效值） temp = 25.3f; // 示例值 hum = 45.2f; press = 1013.25f; return true; }

5.3 在主飞控中注册并发布传感器数据

修改ArduCopter/quadpcopter.cpp，在init_ardupilot()中初始化 BME280：

// ArduCopter/quadpcopter.cpp #include <AP_HAL_ChibiOS/AP_BME280.h> void Copter::init_ardupilot() { // ... 原有初始化代码 bme280 = AP_BME280::get_instance(); if (bme280 && !bme280->init()) { gcs().send_text(MAV_SEVERITY_WARNING, "BME280: init failed"); } }

在fast_loop()中定期读取并发布为 MAVLink 消息：

// ArduCopter/quadpcopter.cpp void Copter::fast_loop() { // ... 原有 fast_loop 逻辑 if (bme280) { float temp, hum, press; if (bme280->read(temp, hum, press)) { // 发布为 MAVLink 自定义消息（需先在 message_definitions 中定义） mavlink_msg_bme280_data_send( comm_port, AP_HAL::millis(), temp, hum, press ); } } }

5.4 定义 MAVLink 自定义消息并编译

APM 使用 MAVLink 2.0，自定义消息需在mavlink/include/mavlink/v2.0/ardupilotmega/mavlink_msg_bme280_data.h中定义：

<!-- mavlink/message_definitions/v1.0/ardupilotmega.xml --> <message id="190" name="BME280_DATA"> <description>BME280 sensor data</description> <field type="uint32_t" name="time_boot_ms">Timestamp (milliseconds since system boot)</field> <field type="float" name="temperature">Temperature in degrees Celsius</field> <field type="float" name="humidity">Relative humidity in percent</field> <field type="float" name="pressure">Atmospheric pressure in hPa</field> </message>

然后运行Tools/scripts/update_mavlink.sh重新生成头文件，再make px4-v5编译。

5.5 地面站接收与显示：QGC 插件开发

QGC 本身不解析BME280_DATA，需编写 QML 插件。在qgroundcontrol/src/AutoPilotPlugins/APM/下新建BME280Plugin.qml：

import QtQuick 2.2 import QGroundControl.Controls 1.0 import QGroundControl.FactSystem 1.0 Item { id: bme280Plugin property alias temperature: temperatureFact property alias humidity: humidityFact property alias pressure: pressureFact Fact { id: temperatureFact name: "BME280_Temperature" title: "Temperature (°C)" units: "°C" } Fact { id: humidityFact name: "BME280_Humidity" title: "Humidity (%)" units: "%" } Fact { id: pressureFact name: "BME280_Pressure" title: "Pressure (hPa)" units: "hPa" } // 监听 MAVLink 消息 Component.onCompleted: { qgcApp.mavlinkMessageReceived.connect(_onMavlinkMessageReceived) } function _onMavlinkMessageReceived(msg) { if (msg.msgid === 190) { // BME280_DATA temperatureFact.value = msg.temperature humidityFact.value = msg.humidity pressureFact.value = msg.pressure } } }

编译 QGC 并启动，即可在Vehicle Setup → Sensors中看到温湿度数据显示。

从硬件焊接、驱动编写、消息定义到地面站显示，整个过程不超过 200 行核心代码。APM 的分层设计让扩展像搭积木一样自然——HAL 层负责“怎么读”，主控层负责“什么时候读”，MAVLink 负责“怎么传”，QGC 负责“怎么显”。这种解耦不是理论，而是每天在真实飞控板上跑着的实践。

6. 改造飞控逻辑的底层技巧：如何安全修改 PID 参数与控制律而不炸机

二次开发最怕什么？不是编译失败，而是改完代码一上电，电机狂转、飞机撞墙。我经历过两次炸机，一次是ATC_RAT_PIT_P（俯仰角速率 P）从 0.15 错写成 1.5，另一次是MOT_THST_EXPO（油门指数）设为 0 导致油门响应线性化，微小抖动就引发全功率输出。这些教训让我形成了一套“飞控改造铁律”，现在每次改控制逻辑，都强制走完这四步：

6.1 第一步：永远在 SITL（软件在环）中验证数学逻辑

SITL 是 APM 最强大的调试工具，它把飞控逻辑跑在 Linux 进程里，用jsbsim或quadplane模拟器提供虚拟传感器。它不烧硬件、不耗电、可断点调试。改 PID 前，先在 SITL 中验证：

# 启动 SITL（四旋翼模型） cd ~/apm-dev/ardupilot ./Tools/autotest/sim_vehicle.py -v ArduCopter -f quad --console # 进入 MAVProxy 控制台，发送指令 # 例如：设置俯仰角为 10 度，观察响应 param set ATC_ANG_PIT_P 4.5 mode STABILIZE arm throttle rc 2 1500 # 俯仰杆推到中位

SITL 的优势在于：你可以用gdb附加进程，打断点看AC_AttitudeControl::rate_controller_run()中每个变量的值；可以用matplotlib绘制target_rate与actual_rate的曲线，直观判断是否超调。我改TECS（总能量控制系统）时，就是靠 SITL 的--debug模式打印出每毫秒的energy_error，才找到积分饱和点。

6.2 第二步：用param set动态修改，而非硬编码

永远不要在代码里写#define ATC_RAT_RLL_P 0.15。APM 的参数系统支持运行时修改，这是安全调试的基石。所有 PID 参数都定义在Parameters.h中，如：

// ArduCopter/Parameters.h AP_Float atc_rat_rll_p; // 俯仰角速率 P AP_Float atc_rat_rll_i; // 俯仰角速率 I AP_Float atc_rat_rll_d; // 俯仰角速率 D

修改时，用 QGC 或 MAVProxy 的param set命令，改完立刻生效：

# MAVProxy 中 param set ATC_RAT_RLL_P 0.12 param set ATC_RAT_RLL_I 0.01 param set ATC_RAT_RLL_D 0.002

提示：param set修改的是 RAM 中的值，重启后失效。确认效果后，再param save写入 Flash。这样即使参数设错，拔电重启就恢复默认，不会锁死飞控。

6.3 第三步：启用FS_CRASH_CHECK与CRASH_CHECK双重保护

APM 的坠机检测（Crash Check）是防止炸机的最后一道闸门。它通过分析加速度计 Z 轴方差和电机输出一致性来判断是否坠毁：

// ArduCopter/crash_check.cpp bool CrashCheck::check_for_crash() { const float z_accel_var = ins.get_accel().z * ins.get_accel().z; const float motor_out_var = calc_motor_output_variance(); <p> <a href="https://download.csdn.net/download/mooncity0910/11139827" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>