企业官网建设流程全解析

PX4机载与QGC地面站通过WiFi实现无线连接配置指南

玩PX4的都知道，调试阶段最烦的就是那根USB线。飞控连着电脑，机架稍微动一下线就松，转个方向还得小心别把接口拽坏。尤其是调PID或者看日志的时候，人得蹲在飞机旁边，姿态数据一边刷一边还要腾出手改参数，别提多折腾了。我大概在第三次被USB线绊到脚之后，下定决心把无线方案彻底搞通。现在我的调试台上，飞控、机载电脑、QGC地面站之间全部走WiFi，从开机到连上地面站基本上十几秒的事，的姿态数据、日志下载、参数读写跟插线没什么区别。

这篇文章就围绕“PX4机载端通过WiFi把MAVLink数据传到QGC地面站”这条主线来写。我会把我在实际配置中用过的几种常见方案摆出来对比，重点讲清楚我目前在用的方案——树莓派（或者其他Linux机载电脑）通过WiFi接入局域网，QGC在同一网络下自动识别飞控——从硬件接线到PX4参数配置再到QGC侧设置，一步步完整走一遍。最后把我踩过的坑、排查的思路、以及一些常规文档里不会写的小技巧都整理出来，方便你直接对着操作。

先说清楚这套方案解决什么问题：调试PX4的时候，不用再被USB线绑在机架旁边，可以在电脑前自由活动；可以在机载电脑上同时跑通信中继、日志记录甚至简单的视觉处理；多台设备（比如电脑、手机）可以同时连接同一台飞控查看数据。适合的对象是正在做PX4二次开发或者经常在外场调试的开发者，不管你是用树莓派、Jetson Nano还是普通NUC，只要跑的是Linux系统，这套流程基本通用。

1. 无线连接方案选型：为什么我最后选了WiFi而非数传

1.1 三种常见无线方案的对比

先说个现实问题：PX4飞控本身不直接支持WiFi，它的MAVLink输出接口要么是串口（UART）要么是USB。所以“机载+WiFi”的方案本质上都是在飞控外面加一层“透传设备”，把MAVLink协议的数据包从串口或USB上搬到一个能让QGC通过TCP或UDP访问的网络通道里去。

市面上常见的无线方案主要有下面三种：

第一种：433MHz/915MHz数传电台。这是很多新手最先接触的方案，买一对成品数传模块，一端接飞控的TELEM口，另一端USB插电脑。优点是无脑即插即用，QGC自动识别串口，不需要任何配置；缺点是带宽低得可怜（通常9600bps到57600bps），传个MAVLink消息还行，想传日志或者同时刷高频率的姿态数据就卡成PPT了。而且数传模块一般要单独供电，距离远了功率不够用。

第二种：4G/5G DTU模块。适合超远距离控制，但配置复杂，需要SIM卡、云服务器中转，延迟大。说实话，做无人机开发调试很少用这种，除非你是做行业应用（比如农业植保、远距离巡检），在实验室里用纯属给自己找麻烦。

第三种：WiFi串口透传模块或者Linux机载电脑自带的WiFi。这就是我这篇文章重点讲的方案。WiFi的带宽随便几十Mbps，传MAVLink绰绰有余；而且你本来就要在机载电脑上跑其他东西（比如视觉定位、日志存储），用它当通信中继完全顺路。

用树莓派或Jetson这类Linux机载电脑做WiFi中继，本质上就是跑一个MAVLink路由程序，把飞控串口的数据转发到网络端口；QGC侧通过UDP或者TCP连接这个端口就能收到数据。这种方式相比单独的WiFi透传模块（比如ESP8266刷MAVLink固件那种），有一个核心优势：机载电脑上可以同时跑多个MAVLink客户端，一个连QGC监控，一个连日志记录器，一个连自主飞行的Python脚本，互不干扰。

1.2 为什么最终选择“机载电脑+WiFi”路线

我在实际项目里试过三种组合，简单分享一下我的体验：

• 飞控 + ESP8266 WiFi模块：成本最低（一个模块十几块钱），但稳定性一般。ESP8266的WiFi天线增益有限，稍微远一点或者中间隔一道墙就掉线；而且它只有一个UART，如果你飞控的TELEM2口已经接了其他外设就没法用。适合做教学演示，不适合正经开发。

