ROS+PX4开源固定翼无人机视觉二次开发全流程解析

ROS + PX4 开源固定翼无人机，尤其像迅翼 S7 视觉版这类自带视觉模块和二次开发接口的平台，解决的是固定翼平台上自主飞行、目标识别与任务载荷联动的开发问题。它适合三类人：想从旋翼转到固定翼的开发者、需要做视觉跟踪或巡线的学生项目组、还有想验证固定翼自主起降和长航时任务算法的工程师。这类平台最值得关注的不是某一个功能，而是 ROS、PX4 飞控、机载电脑、相机和任务逻辑能不能在一条链路里闭环。我实际接触下来的体会是：固定翼二次开发的麻烦，大部分不在飞控参数，而在环境搭建、坐标系转换和视觉失效时的安全处理。下面按实际落地顺序拆开说。

1. 先搞清楚 ROS + PX4 固定翼平台到底在解决什么问题

1.1 固定翼不是旋翼的放大版

很多从旋翼转过来的开发者，会把固定翼想象成“飞得慢一点的航拍机”。这个误解在二次开发中很容易踩坑。

旋翼飞机可以原地悬停，可以通过四个电机差速产生任意方向的推力，控制逻辑相对集中。固定翼不一样，它必须持续获得前进速度才能产生升力。没有空速或者速度过低，飞机可能直接失速；转弯时如果坡度太大，升力方向变化，高度保持不住；速度太快又可能超过机体结构承受范围。这些动力学特性决定了固定翼在 PX4 里的控制方式与旋翼完全不同。

在 PX4 中，固定翼有单独的姿态控制器、位置控制器和固定翼混控器。Offboard 模式下，你不能像旋翼那样让飞机在一个很小的空间里慢慢悬停调整，而是要根据空速、航向和任务航线持续给出合理的速度或位置设定点。如果设定点逻辑写得不对，飞机会出现剧烈俯仰或者绕圈下坠。第一次用 PX4 做固定翼 Offboard 时，最好先在地面站里跑一遍标准 Auto 任务，感受一下飞机对航点和高度指令的响应方式。

1.2 视觉版平台增加的开发范围

所谓“视觉版”，不只是在一个固定翼上装一个摄像头。它的核心是把视觉传感器、机载计算、识别算法、决策逻辑和飞控执行串成一个完整闭环。

平台一般包含这样几层：

• 底层是 PX4 飞控，负责姿态控制、导航、遥控器保护和失效保护。
• 中间是机载电脑或嵌入式计算板，负责运行视觉算法和任务逻辑。
• 上层是相机等传感器，输出实时图像、深度信息或目标坐标。
• 通信层通过 MAVLink 把机载电脑的指令发给飞控，再把飞控状态传回任务逻辑。

这类二次开发平台的定位，是让你不用从零焊电路、调飞控板、画结构件，而是把精力集中在算法和业务逻辑上。比如目标识别、视觉降落、巡线、目标跟随、避障决策等。像迅翼 S7 视觉版这类整体方案，往往已经把机体结构、飞控和相机接口焊在一起，剩下的问题就是“怎么让视觉结果变成飞控能执行的指令”。

1.3 开源平台的价值在于可改源码

选择 ROS + PX4 而不是封闭飞控，最大的好处是源码可见、可改、可复现。PX4 的固定翼控制器可以调整，混控器可以自定义，MAVLink 消息字段也能扩展。ROS 则让相机驱动、图像处理、状态机、规划算法这些模块可以分开开发、单独替换。

换句话讲，开源平台适合做两件事：第一，学习固定翼自主飞行系统是怎么组织的；第二，把新的感知或决策算法挂上去验证。这两件事都需要你理解飞控和上层计算之间如何配合，而不是只在一个图传画面里看摄像头。

实践中我建议先别急着改飞控内部代码。先把整条数据链路跑通：相机出图，识别模块输出目标，决策模块发设定点，飞控执行并回传状态。链路稳定之后，再回去优化飞控参数或改控制算法，否则问题边界会非常难定位。

