Ubuntu 20.04无人机开发环境搭建：ROS+PX4仿真避坑指南

从入门到能跑仿真：Ubuntu 20.04 无人机软件开发环境的搭建与避坑

不管你是打算做 PX4/ArduPilot 二次开发，还是想在机载电脑上跑 ROS 做视觉避障，只要跨进无人机软件开发这扇门，第一个绕不开的环境就是Ubuntu 20.04。我见过太多人卡在第一步：系统装好了不知道下一步该干嘛、权限报错看不懂、依赖冲突解决一整天，最后连一个仿真都没跑起来。这篇内容就是把我自己搭这套环境时做的事、为什么这么做、以及踩过的坑一次性讲清楚，给准备入门或正在被环境折磨的你一条可以直接照着走的路径。

这篇文章不是什么高深原理，而是实打实的工程基础课。我会先解释为什么无人机软件生态普遍绑定 Ubuntu 20.04 而不是更新的版本，然后从零开始做系统配置，再把 Linux 工程基础里真正影响开发效率的部分拎出来讲，最后完整走一遍 ROS 和 PX4 仿真的搭建流程。适合 Ubuntu 接触不多、想搞无人机开发的新手，也适合已经在用但始终没理清环境逻辑的开发者。

1. 无人机软件栈，为什么绕不开 Ubuntu 20.04

1.1 无人机软件不是“一个程序”，而是一条工具链

很多人以为无人机软件开发就是写飞控里的 C/C++ 代码，其实远不止如此。一套完整的无人机软件栈，至少包含四层：

• 飞控层：运行在 STM32 等 MCU 上的实时控制固件，比如 PX4、ArduPilot。
• 机载电脑层：运行在 Linux 系统里的高算力程序，比如 ROS 节点、SLAM、目标检测。
• 地面站层：QGroundControl、Mission Planner 这类地面控制软件。
• 仿真层：Gazebo、jMAVSim 这类用来在电脑上模拟无人机飞行的环境。

这四层在开发阶段几乎都要在一台 Linux 电脑上完成编译、运行和联调。飞控固件要交叉编译后刷进硬件，机载电脑代码要直接编译运行，仿真更是要把整套软件栈拉起来跑。所以你的开发机系统选得好不好，直接影响后面每个环节的顺畅程度。

1.2 版本选型不是拍脑袋：20.04 的生态位置

先给一个直接结论：如果你用的是 PX4 + ROS 这套主流开源组合，Ubuntu 20.04 是当前兼容性最省心的版本。

原因有几个方面：

• ROS 1 的最后一个版本 Noetic 只官方支持 Ubuntu 20.04。ROS 2 的 Foxy 同样绑定 20.04。虽然 ROS 2 的新版本已经开始支持 22.04/24.04，但很多项目积攒下来的代码、文档、依赖库还是围绕 Noetic 写的，你随手查的一个功能包可能都基于 Noetic。
• PX4 官方文档的默认开发环境就是 Ubuntu 20.04。PX4 的编译脚本、工具链版本、Gazebo 仿真搭配，在 20.04 上经过的测试最充分。
• 第三方依赖的兼容性。比如一些相机驱动、激光雷达 SDK、CUDA 版本，厂商给的安装包往往优先适配 LTS（长期支持）版本。20.04 作为 2020 年的 LTS，在 2025 年之前一直是“够新且稳定”的平衡点。

不是说你不能用 22.04 或者更新版本，而是如果你刚入门，选择一个资料最多、踩坑代价最低的环境，能省下大量查错时间。等你把整套流程跑通，再考虑迁移也不迟。

1.3 安装方式：双系统、虚拟机还是 WSL 2

确定了 Ubuntu 20.04 之后，下一个问题是怎么装。三种主流方式各有取舍，直接说我的建议：

我的建议很明确：如果你准备认真做无人机开发，直接上双系统。因为后面很可能会遇到连接 Pixhawk 飞控、接传感器、跑 Gazebo 3D 仿真这些场景，双系统下这些事情的体验远好于虚拟机和 WSL 2。虚拟机适合你只是想先看看 Linux 长什么样，WSL 2 适合只做算法模块的编码调试，但一遇到硬件设备就容易卡壳。

2. 新装系统后的第一轮“工程化装修”

2.1 换源、更新、安装基础软件包