• 飞控 + 树莓派 + USB WiFi网卡：这是我目前的主力方案。树莓派的WiFi性能比ESP8266强太多，而且可以顺便在树莓派上跑mavproxy或者mavlink-router做数据分发。调试的时候把树莓派丢机架上，人在电脑前坐着，非常舒服。

• 飞控 + 开发板自带WiFi（比如Jetson Nano）：配置流程和树莓派完全一样，只是你需要确保内核里有对应的无线网卡驱动，以及注意开发板的WiFi天线位置别被机架金属件遮挡。

从成本和稳定性两个维度综合考虑，我建议是：如果你只是想在屋里飞个穿越机、调调参数，用树莓派Zero 2 W就够了，三十多块钱的板子，功耗低，体积小，直接双面胶粘在机架上；如果你要跑SLAM或者视觉识别，那上Jetson系列，WiFi配置方法一模一样。

2. 环境准备：硬件接线、系统配置与软件工具

2.1 硬件清单与接线细节

在开始配置之前，先把硬件准备好。下面这套清单是我自己工作室里的标准配置，你可以根据自己的手头设备替换，但核心连接逻辑是一样的：

接线这块，很多新手容易看错地方。PX4飞控上通常有标注TELEM1、TELEM2的接口，这两个是串口，也是我们最常用的MAVLink数据出口。如果你用的是USB连接机载电脑，那就简单得多：数据线插飞控的USB口，另一头插机载电脑的USB口，本质上和插台式机没有区别。

我自己的做法是用USB转串口模块接飞控的TELEM2口（留TELEM1备用），然后把模块的USB端插在树莓派上。有人会问，为什么不用飞控的USB口直接连树莓派？可以，但USB口只有一个，以后你要插其他设备（比如GPS模块的USB调试线、外接存储）就没得用了。而且用TELEM口还有一个好处：TELEM口是经过电平转换和保护的，直接USB插拔的时候更耐操。

如果你决定用串口直连，接线时注意：

• TX-TX，RX-RX，不是交叉接线。很多用惯Arduino的人习惯TX接RX，但PX4的TELEM口在飞控板上已经做过了交叉，你只要将USB转串口模块的TX接飞控的RX，模块的RX接飞控的TX，同名牌对接就行。
• 模块的GND必须和飞控共地，否则通信会出现随机乱码。
• 如果飞控板子上的TELEM口电压是3.3V，你的USB转串口模块必须支持3.3V电平，否则可能烧毁飞控串口引脚。

2.2 机载电脑系统准备：以树莓派为例

树莓派上的系统我推荐用官方的Raspberry Pi OS Lite（64位），不要带桌面版——无人机机载电脑跑桌面纯属浪费资源。安装好系统之后，先做三件事：

第一，设置好WiFi连接。编辑/etc/wpa_supplicant/wpa_supplicant.conf，把你的路由器SSID和密码写进去。这里要特别强调：WiFi频段尽量选2.4G。5G频段虽然干扰少，但穿墙能力弱、覆盖范围小，而且很多USB WiFi网卡对5G的支持不佳。如果你在飞场调试，距离远了5G基本就废了，2.4G反而能撑更远。

第二，开启SSH服务。在树莓派上执行sudo systemctl enable ssh和sudo systemctl start ssh。这样你就能从电脑上远程登录树莓派做后续配置，不用一直插着键盘显示器。

第三，更新软件源并安装必要工具：

sudo apt update sudo apt upgrade -y sudo apt install git python3-pip screen -y

如果你用的是Jetson系列，系统自带Ubuntu，但网络驱动可能需要手动确认。可以用ip a查看无线网卡是否被识别到，如果出现wlan0就说明驱动正常。网上有人反映Jetson的WiFi模块驱动在某些内核版本下不稳定，这跟Realtek的网卡驱动一样属于老话题了，稍后我会专门说一下排查思路。

2.3 确认PX4机载端与QGC版本

PX4固件我建议用较新的稳定版（比如v1.14.x或者v1.15.x），因为旧版本在MAVLink配置参数上有些差异，网上很多教程停留在v1.12甚至更早，照着做容易踩坑。QGC的话直接用官网最新版就行，目前是v4.x系列，支持Windows、Linux、macOS，移动端也有Android版本。