2. 环境准备：ROS、PX4 和仿真器必须一起规划

2.1 版本搭配：Ubuntu、ROS、PX4 是一个组合

很多人在环境搭建阶段就放弃，不是因为代码难，而是因为版本之间互相不兼容。ROS、PX4、Gazebo、MAVROS、QGroundControl 并不是独立安装的，它们之间有关联约束。

常见的一组搭配是 Ubuntu 20.04 + ROS Noetic + PX4 稳定分支 + Gazebo。这套组合资料多，教程多，MAVROS 在 ROS Noetic 下也相对成熟。Ubuntu 22.04 + ROS 2 Humble + PX4 也可以跑，但很多老教程里的rostopic、roslaunch命令在 ROS 2 里变成了ros2 topic、ros2 launch，话题名和节点设计也变了，新手如果直接上 ROS 2，遇到问题的时候不容易判断是语法问题还是功能问题。

所以我一般建议第一套环境选 Ubuntu 20.04 和 ROS Noetic。等你把固定翼的仿真链路跑通，理解了 MAVLink 和话题通信之后，再去迁移 ROS 2 会轻松很多。

硬件上，内存建议至少 8G，最好 16G。磁盘预留 50G 以上，因为 Gazebo 模型、PX4 依赖库、ROS 包和编译缓存都很占空间。虚拟机可以用，但 USB 设备透传和 GPU 加速会比较麻烦，真机调试时更容易出问题。有条件的话直接用物理机装双系统，或单独准备一台 Linux 电脑。

2.2 ROS 安装：手动和脚本选哪种

ROS 安装一般有两条路：

一是手动配置 apt 源后安装。在 Ubuntu 20.04 上，可以用清华源或阿里云镜像源把sources.list配好，然后通过 apt 安装ros-noetic-desktop或ros-noetic-desktop-full。手动安装的好处是你能看到每一个依赖，出问题的时候知道从哪里排查。

二是使用社区一键安装脚本。比如很多教程里提到的“鱼香ROS”一键安装工具，它会帮你配置源、安装 ROS、处理依赖。这类脚本对学习环境很友好，能省不少时间。但我的建议是：第一次使用前至少把脚本内容过一遍，看看它会修改哪些系统配置，不要盲跑。因为一键脚本不一定适配你当前的 Ubuntu 小版本，也不一定适配你后续要装的 PX4 工具链。

装完后验证方式很简单。ROS 1 下打开一个终端运行roscore，能启动就说明基本安装正常。不过现在很多教程更习惯直接通过 ROS 节点测试，比如运行一个小例程，看话题能不能互通。

2.3 PX4 源码拉取和网络问题

PX4 源码拉取是第一个容易卡住的点。官方仓库在 GitHub，命令通常是：

git clone --recursive https://github.com/PX4/PX4-Autopilot.git

--recursive表示同时拉取子模块。PX4 有不少依赖子模块，如果网络不稳定，经常会出现某个子模块拉取失败，整个环境就没法继续。

常见的报错类似：

fatal: 无法访问 'https://github.com/px4/px4-autopilot.git/': failed to connect

这个报错大多数情况是网络访问问题。处理思路不是绕行，而是换一个更稳的获取方式：

• 换网络环境，比如从公司网络切到家庭网络，或者反过来。
• 通过 Gitee 或 GitHub 的镜像仓库先下载源码包，再手动解压。
• 在 Gitee 上导入 PX4-Autopilot 仓库，再从 Gitee 克隆，子模块地址仍然可能指向 GitHub，需要单独处理。
• 反复执行git submodule update --init --recursive，多试几次也能补齐，但比较费时间。

另外，学习时不要直接拿 master 最新代码跑。PX4 开发迭代很快，最新代码可能改动很大，也可能和当前 ROS 包不兼容。建议先看发布标签，比如常见的稳定版本，然后用：

git checkout 目标版本标签

