企业官网建设流程全解析

1. 为什么 Windows 11 上用 WSL2 而不是双系统跑 PX4 仿真

两年前我第一次搭 PX4 仿真环境，选的是双系统。每次要飞仿真就得重启到 Ubuntu，写完代码切回 Windows，来回折腾至少五分钟。后来换成 Windows 11 + WSL2 这套方案，流程变成：打开终端，输入wsl，三秒钟进 Ubuntu 环境，Gazebo 里的无人机照样飞，QGroundControl 照样连，ROS 2 节点照常跑。这个改变直接让我把 WSL2 从“可以试试”变成了“强烈推荐”。

1.1 一套环境解决三件麻烦事

WSL2 并不是一个“虚拟机”那么简单。它底层基于 Hyper-V 的轻量级虚拟机，但微软把文件系统、端口转发、本地回环网络都做了整合。对搞无人机开发的人来说，意义不是“能在 Windows 下用 Linux”，而是同时保住三样东西：

• 保留 Windows 侧的应用生态：编译大文件、跑 IDE、用浏览器查资料，都在原生 Windows 下做，不会因为装了 Linux 而牺牲日常使用体验。
• 获得接近原生 Linux 的仿真能力：PX4 的 SITL（Software In The Loop）、Gazebo、ROS 2 这些项目，官方支持的是 Ubuntu，WSL2 走的是完整 Linux 内核，绝大部分工具链可以直接跑。
• 开箱即用的图形界面：WSL2 自带 WSLg，Ubuntu 里的 GUI 程序会直接显示在 Windows 桌面上，不用额外装 X Server，QGroundControl 和 Gazebo 都能正常渲染。

我之前用 VMware 跑 Ubuntu 也踩过不少坑，特别是 Gazebo 的 OpenGL 渲染，VMware 默认的 3D 加速经常导致屏幕闪烁、黑屏，要折腾一大轮图形驱动。WSL2 在这方面反而省心很多，Windows 侧的 GPU 驱动会被透传进 WSL2，Gazebo 能用上 GPU 渲染，这对仿真性能影响非常大。

1.2 WSL2 的边界条件，你得先知道

不过 WSL2 不是万能的，有几个边界条件必须提前了解，否则后面会怀疑人生。

第一，跨文件系统访问慢。这是 WSL2 最典型的坑。如果你把 PX4-Autopilot 仓库克隆到 Windows 的 D 盘，然后跑到 WSL2 里编译，你会发现编译速度慢到离谱，因为 WSL2 访问/mnt/d/...走的是一层 9P 协议，IO 性能跟本地 ext4 差一个数量级。所以项目源码一定要放在 WSL2 自己的文件系统里，比如~/PX4-Autopilot，而不是/mnt/c或/mnt/d。

第二，WSL2 是动态内存占用，你不管它，它可能默认吃满宿主机一半以上的内存。后面我会讲用.wslconfig限制内存和 CPU，这只是第一步，编译 PX4 时还需要额外的 swap 空间。

第三，精简版系统别碰。网上经常出现windows 11 x-lite、windows server 2022 wsl1 改不成 wsl2这类问题。WSL2 依赖VirtualMachinePlatform、Microsoft-Windows-Subsystem-Linux这两个 Windows 功能，精简版系统经常把这些组件砍掉，装到最后发现wsl --set-default-version 2一直失败，又得重装系统，得不偿失。

第四，USB 设备透传很麻烦。如果你打算接 Pixhawk 硬件的 USB 口，WSL2 默认不支持 USB，要用 usbipd-win 这样的工具转发。仿真阶段一般用不到真机，可以先不折腾。

这些边界条件搞清楚之后，后面每步都会顺很多。

2. 装环境前的版本规划：Ubuntu 22.04 + ROS 2 Humble 为什么是当前最优组合

很多人一上来就装最新版：Ubuntu 24.04、ROS 2 Jazzy、Gazebo Ionic，结果发现 PX4 的官方仿真插件跑不起来，再退回来重新装。我建议冷静一下，先把版本组合定好。

2.1 不要把最新版当成首选

当前（2025 年前后）最稳的组合是：

