一、PX4飞控概述：从历史到实战

各位同学，欢迎来到《PX4飞控参数配置实战》的第一章。我是你们这门课的老朋友，一个在无人机行业摸爬滚打多年的飞控工程师。

咱们开门见山。今天要聊的，是PX4飞控的“前世今生”。你可能会问：“学参数配置，干嘛要先扯历史？” 嗯，我当年也有这个疑问。直到有一次，我在一个老项目里看到一堆奇怪的参数名，翻遍文档才明白——那是早期版本的遗留物。不了解历史，你连参数为什么叫这个名字都搞不懂。

PX4的故事，得从2011年说起。那时候，无人机飞控还是个“小圈子”的事。苏黎世联邦理工（ETH Zurich）的几个研究生，觉得当时的飞控软件太封闭、太难用，干脆自己写了一个。

这就是PX4的雏形。它最初叫“PIXHAWK”，是个硬件项目。后来软件和硬件分家，软件部分就独立成了我们今天说的PX4固件。

几个关键节点，我帮你捋一下：

年份	事件	我的个人感受
2011	ETH启动PIXHAWK项目	那时候我还在玩ArduPilot，觉得PX4就是个“学院派”玩具
2014	PX4加入Dronecode基金会	嗯，从这开始，它不再是“玩具”了
2017	PX4 v1.6发布，重构了导航滤波器	我记得那次升级，好多老用户的参数都得重新调
2020	PX4 v1.11，引入uORB消息机制大改	说实话，那次改动让我重写了不少驱动代码
至今	活跃迭代，v1.14+，支持VTOL、水下、室内	现在它已经是行业里绕不开的“标配”了

核心观点： PX4不是一夜成名的。它从学术项目起步，靠着开源社区的“野蛮生长”，一步步变成了今天无人机、机器人和自动驾驶领域的“瑞士军刀”。

聊完历史，咱们看看PX4到底跑在什么硬件上。说白了，飞控硬件就是一块“特化”的嵌入式计算机。

典型的PX4硬件架构，我习惯把它分成三层：

我个人习惯，选硬件时最看重的是IMU冗余。为什么？因为IMU一旦挂了，飞控就是“睁眼瞎”。我在项目里遇到过两次IMU数据跳变，幸亏有冗余传感器，飞机才没炸。

避坑指南： 别只看主频！PX4对硬件的要求，核心是“传感器数据同步精度”和“实时性”。我曾经见过有人用一块高频MCU，但IMU数据读取延迟大，结果飞起来晃晃悠悠的。

下面这张图，是我自己画的PX4硬件架构简图。你一看就明白数据是怎么流的：

硬件是骨架，软件才是灵魂。PX4的软件架构，说白了就是一个“实时操作系统 + 模块化应用”的组合。

核心组件，我帮你拆解一下：

实时操作系统（RTOS）： 基于NuttX。为什么选它？因为它是POSIX兼容的，写代码跟写Linux应用差不多。我个人觉得，这是PX4比ArduPilot“现代”的地方。
uORB（微对象请求代理）： 这是PX4的“消息总线”。所有模块之间不直接调用，而是通过uORB发布/订阅消息。比如，GPS模块发布位置数据，导航模块订阅它。
模块化应用： 每个功能都是一个独立模块。比如 sensors 模块读传感器，ekf2 模块做姿态估计，mc_pos_control 模块做位置控制。
参数系统： 这就是咱们这门课的核心了。所有可调参数都通过 param 系统管理，支持动态加载和保存。

注意： 别被“模块化”迷惑了。模块之间虽然解耦，但耦合在“数据流”上。我曾经遇到过一个问题：GPS模块数据更新频率太高，导致uORB消息队列溢出，整个飞控卡死。嗯，调参数时一定要关注消息频率。

下面这张软件架构图，能帮你理清模块之间的关系：

你可能会觉得，PX4就是个“无人机飞控”。其实不然。它的应用场景，比你想象的要广得多。

我按“成熟度”给你排个序：

一句话总结： 只要是需要“自主运动控制”的机器人，PX4都能插一脚。但不同场景的“坑”不一样，咱们这门课会重点讲多旋翼和VTOL的参数配置，因为这是大家最常碰到的。