这就是社区里常说的“px4 checkout 老版本”的用途。版本一旦切换，后面 PX4 与 QGroundControl、MAVROS 的兼容性也要一起考虑。我的经验是：记录你使用的 PX4 版本、ROS 版本、MAVROS 版本，不要只记“跑通了”，否则三个月后复现会非常痛苦。

2.4 编译固件并启动 Gazebo 仿真

源码拉完后，PX4 自带环境准备脚本会安装大量编译依赖。这个阶段需要耐心，因为编译和安装时间通常很长。依赖装好后，可以用仿真目标启动 Gazebo，比如：

make px4_sitl gazebo

不同版本的 PX4 仿真目标名称会有变化，有的版本需要指定机架类型，有的版本默认加载固定翼模型。所以如果命令和当前版本不一致，先看 PX4 文档或源码里的make帮助。

启动成功的标志是：

• Gazebo 世界正常打开，能看到固定翼模型。
• PX4 终端出现飞控状态输出，说明 SITL 固件已经运行。
• QGroundControl 能识别到 PX4 的 UDP 连接，飞控状态显示连接正常。

第一次编译时间会很长，不要因为终端卡住就以为死机。可以在另一个终端用top或htop看 CPU 和内存占用，确认编译还在进行。Gazebo 模型加载时还需要从网络下载模型库，如果模型加载慢或者卡在某个模型上，同样需要先处理网络问题，或者提前把模型库放到本地~/.gazebo/models目录。

3. 把 ROS 和 PX4 之间的通信打通

3.1 MAVROS：最常用的通信桥

在 ROS 1 里，ROS 和 PX4 之间最常用的桥接工具是 MAVROS。MAVROS 通过 MAVLink 协议和 PX4 通信，把飞控的状态、传感器、GPS、姿态、位置等转成 ROS 话题，同时也能把 ROS 里的控制指令转成 MAVLink 消息发给飞控。

安装方式一般是通过 apt：

sudo apt install ros-noetic-mavros ros-noetic-mavros-extras

安装之后，MAVROS 还需要安装 GeographicLib 数据集，这一步经常被忽略。没有数据的情况下，有些定位消息会报错或输出异常。

启动 MAVROS 的常用方式是：

roslaunch mavros px4.launch fcu_url:=udp://:14540@127.0.0.1:14557

这里fcu_url表示飞控通信地址。仿真模式下，PX4 SITL 会通过本地 UDP 端口与 MAVROS 通信。真机模式下，地址要改成对应的串口设备，例如：

roslaunch mavros px4.launch fcu_url:=/dev/ttyACM0:921600

真机使用串口时，优先级最高的问题是权限。如果 MAVROS 提示无法打开串口，先确认当前用户是否在dialout用户组里：

sudo usermod -a -G dialout $USER

改完用户组后需要重新登录，否则权限不会立即生效。

3.2 启动后先验证哪些话题

MAVROS 启动后，先不要急着发控制指令。先看数据，确认链路通没通。

常用验证命令：

rostopic echo /mavros/state rostopic echo /mavros/local_position/pose rostopic echo /mavros/global_position/global

其中/mavros/state是飞控连接状态。如果connected字段为true，说明 MAVROS 和 PX4 已经接通。armed字段表示解锁状态，mode表示当前飞行模式。

头一次跑仿真时，很多人会看到/mavros/local_position/pose没有输出，或者位置一直不变。这种情况先确认两件事：PX4 SITL 是否真的在运行，Gazebo 里飞机模型是否加载成功；MAVROS 的fcu_url端口是否和 PX4 仿真端口一致。端口对不上，MAVROS 可能一直处于未连接状态。

除了话题数据，还可以用 rqt_graph 看节点之间的发布订阅关系。如果图像或状态话题没有出现在图里，说明对应节点没有启动成功。这一步能帮你快速区分“消息没发出来”和“消息发出来了但接收端没订阅”这两种情况。

3.3 最小 Offboard 流程

Offboard 是 PX4 的自主飞行模式，机载电脑可以通过 MAVLink 持续发送设定点。对于固定翼，最小 Offboard 流程可以这样拆：