不管你是刚装好系统还是拿到一台干净环境，第一步永远是换软件源。Ubuntu 默认源在国外，下载速度会让你怀疑人生。国内推荐换阿里云、清华或中科大的镜像源。

打开终端，先备份原始源文件，这是个好习惯：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

然后编辑/etc/apt/sources.list，把archive.ubuntu.com和security.ubuntu.com替换成镜像源地址。用 sed 可以一键完成：

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

执行更新并顺手装上一批开发必备软件：

sudo apt update && sudo apt upgrade -y sudo apt install -y vim git curl wget net-tools htop tmux \ terminator build-essential cmake python3 python3-pip \ openssh-server can-utils

这里逐个说下为什么装这些：build-essential提供 gcc/g++/make，任何 C/C++ 项目编译都绕不开；cmake是绝大多数现代项目的构建工具；git不用解释，代码版本管理全靠它；net-tools提供 ifconfig 等老牌网络命令，排查 IP 时方便；terminator是一个支持分屏的终端，跑多个 ROS 节点时非常实用；openssh-server让你可以用 SSH 从另一台电脑远程操作这台机器，机载电脑开发尤其需要。

2.2 把终端和 Shell 调教成“称手工具”

环境装好后，第一步就该配置好终端。不要小看这一步，日常开发绝大部分时间在终端里度过，终端顺不顺手直接影响效率。

我会在~/.bashrc里加上几个最常用的 alias：

echo "alias ll='ls -alF'" >> ~/.bashrc echo "alias la='ls -A'" >> ~/.bashrc echo "alias gs='git status'" >> ~/.bashrc echo "alias gp='git pull'" >> ~/.bashrc source ~/.bashrc

Python 方面，Ubuntu 20.04 自带 Python 3.8，建议用python3 -m pip而不是直接敲pip，避免系统 Python 环境被搞乱。后续做 Python 开发强烈建议使用venv或 conda 隔离环境，不要让 pip 的包直接装在系统 Python 里。我见过太多人因为直接在系统环境里pip install一些库，把系统自带的包搞坏，最后被迫重装系统。

另外，建议把中文输入法搞定。Ubuntu 20.04 上我推荐安装 fcitx5 + 中文拼音：

sudo apt install -y fcitx5 fcitx5-chinese-addons

安装后在“设置—区域与语言—输入法”里添加拼音即可。终端里输代码时不需要中文输入法，但写文档、查资料时没有它就很难受。

2.3 用户、权限和软件安装的本质

很多新手在 Ubuntu 里遇到的第一道坎是“Permission denied”。这背后是 Linux 的权限模型，理解它才能彻底根治问题。

Linux 下每个文件都有所有者、所属组和其他用户的读/写/执行权限。sudo只是让你临时以 root 身份执行命令，不是说你以后所有操作都要加 sudo。如果你发现自己频繁需要 sudo 才能操作自己目录下的文件，大概率是目录权限或所有者有问题。

常用的用户和权限命令，在这里做个小结：

sudo adduser newuser # 新建用户并创建用户目录 sudo usermod -aG sudo newuser # 把用户加到 sudo 组 sudo chown -R user:user dir # 修改文件所有者为 user sudo chmod 755 script.sh # 设置权限 rwxr-xr-x

很多人喜欢sudo chmod 777解决问题，这是个大忌。777 意味着所有用户都能读写执行，在开发机上会埋下严重的安全隐患，也会让文件所有者变得混乱。正确做法是管理好用户和组，把当前用户加到合适的组里。比如无人机开发中经常要访问串口设备，就要把用户加到 dialout 组：

sudo usermod -aG dialout $USER

否则后面连飞控、接传感器时，会一直提示没有权限打开设备节点。

3. Linux 工程基础：真正拉开差距的是系统思维

3.1 文件系统：理解“一切皆文件”

很多新手觉得 Linux 命令背不完，其实问题不在于背，而在于没有理解 Linux 的底层设计哲学——一切皆文件。普通文件、目录、设备、甚至进程信息，都可以用文件的方式去访问和操作。

Linux 目录结构（FHS）是有固定规范的，我用自己的理解快速梳理一遍：