在开始下一步之前，先确认你的飞控能正常连接机载电脑。拿串口转USB模块接好，树莓派上执行：

ls /dev/ttyUSB*

正常会输出类似/dev/ttyUSB0的设备节点。如果看不到，先检查硬件连接和驱动：dmesg | grep -i usb看看内核有没有报错。

3. PX4机载端参数配置：让串口变成MAVLink数据出口

3.1 MAVLink配置核心思路

PX4的参数非常多，但跟MAVLink通信相关的就那几个，核心逻辑是“指定某个串口作为MAVLink输出口，并设定波特率”。在QGroundControl的参数界面里，你要关注的是以MAV_和SER_开头的参数。

从PX4 v1.14开始，MAVLink的配置逻辑做过一次重构，核心体现在MAV_1_CONFIG这个参数上。它指定了第一个MAVLink实例绑定到哪个串口设备。参数的可选值很多，常见的有：

• -1：禁用（Disable）
• 0：TELEM1口
• 1：TELEM2口
• 2：UART4
• 3：USB口

当你把MAV_1_CONFIG设置为串口对应的值后，系统会自动弹出或激活另一组MAVLink参数，比如MAV_1_MODE（MAVLink模式，Onboard或Normal）、MAV_1_RATE（数据发送间隔）、MAV_1_FORWARD（是否转发其他MAVLink链路数据）等。

这里有一个非常容易掉坑的点：MAV_1_MODE这个参数的选择。

• Onboard模式：会以更高的频率发送更多类型的数据，适合连接机载电脑（比如树莓派、Jetson）。它会发送一些普通模式不发送的消息（如详细的IMU数据），但因为频率高、数据量大，如果链路带宽不足，反而容易拥堵。
• Normal模式：频率适中，适合连接地面站或者数传。QGC通过WiFi连接时用默认Normal就好。

我用树莓派做中继的时候，飞控的串口模式设置的是Onboard，因为后面我还要在机载电脑上跑一些实时数据处理。如果你的机载电脑只做中继，不消费MAVLink数据，Normal就够用了。

3.2 具体参数设置值（以Pixhawk 6C为例）

下面是我实际测试过可以直接使用的参数组合。假设我是用TELEM2口连接机载电脑：

这里SER_TEL2_BAUD对应的是TELEM2口的波特率，如果你用的是TELEM1，就找SER_TEL1_BAUD。我直接设921600，这是因为串口带宽越大，MAVLink数据在串口段就越不容易成为瓶颈。921600也是老外博客里最常见的推荐值，实测稳定。

设置完参数后要执行一次“重启”才能生效。QGC会提示你重启飞控，确认即可。重启后可以再检查一下参数是否被保留——有些串口映射参数在旧固件上会被“恢复默认”，这是固件版本问题导致的，建议用最新稳定版规避。

3.3 在机载电脑上验证串口数据流

参数设定完成后，先不要急着启动QGC。先在机载电脑上验证一下串口是否有MAVLink数据流，这样后续排查会更清晰。

在树莓派上安装一个常用的MAVLink调试工具mavlink-router或者直接用python3的pymavlink库读取串口。我一般先用一个简单的Python脚本做快速验证：

import serial ser = serial.Serial('/dev/ttyUSB0', 921600, timeout=1) while True: data = ser.read(100) if data: print(data.hex())

如果串口数据正常，你会看到类似fe 09 14 00 ... 55这样的MAVLink帧头数据。如果什么都没有或者全是乱码，检查一下波特率是否匹配、飞控是否真的输出MAVLink（用QGC先USB连一次确认参数生效）。

这一步很关键，它帮你区分“串口层问题”和“网络层问题”，后面排查的时候会省很多事。

4. WiFi网络搭建与机载端MAVLink路由：从串口数据到UDP端口

4.1 WiFi网络搭建的两种方式：路由器与直连

WiFi网络搭建是整个方案里最容易让人忽略的一环，但恰恰是最影响体验的。我试过的方案大概有两种：

