做了这么多年无人机开发我踩过最深的坑就是环境搭建。很多新手一上来就被 Windows、Linux、飞控、仿真器、通信框架这一整套东西劝退其实只要把每一步的逻辑理清楚环境本身并不难。这篇文章我会把 Windows 11 上通过 WSL2 搭建 PX4 Gazebo ROS 2 QGroundControl Android AI 的多机协同开发环境完整讲一遍把我实际动手时的选型思路、操作步骤、踩坑记录都写出来争取你照着走一遍就能跑起来。先说清楚这个环境能干什么你可以在 Windows 笔记本上不装虚拟机、不双系统直接跑 PX4 飞控的软件在环仿真在 Gazebo 里模拟多架无人机起飞、编队、避障用 ROS 2 做机间通信和任务调度用 QGroundControl 地面站像操作真机一样监视和指挥仿真无人机再通过 Android 设备做移动端控制甚至让 AI 视觉模型跑在 WSL2 里参与目标识别。整个链路覆盖了从飞控逻辑、仿真验证、地面控制到机载智能的全流程适合无人机开发入门、多机协同算法验证、机器人通信开发的同学参考。1. 整体架构与选型思路1.1 为什么用 WSL2 而不是虚拟机或双系统早期无人机开发通常是在 Ubuntu 主机上完成的因为 PX4 工具链对 Linux 的兼容性最好ROS 2 本身也以 Linux 为第一优先平台。可现实是很多开发者的主力机器是 Windows尤其是笔记本装双系统切换麻烦虚拟机又有性能损耗和硬件透传限制。WSL2 的出现恰好解决了这个矛盾。WSL2 从架构上看是运行在 Hyper-V 虚拟机平台上的轻量级 Linux 环境但它的集成度远超传统虚拟机可以通过localhost直接访问 Windows 服务Windows 侧也能访问 Linux 里的端口共享文件系统打通代码放在 Windows 盘、在 WSL2 里编译都没问题加上 Windows 11 内置了 WSLg 图形支持Gazebo、QGroundControl 这种 GUI 程序可以直接弹出窗口。对 PX4 开发来说WSL2 的性能损失非常小编译和仿真的体验接近原生 Linux。选 Ubuntu 22.04 也很关键。ROS 2 的 Humble 版本官方只支持 Ubuntu 22.04PX4 对 22.04 的一键脚本支持最完善Gazebo Classic 11 在 22.04 的源里直接有。如果选 24.04ROS 2 Humble 的适配要多绕很多路没必要给自己加难度。1.2 PX4、Gazebo、ROS 2 各自扮演什么角色新手最容易把这三个东西搞混我用一个生活化的类比讲清楚PX4 是无人机的大脑负责姿态控制、位置估计、航线规划这些飞控逻辑。在 SITLSoftware In The Loop模式下PX4 固件直接作为 PC 上的进程运行不需要真实硬件。Gazebo 是眼睛和身体提供一个物理仿真世界包含重力、空气阻力、地形、传感器模型。PX4 在仿真的世界里飞飞控看到的数据都来自 Gazebo 的传感器插件。ROS 2 是神经系统负责把仿真里的数据、传感器信息、控制指令在各个节点之间流转尤其支持多机场景下分布式通信。多架无人机之间的协同逻辑几乎都在 ROS 2 层实现。这三者的数据关系是Gazebo 生成 IMU、GPS、光流等传感器数据PX4 接收后运行状态估计和控制算法再把电机指令发回 Gazebo形成闭环。ROS 2 通过 MAVROS 或 MAVSDK 这类 MAVLink bridge 接入 PX4读取状态、下发任务。QGroundControl 也通过 MAVLink 和 PX4 通信相当于从地面站视角看到的仿真飞行。1.3 Android 和 AI 在整个链路中的位置很多人好奇 Android 和 AI 在这个环境里到底干什么。Android 端通常是跑 QGroundControl 或基于 MAVSDK 的定制 App通过 WiFi 连接地面站或直接连接仿真 MAVLink 端口相当于一个移动地面站。AI 则跑在 WSL2 里利用 Windows 11 对 WSL2 的 GPU 透传能力直接调用 NVIDIA 显卡做 CUDA 计算比如对 Gazebo 输出的图像流做目标检测、手势识别等。检测结果通过 ROS 2 topic 发布给 PX4就能实现简单的视觉引导功能。后面我会把这个逻辑串成一条完整的链路仿真无人机 - MAVLink - ROS 2 节点 - AI 推理 - 控制指令回传这也是目前多机编队和视觉协同最常见的实验范式。2. Windows 11 与 WSL2 基础环境准备2.1 宿主机前置检查与系统配置在动手装 WSL2 之前先用几分钟确认机器状态避免后面反复踩坑。需要满足的条件不复杂Windows 11 系统CPU 支持虚拟化并且在 BIOS 里开启BIOS 里对应的开关叫 Intel VT-x 或 AMD-V不同主板厂叫法不一样但都在 CPU Configuration 或 Advanced 菜单下。开启虚拟化是必须的WSL2 和 Docker Desktop 都依赖 Hyper-V 平台。内存方面我建议至少 16GB。PX4 Gazebo ROS 2 QGroundControl 同时跑起来再加上 WSL2 自身开销8GB 会比较紧张16GB 算是一个舒适区间单机多机仿真建议 32GB。磁盘空间准备 60GB 以上比较稳妥这里面大头是 PX4 工具链、Gazebo 模型、ROS 2 桌面版编译中间文件也很占地方。确认完之后以管理员身份打开 PowerShell检查 Windows 功能状态Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform如果状态不是 Enabled就用下面的命令开启开启后重启系统dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart这一步完成后的重启不要跳过我就是因为没重启直接装 WSL结果出现了各种莫名其妙的安装错误。2.2 安装 WSL2 和 Ubuntu 22.04WSL 本身只是一个运行时真正干活的发行版要单独装。Windows 11 上最简单的方式是直接执行wsl --install -d Ubuntu-22.04这个命令会自动装 WSL、把默认版本设为 WSL2、下载 Ubuntu 22.04 镜像。首次安装完系统会要求重启重启后 Ubuntu 终端会自动弹出并让你创建用户名和密码这里创建的账号不是 root 而是具有 sudo 权限的管理员账号后面所有软件安装都可以用 sudo 完成。装完以后用wsl --status确认当前版本是 2如果显示版本 1手动升级wsl --set-version Ubuntu-22.04 2把发行版从其他盘迁移到 C 盘以外也有技巧在 PowerShell 里用wsl --export导出 tar再wsl --import导入目标盘。我习惯把 WSL 的 vhdx 文件放在 D 盘这样重装系统不慌。具体命令大概是wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu.tar wsl --unregister Ubuntu-22.04 wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\wsl-backup\ubuntu.tar --version 2注意--import以后默认用户会变成 root可以在 Ubuntu 里执行sudo nano /etc/wsl.conf加入[user] default你的用户名重启 WSL 后恢复。2.3 WSL2 资源配置与 GPU 透传WSL2 默认分配的内存和 CPU 核数是按宿主机比例计算的但对于无人机仿真这种吃资源的负载我建议手动限制和控制。在C:\Users\你的用户名\.wslconfig文件里写入[wsl2] memory16GB processors8 swap8GB localhostForwardingtruelocalhostForwarding保持默认开启就行这决定了 Windows 能不能通过localhost访问 WSL2 里的端口后面 QGroundControl 连接仿真 MAVLink 端口时很关键。GPU 透传这块要单独说。Windows 11 的 WSL2 支持 CUDA 直通前提是 Windows 侧装了最新的 NVIDIA 驱动WSL2 里不需要再装驱动但要在 Ubuntu 里装 CUDA Toolkit 和 cuDNN。验证 GPU 是否可用可以跑nvidia-smi如果在 WSL2 里能看到显卡信息就说明透传成功。AI 视觉任务后面就依赖这个能力。3. PX4 与 Gazebo 仿真环境搭建3.1 PX4 飞控固件编译与工具链安装PX4 官方提供了一键安装脚本但这个脚本会装很多依赖在 WSL2 里跑需要一点耐心。按照官方文档的推荐Ubuntu 22.04 上最干净的方式是先更新系统基础包再运行脚本cd ~ sudo apt update sudo apt upgrade -y git clone https://github.com/PX4/PX4-Autopilot.git --recursive cd PX4-Autopilot bash ./Tools/setup/ubuntu.sh脚本会安装包括编译工具链、Python 依赖、Gazebo Classic 11、MAVLink 库等一整套东西耗时取决于网速。这里有个很容易被忽视的坑--recursive参数必须带上PX4 有大量子模块缺了后面make编译时会出现头文件缺失这类奇怪问题。如果之前克隆的时候漏了在 PX4-Autopilot 目录里执行git submodule update --init --recursive补救。装完依赖后先跑一次编译把基础固件构建出来cd ~/PX4-Autopilot make px4_sitl首次编译会下载一些工具链组件比如 ARM GCC 编译器、nuttx 相关组件也需要些时间。编译成功后再测试 Gazebo 仿真make px4_sitl gazebo-classic这条命令会自动启动 Gazebo Classic加载一个默认的户外世界然后把 PX4 SITL 接入进去。看到终端里输出INFO [commander] Ready for takeoff这类日志就说明仿真链路已经通了。3.2 Gazebo 仿真世界的配置与多机部署单机验证通过后下一步就是多机协同。PX4 的多机仿真有好几种做法最常用的是通过 Gazebo 的sitl_multiple_run.sh脚本批量起多个 PX4 实例每架飞机有自己的 instance 编号。cd ~/PX4-Autopilot/Tools/simulation/gazebo-classic ./sitl_multiple_run.sh 3这个脚本会启动 3 架无人机每架分配不同的 MAVLink 端口和 Gazebo 模型位置。端口分配规律很关键第一架飞机使用udp://:14540127.0.0.1:14557第二架是14541第三架是14542以此类推。ROS 2 侧的 MAVROS 节点要按各自的端口对接后面写 launch 文件时就得注意。如果想自定义飞机模型和位置改动 Gazebo 的 world 文件即可常见文件在Tools/simulation/gazebo-classic/sitl_gazebo/worlds目录下。多机仿真有一个明显特点飞机越多CPU 消耗越大因为每架无人机都是一个独立的飞控进程Gazebo 要同时维护多个物理模型和传感器数据。我实测时 3 架飞机在 8 核 16GB 的配置下还能流畅跑5 架以上就会开始掉帧所以多机实验尽量控制在 3 到 4 架。3.3 PX4 多机仿真的 MAVLink 端口规划端口规划看似不起眼但多机协同调试时一半以上的问题都出在这里。PX4 SITL 默认监听 14540 端口QGroundControl 地面站默认通过 14550 端口发现无人机。多机模式下每架飞机的 MAVLink 数据都通过独立的 UDP 端口输出我们对接 ROS 2 时也要依赖这个映射关系。我习惯在启动仿真前先画一张简单的端口表把 instance ID、MAVLink 端口、对应机型都写清楚。比如./sitl_multiple_run.sh 3会启动实例 0、1、2对应端口 14540、14541、14542。这种表格在实际调试时能省很多时间尤其是遇到多架飞机同时起飞、某架飞机联系不上的情况只需要看一眼端口就知道是哪一层的问题。4. ROS 2 Humble 接入仿真链路4.1 ROS 2 Humble 的安装与基础验证PX4 仿真跑起来后要把 ROS 2 接进去就需要安装 Humble 版本它和 Ubuntu 22.04、PX4 的 MAVROS 版本都兼容。安装 ROS 2 Desktop 版即可功能齐全后面做视觉和协同开发基本够用sudo apt install software-properties-common curl sudo add-apt-repository universe sudo apt update sudo apt install ros-humble-desktop装完后在~/.bashrc里添加环境变量以便每次终端自动加载echo source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc验证 ROS 2 是否正常工作的经典命令是ros2 run demo_nodes_cpp talker ros2 run demo_nodes_py listener在两个终端里分别跑如果 listener 能收到 talker 的消息说明 ROS 2 通信正常。这一步虽然简单但建议不要跳过因为 ROS 2 的 DDS 环境变量、网络发现和 Gazebo 插件这些问题都是从能跑 demo和我能跑我自己写的节点之间的距离开始的。4.2 MAVROS 与 MAVSDK连接 PX4 的两种方式ROS 2 和 PX4 之间通信的主流方式有两种MAVROS 和 MAVSDK。MAVROS 是 ROS 社区的经典方案把 MAVLink 消息映射成 ROS 2 topic 和服务适合和 PX4 的深度交互MAVSDK 是 PX4 官方的现代 SDK接口更简洁适合快速开发应用层逻辑。我这里以 MAVROS 为主因为它的生态更成熟资料也更多。安装 MAVROS 在 Ubuntu 22.04 上用二进制包即可sudo apt install ros-humble-mavros ros-humble-mavros-extras装完以后需要下载地理数据文件这一步经常被遗漏但缺了它会导致后面 launch 时报错。相关配置文件路径在/opt/ros/humble/share/mavros/可以通过以下方式安装sudo /opt/ros/humble/lib/mavros/install_geographiclib_datasets.sh这一步命令会自动下载全球地理信息数据需要几分钟。网络状况不好时容易失败失败后重复执行几次通常能成功。4.3 单机与多机的 ROS 2 Launch 配置单机场景下连接 PX4 的 MAVROS launch 文件里最关键的是fcu_url参数。PX4 仿真默认输出到 14540 端口MAVROS 要监听这个端口。启动命令大概是ros2 launch mavros px4.launch fcu_url:udp://:14540127.0.0.1:14557看到 MAVROS 日志出现连接成功的提示后可以用另一个终端查看当前无人机状态ros2 topic echo /mavros/state如果输出的connected: true说明 ROS 2 已经接入 PX4 仿真链路。多机场景下每架飞机用一个独立的 MAVROS 实例每个实例的 namespace 也不同。假设有两架飞机就分别用namespace:/drone0和namespace:/drone1各自的fcu_url指向对应端口。我一般会写一个总的 launch 文件统一启动所有 MAVROS 实例而不是开一堆终端。launch 文件里用到Group和Node标签核心逻辑是把每个飞机的参数包进去group push-ros-namespace namespacedrone0/ node pkgmavros typemavros_node namemavros param namefcu_url valueudp://:14540127.0.0.1:14557/ /node /group这样启动后每个飞机的节点话题都在自己的命名空间下比如/drone0/mavros/state和/drone1/mavros/state互不干扰协同逻辑分工也清晰。4.4 在 Gazebo 中接入 ROS 2 的相机与传感器话题多机协同绕不开传感器数据尤其是视觉算法依赖的相机图像。Gazebo 模型默认带了很多传感器但要把数据送到 ROS 2就必须让 Gazebo 加载 ROS 2 的传感器插件。这里有一个常见的坑Gazebo Classic 的原生插件是基于 ROS 1 的ROS 2 需要额外安装gazebo-ros-pkgs它是 ROS 2 和 Gazebo 通信的桥梁。安装方式sudo apt install ros-humble-gazebo-ros-pkgs装完以后需要修改 px4 模型目录下的 sdf 文件给相机传感器加上 ROS 2 的插件配置。也可以在启动时通过环境变量和插件参数加载。最简单的方式是用gz topic系列工具来确定话题名再在 ROS 2 侧创建一个桥接或者直接用ros2 run tf2_ros static_transform_publisher广播坐标变换。不过在实际仿真里我推荐用 PX4 自带的Tools/simulation/gazebo-classic/sitl_gazebo里适配好的模型很多模型已经带好了相机和激光雷达插件只需要在 world 文件中确认对应传感器是否开启。你也可以把图像话题通过image_transport转成 JPEG 压缩流再送到 AI 节点做推理降低带宽压力。5. QGroundControl 地面站接入5.1 WSL2 里运行还是 Windows 原生运行QGroundControl 地面站有两种接入方式在 Windows 原生运行或者在 WSL2 的 GUI 环境里运行。我的经验是优先用 Windows 原生版本理由很朴素QGC 的 Windows 版本是官方正式支持的GPU 渲染、USB 串口识别、音频告警都稳定而且可以和 WSL2 里的 PX4 直接通过localhost通信不需要额外折腾网络配置。从官网下载 Windows 版 QGC解压后直接运行。首次启动时它默认通过 UDP 14550 端口监听无人机而 PX4 SITL 默认的 MAVLink 输出正好能到达这个端口所以在仿真启动后再启动 QGC通常几秒内它就会自动发现仿真无人机。在地面站的左上角看到飞机图标就说明连接成功。5.2 与多机仿真的连接配置多机场景下 QGC 默认只能发现一架飞机因为地面站默认只监听一个端口。如果想用 QGC 同时监视多架仿真无人机需要给每一架飞机分配独立的 QGC 实例或者利用 QGC 的 MAVLink 多链路功能。实际操作中我比较简单粗暴每架飞机启动前通过 UDP 14550 以外的端口做端口映射然后在 QGC 里通过 Comm Link 添加新的监听端口。更推荐的做法是把 QGC 主要当作单机调试工具多机监视和指令下发交给 ROS 2 的可视化工具比如 RQT 界面或者编写一个简单的状态监控节点。这样分工明确QGC 负责飞控层面深度调试ROS 2 负责协同逻辑。6. Android 端控制与 AI 扩展6.1 Android QGroundControl 与 MAVSDK 开发Android 端在这个环境里主要是两类角色一是跑 QGroundControl 移动版作为便携地面站二是基于 PX4 官方 MAVSDK 开发自己的控制 App。MAVSDK 的好处是它封好了大量无人机控制接口比如takeoff、land、arm、set_position等不需要你理解底层的 MAVLink 消息结构。Android 项目里引入 MAVSDK 只需要在 Gradle 依赖里加com.mavsdk:mavsdk然后通过 TCP 或 UDP 连接到仿真 MAVLink 端口。开发时有一个细节Android 模拟器里访问宿主机 WSL2 的 localhost 经常会失败这是因为模拟器的网络地址映射机制和仿真 MAVLink 的 UDP 端口转发有冲突。最好用真机调试或者确保 Android 模拟器能通过宿主机 IP 访问到 MAVLink 端口。6.2 AI 视觉任务与 WSL2 GPU 加速AI 视觉这部分我推荐在 WSL2 里直接用 PyTorch CUDA。前面提到过 WSL2 的 GPU 透传实际用起来相当流畅训练和推理的体验接近原生 Linux。一个典型的视觉协同流程是Gazebo 里的无人机相机把图像发给 ROS 2 的图像话题AI 节点订阅这个话题并实时推理输出目标位置再通过 MAVROS 的话题把控制指令发给飞控。我在实际测试中跑了个 YOLOv8 的检测推理用 WSL2 里的 RTX 显卡做 GPU 推理无人机在 Gazebo 里的地面目标识别率很高延迟大概几百毫秒完全能够支撑视觉引导降落这类应用。需要注意的一点是WSL2 里的 CUDA 版本要和 Windows 驱动匹配否则会报CUDA_ERROR_UNKNOWN。7. 常见问题与排查技巧实录7.1 WSL2 端口与网络问题速查现象常见原因解决方案Windows 访问 WSL2 里的 Gazebo Web 页面失败WSL2 是 NAT 网络端口监听地址为 0.0.0.0 才能被外部访问检查服务监听地址用localhost访问时确保 Windows 防火墙放行QGC 无法发现仿真无人机MAVLink 端口映射错误或 QGC 默认端口不匹配确认 PX4 的 14540 输出端口QGC 设置里添加对应通信链路WSL2 内 ping 不通外部网络DNS 配置异常编辑/etc/resolv.conf或/etc/wsl.conf重启 WSLWSL2 里 GUI 程序黑屏WSLg 显示服务异常执行wsl --shutdown重启 WSL更新 Windows 版本WSL2 的网络模式和宿主机不同是个高频坑。默认它是 NAT 模式Linux 内网的 IP 是虚拟网卡分配的。大部分仿真场景我们只在本地通信所以 14540、14557、14550 这类端口都在localhost上转发问题不大。但如果要跨设备访问比如 Android 手机通过局域网连接宿主机上的仿真 MAVLink就需要注意 Windows 侧的端口转发和防火墙配置了。7.2 Gazebo 启动失败与模型加载异常Gazebo 启动时卡在Loading model...是很常见的问题大部分原因是模型文件缺失或网络下载失败。PX4 的 Gazebo 仿真会引用一些依赖模型比如sitl_gazebo子模块里的模型库如果克隆 PX4 时没有拉全子模块启动就会缺少模型。另一个典型问题是 Gazebo 窗口闪烁或者不出现这在 WSL2 里尤其明显。WSLg 对 OpenGL 的支持依赖虚拟 GPU显卡驱动不对或 Windows 版本过旧都会导致渲染异常。我遇到过一次 Gazebo 窗口一片灰但终端日志显示仿真正常最后通过更新 Windows 11 系统版本解决了。如果比较着急也可以用软件渲染模式LIBGL_ALWAYS_SOFTWARE1兜底但帧率会明显下降。7.3 ROS 2 节点间话题不通的排查思路ROS 2 的话题通信依赖 DDS而 DDS 的底层发现机制走的是 UDP。多机协同场景下多架飞机在同一台电脑上跑是没问题的但如果要跨机器通信比如 Windows 和 Linux 各跑一部分节点就需要确保 DDS 域 ID 一致。在~/.bashrc里设置export ROS_DOMAIN_ID42所有参与通信的机器都设成同一个域 ID节点之间才能互相发现。排查话题不通时我通常先用ros2 node list确认节点是否都在线再用ros2 topic list和ros2 topic info看话题类型是否匹配。ROS 2 对话题类型很严格发布的是sensor_msgs/Image订阅端写成了sensor_msgs/CompressedImage两者互不可见。7.4 多机仿真性能不足的优化技巧多机仿真的性能瓶颈通常在 CPU因为每架飞机都是一个独立的 PX4 进程Gazebo 里的物理引擎还要同时计算多个模型的动力学。如果感觉卡顿第一步先降低 Gazebo 的渲染频率或把传感器更新率调低第二步是关闭仿真窗口的实时渲染用gzclient的最小化方式运行只保留物理更新第三步是检查~/.bashrc里是否加载了太多 conda、ROS 环境变量影响编译和启动效率。我自己的经验是3 架以下的编队仿真用默认配置就能跑4 架以上建议把 Gazebo 的实时因子降到 0.5 左右物理计算还能保持准确画面流畅度更高。这里不是要让仿真失真而是寻找一个精度和性能的平衡点。7.5 环境搭建中的独家避坑笔记最后分享几条没法完全写在官方文档里的经验都是我反复踩过的WSL2 的磁盘空间回收要主动做。PX4 每次编译都会产生大量缓存的中间文件Gazebo 的模型下载也会积累数据vhdx 文件只增不减。定期在 PowerShell 里执行wsl --shutdown后用Optimize-VHD工具压缩虚拟磁盘能回收十几个 GB。PX4 子模块更新要勤快。PX4 迭代非常快如果发现某些新模型没有出现或编译报错先执行git submodule update --init --recursive再重试。很多时候问题根本不是代码语法而是子模块版本没同步。ROS 2 和 Gazebo 的 bridge 依赖 gazebo_ros_pkgs这个包版本一定要和 ROS 2 Humble 匹配。我从网上抄过一个教程装错源结果 Gazebo 启动直接全部插件加载失败最后只能重装 Ubuntu 才恢复干净环境。装包前一定要确认是ros-humble-gazebo-ros-pkgs。我个人在实际操作中的体会是这套环境最花时间的不是安装而是理解每一层之间的数据流关系。先把 Gazebo 到 PX4 的链路跑通再加入 ROS 2最后才去做 Android 和 AI 的扩展一步步来比一次性全配完要稳得多。最后再分享一个小技巧把 PX4-Autopilot 和 ROS 2 workspace 放在 WSL2 的 ext4 文件系统下不要放在/mnt/c这种 Windows 挂载盘否则编译速度会慢好几倍这是 Linux 文件系统和 NTFS 交互的固有开销放在原生 ext4 里能完全规避。