为什么不用 Ubuntu 24.04？因为 PX4 官方文档中 Gazebo 仿真的主要支持路径还是基于 22.04 的 Gazebo Classic，而 24.04 默认的 Gazebo 变成了全新的 Ignition/Garden 系列，PX4 的适配代码还在持续迭代。你用最新版不是不行，但会遇到更多需要自己修的问题。对于“从零搭建”的目标来说，先用官方验证过的组合是最聪明的做法，这不是保守，是省时间。

ROS 2 选 Humble 同理。它对应 Ubuntu 22.04，属于同一个 LTS 周期，官方库安装时不会出现依赖冲突。Humble 的文档、Stack Overflow 的问答数量、各社区踩坑记录，都比新版本多得多，真出了问题能搜到答案，这对新手太重要了。

2.2 PX4、Gazebo、ROS 2 的三角关系

很多人一开始分不清 PX4、Gazebo、ROS 2 各自负责什么，导致后面配置环境变量时一团乱麻。我用一句话理清：

• PX4 是“飞机的大脑”，跑的是飞行控制固件，仿真时以 SITL 方式运行，不依赖真实硬件。
• Gazebo 是“世界”，提供物理仿真环境、地形、传感器数据和无人机机体模型。
• ROS 2 是“神经系统”，负责在 PX4 和上层算法之间传递消息，让你方便地写感知、规划、编队等逻辑。

换句话说，PX4 是主角，Gazebo 是舞台，ROS 2 是舞台和主角之间的通信管道。QGroundControl 则是地面调度台，通过 MAVLink 直接和 PX4 对话，帮助你看状态、发指令、看实时画面。

在编译 PX4 时，make px4_sitl gazebo-classic会把 PX4 固件、Gazebo Classic 插件、MAVLink 接口一次性编译出来，启动后 PX4 通过 UDP 14540/14550 端口与 Gazebo 和外部地面站通信。理解了这个链路，之后排查问题你就知道该看哪一层了。

2.3 硬件底线：内存、磁盘和 CPU 分配

这套环境对硬件有要求，不是随便一台笔记本就能流畅跑的。我实测下来的最低可接受配置：

• 宿主机内存：16 GB。WSL2 建议分配 8 GB 给 Linux，PX4 编译时最多能吃到 4~6 GB，Gazebo 再占 2~3 GB，这就 10 GB 左右了。只有 8 GB 内存的机器会非常紧张。
• 磁盘：留出 50 GB 以上空闲空间。PX4 源码加依赖、ROS 2、Gazebo 加起来 20 GB 很正常，再加上编译产物和 swap 文件，50 GB 是最低线。
• CPU：8 核以上体验好很多。编译 PX4 是 CPU 密集的任务，核数少就只能等。
• GPU：有 NVIDIA 独显最好。WSL2 支持 CUDA，nvidia-smi在 WSL2 里可以直接用，后续做 AI 推理、Gazebo 渲染都会受益。核显也能跑，但 Gazebo 场景复杂时帧率会掉。

如果你用的是 Windows Server 2022，想把 WSL1 改成 WSL2 却失败，多半是VirtualMachinePlatform功能没启用，或者没有重启。先检查功能状态，不要急着重装系统。

3. WSL2 安装与基础调优实战

版本规划好了，正式开始动手。这一节我会按顺序走一遍，尽量细致。

3.1 从 Windows 11 侧完成安装

打开 PowerShell（管理员权限），输入：

wsl --install

这个命令会一次性安装 WSL 组件、虚拟机平台，并且默认安装 Ubuntu。装完之后重启电脑，第一次启动 Ubuntu 会提示你设置 Linux 用户名和密码。用户名会自动加入 sudo 组，后面不需要切 root，全程用sudo就行。

重启后先确认版本：

wsl -l -v

如果输出的 Ubuntu 版本是2就对了。如果发现是1，执行：

wsl --set-version Ubuntu 2

如果这一步报错，去控制面板“启用或关闭 Windows 功能”里确认虚拟机平台和适用于 Linux 的 Windows 子系统都勾上了，再重启一次，基本就能解决。