1. 启动 PX4 SITL、Gazebo 和 MAVROS。
2. 确认/mavros/state里connected为 true。
3. 通过 QGroundControl 或 ROS 服务切换到 Offboard 模式。
4. 持续向/mavros/setpoint_position/local或/mavros/setpoint_velocity/cmd_vel发送设定点。
5. 解锁飞控，设置一个足够安全和合理的目标位置或速度。
6. 观察飞机是否按设定点飞行。

这里有一个关键点：PX4 在进入 Offboard 模式前，通常要求已经持续收到设定点。如果机载电脑才启动就开始发模式切换指令，飞控可能直接拒绝，因为内部没有进入 Offboard 的条件。所以代码里，一般先启动设定点发布线程，持续发送几秒甚至更久，再去切模式。

固定翼的 Offboard 和旋翼差别很大。旋翼收到一个位置设定点后，可以原地起飞并稳定在那个点。固定翼如果要保持某个位置，必须持续飞行盘旋，不能像旋翼那样悬停。如果代码里只是发一个固定位置设定点然后不管，飞机很可能绕圈子或者偏离航线。更稳妥的做法是发送速度设定点，配合期望高度和航向，让飞控以固定翼飞行方式执行。

3.4 仿真到真机的通信变化

仿真里通信链路是本地 UDP，延迟低、不会丢包。真机环境下，飞控和机载电脑之间可能是串口、CAN 或数传电台。通信时延、带宽、乱序和丢包都会对任务逻辑产生影响。

在真机上做 Offboard 开发，有一个基本要求：不能因为 ROS 节点崩溃或机载电脑断电就让飞机失控。正确的做法是在飞控侧设定失效保护。比如设置 Offboard 丢失信号后自动切换为 Return 或 Land。这部分参数在 QGroundControl 的 Safety 页面设置，也可以在 PX4 参数里查。

另外，真机必须保留遥控器信号作为最后手段。固定翼不像旋翼可以一键急停悬停，失控时如果遥控器也切不过来，后果会很严重。所以我个人非常不建议在没有 RC 和地面站双重监控的情况下跑固定翼 Offboard。先在地面站里用 Auto 任务验证飞行，再做 Offboard 功能，是更稳定的路径。

4. 视觉版自主飞行的核心开发链路

4.1 先让相机在 ROS 里稳定输出

视觉版平台的开发，第一步不是写识别模型，而是让相机稳定出图。

在 ROS 1 里，USB 摄像头常用usb_cam驱动：

roslaunch usb_cam usb_cam_node.launch

启动后查看话题：

rostopic hz /usb_cam/image_raw

如果帧率稳定，图像清晰，说明图像链路基本正常。如果是海康这类工业相机，一般需要单独安装厂商提供的 ROS 驱动或 SDK，通过 RTSP 或 GigE 接口把图像传入 ROS。

相机接入后，最重要的一件事是标定。内参标定影响目标检测和坐标解算的准确性，外参标定则决定相机坐标系和机体坐标系之间的相对关系。很多视觉跟踪项目一开始跑不通，不是模型不好，而是相机安装角没标好，导致目标像素坐标转换出来的位置和实际位置差了很大一截。

4.2 识别结果怎样转换成飞控能用的指令

相机标定完成后，视觉识别模块会输出目标信息。常见输出有两种：

• 像素坐标，比如目标在图像中的中心点(u, v)。
• 世界坐标或相对坐标，比如目标相对相机的 x、y、z 距离。

不管是哪种输出，最终都要转换成飞控能用的设定点。PX4 的 Offboard 控制通常接收 NED 或 ENU 坐标系下的位置、速度或姿态指令。这就涉及多层坐标系转换：

1. 像素坐标转到相机坐标系。
2. 相机坐标系转到机体坐标系。
3. 机体坐标系结合当前姿态转到世界坐标系。
4. 世界坐标系里的目标位置或速度，再通过 MAVROS 的 setpoint 话题发送给飞控。

