3. 开发环境搭建

PX4自定义传感器驱动开发的第一步，不是写代码，而是把“能编译、能仿真、能上板”的闭环环境搭起来。驱动代码最终要同时运行在SITL仿真和真实飞控上，因此环境搭建的目标是：在Ubuntu上获得一套可复现的PX4源码树、可用的交叉编译工具链、可运行的Gazebo仿真，以及能识别I2C/SPI传感器的硬件连接条件。本节按“系统→源码→工具链→仿真→硬件→编译”的顺序展开。

一、核心原理：为什么驱动开发对环境如此敏感

PX4驱动属于中间件层代码，它依赖NuttX实时操作系统、uORB消息总线和板级支持包（BSP）。驱动源码通过CMake被编入不同的目标：px4_sitl用于仿真，px4_fmu-v5_default等用于真实硬件。如果工具链版本、子模块状态或Python依赖不一致，最常见的现象是编译通过但运行时报“sensor not found”，或仿真中驱动根本不加载。因此环境搭建的核心是版本锁定与依赖完整。

二、Ubuntu系统与基础依赖

建议使用原生Ubuntu或WSL2（需支持USB直通）。先更新系统并安装通用工具：

sudo apt update && sudo apt upgrade -y
sudo apt install -y git cmake ninja-build build-essential \
  python3 python3-pip python3-venv ccache gdb

# 串口与USB权限
sudo usermod -a -G dialout $USER
sudo apt install -y picocom minicom

PX4官方提供了一键脚本，它会自动安装仿真、工具链和Python依赖：

git clone https://github.com/PX4/PX4-Autopilot.git --recursive
cd PX4-Autopilot
bash ./Tools/setup/ubuntu.sh
# 安装完成后重启终端，使dialout组生效

三、源码获取与子模块管理

PX4使用Git子模块管理NuttX、mavlink、uORB等组件。克隆时必须带--recursive，否则编译会因缺少NuttX而失败。若已克隆但子模块不全，执行：

git submodule update --init --recursive
git submodule status | head
make distclean   # 清理旧构建缓存

四、工具链与仿真环境

工具链分两类：仿真使用本机gcc，真实硬件使用arm-none-eabi-gcc。ubuntu.sh已安装二者，可用以下命令验证：

arm-none-eabi-gcc --version
gcc --version
cmake --version

仿真环境推荐Gazebo Classic，启动SITL：

make px4_sitl gazebo-classic
# 或仅启动SITL，不加载机型
make px4_sitl none

若使用Gazebo Sim（新版本），命令为make px4_sitl gz_x500。仿真启动后，可在QGroundControl中查看姿态与传感器状态，这是验证驱动是否被正确加载的最快方式。

五、硬件准备与连接检查

自定义传感器通常通过I2C、SPI或UART接入。以I2C为例，需要准备：飞控（如Pixhawk 4/6X）、传感器模块、杜邦线或专用转接板、USB转串口调试器。接线前务必确认电压（3.3V/5V）与上拉电阻，I2C总线必须共地。上电后用i2cdetect或PX4的i2c scan确认地址：

# 在PX4 NSH中
i2c scan
# 期望看到类似 0x68 的传感器地址

六、编译流程与目标选择

PX4使用make封装CMake。常用目标如下表：

编译硬件固件后，使用make px4_fmu-v5_default upload烧录。若只想验证驱动是否被编入，可查看构建日志中是否出现你的驱动源文件：

make px4_fmu-v5_default | grep -i my_sensor
# 或查看 build/px4_fmu-v5_default/ 下的编译单元

七、案例场景：从零到仿真中看到自定义传感器

假设要接入一个I2C温度传感器。流程是：在src/drivers/下新建驱动目录，编写CMakeLists.txt与Kconfig，在板级配置中使能该驱动，然后执行make px4_sitl gazebo-classic。启动后在NSH中执行my_sensor start，再用listener sensor_temp查看uORB消息。若仿真中无数据，优先检查驱动是否被编译进px4_sitl目标，而不是先怀疑传感器。

八、常见误区与复盘

• 只克隆主仓库：忘记--recursive，导致NuttX缺失，编译报错。
• 工具链版本漂移：系统升级后gcc版本变化，旧固件链接失败，应固定版本或使用官方脚本。
• 仿真与硬件目标混淆：在SITL中测试的驱动未加入硬件板级配置，上板后“消失”。
• 权限问题：未加入dialout组，串口无法打开，表现为上传失败或NSH无响应。
• 未清理构建缓存：切换分支后残留build/导致诡异错误，make distclean是首选排查手段。

完成以上步骤后，你应当能在SITL中启动自定义驱动并看到uORB消息，同时能编译出对应硬件的固件。环境搭建不是一次性任务，而是驱动开发过程中反复回归的基线：每次修改板级配置或切换PX4版本，都应重新执行make distclean并验证仿真，确保问题定位在驱动逻辑而非环境差异上。