注意：如果你的电脑开启了 Secure Boot，WSL2 本身是兼容的。真正容易出问题的是那些“优化版”精简系统，把上述 Windows 功能组件裁掉了。遇到WSL 2 is not available类似的报错，先检查这两项功能，不要盲目重装。

3.2 .wslconfig 关键参数

WSL2 默认配置不一定适合跑仿真。我在 Windows 用户根目录下创建了.wslconfig文件：

[wsl2] memory=8GB processors=8 swap=8GB localhostForwarding=true guiApplications=true

• memory：分配给 WSL2 的内存上限。我这里设了 8 GB，宿主机是 32 GB，剩下给 Windows 自己用。
• processors：分配 CPU 核数。注意不是越多越好，留一部分给宿主机。
• swap：WSL2 的 swap 文件，编译 PX4 时非常有用，能明显降低 OOM（内存耗尽）概率。

改完配置之后，必须执行wsl --shutdown让 WSL2 完全重启，配置才会生效。这一点很容易忘，我见过有人改完配置没重启 WSL2，然后一直觉得是配置写错了。

3.3 换源和基础依赖

进入 Ubuntu 后，先更新软件源索引：

sudo apt update && sudo apt upgrade -y

如果你觉得 Ubuntu 默认源下载速度不理想，可以改成国内镜像站。以阿里云为例，编辑/etc/apt/sources.list，把archive.ubuntu.com换成mirrors.aliyun.com：

sudo sed -i 's|//.*archive.ubuntu.com|//mirrors.aliyun.com|g' /etc/apt/sources.list sudo apt update

然后装基础工具链：

sudo apt install -y git build-essential cmake ninja-build \ python3-dev python3-pip python3-venv terminator \ net-tools curl wget lsb-release gnupg

这里把cmake、build-essential都装了，后面编译 PX4 和 ROS 2 功能包都会用到。terminator是多标签终端，支持分屏，多机仿真时一个屏幕看多个终端非常方便，强烈建议装上。

4. Ubuntu 侧 ROS 2 Humble + Gazebo Classic 11 联合安装

WSL2 环境就位，接下来安装核心软件栈。

4.1 系统初始化和换源

上一步已经做了基础更新。再确认一下 locale，ROS 2 对 UTF-8 有要求：

sudo apt install -y locales sudo locale-gen en_US en_US.UTF-8 sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 export LANG=en_US.UTF-8

建议把export LANG=en_US.UTF-8写进~/.bashrc，避免每次开终端要手动设置。

4.2 ROS 2 Humble 安装与验证

添加 ROS 2 官方软件源：

sudo apt install -y software-properties-common sudo add-apt-repository universe sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null sudo apt update sudo apt install -y ros-humble-desktop

ros-humble-desktop包含了 ROS 2 通信、工具、可视化 RViz2、demo 程序，体积比较大，安装时间会久一些。装完在~/.bashrc末尾加：

source /opt/ros/humble/setup.bash

验证是否装好。一终端跑：

ros2 run demo_nodes_cpp talker

另一终端跑：

ros2 run demo_nodes_py listener

如果能看到Listening ...的输出，说明 ROS 2 通信正常。这一步很关键，先确认 DDS 没问题，再往上层叠 PX4，排查起来才不至于两头猜。

4.3 Gazebo Classic 11 以及与 ROS 2 的桥接包

Ubuntu 22.04 可以直接 apt 装 Gazebo Classic：

sudo apt install -y gazebo11 libgazebo11-dev

验证：

gazebo --version

然后装 ROS 2 的 Gazebo 桥接包：

sudo apt install -y ros-humble-gazebo-ros-pkgs

这个包里包含了gazebo_ros，负责把 Gazebo 的传感器数据发布成 ROS 2 话题。后续 AI 接入时，我们要从仿真相机里取图像，就是靠它。

Gazebo 启动后如果界面黑屏或者闪退，先确认 WSLg 是否正常工作。最简单的方法是随便开一个 GUI 程序，比如gedit，如果在 Windows 桌面上能看到窗口，说明 WSLg 没问题。黑屏大概率是 GPU 渲染的问题，可以试试加环境变量：

export LIBGL_ALWAYS_SOFTWARE=1 gazebo