这条链路很容易出问题。比如安装角没有标定，相机朝向和机头方向不一致，飞机就会追着目标转圈。时间同步也是一个问题，视觉结果和飞控姿态消息之间如果有几百毫秒延迟，在固定翼这种速度较快的平台上，误差会被明显放大。

所以不要期待像素识别一出来就能直接当飞控输入。先把转换链路在仿真和录制的数据里离线验证，再上真机。

4.3 视觉失效时必须有回退策略

固定翼视觉任务中，最容易被忽视的问题是“视觉识别失效了怎么办”。光照变化、目标被遮挡、运动模糊、云台震动、曝光突变，这些都可能导致识别结果中断或错误。

比较稳健的任务状态机至少包含三层：

• 正常跟踪层：视觉锁定目标，持续发送设定点。
• 丢失回退层：连续若干帧没有检测到目标，停止跟踪，切回安全行为。
• 安全执行层：如果高度过低或偏离航线过远，切回航线模式并通知地面站。

在实现时，可以设定一个“连续丢失帧数”阈值。比如连续 10 帧没有输出目标，就认为目标丢失，不再发送跟踪指令，而是切回预先设置的盘旋点或返航航线。不要因为某一帧置信度低就立刻猛打方向，这样会让飞机反复抖动。

固定翼的响应速度比旋翼慢，机动空间也更有限。视觉避障在固定翼上尤其难，因为飞机在接近障碍物时速度很高，留给规划算法的时间非常短。更现实的做法是先做“目标跟踪”，也就是跟住一个目标，而不是做通用避障。

4.4 开发顺序：先跟踪，再避障

我见过不少项目，一开始就打算做“全方位自主避障”，结果卡在传感器、算力和控制链路三座大山之间。

更现实的路径是分阶段推进：

• 第一阶段：固定翼按固定航线飞行，同时用相机录制视频，离线运行识别算法，验证模型效果。
• 第二阶段：在仿真环境里接入识别结果，让飞机跟踪一个移动目标，测试目标跟踪逻辑。
• 第三阶段：真机低空、低速条件下，测试目标跟踪和丢失回退策略。
• 第四阶段：再考虑避障。避障需要更多传感器输入，比如深度相机、毫米波雷达或激光雷达，同时还要改航迹规划模块。

如果本身是低配置机载电脑，目标检测模型也不能选太大。固定翼不允许机载电脑占用太多电能和重量，散热也更受限制。常见的做法是选用轻量目标检测模型，在保证帧率的前提下再提升精度。

5. 试飞之前和故障之后的检查顺序

5.1 真机试飞前的最小检查清单

真机试飞和仿真最大的区别是“错误的代价很大”。所以试飞前一定要做一个固定检查流程。

我一般建议至少检查这些项目：

这些检查看着琐碎，但每一条都可能在飞行中变成致命问题。尤其是舵面方向，如果正负方向搞反，起飞后基本没有修正机会。

5.2 常见故障排查顺序

固定翼二次开发中遇到的问题，可以按顺序排查：

1. 先看现象。是 ROS 节点报错、飞控没有反应、图像出不来，还是飞机姿态乱动。
2. 再看日志。ROS 节点日志、PX4 控制台日志、QGroundControl 的 log 文件，都要先看。
3. 再查输入。串口设备是否正确、相机设备号是否变化、GPS 是否锁星、RC 信号是否正常。
4. 再查资源。CPU 占用是不是满了，内存是不是不够，磁盘是不是满了，图像话题帧率是不是太低。
5. 再查参数。PX4 参数、MAVROS 启动参数、ROS 环境变量、坐标系定义是否一致。
6. 最后查版本。PX4、MAVROS、ROS、相机驱动的版本组合是否兼容。

比如 MAVROS 一直提示no heartbeat，就先不要改任何参数，先确认fcu_url地址和波特率是否正确，再确认飞控和机载电脑的串口设备路径，最后确认权限。很多时候问题就是/dev/ttyACM0和/dev/ttyUSB0混淆了，或者设备插入顺序变了。

5.3 源码、网络和版本兼容问题