• /bin、/usr/bin：系统命令和用户程序的存放位置。
• /etc：配置文件所在地，几乎所有软件的配置都在这。
• /home：用户目录，你自己的代码和文件都在这。
• /var：日志、缓存等经常变化的文件，比如/var/log/syslog。
• /opt：第三方软件安装目录，很多厂商 SDK 默认装这里。
• /tmp：临时文件，重启后会被清掉。

这就是为什么我们常说要“把软件装到对的位置”。用 apt 安装的软件会把可执行文件放到/usr/bin，配置文件放到/etc，库文件放到/usr/lib，这是 Debian 系的标准布局。而源码编译安装的软件默认装到/usr/local，两者互不干扰。

理解了目录规范，再去看那些“找不到命令”“找不到库文件”的报错，心里就有数了——大概率是 PATH 环境变量没包含对应目录，或者动态链接库搜索路径不对。

3.2 软件安装的三种方式，不要混着用

Ubuntu 里装软件有三种主要方式，很多人经常混用导致依赖错乱：

apt 安装：从软件仓库下载预编译好的 deb 包，自动解决依赖。这是首选方式，干净、可控。命令是sudo apt install 包名。

pip 安装：Python 包的安装方式，只影响 Python 环境。要注意别用 sudo pip 装到系统解释器里，除非你确定自己在干什么。

源码编译安装：从 GitHub 或官网拉源码，自己./configure && make && sudo make install。这种方式灵活性最高，但升级卸载全靠手动，依赖问题也最多。很多无人机项目（比如 PX4）就是源码编译方式，因为厂商没提供现成的 deb 包，必须自己构建。

我的原则是：能用 apt 绝不用源码编译，除非官方明确要求。PX4 这种项目之所以源码编译，是因为它本身就是一个大型 monorepo，需要自己拉子模块、管理工具链版本，这也是为什么环境搭建对新手来说是道坎。

3.3 进程、服务与日志定位

开发中经常遇到“程序启动了但莫名其妙退出了”这类问题。在 Windows 上你可能习惯去任务管理器看，但在 Linux 上最重要的三个命令是：

ps aux # 查看当前进程 top / htop # 实时看系统资源占用 systemctl status 服务名 # 查看系统服务状态

Ubuntu 20.04 使用 systemd 管理服务和开机启动。比如你想让 SSH 服务开机自启：

sudo systemctl enable ssh sudo systemctl start ssh sudo systemctl status ssh

排查问题时，日志比进程状态更关键。系统日志集中在/var/log/，而 systemd 管理服务的日志用journalctl查看：

journalctl -u ssh -f # 实时查看 SSH 服务的日志 journalctl -xe # 查看最近的系统错误日志

我遇到过一个典型场景：ROS 节点启动就崩，终端只提示“段错误”，看不出原因。后来用journalctl看到底层库的报错，才发现是显卡驱动和某依赖库版本不匹配。这个思路可以复制到任何 Linux 问题排查上——先看日志，再猜原因，永远别瞎试。

3.4 脚本化思维：把重复劳动交给电脑

一套环境搭建流程里，有大量固定操作：source 环境变量、编译、启动仿真。手动一条条敲不仅慢，还容易漏。这时候就该写脚本。

我给自己的环境准备了一个一键编译脚本，结构大致这样：

#!/bin/bash set -e # 出错立即停止 echo "[1/3] 初始化环境变量..." source /opt/ros/noetic/setup.bash source ~/catkin_ws/devel/setup.bash echo "[2/3] 编译工作空间..." cd ~/catkin_ws catkin_make echo "[3/3] 设置环境..." source ~/catkin_ws/devel/setup.bash echo "编译完成"

set -e是重点，它让脚本在第一条失败的命令处停下来，避免在错误基础上继续执行产生更多问题。写脚本时还有一个习惯值得养成：把 ASCII 码转成大段界面的脚本兼容性问题处理好，终端宽度不够时容易乱。

4. 动手搭建无人机开发验证环境：ROS + PX4 仿真

4.1 ROS Noetic 安装与 source 机制

前面铺垫了这么多，现在到核心环节。先装 ROS Noetic 桌面完整版：

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list' sudo apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654 sudo apt update sudo apt install -y ros-noetic-desktop-full

安装完成后一定要执行这行，把 ROS 环境变量写入 shell 配置：

echo "source /opt/ros/noetic/setup.bash" >> ~/.bashrc source ~/.bashrc