但这是软件渲染，帧率有限，只用来排查。正常情况 WSL2 里应该能直接用 GPU 渲染。

5. PX4 固件编译与第一次仿真起飞

ROS 2 和 Gazebo 就绪，下面进入正题：编译 PX4 并跑起第一架仿真无人机。

5.1 克隆与编译 PX4-Autopilot

先把源码放到 WSL2 自己的文件系统里：

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

PX4 仓库里有子模块，--recursive必须带上，否则 Gazebo 仿真插件会缺失。如果 clone 过程中子模块拉取不完整，再执行：

git submodule update --init --recursive

然后运行官方依赖配置脚本：

bash ./Tools/setup/ubuntu.sh

这个脚本会安装编译 PX4 需要的所有依赖，包括 GCC 工具链、Python 包、MAVLink 相关工具等。中间有询问时我一般一路回车，用默认选项。

接着编译 SITL 和 Gazebo 插件：

make px4_sitl gazebo-classic

第一次编译会很久，核心数少的话三十分钟到一小时都可能。成功之后终端里会看到 PX4 shell 的提示符，同时 Gazebo 会自动启动，一架默认的 iris 无人机出现在世界场景中。

这里有个常见问题：编译到一半报错内存不足。如果你的.wslconfig只给了 4 GB 内存，建议给到 8 GB，并把 swap 调到 8 GB，然后wsl --shutdown重启 WSL2，再重新make。如果提示找不到gazebo-classic这个 target，先确认你安装的是 Gazebo Classic 11，而不是 Gazebo 的新版本系列。

5.2 启动仿真、连接 QGroundControl

第一次make px4_sitl gazebo-classic已经把 PX4 和 Gazebo 都拉起来了。平时想重新启动 SITL，同样执行make px4_sitl gazebo-classic即可。

PX4 SITL 默认通过 UDP 14550 向外发送 MAVLink 数据。这时启动 QGroundControl，它就会自动发现仿真无人机。

在 WSL2 里下载 QGC：

cd ~ wget https://github.com/mavlink/qgroundcontrol/releases/download/v4.4.4/QGroundControl.AppImage chmod +x QGroundControl.AppImage ./QGroundControl.AppImage

QGC 界面打开后，主界面会显示当前连接的飞行器，你能看到姿态、高度、GPS 状态等。你可以手动切换飞行模式，也可以用虚拟摇杆推动无人机起飞。第一次在仿真里看到自己的无人机飞起来，还是挺有成就感的。

提示：QGC 如果在 Windows 侧跑，连 WSL2 里的 UDP 14550 端口可能因为 NAT 转发不稳定而连不上。最省事的方案是把 QGC AppImage 也放在 WSL2 里跑，两者都在同一 Linux 环境中，localhost 直接通信，稳得很。

5.3 多机协同仿真的启动方法

单机仿真跑通后，多机协同就是下一步。PX4 官方提供了一个多机脚本：

cd ~/PX4-Autopilot/Tools/simulation/gazebo-classic ./sitl_multiple_run.sh

这个脚本默认启动多架 iris 无人机，数量可以在脚本头部配置。每架无人机有独立的 MAVLink 端口，例如 14540、14541、14542，QGC 也能在同一个地面站里看到多台飞行器。

如果你需要手动控制实例编号启动，可以开多个终端，每个终端执行：

PX4_SIM_MODEL=iris ./build/px4_sitl_default/bin/px4 -i 1

-i 1是实例编号，每开一个终端就递增一个编号。配合 Gazebo 那边 spawn 对应数量的无人机模型，就能构建自己的多机仿真场景。

多机脚本的好处是省去手动 spawn 模型的麻烦，推荐直接用官方脚本。后面讲 AI 协同，我用的也是这个脚本启动的多机场景。

6. QGroundControl 地面站与 Android 端的协同位置

6.1 在 WSL2 里跑 QGC

前面已经装了 QGC AppImage，这里补充几个使用细节。

QGC 的自动连接默认会监听 14550 端口，PX4 SITL 启动后它自动就能连上。如果想手动指定连接，在 QGC 的“Application Settings - Communication Links”里添加一个 UDP Link，本地端口填 14550。