开发过程中，GitHub 访问不稳定是很常见的事。PX4 源码、ROS 包、Gazebo 模型库都可能因为网络原因下载失败。我的处理思路是：

• 优先使用国内镜像站配置 apt 源。
• 源码仓库可以导入 Gitee 后克隆，但要注意子模块和后续更新。
• Gazebo 模型库提前下载到本地~/.gazebo/models，避免每次启动仿真都卡在下载。
• 对 ROS 依赖安装失败，先确认软件源是否配置正确，再确认目标 ROS 版本对应的 Ubuntu 版本是否正确。

代码版本方面，最怕的是“哪个新用哪个”。PX4 的 master 分支、ROS 包的最新版、MAVROS 的 GitHub 版，放在一起可能并不兼容。我建议记录一组固定的版本组合，比如 Ubuntu 20.04 + ROS Noetic + PX4 某个稳定 tag + MAVROS 发行版。之后升级只升级其中一个，并且每次升级后都重新跑一遍仿真验证。

6. 二次开发的路子怎么走才不绕远

6.1 三个阶段的实践路线

如果刚开始接触这类平台，我的建议是不要把目标定成“直接做自动避障”，而是先走完三个阶段。

第一阶段：仿真里跑通最小闭环。环境搭好后，先用 QGroundControl 给固定翼规划一条航线，起飞、巡航、降落。然后再用 MAVROS 读取状态，用 ROS 发布一个简单的 Offboard 速度指令，验证飞机能响应。

第二阶段：真机做非自主试飞。不接视觉，不跑自主算法。人工遥控起飞，切换几个飞行模式，检查固定翼在不同模式下的响应。这一步的目的是熟悉固定翼的飞行特征，验证飞控参数和机械结构。

第三阶段：视觉任务逐步接入。先在仿真里用虚拟相机做目标识别，或者用录制的数据包离线跑识别。然后真机在安全空域里做目标跟随，并且准备好回退策略。

这三个阶段每步都不要省。跳过仿真直接真机，安全和排错成本都很高。

6.2 硬件选型里的判断标准

开源固定翼平台很多，选型时不要只看宣传视频，要看这些可判断的信息：

比如固定翼速度一般比旋翼快，卷帘快门相机在高速运动下容易出现果冻效应，可能影响识别。如果要追求更稳定的动态识别，优先考虑全局快门相机或者帧率更高的工业相机。

机载电脑选择上，不要只追求大模型。固定翼对重量和供电非常敏感，算力越强通常功耗和重量也越高。低配置板子也能跑轻量模型，只要目标明确、模型压缩到位。判断标准不是“能不能跑”，而是“连续飞行 20 分钟里温度是否稳定、任务线程是否持续发布、图像帧率是否达标”。

6.3 对开源平台应保持的预期

开源平台不等于开箱即用。尤其是固定翼 + ROS + PX4 这种组合，涉及飞控、通信、视觉、机载计算多个领域，任何一个环节不匹配都会让项目卡住。

合理的预期是：

• 有完整源码，遇到问题能看实现细节。
• 有社区资料，但资料可能基于特定版本，不一定适合你当前的版本。
• 能改能扩展，但改动后要自己做测试和验证。
• 功能支持范围有限，“支持视觉”不意味着所有视觉任务都开箱可用。

踩过几次之后我发现，很多问题不是工具能力不够，而是前置环境和输入材料没有处理干净。比如相机驱动没标定、PX4 版本和教程不一致、MAVROS 端口不对、坐标系没有统一、视觉结果延迟太高。这些问题如果一开始就按“先链路，后算法，最后参数”的顺序做，会少走很多弯路。

固定翼 + ROS + PX4 这类二次开发平台，真正值钱的是你能把视觉、控制、飞行安全串成一条完整链路。我个人会更建议先花两周把仿真环境跑稳，再谈真机。很多问题不是算法难，而是环境没搭干净、坐标系没对齐、视觉失效时没有退路。先把最小闭环做出来，后续扩展会顺利很多。