干无人机调试的兄弟应该都有过这种经历：飞控和地面站之间拖着一根USB线，调试的时候人得蹲在机架旁边，想站远一点观察就束手束脚。后来换数传电台，距离是远了，但一对电台几百上千，不同协议还有兼容性坑。其实大多数实验室和室内调试场景，根本用不到电台——机载电脑和地面站电脑之间，用现成的WiFi就能把MAVLink数据传得稳稳当当。
下面这套配置就是把PX4机载电脑和QGC地面站通过WiFi搭成无线链路。核心思路不复杂：机载端把飞控的串口数据转发进局域网，地面站QGC通过UDP或TCP去接收。适合正在做PX4二次开发、经常在实验场地来回跑、或者单纯想摆脱USB线束缚的开发者。只要你的机载电脑能连WiFi，这套配置基本都能照搬。
1. 无线连接的原理与方案选型
1.1 MAVLink数据链路的核心概念
MAVLink是PX4与地面站之间通信的基础协议。飞控通过串口或USB口，把姿态、位置、遥控信号、任务信息等封装成MAVLink消息发出来；地面站收到后解析成可视化界面上的数据和指令。这个链路在传统调试里就是一根USB线，在机载方案里则需要一个中间进程，帮你把飞控口的数据“搬”到WiFi网络上。
机载端承担这个搬运任务的常用工具有两个：mavlink-router和MAVProxy。mavlink-router是PX4社区推荐的轻量级路由，启动后监听飞控串口，再根据配置把数据复制转发到多个UDP或TCP端点。MAVProxy是老牌地面通信组件，功能更多但配置略重，调试期好用，长期跑任务我反而更倾向于mavlink-router，原因后面细说。
理解这个数据链路是排查一切问题的前提。飞机端的飞控只是老老实实把MAVLink消息发到串口，机载电脑上的路由进程负责转发，地面站QGC负责接收和展示。任何一段出问题，表现都是“连不上飞机”，但排查路径完全不同。所以我习惯把链路拆成三段去看：飞控到机载电脑的串口段、机载电脑内部的路由转发段、WiFi网络到QGC的接收段。
1.2 三种WiFi组网方式怎么选
无线方案先要确定网络拓扑。最省事的是AP模式：机载电脑和地面站一起连同一个无线路由器，两台设备IP在同一个子网内，互相能直接ping通。这是大多数实验室和室内场地的标准做法，路由器固定放在场地一角即可，配置最透明，出问题也好定位。
第二种是机载端自建热点。树莓派或NUC上把无线网卡切成AP模式，地面站笔记本去连这个热点。好处是不需要额外路由器，适合没有固定网络的野外空地；缺点是热点一般都带NAT转发，机载端和地面站虽然还在同一个局域网，但如果地面站同时还想着上互联网，就需要机载端做IP转发，配置多一层，调试时容易分心。
第三种是机载端连接已有的园区WiFi，地面站也连同一个WiFi。这种方案一般在半室外场景用，但园区WiFi的AP部署、频段选择、IP分配策略都不可控，调试时经常出现信号抖动。我的建议是除非环境特别简单，否则别选这条路。自己带一个双频路由器，比什么都稳。
1.3 UDP与TCP：调试场景下的取舍
MAVLink数据的传输协议不外乎UDP和TCP。QGC默认在UDP 14550端口上监听，机载端把数据发到这个端口，QGC收到就能解析。UDP的特点是只管发和收，丢包不重传，对于遥测类数据（姿态、电量、GPS）来说非常合适，实时性优先，偶尔丢几个包影响不大，下一帧数据很快就补上来了。
TCP则强调可靠性，数据包丢了会重传，代价是延迟会跳动，在WiFi信号弱的场景下甚至会出现明显的滞后。但TCP有个好处：连接关系明确，QGC作为客户端主动去连机载端的TCP端口，机载端不用关心QGC的IP，只要QGC知道机载端IP就能建立链路。所以我的建议是，默认用UDP广播方式调试，信号差、需要稳定传输完整日志时再切TCP。
MAVLink生态对端口有一个约定俗成的用法：14550是QGC监听的UDP端口，5760是mavlink-router默认的TCP端口。这两个数字会贯穿整篇配置，建议直接记在笔记里。
2. 环境准备与通信参数规划
2.1 硬件与软件版本清单
以我手头这套典型配置为例：飞控是Pixhawk 6C，机载电脑是树莓派4B，地面站是一台Windows 11笔记本，路由器是支持5GHz的双频设备。这套组合在社区里覆盖度很高，你手里的硬件即使型号不同，配置逻辑也完全一样。
软件方面，机载端我用Ubuntu 22.04，mavlink-router用最新release版本；PX4固件1.14.x以上都行；QGC用4.x。有一点需要提醒，mavlink-router的编译依赖会随版本更新，如果你拉的是老版本代码，在Ubuntu 22.04上可能会遇到个别依赖缺失，按照报错提示装齐就行，不是大问题。
2.2 IP、端口与串口规划
统一IP规划很重要。我习惯把机载电脑固定成静态IP，地面站保持DHCP或也固定一个。比如下面这个例子：
| 设备 | IP地址 | 说明 |
|---|---|---|
| 机载电脑 | 192.168.1.100 | 静态，配置DHCP保留 |
| 地面站 | 192.168.1.50 | 静态或DHCP均可 |
| 路由器 | 192.168.1.1 | 默认网关 |
端口方面，前面提到的14550和5760是核心。如果你有多个飞控或者多台地面站同时接，端口需要错开，否则数据会串。一般情况下，一套飞控对应一台地面站，这两个端口就够了。
串口规划容易被忽略。飞控通过USB接到树莓派，Linux下设备节点通常是/dev/ttyACM0。如果走的是飞控的TELEM口，那就是/dev/ttyUSB0或/dev/ttyUSB1。一定要先搞清楚飞控对应的设备节点是哪个，后面所有配置都依赖这个路径。
2.3 串口联调：WiFi之前必须做的一步
在配置WiFi之前，先确认机载电脑能正常读取飞控数据。飞控通过USB接到树莓派后执行：
ls /dev/ttyACM*大概率看到/dev/ttyACM0。如果什么都没有，检查USB线是不是只能充电不能传数据，这种线在调试现场太常见了，我至少有两次卡在这上面，换了根数据线立刻就好。
然后看权限。如果设备节点的属主是root，当前用户打开会有Permission denied问题。把当前用户加入dialout组：
sudo usermod -a -G dialout $USER重新登录后生效。不然后面mavlink-router每次启动都要sudo，做开机自启时更是麻烦。
接下来验证串口数据是否正常。最简单的办法是用QGC通过USB先连一次，确认姿态数据能刷新。这一步别省，串口联不通，后面WiFi链路全白搭。如果你手头有分线板或者逻辑分析仪，也可以直接抓串口波形，但对大多数人来说，QGC能看到飞机姿态就是串口没问题的铁证。
3. 机载端mavlink-router配置
3.1 编译安装
树莓派上可以直接用apt装mavlink-router，但版本可能偏老，我建议源码编译，过程不复杂。
先装依赖：
sudo apt update && sudo apt install -y git cmake g++ ninja-build拉代码：
git clone https://github.com/mavlink/mavlink-router.git cd mavlink-router git submodule update --init --recursive编译安装：
mkdir build && cd build cmake .. make -j4 sudo make install编译时间在树莓派4B上大概几分钟，如果用的树莓派5会更快。装完后验证一下：
mavlink-routerd --version能输出版本号就没问题。有一个小坑，某些版本安装后二进制名带d，叫mavlink-routerd，有些版本则叫mavlink-router，写systemd服务时留意一下。
3.2 主配置文件详解
mavlink-router的主配置文件默认路径是/etc/mavlink-router/main.conf。我推荐的最小配置如下：
[General] DebugLogLevel=1 TcpPort=5760 ReportStats=false [UdpEndpoint broadcast] Address=255.255.255.255 Port=14550 [UdpEndpoint localhost] Address=127.0.0.1 Port=14550 [SerialEndpoint PX4] Device=/dev/ttyACM0 Baudrate=115200几个关键点拆开讲。
Address设置为255.255.255.255是广播地址，mavlink-router会把MAVLink数据包发给整个局域网。这样QGC端不需要知道机载电脑的IP，只要在同一个WiFi下、监听14550端口，就能自动收到心跳包。省去了换网络就要改IP的麻烦。
Baudrate这一项如果飞控是USB连接到机载电脑的，其实不生效，因为USB虚拟串口没有真正的波特率概念，但mavlink-router要求必须填，填115200即可。如果走TELEM口接，波特率必须和PX4里设置的一致，TX1/TX2口默认值不一样，去QGC的参数列表里看MAV_1_CONFIG或MAV_2_CONFIG对应的波特率就对了。
如果你不想让数据满局域网广播，可以把UdpEndpoint的Address改成特定IP：
[UdpEndpoint GroundStation] Address=192.168.1.50 Port=14550广播和定点两种方式各有利弊。定点发送流量干净，不打扰其他设备，但每次换网络都要改配置；广播省心，QGC开机就能识别，代价是每个连到同一个WiFi的设备都能收到MAVLink包。调试阶段我几乎都开广播，省下来的时间比什么都值。
还有个细节，文件里我加了localhost的UdpEndpoint，意思是同时向本机的14550端口发一份。这个有时候调试有用，比如机载电脑上本地跑MAVSDK或者MAVProxy去读数据时能直接用。如果你不需要，删掉这节不影响正常连接。
3.3 系统服务与开机自启
配置写好后，启动mavlink-router服务：
sudo systemctl enable mavlink-router sudo systemctl start mavlink-router如果是编译安装，mavlink-router大概率已经自带systemd service文件；如果没有，手动创建一个：
sudo nano /etc/systemd/system/mavlink-router.service内容：
[Unit] Description=MAVLink Router After=network.target [Service] ExecStart=/usr/bin/mavlink-routerd -c /etc/mavlink-router/main.conf Restart=on-failure User=your_username [Install] WantedBy=multi-user.target注意把ExecStart的路径换成你实际的二进制路径，用which mavlink-routerd查一下。如果不用User指定用户，服务会以root跑，串口权限没问题，但安全上不太优雅。
启动后看日志确认：
journalctl -u mavlink-router -f看到类似“Serial connection on /dev/ttyACM0”和“UDP endpoint created”的信息，说明串口和网络端点都正常了。
这里要分享一个真实踩过的坑：树莓派上如果同时插了USB转串口和测距仪，/dev/ttyACM*的顺序可能不固定，这次是/dev/ttyACM0，那次是/dev/ttyACM1。稳妥做法是写udev规则，按设备序列号把飞控固定成软链接/dev/ttyACM_px4。操作方法是：
udevadm info -a -n /dev/ttyACM0在输出里找到ATTRS{serial}的值，然后创建规则文件，把设备固定下来。这个技巧可以彻底避免开机后识别错设备，多飞控调试时尤其有用。
3.4 MAVProxy替代方案
有朋友习惯用MAVProxy做机载路由，也行。一条命令搞定：
mavproxy.py --master=/dev/ttyACM0,115200 --out=udp:192.168.1.50:14550或者广播形式：
mavproxy.py --master=/dev/ttyACM0,115200 --out=udpbcast:14550MAVProxy可以随时在终端里用命令行操作MAVLink消息，调试期确实方便，比如直接发指令切换飞行模式。但长期运行时它的日志输出比mavlink-router多，出错时关键信息容易被刷屏。我的习惯是调试抓包用MAVProxy，稳定飞行任务跑mavlink-router，各管一段。
4. QGC地面站连接配置
4.1 UDP模式：一把梭连上
打开QGC，点击左上角的“Q”图标，进入Application Settings，再进Comm Links。
点Add添加一个链路，Type选择UDP，端口填14550。这个链路本质上是让QGC在14550端口上默默监听，一旦收到MAVLink包就会自动连接。
如果机载端用的广播模式，地面站这边什么都不用多改。QGC开在那里，飞控加电、mavlink-router启动之后，最多几秒钟，右上角就会从Disconnected变成你的飞机型号和固件版本。我实际使用中，UDP方式的自动发现基本是秒连，这也是我推荐UDP广播作为首选的原因。
4.2 TCP模式：主动连接更可控
如果你在mavlink-router里开了TcpPort=5760，QGC也可以走TCP。添加Link时Type选择TCP，Server Address填机载电脑的IP，比如192.168.1.100，Server Port填5760，点Connect即可。
TCP的优点前面说过，QGC是主动连接方，哪怕机载端广播链路关了，只要TCP端口开着，QGC一直重试也能连上。缺点同样明显：每次开机机载电脑的IP一变，QGC这边就再也连不上了。所以选TCP方案的前提是先给机载电脑配好静态IP，不然每次重启都像开盲盒。
4.3 连接成功后的三步验证
连上之后，先别急着解锁起飞。在QGC里做三件事：
第一，看主界面右上角的连接状态和飞机型号，确认固件版本被正确识别。
第二，打开MAVLink Inspector，路径在Analyze工具里，确认消息流里有HEARTBEAT、GPS_RAW_INT、ATTITUDE等常见消息。如果消息频率特别低，八成是无线链路不稳，去查信号。
第三，切到Fly页面，把飞机放在桌上，手动轻轻晃动飞控，看姿态是否跟着动。这一步能确认遥测数据是实时通着的，不是只有心跳包。
如果发现MAVLink消息频率很低，优先排查WiFi信号，其次检查mavlink-router日志。具体排查方法看下一节。
5. 高频问题排查与避坑实录
5.1 高频问题速查表
我整理了一份问题对照表，基本覆盖了WiFi连接配置中八成的情况：
| 现象 | 可能原因 | 处理方法 |
|---|---|---|
| QGC一直显示Waiting for vehicle | 机载端没发心跳包 | 查mavlink-router日志，确认/dev/ttyACM存在 |
| 机载和地面站能互相ping通但QGC连不上 | UDP端口被防火墙拦截 | 放行14550/5760端口，或临时关闭ufw |
| 连上后数据刷新很慢 | WiFi信号差或频段拥挤 | 近距离测试，或换5GHz频段 |
| 重启机载电脑后连接失效 | 静态IP没配、串口设备名变了 | 配静态IP，用udev固定串口 |
| mavlink-router启动报Permission denied | 当前用户不在dialout组 | usermod -a -G dialout并重新登录 |
| 广播模式下QGC还是收不到 | 路由器开了AP隔离 | 进路由器后台关闭客户端隔离 |
防火墙这里多说一句。Ubuntu的ufw默认一般没开，但如果你曾经配过防火墙，记得加规则：
sudo ufw allow 14550/udp sudo ufw allow 5760/tcp sudo ufw allow 5760/udp很多人在Windows笔记本上折腾半天，结果问题是机载端Linux防火墙把UDP广播挡了，这类问题最费时间。
5.2 无线信号与延迟优化
我实际调试中最常见的问题不是配置，而是信号干扰。实验室WiFi环境特别拥挤，2.4GHz频段经常有几十个热点，蓝牙鼠标、无线键鼠也都在这个频段附近凑热闹。第一次测试的时候，飞机在地面站旁边不到三米，数据却一波一波地卡顿，最后发现是2.4GHz被干扰得厉害。
处理办法是近场用5GHz，远场降到2.4GHz。5GHz近距离延迟低、吞吐高，但穿墙衰减明显；2.4GHz覆盖远但干扰源多。如果你不确定当前信号质量，在QGC的MAVLink Inspector里看消息频率，正常连接下消息刷新应该是每秒十几到几十条，明显低于这个数值就要处理信号了。
还有一个容易被忽略的点是天线方向。笔记本天线通常集成在屏幕边框，树莓派小铁盒里的天线位置又朝向另一边。调试时把双方的天线方位大致对齐，信号质量能改善不少。另外，路由器尽量放在场地中间偏高的位置，不要放在金属桌面或机架旁边，金属对WiFi信号的衰减比你想象中大得多。
5.3 无路由器场景的AP热点应急方案
如果外出场地没有路由器，机载电脑开热点是最后的兜底方案。树莓派上NetworkManager切AP模式很容易：
先查看无线网卡名称：
nmcli device status创建热点，假设网卡是wlan0：
nmcli device wifi hotspot ifname wlan0 ssid px4-link password "12345678"创建完查看热点的IP段：
nmcli connection show Hotspot | grep IP4.ADDRESS一般是192.168.2.1/24这类网段。此时mavlink-router不用大改，还是广播模式；地面站笔记本连上这个热点后，IP会自动从热点网段拿一个，QGC监听14550，自动就能收到广播数据包。
有两点提醒：一是热点名称别太复杂，个别老式网卡对特殊字符的SSID支持有问题；二是机载电脑开了热点多半就没法同时上外网了，如果还需要远程SSH或者其他联网服务，建议准备第二块USB无线网卡，一块做热点，一块上网，互不干扰。
跑这套配置踩过不少坑，最大的体会是“先有线，再无线”这个顺序千万不能乱。很多人一上来就急着配mavlink-router和WiFi链路，结果串口那头根本没数据，后面排查全是白费功夫。从飞控到机载电脑，再经WiFi到QGC，链路一段一段通，任何一步出问题都容易定位。
最后分享一个小技巧：如果调试时不方便带路由器，又想让地面站和机载端同时上网，可以在机上把USB tethering和WiFi热点配合使用。手机USB共享网络给树莓派，树莓派再开热点给地面站，这样地面站既能看到飞机，又能正常上云台控制和其他网络服务。这套组合在户外实测过很多次，稳定性非常不错。WiFi链路本身做室内调试和集群测试已经很够用了，实在要飞远再上数传电台也不迟。