还有一个情况：仿真跑久了，QGC 偶尔会显示“Link Lost”。别急着怀疑配置，先看 PX4 SITL 终端有没有报错，再确认 Windows 防火墙是否拦截了 UDP 14550。在 Windows 侧给 WSL 相关程序放行 UDP 端口，问题基本就消失了。

WSL2 里跑 QGC 还有一个体验优化：在高 DPI 缩放的 Windows 桌面上，QGC 字体可能偏小，可以在 QGC 设置里把字体调大。WSLg 对 Qt 应用的兼容性整体不错，一般不需要额外配置图形后端。

6.2 Android 端在整套体系里的定位

标题里有 Android，很多人的第一反应是“用手机控制真机”。没错，但我想把 Android 端在仿真开发中的三个角色拆开说：

第一，Android 版 QGC 作为移动地面站。它和电脑端 QGC 功能基本一致，可以连接局域网里的无人机 MAVLink 端口。在户外真机测试时，手机比笔记本方便得多。

第二，Android 设备作为边缘 AI 节点。现在很多 Android 手机跑 TensorFlow Lite 的速度非常快，你可以把手机摄像头对准仿真屏幕，做视觉识别然后发指令。但这种“屏幕级”方案不够严谨，更适合演示。

第三，更接近实战的做法：把 Android 端连接到 MAVSDK 后端。通过 WiFi 局域网访问电脑上运行的 MAVSDK Server，手机上写一个 App 订阅无人机状态，发送定点任务指令。这条链路在真机和仿真里通用，是值得投入的方向。

对于从零开始的人，我建议先把电脑端 QGC 和多机仿真玩熟，再去碰 Android 端，否则两边同时出问题会非常难排查。

7. AI 环节接入：从单机视觉到多机协同

整套环境搭到这一步，不用起来做点 AI 就太浪费了。这一节我讲两种实际可落地的接法。

7.1 仿真中的 AI 能做什么

结合标题里的多机协同，AI 在仿真里常见的几个方向：

• 目标检测：通过下视相机识别地面目标，判断目标位置和类别。
• 避障：利用前视相机或者激光雷达点云，在飞行路径上检测障碍物并绕开。
• 编队协同：多架无人机之间通过 ROS 2 话题共享目标信息，一架负责侦察、其他架负责执行。

Gazebo 的好处是传感器模型齐全，相机可以模拟真实噪声，比纯数学仿真可靠得多。你可以先在一架无人机的模型上挂相机，验证识别逻辑，再推广到多机。

7.2 接入思路一：通过 MAVSDK 控制

MAVSDK 提供 Python 和 C++ 接口，能直接发 offboard 指令，比手动写 MAVLink 协议省事。安装：

pip install mavsdk

连接多机仿真中的第一架无人机（14540 端口），发送北东地坐标系下的位置设定值：

import asyncio from mavsdk import System async def run(): drone = System() await drone.connect(system_address="udp://:14540") async for state in drone.core.connection_state(): if state.is_connected: print("connected to vehicle") break # 北 0 米、东 0 米、高度 5 米（NED 中 D 向下为正）、偏航 0 度 await drone.offboard.set_position_ned([0, 0, -5, 0]) await drone.offboard.start() print("offboard started") await asyncio.sleep(10) asyncio.run(run())

执行前，需要先把无人机切换到 Offboard 模式，可以用 QGC 手动切，也可以在代码里用drone.offboard.start()自动完成（不同 PX4 版本行为略有差异，建议先在 QGC 里确认模式状态）。这段代码跑通后，你就有了“用 Python 控制仿真无人机”的能力，AI 逻辑只需要产出目标位置，剩下的交给这套接口。

7.3 接入思路二：ROS 2 话题驱动

如果你已经写了 ROS 2 节点，更自然的方式是把 PX4 纳入 ROS 2 图。PX4 仓库里自带 ROS 2 接口px4_msgs，位于~/PX4-Autopilot/ROS2/px4_msgs。编译它：

cd ~/PX4-Autopilot/ROS2 colcon build source ~/PX4-Autopilot/ROS2/install/setup.bash