方案A：使用路由器/AP方式（推荐）。机载电脑和地面站电脑都连接同一个路由器，QGC通过路由器发现机载电脑的IP和端口。这种方式的优点是网络结构简单稳定、同时支持多设备连接（电脑、手机、平板都能连），排查也方便。缺点是飞场环境没那么方便带路由器，但一个几十块钱的迷你路由就解决了。

方案B：机载电脑开热点，地面站连接热点。这种方式适合户外没路由器的情况。机载电脑上创建一个WiFi热点，电脑（或手机）连接这个热点，然后机载电脑既是热点又是MAVLink服务端。配置稍微复杂一点，但省去了额外硬件。

我实际测试中，方案A比方案B更稳定，尤其是在数据量大的时候。因为树莓派或Jetson自带的WiFi芯片在“同时做AP和传数据”时会存在调度开销，偶尔会出现丢包和延迟抖动。而路由器模式中机载电脑的WiFi只需做station角色，稳定性高很多。

4.2 用mavlink-router做UDP数据分发

现在关键的一步来了：把飞控串口的数据转到WiFi网络上。在机载电脑上要跑一个“路由器”程序，它的作用就是读取飞控串口的MAVLink包，同时把它广播到UDP端口，QGC通过UDP连接到这个端口。

Linux下有现成的工具，我用得最多的是mavlink-router。这是Intel开发的开源项目，专门用来在MAVLink各节点之间做数据路由，比古老的mavproxy轻量且好用得多。

安装方式通常是源码编译：

git clone https://github.com/intel/mavlink-router.git cd mavlink-router ./autogen.sh ./configure make -j4 sudo make install

编译过程没什么坑，只要系统有gcc和meson依赖就行。没装依赖的先执行：

sudo apt install meson ninja-build pkg-config libsystemd-dev

编译完之后，启动一个基本路由任务，语法是：

mavlink-routerd -e 192.168.1.100:14550 /dev/ttyUSB0:921600

这条命令的意思：读取/dev/ttyUSB0这个串口（波特率921600），把MAVLink数据广播给UDP端口14550，同时发送到目标IP192.168.1.100（这里是地面站电脑的IP）。

但是这里要特别注意：-e参数指定的是单播目标IP，如果你的地面站IP经常变（用DHCP的话可能每次都不同），用单播模式每次都要改命令。更好的方式是使用UDP广播地址：

mavlink-routerd -e 192.168.1.255:14550 /dev/ttyUSB0:921600

把IP地址的最后一段改成255，就是广播模式。这样同一个局域网里任何一台电脑上的QGC只要监听UDP 14550端口，都能收到数据，不用管IP地址是什么。我日常调试就是用的广播模式，省心。

当然，mavlink-routerd支持更多的细粒度配置（比如不同端口的速率限制、多端口路由等），但是基础场景下，上面这条命令就够了。

4.3 开机自启与后台运行

我们在飞场调试的时候，总不能每次上电后还手动登录树莓派敲命令启动mavlink-routerd。把它注册成systemd服务，开机自启，这样只要树莓派通电，过个十几秒QGC就能自动连上数据。

创建一个systemd服务文件/etc/systemd/system/mavlink-router.service：

[Unit] Description=MAVLink Router Service After=network.target [Service] ExecStart=/usr/local/bin/mavlink-routerd -e 192.168.1.255:14550 /dev/ttyUSB0:921600 Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

然后执行：

sudo systemctl daemon-reload sudo systemctl enable mavlink-router sudo systemctl start mavlink-router

之后每次树莓派开机，这个服务就会自动把飞控的MAVLink数据广播到局域网的14550端口。如果中途/dev/ttyUSB0设备节点变过（比如换了USB口），服务会失败，Restart=always会自动重试，但如果设备节点一直不存在，那就需要检查硬件连接了。

这里有一个人人都会遇到的坑：树莓派USB设备节点顺序可能不稳定（比如插了一个U盘后再插USB转串口，设备节点从ttyUSB0变成ttyUSB1）。我自己的解决办法是在systemd服务里写一个udev规则，或者用/dev/serial/by-id/路径代替。

用ls /dev/serial/by-id/看看，一般输出类似：

usb-FTDI_FT232R_USB_UART_A50285BIY-if00-port0