这步极其关键。ROS 是一个庞大的软件集合，所有 ROS 命令、功能包的位置都靠环境变量来指定。很多人安装完 ROS 后马上敲roscore，结果提示找不到命令，原因就是没 source。source 一次只在当前终端生效，写进~/.bashrc才能真正一劳永逸。

然后初始化 rosdep，这是 ROS 管理功能包依赖的工具：

sudo rosdep init rosdep update

国内网络环境下rosdep update经常卡住，这是 ROS 新手最常遇到的第一个大坑，我待会儿在最后一章专门讲解决办法。

4.2 PX4 固件编译与 Gazebo 仿真

ROS 装好只是第一步，真正跑无人机仿真还需要 PX4 固件。从源码编译 PX4 的过程如下：

git clone --recursive https://github.com/PX4/PX4-Autopilot.git cd PX4-Autopilot make px4_sitl gazebo

sitl是 Software In The Loop 的意思，即软件在环仿真。这套机制把飞控固件当作一个普通 Linux 进程跑起来，与 Gazebo 模拟器通信，实现“无人机在电脑里飞行”的效果。首次编译会下载大量依赖，耗时取决于网络状况，20 到 40 分钟都算正常。

如果编译过程中提示缺少依赖，PX4 官方提供了一个自动化脚本：

bash ./PX4-Autopilot/Tools/setup/ubuntu.sh

这个脚本会把需要的工具链、Python 库、交叉编译器都装好。但是要注意，它会修改你系统里的 Python 环境，所以更稳妥的做法是先创建一个 conda 环境或者 venv 环境，再跑这个脚本。

跑仿真前还要注意一个细节：Gazebo 首次启动时会从网上拉取无人机模型文件，国内访问模型库特别慢，甚至直接卡在加载界面。常见的解决办法是提前把模型库下载好，放到~/.gazebo/models目录下，或者在启动环境里设置：

export GAZEBO_MODEL_PATH=模型目录:$GAZEBO_MODEL_PATH

把这些写入~/.bashrc，就再也不会卡在加载界面了。

4.3 机载电脑与交叉编译的工程思路

无人机开发不仅有机载电脑的 Linux 程序，还有飞控 MCU 上的固件。飞控固件编译和普通程序不一样，它在性能强大的电脑上编译，生成的是另一套 CPU 架构（ARM）可执行文件，这个过程叫交叉编译。

PX4 官方对 Pixhawk 系列飞控的固件编译方式是：

cd PX4-Autopilot make px4_fmu-v5_default

它会自动调用预先配置好的交叉编译工具链，把我们熟悉的gcc替换成了arm-none-eabi-gcc这类针对 ARM 的编译器。理解这一点很重要，因为嵌入式平台（比如 Zynq-7000 系列）的软件开发也有类似流程：先装对应平台厂商提供的交叉编译工具链，然后设置CC、CXX等环境变量指向工具链，再编译源码。

这套思路在无人机、自动驾驶、机器人领域通用。以后你拿到一块新板子，不用慌，核心就是三步：找工具链、配环境变量、编译测试程序验证。建议自己试着给一个最低限度的 hello world 写交叉编译脚本，跑通一次，后面上手会快很多。

5. 实际开发中绕不开的坑与排查思路

5.1 一套通用的 Linux 问题排查链路

在经历了若干次“配置两天、运行三秒”之后，我总结了一套自己的排查思路，分享出来供参考：

1. 复现场景：什么命令、什么操作触发了问题，尽量最小化复现。
2. 看报错信息：报错信息里往往直接写明了原因，不要跳过第一行红字。
3. 看日志：journalctl -xe、/var/log/下的系统日志，或者程序自己的 log 文件。
4. 确认环境变量：command not found、库找不到，八成是 PATH 或LD_LIBRARY_PATH没设对。
5. 确认权限：Permission denied，要么用 sudo，要么改用户组和文件权限。
6. 二分定位：如果是刚装完的软件，回退到“装之前能用吗”来缩小范围。
7. 网上搜索：把完整报错粘贴到搜索引擎，注意看发布时间和系统版本是否匹配。

这套链路看着简单，但真遇到问题时能帮你少走弯路。我见过很多人遇到报错就开始盲目卸载重装，折腾一整天发现是路径少了个斜杠，非常浪费时间。