编译完成之后，你可以在 ROS 2 节点里订阅fmu/out/vehicle_attitude获取姿态，也可以向fmu/in/offboard_control_mode和fmu/in/trajectory_setpoint发布 offboard 指令。这种方式的好处是和视觉、规划算法完全共享同一套通信体系，写多机协同逻辑时特别顺手。

7.4 多机协同的 AI 演示逻辑

结合 5.3 节的多机脚本，一个简单的协同演示可以这样设计：

• 启动sitl_multiple_run.sh，得到两架无人机，记为无人机 A（14540）和无人机 B（14541）。
• 给 A 挂一个下视相机，通过gazebo_ros的 camera 插件把图像发布到 ROS 2 话题/drone_A/camera/image_raw。
• 写一个 ROS 2 视觉节点，检测地面上的红色目标，估算目标相对 A 的位置。
• 将目标坐标通过 ROS 2 话题/target_pos广播出去。
• 无人机 B 的 offboard 节点订阅/target_pos，然后朝目标飞。

这样就是一个完整的“侦察-执行”协同链路，而且每个环节都能替换成更复杂的算法，比如 YOLO 检测、A* 路径规划、动态避障。第一步先把通信链跑通，AI 模型反而是最容易换的部分。

Gazebo 默认的 iris 机型不一定带相机，需要在模型 SDF 里加 camera sensor 或通过 gazebo_ros 的插件添加。这一步比较繁琐，但网上模板很多，照着改即可。我自己的做法是单独复制一份 iris 模型文件，在里面加一个朝下的 RGB 相机插件，避免动到官方默认模型。

8. 实测中遇到的坑和最后一点心得

搭建这套环境的过程中，我踩过的坑不算少，这里挑几个最值得说的。

8.1 内存和编译速度

第一次编译 PX4 直接 OOM，当时以为代码写错了，后来发现是内存不够。查了.wslconfig才想起来用的是默认配置，WSL2 只给我分了宿主机一半内存。调整到 8 GB + 8 GB swap 之后，编译稳定多了。

另外，make px4_sitl gazebo-classic可以限制并行任务数，减少内存峰值：

make px4_sitl gazebo-classic -j4

如果你的机器内存不大，别贪心开-j16。

8.2 Gazebo 黑屏与图形问题

WSL2 下 Gazebo 黑屏最常见的原因有两个：一是 WSLg 没有正常工作，二是模型资源路径没配对。先确认gazebo --version正常，再试着打开一个空场景。如果空场景正常但 iris 模型场景黑屏，很多是模型路径的问题，检查 PX4 的setup_gazebo.bash是否被 source 了。

另一个经验：不要在 Windows 侧的文件夹里存放 Gazebo 模型文件，WSL2 读取/mnt/c下的模型文件速度很慢，而且路径处理经常有问题。把模型放到~/下最省心。

8.3 QGC 连接断掉的排查

QGC 连不上 PX4 SITL 时，我一般按顺序查：

1. PX4 SITL 终端是否还在运行，有没有报端口占用。
2. QGC 和 PX4 是否都在 WSL2 内（都在的话几乎不会有网络问题）。
3. Windows 防火墙是否拦截了 UDP 14550。
4. 是否用wsl --shutdown重启过 WSL2（IP 变化可能导致旧的连接失效）。

大多数情况下，第 2 点就能解决问题。我强烈建议把 QGC 也放到 WSL2 里跑，比在 Windows 侧连着省心得多。

8.4 一个能少走弯路的习惯

最后分享一个习惯：每次改动环境后，都先跑一遍最小验证链路。比如装了 ROS 2 就跑 talker/listener，装了 Gazebo 就跑空场景，编译完 PX4 就先让它飞起来。如果不做这些最小验证，一旦环境出问题，你根本不知道是哪一层坏的。

这套环境目前是我电脑上利用率最高的开发环境。真机飞行测试前的算法验证、多机编队逻辑调试、AI 视觉识别，我都在 WSL2 + Gazebo 里完成。等仿真里跑得足够成熟，再上真机，风险小很多，迭代也快。希望这篇记录能帮你少走点弯路。