把这个完整路径填到服务文件的ExecStart里，就不会因为USB节点顺序变化而找不到设备了。

5. QGC地面站连接设置：UDP与TCP的取舍

5.1 QGC端通信方式选择

QGC连MAVLink的方式很灵活，支持USB串口、TCP、UDP。在我们这个WiFi方案里，用的自然是UDP或者TCP连接。QGC主界面右上角的“通信方式”图标（一个插头/齿轮图案），点开后可以添加不同类型的连接。

在局域网WiFi场景下，我最推荐的是UDP协议。原因很简单：QGC作为MAVLink地面站本身是“被动监听”的角色（通常是接收端），UDP不需要建立稳定的连接——机载电脑广播数据，QGC在同一个网段监听14550端口，数据直接就能收到。UDP是无连接的，就算你电脑休眠几秒钟再醒来，网络恢复后数据马上又能收到。

TCP则更像打电话：需要先建立连接，连接断了要重新拨号。WiFi环境下偶尔会有短暂丢包或者延迟波动，TCP遇到这种情况会进入重传等待状态，表现反而不如UDP顺畅。当然，如果你用的是有争议的4G远程控制场景，TCP的长连接可以更好地穿透NAT，但那跟我们这篇文章的局域网场景不搭。

所以在QGC里，添加连接时选UDP，监听端口填14550即可。如果你用的是广播模式，不需要填监听IP（0.0.0.0代表任意地址），直接写端口就行。

5.2 QGC端参数设置步骤

具体操作步骤大家应该很熟悉了，但还是完整走一遍：

1. 打开QGC，点击右上角的“通信方式”图标（一个插头形状）。
2. 在下拉菜单里选择“Add UDP Connection”。
3. 在弹出的对话框里，监听端口填写14550，点击OK。
4. 如果一切正常，QGC主界面左侧的“Vehicle”图标会从灰色变成高亮，地图上会出现你的飞机和姿态数据。

如果你用的是TCP模式，那就在添加连接时选择“Add TCP Connection”，注意TCP模式下QGC是作为客户端去连接机载电脑的服务端口，所以需要填机载电脑的IP和端口（比如192.168.1.50:5760）。但这需要mavlink-routerd配置为TCP服务模式，我建议新手别折腾TCP，UDP广播模式是最省心的。

另外，QGC有个小技巧：在主界面的“App Settings”里找到“General”，里面有“Enable MAVLink”相关的选项，确认你的MAVLink协议版本和飞控一致（PX4默认MAVLink协议版本是2.0，QGC自动识别，一般不用改）。

5.3 多地面站同时连接：一台飞控，多端监控

WiFi方案的一大优势就是可以多端同时监控。比如我在调机的时候，电脑上开着QGC看全参数和地图，手机上再开一个QGC精简界面看姿态角，甚至同时让一个Python脚本用pymavlink去订阅消息。

这在传统数传方案里很难实现，因为数传一次只能绑定一个地面站。但在WiFi拓朴下，机载电脑上的mavlink-routerd可以将MAVLink数据广播到多个端口，QGC也能以多实例方式运行（或者多个设备分别连）。只要端口不冲突，随你怎么连。

我自己的常用组合是：

• 电脑QGC：UDP 14550端口，负责姿态、地图、参数调节。
• 手机QGC：UDP 14550端口，飞的时候随身携带看状态。
• 电脑上的MAVSDK-Python脚本：UDP 14551端口订阅位置和IMU数据，做飞行数据记录。

QGC监听端口可以自己在“Add UDP Connection”里改成其他端口，只要和机载电脑路由转发规则匹配就行。mavlink-routerd默认把所有进来的MAVLink包都广播到所有配置的输出端口，所以只要你在启动命令里添加多个-e参数，就能把同一份数据发到多个端口。

6. 常见问题与排查技巧实录：让WiFi连接不再掉链子

6.1 问题速查表

WiFi连接本身不算复杂，但实际用起来总会遇到各种小问题。我汇总了一下我在GitHub issues和论坛上看到的、以及自己亲自踩过的坑，整理成下面这个速查表：

6.2 机载电脑WiFi网卡的玄学：Realtek与高通芯片的恩怨