5.2 高频坑一：rosdep update 卡住

前面提过rosdep update慢的问题。这个工具要访问 GitHub 上的资源列表，在国内网络环境下经常超时。我用的解决方法是配置代理镜像，思路是把 rosdep 的资源下载地址从 GitHub 换成国内可达的镜像地址：

sudo apt install -y python3-rosdep2 sudo sed -i "s/raw.githubusercontent.com/raw.gitmirror.com/g" /usr/lib/python3/dist-packages/rosdep2/sources_list.py sudo sed -i "s/api.github.com/镜像地址/g" /usr/lib/python3/dist-packages/rosdep2/gbpdistro_support.py

关键点是找到你环境里 rosdep 的安装路径，然后修改对应的 URL 前缀。如果你网络环境通畅，此坑可以绕过，但如果卡住超过 10 分钟，建议直接动手换镜像。

这个问题的本质是 rosdep 要下载一份“包名到依赖”的映射数据库，文件不大但对网络要求高。理解了这一点，后续遇到类似“下载慢”问题也就能举一反三了。

5.3 高频坑二：USB 设备权限与 dialout 组

连接 Pixhawk 等飞控硬件时，最典型的问题是：

ls /dev/ttyACM0 # 提示：Permission denied

原因就是当前用户对串口设备节点没有访问权限。前面已经提到解决办法，把用户加入 dialout 组并重新登录：

sudo usermod -aG dialout $USER # 重新登录后生效

之所以这么麻烦，是因为 Linux 对设备的访问权限继承自“组”的概念。设备节点的默认组是 dialout，所以正确做法是把用户加进这个组，而不是用chmod 777改设备权限。用后者，你每次插拔设备后权限又变回默认，还是要重新改，非常不优雅。

顺带提一句，连接飞控后在 QGroundControl 里看不到设备，也经常是同样的问题。别急着换数据线，先查权限。

5.4 高频坑三：Python 包冲突与 pip 乱装

无人机项目通常依赖大量 Python 包，比如 MAVSDK-Python、numpy、opencv-python。很多新手图省事直接sudo pip3 install xxx，结果可能把系统 Python 环境弄坏，甚至导致apt都无法正常工作。

我自己的方案是：所有 Python 开发需求一律使用虚拟环境。可以以venv为例：

cd ~/project python3 -m venv .venv source .venv/bin/activate pip install numpy opencv-python

这样每个项目的依赖互相隔离，某个项目依赖版本升级不影响其他项目，也不会动到系统 Python。如果遇到某些需要 Python 版本比较固定的项目（比如 ROS 的某些包只支持 Python 3.8），可以直接用 conda 创建对应版本环境。20.04 自带的 Python 3.8 对 ROS 生态而言其实是优势，别轻易升级系统默认 Python。

5.5 高频坑四：Gazebo 加载慢或黑屏

Gazebo 首次启动，你会看到一个无限转圈的黑界面，大概率是在下载模型库。除了前面提到的提前下载模型库并设置GAZEBO_MODEL_PATH外，还有一个常见的性能问题：你的电脑显卡不支持 OpenGL 硬件加速，Gazebo 会回退到软件渲染，画面极其卡顿。

解决办法是安装显卡驱动，或者调整 Gazebo 的环境变量：

export LIBGL_ALWAYS_SOFTWARE=1

但注意这是无奈之举，软件渲染会严重影响仿真性能，只能作为临时兜底。如果你计划长期做视觉仿真，还是建议用一台带独立显卡、驱动正常的电脑，或者直接清掉双系统，用真实 Linux 系统，性能比虚拟机里跑 Gazebo 好太多。

我知道这一节列的坑不算全面，但都是实际开发中最容易卡住新人的地方。环境搭建本身就是一次“练手”，经历过这些问题以后，再看到类似的报错信息，你的第一反应就不再是慌张，而是按套路定位、解决。这就是工程经验和纯粹看教程之间的最大区别。

最后分享一点个人体会：搭建环境的过程确实煎熬，但当你第一次在 Gazebo 里看到无人机起飞，第一次通过 ROS 拿到仿真传感器数据时，那种成就感会告诉你这一切都值得。别怕折腾，环境本身就是你对 Linux 的第一堂实战课。