我用了好几块USB WiFi网卡，踩得最多的坑就是Realtek芯片的网卡在Linux下掉线问题。你从网上搜“realtek rtl8852be wifi 6”都能看到一堆人问为什么网页测速都会中断——在无人机场景下，这问题更致命，因为无线链路一断，QGC就相当于失联。

从我的经验看，机载电脑上的WiFi网卡优先选择Atheros（高通）芯片的，兼容性最好。或者直接用树莓派、Jetson自带的WiFi，只要天线布置合理，2.4G频段下稳定传输个30米问题不大。Realtek芯片的网卡在Linux下的驱动质量参差不齐，尤其是新出的WiFi 6型号，内核驱动的bug动不动就导致连接中断，我试过一次之后直接放弃了。

如果你只能用Realtek的网卡，可以尝试手动更新驱动。搜索你的网卡芯片型号加“linux driver”一般能找到官方驱动仓库。但是做好心理准备——在Ubuntu内核更新之后，老驱动可能编译不过。我个人的原则是：“能用原装的就不加USB网卡，必须用USB网卡就选Atheros”。

6.3 排查顺序建议：由底层到上层

如果QGC连不上飞控，别急着改参数。我有一套自己的排查顺序，按照“底层到上层”的思路走，效率最高。

第一步：确认飞控串口是否在输出数据。关掉mavlink-routerd，直接用一个串口调试工具（比如minicom或前面的Python脚本）去读/dev/ttyUSB0，看看有没有MAVLink帧头。如果没有，说明飞控参数设置有问题，回到第3节检查参数。

第二步：确认路由服务是否在运行且转发正常。启动mavlink-routerd，用sudo tcpdump -i wlan0 udp port 14550抓包，看看有没有UDP数据包从机载电脑发出去。如果没有，说明路由服务配置有问题（比如串口路径不对）；如果有，说明网络层正常。

第三步：确认QGC所在电脑的网络连通性。在电脑上ping一下机载电脑的IP：ping 192.168.1.50。能通，但QGC收不到数据，检查防火墙是否拦了UDP 14550端口。这个坑很常见，电脑上装的安全软件或系统防火墙默认会拦截UDP端口。

第四步：用QGC手动添加连接。如果自动搜索模式找不到飞控，手动添加UDP连接，端口14550，这是最可靠的连接方式。如果手动能连上而自动搜不到，那是QGC的网络发现机制问题（比如mavlink-routerd开启了MAV_1_FORWARD后的数据内容兼容性），不影响了。

6.4 局域网外能连吗？聊聊WiFi方案的边界

有人会问能不能用这个方案在楼上控制楼下的飞机？答案是：理论上可以，但实际使用受限于WiFi信号覆盖范围。WiFi的2.4G频段在无遮挡开阔环境下可以传一两百米，但穿墙后衰减很快，而且无人机机载电脑的WiFi天线位置往往会被机架碳板遮挡。所以这个方案的实用范围是以机载电脑的WiFi覆盖半径为准，室内大概二三十米，室外开阔环境可以到百米以上。

如果要做更远距离的飞行调试，要么加高增益天线，要么换4G模块走公网，但那已经不是这篇文章讨论的范围了。至少在我自己的开发流程里，屋里的调试、外场的调参，WiFi方案已经足够用了。

7. 日志下载与多场景扩展：让无线调试效率翻倍

7.1 利用无线链路直接下载飞行日志

有了稳定的WiFi链路之后，再也不用拔SD卡拷日志了。QGC本身支持通过MAVLink下载飞控上的日志文件，在“Analyze Tools”里找到“Log Download”选项卡，选择Flight Review日志，点击下载就行。

实际下载速度取决于你的MAVLink数据链路转发能力。如果不做特殊配置，串口波特率921600配合WiFi传输，下载一个几十MB的飞行日志也就几秒钟。如果日志很大（比如飞了半小时带大量IMU数据），下载时间会比较长，这时候可以调高MAV_1_RATE参数，让日志传输的消息被更频繁地调度。

有个小细节：QGC下载日志实际是通过MAVLink的MAV_CMD_REQUEST_LOG_FILE命令来请求分包传输，链路里千字节的数据包会占满MAVLink带宽，所以你会看到QGC界面上姿态数据暂时“卡住”了。这属于正常现象，日志下载完就恢复。

7.2 在同一网络里叠加其他MAVLink工具

既然是WiFi局域网，那能做的事情就多了。比如我想在飞行的时候记录原始IMU数据，用MAVSDK-Python在电脑上订阅消息并落盘；再比如我想在飞行前用mission planner规划航点，直接在同一台电脑上跑Mission Planner（它和QGC的MAVLink协议兼容），然后和QGC同时连接飞控。

实测下来，只要mavlink-routerd配置正确，这些工具完全可以并存。我一般会让mavlink-routerd同时开启三个UDP输出端口，一个给QGC、一个给Python脚本、一个给日志系统，各干各的互不干扰。

7.3 配合机载视觉或SLAM的场景

如果你在做视觉定位或者SLAM，机载电脑上肯定还跑着其他程序（比如VINS-Fusion、ORB-SLAM）。这种情况下WiFi链路还能顺带把中间计算结果（比如位姿估计）以MAVLink扩展消息的方式传到地面站，QGC上可以写一个自定义的MAVLink插件来显示这些数据。

这块实现起来会复杂一些，需要自己定义MAVLink消息ID和数据格式。但是有了前面的WiFi通信链路，你完全不用再额外找一条数据通路，直接在现有链路上扩展就行。很多做PX4二次开发和视觉导航的朋友，都是在这个基础上叠加自己的消息类型的。

8. 从配置到日常使用：我的一些个人建议与避坑心得

最后聊点实操层面的心得体会。这套WiFi方案用了一年多，中间经历了各种掉链子、换设备、改配置，慢慢总结出几个自己觉得值得记住的经验。

第一个经验：调试阶段别一上来就追求“开机自启”。新手期的第一台树莓派+飞控，先手动跑命令验证通了，再配置systemd服务。我看到太多人在系统服务里写错了参数，结果开机后mavlink-routerd一直都在崩溃重启，却从来没真正跑起来过。手动验证熟练了，再固化成果，这个顺序不能乱。

第二个经验：串口波特率不要太低也不要太高。有人贪图稳定设57600，结果QGC上传输延迟大、姿态刷新慢，体验很差；有人直接设1500000（某些USB转串口模块能支持），但飞控串口的稳定性会受影响。我自己实测下来921600是最佳平衡点，在MAVLink 2.0模式下非常流畅。

第三个经验：WiFi的2.4G频段和5G频段的取舍要结合实际环境。我上面推荐2.4G是因为穿墙能力强、兼容性好，但如果你在飞场，周围没有太多WiFi干扰源，5G的传输延迟会更低、带宽更高。归根到底，环境测试说了算，不要盲信任何人的“最优解”。

第四个经验：地面站电脑的防火墙真的会拦UDP。这不是段子，我至少有三次连不上QGC，最后发现是Windows防火墙把UDP 14550端口禁止了。解决方法是直接在防火墙规则里放行UDP 14550，或者干脆添加一条允许QGroundControl.exe通信的规则，一劳永逸。

第五个经验：多备一个USB转串口模块。这玩意儿在调试中很容易出问题——接触不良、驱动冲突、芯片烧毁。我手上常备三四个CP2102和FT232的模块，每次出去调机都带两个。但凡遇到串口连接不上，第一反应就是换个模块试试，很多“飞控突然不输出MAVLink”的灵异事件，最后发现只是模块坏了。

WiFi无线连接方案带给我的最大改变，其实是调试节奏的转变。以前每次调参都要蹲在机架旁边插着线，姿态数据还要低头看屏幕；现在我可以把飞机放在阳台或者开阔场地，自己坐在电脑前看着大屏，一边刷数据一边改参数，机载电脑上同时跑着日志记录和数据转发。这种感觉，和插着USB线的体验完全是两个时代的东西。

如果你对这套方案的某个环节还有疑问，比如mavlink-routerd的具体参数、QGC的日志下载操作细节，或者树莓派之外的机载电脑怎么适配，欢迎留言区讨论。调试无人机本身就是个不断踩坑和解决问题的事情，希望这篇文章能帮你少走一些弯路。