做无人机开发这些年我带过不少新人也踩过数不清的坑。有个规律挺有意思最后能独立扛起项目的人往往不是一开始就会调参、会写控制律的而是Linux功底扎实、能在命令行里行云流水解决问题的。无人机软件栈的底层是Linux这句话不是口号是真刀真枪的硬约束——PX4飞控固件要编译ROS节点要跑视觉SLAM要装CUDA仿真要起Gazebo哪一步都离不开一套稳定、干净的Linux开发环境。这篇内容围绕“Module 3Ubuntu 20.04 Linux 工程基础——无人机软件开发环境”展开。目标很直接从零开始搭出一套专门面向无人机软件开发的Ubuntu 20.04环境说清楚为什么选这个版本、怎么规划磁盘和源、哪些Linux命令是真正高频的、Python和ROS环境怎么隔离以及PX4仿真怎么跑起来。它适合两种人一是刚接触无人机软件开发的学生或转行者二是已经在用Ubuntu但总觉得环境“不舒服”、想系统性整理一遍的开发者。既然标题已经点明了是Module 3前面大概率已经有了无人机的基本概念或硬件认知。这个阶段的任务就是把“软件地基”打好——地基稳了后面学路径规划、目标检测、飞控二次开发都顺。这篇文章没有废话都是实操经验和踩坑记录。1. 为什么无人机软件开发绕不开Ubuntu 20.04——先说版本选型1.1 无人机软件栈对系统版本的真实约束很多没接触过无人机软件栈的人会有一个错觉Linux发行版那么多随便装一个就行实际不是这样。无人机软件链的核心成员——PX4 Autopilot、ROS、Gazebo、MAVSDK、OpenCV、CUDA——它们对操作系统版本有明确的依赖关系。其中约束最狠的是ROS和Gazebo的组合。Ubuntu 20.04对应的是ROS Noetic这是ROS1的最后一个长期支持版本官方支持到2025年。Gazebo在20.04的官方源里是Gazebo 11恰好是PX4官方仿真推荐搭配。CUDA这边NVIDIA驱动520分支对应CUDA 12.x在20.04上依然有官方支持。也就是说20.04在“ROS1 Noetic Gazebo 11 PX4 SITL”这条经典链路上是官方文档覆盖最全、社区踩坑记录最多的组合。这里想说得直白一点如果你跑的无人机项目是PX4 ROS Gazebo这条主流路线选Ubuntu 20.04不是“老”而是“成熟”。20.04是2014年Ubuntu 14.04之后又一个长期稳定普及度极高的版本软件生态的兼容性在多年打磨后非常可靠。1.2 20.04相比18.04、22.04的取舍先说18.04。它的ROS对应是MelodicGazebo是9PX4新版本对Gazebo 9的支持已经越来越少。很多新出的PX4模块或外部插件直接用Gazebo 11的APIGazebo 9跑起来会报一堆找不到头文件的错。对新手来说这种“版本不匹配”的问题非常消耗耐心。22.04则是另一个方向的问题ROS 2的Humble很新但大量存量项目、教程、论文复现代码还是ROS 1 Noetic的。如果你跟着PX4官方文档走很多示例代码默认ROS Noetic MAVROS。22.04上跑ROS 1要么用Docker容器要么自己编译源码这对新手不友好对老手也麻烦。所以我通常建议新人直接上20.04。它不是配置最“潮”的但一定是踩坑成本最低的。等你哪天需要ROS 2或更新的Gazebo了用Docker或双系统再切换也不迟。1.3 一个反直觉的建议先装双系统还是虚拟机很多初学者问我Windows用习惯了能不能在虚拟机里装Ubuntu 20.04来做无人机开发我的建议很明确日常验证、跟教程敲命令虚拟机可以真要编译PX4固件、跑Gazebo仿真、连接飞控USB调参请果断装双系统。原因不复杂。虚拟机对USB设备透传的支持始终有限尤其是飞控、GPS模块、数传模块这类串口设备。虽然VMware和VirtualBox都支持USB passthrough但遇到驱动或权限问题时的排查路径比双系统麻烦得多。更关键的是性能Gazebo仿真本质是物理引擎实时计算加3D渲染虚拟机的图形性能和CPU调度会有明显损耗起飞悬停的仿真跑起来一卡一卡的很难判断算法问题还是性能问题。如果是NVIDIA显卡的机器还有个坑Host系统Windows和Guest系统Ubuntu抢GPU资源CUDA在虚拟机里的性能衰减很严重视觉SLAM训练和推理基本不用想。所以我把话放这想在无人机软件方向认真走下去双系统是首选。虚拟机可以作为“临时看一下文件”的辅助工具。2. 构建可用开发环境磁盘规划、换源、驱动与必备组件2.1 磁盘分区与系统安装的工程化思路装系统前先想清楚磁盘怎么分这比装完系统再折腾省心得多。我个人的工程习惯是如果一块SSD是500GB以上给Ubuntu至少划出200GB。不要只给一个根分区就算了要分出独立的home分区和swap分区。具体来说/给80~100GB装系统和开发工具/home给100GB以上用来放ROS工作空间、PX4源码、数据集swap给8~16GB考虑到Gazebo和编译时内存可能吃紧。这样一个好处是以后系统崩了或者想换发行版只要不格式化/home代码和数据集都还在。我见过太多人把代码放在根目录下面系统一升级全没了痛不欲生。分区表格里至少要有这几项挂载点建议大小文件系统用途/80~100GBext4系统与软件/home剩余空间ext4代码、数据集、工作空间swap8~16GBswap内存交换安装的时候如果用的是U盘启动盘建议用Rufus制作启动盘在写入模式上选择DD模式这样引导兼容性最好。2.2 软件源配置别等到编译到一半才想起来装完系统第一件事不是装任何软件而是换软件源。国内默认源是archive.ubuntu.com下载速度会非常痛苦尤其是apt安装依赖时一长串包列表。换成阿里云或清华的镜像源速度立竿见影。换源的操作如下编辑/etc/apt/sources.listsudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo vim /etc/apt/sources.list把里面的archive.ubuntu.com全部替换成mirrors.aliyun.com或者mirrors.tuna.tsinghua.edu.cn。然后执行sudo apt update sudo apt upgrade -y这里提醒一个细节Ubuntu 20.04的源文件里可能还有security.ubuntu.com和ports.ubuntu.com也要一并替换。很多同学只换主源安全更新源还是国外结果apt upgrade时又卡住。2.3 NVIDIA驱动与CUDA图形界面与计算环境的版本匹配无人机视觉开发基本绕不开NVIDIA显卡。装驱动要遵循一个原则用Ubuntu的附加驱动工具不要从NVIDIA官网瞎下载。20.04的“软件和更新”应用里切到“附加驱动”标签页系统会自动检测合适的驱动版本。不过有些场景下官方源里的驱动版本不够新。比如你需要在Ubuntu 20.04上用较新的CUDA可能需要手动安装特定分支的驱动。网上很多人会搜到“nvidia 520 linux 64-bit ubuntu 20.04”这类关键词520分支对应的是CUDA 12.x时代如果你要跑的是较新的PyTorch或TensorFlow这个版本是合理的。手动安装驱动的路径是sudo apt install build-essential dkms sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt update sudo apt install nvidia-driver-520 sudo reboot装完用nvidia-smi确认驱动工作正常。有一点一定要记住不要同时从官网下载.run驱动和用apt装驱动两者会打架装完经常出现登录界面循环或黑屏。如果已经踩了这个坑可以在恢复模式下purge掉nvidia相关包再重装。2.4 必备开发组件的批量安装基础环境里有一批是所有项目都要用的直接用一条命令装齐sudo apt install -y git vim curl wget htop tree net-tools cmake build-essential \ python3 python3-pip python3-venv python3-dev \ terminator openssh-server openssh-client \ libeigen3-dev libopencv-dev \ net-tools can-utils这里说明一下每个组件的角色git是代码版本管理基础PX4源码和ROS包都靠它拉取eigen是无人机算法里频繁用到的线性代数库opencv是视觉开发的基础后面跑目标检测或光流都要用can-utils是排查CAN总线设备问题用的比如部分电调和传感器通过CAN连接飞控。terminator是个被低估的工具。它支持分屏一个终端跑仿真一个终端跑ROS节点一个终端跑日志监控效率比开一堆窗口高太多。我建议所有新人第一天就装。3. 真正干活的Linux基本功无人机工程中的命令实战3.1 文件与目录操作日志、数据集、构建产物的分层管理Linux命令大家都会背但无人机项目里真正高频的是哪几条我观察下来不是ls、cd这种基础而是跟“找东西”和“看占用”相关的命令。无人机开发中经常要处理三类数据飞控日志.ulg文件或.bin文件、相机数据集一堆.jpg/png序列、编译产物build目录里的中间文件。如果目录不分层几天后你的home目录就是一锅粥。我自己习惯的项目目录结构是~/drone_ws/ ├── src/ # 源码、ROS包 ├── data/ # 数据集、测试图片、日志 ├── build/ # 编译产物 每次删除不心疼 └── scripts/ # 自动化脚本在找文件时du和df是最高频的硬盘检查工具df -h # 查看磁盘分区剩余空间 du -sh ~/drone_ws/* # 查看各目录占用很多人磁盘满了不知道是哪里占的第一反应是用图形界面一个个点效率极低。直接用du -sh //* 2/dev/null | sort -rh | head -20列出来最大的一批目录一目了然。3.2 进程与资源监控定位CPU占用和内存泄漏无人机算法的调试中有一种经典场景代码跑了一段后飞机反应越来越迟钝甚至掉线。极大概率是某个节点内存泄漏或CPU被打满。这时候top和htop是你的第一道防线。htop比top直观很多可以直接按CPU或内存排序快速定位是哪个进程在捣鬼htop还有一种情况明明某个程序退出了但串口或网口还被占着报“port already in use”。这是典型的僵尸进程问题。排查方法ps aux | grep 你的程序名 kill -9 对应的PID如果你监听的是UDP/TCP端口可以用ss -tulpn查看哪个进程占了端口。这些都是无人机开发里每天都要用的底层能力比死记命令重要得多。3.3 串口与USB设备权限飞控连接开发机的常见坑这是新手最容易卡住的地方之一。飞控通过USB连接到电脑后Linux下会表现为一个串口设备通常是/dev/ttyACM0或/dev/ttyUSB0。但默认情况下普通用户没有权限访问串口设备于是QGroundControl或MAVROS一连接就报权限错误。解决办法是把自己加入dialout用户组sudo usermod -aG dialout $USER执行完必须注销重新登录组权限才会生效。之后用ls -l /dev/ttyACM0确认设备已可访问。再补一个经验如果设备插上后连/dev/ttyACM0都不出现先别忙着重装驱动用dmesg | tail -20看内核日志。很多情况是USB线质量问题或接口接触不良这时候硬件层面换根线比折腾软件有效得多。3.4 Shell脚本编译、刷写、日志采集的自动化以前见新人编译PX4固件都是手动敲命令然后看着一屏一屏的输出发呆。这种做法浪费生命。我建议把重复操作写成脚本比如一个build_and_test.sh#!/bin/bash set -e source /opt/ros/noetic/setup.bash cd ~/PX4-Autopilot make px4_sitl gazeboset -e的作用是脚本中任何一条命令失败就停止执行避免犯“编译失败了还在往下跑”的低级错误。日志采集也可以用类似思路#!/bin/bash mkdir -p ~/drone_ws/logs/$(date %Y%m%d_%H%M%S) rosbag record -O ~/drone_ws/logs/$(date %Y%m%d_%H%M%S)/flight.bag /mavros/state /mavros/local_position/pose用日期做目录名以后回看日志时一目了然不用猜是哪个架次的。4. Python与ROS无人机算法开发的软件基座4.1 系统Python与虚拟环境的隔离Ubuntu 20.04自带的Python 3.8是系统级Python很多系统工具依赖它。如果你不管三七二十一用sudo pip install往里塞包大概率会把系统搞坏。经典事故是把setuptools或pip升到不兼容版本然后系统的软件中心、甚至apt工具链都崩了。正确的做法是任何项目都开虚拟环境python3 -m venv ~/drone_ws/venv source ~/drone_ws/venv/bin/activate pip install numpy opencv-python matplotlib虚拟环境之间互不影响而且是用户级的不需要sudo。如果项目里需要不同的Python版本建议装pyenv来管理多个版本但暂时没有这个需求的就别折腾了够用就好。与Python配套的还需要注意ROS Noetic默认Python 3.8虚拟环境里的Python如果版本不同ROS的python脚本会找不到rospy。所以虚拟环境和ROS混用时必须在虚拟环境里手动安装ROS的Python模块要么就不在虚拟环境里跑ROS节点二选一不要混着乱来。4.2 ROS/ROS2安装思路与工作空间Ubuntu 20.04上的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 install curl curl -s https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | sudo apt-key add - sudo apt update sudo apt install ros-noetic-desktop-full安装完成后要配置环境变量echo source /opt/ros/noetic/setup.bash ~/.bashrc source ~/.bashrcROS的工作空间结构需要刻意养成习惯。后续编译自定义功能包时创建workspacemkdir -p ~/catkin_ws/src cd ~/catkin_ws catkin_make或者用catkin build无人机项目里ROS永远是核心通信骨架MAVROS把PX4的状态发给其他节点视觉节点把检测结果发布出去路径规划节点接收目标点并解算期望姿态。这一条消息流在搭环境时就要了然于胸。4.3 时间同步与通信机制无人机多进程协作的底层逻辑无人机系统里时间同步是很多人忽略的坑。飞控内部有自己的时钟ROS节点也有自己的时钟如果它们是两台不同的电脑比如机载电脑和地面站时间不同步会导致数据时间戳错乱日志分析时对不上号。20.04上常用的方案是用chrony做NTP时间同步sudo apt install chrony sudo systemctl restart chrony对于需要更高精度时钟同步的场景可以了解PTP精确时间协议但由于需要硬件支持适合后面深入做多机编队时再研究。初学者先把chrony配好保证机载电脑和地面站在同一个时间基准下问题就解决了一大部分。通信机制方面ROS的话题Topic是异步的、一对多的适合传感器数据和状态量服务Service是同步请求/响应的适合“查询参数”或“执行一次性动作”动作Action适合需要持续反馈的任务比如航点跟踪。理解这三者的区别后面写无人机的任务节点才不会逻辑混乱。5. 仿真先行PX4 Gazebo 环境搭建思路5.1 为什么要先搭仿真很多新人的想法是要去买一台真机再开干。我不反对真机但强烈建议在仿真里先跑通整个流程。原因很现实PX4在仿真里可以直接跑SITLSoftware In The Loop模式飞控固件的逻辑和真机一模一样主要区别只是没有真实传感器数据。在Gazebo里你能做大量测试验证起飞流程、测试避障算法的逻辑、调串级PID的初步参数——这些在真机上一旦炸机轻则换桨叶重则伤人或毁机架。而仿真里炸一百次也不心疼还能随时重置。此外仿真环境方便采集数据。机器人在仿真世界里的ground truth位置、速度、姿态是完美的没有传感器噪声。这对算法调试初期排除感知误差非常有帮助。5.2 基础安装步骤与关键依赖PX4官方推荐的依赖脚本能省很多事但要注意不要无脑跑官方脚本先确认你已经装了前面提到的基础组件。然后按这个顺序git clone https://github.com/PX4/PX4-Autopilot.git ~/PX4-Autopilot --recursive cd ~/PX4-Autopilot ./Tools/setup/ubuntu.shubuntu.sh是一个自动化脚本会把Gazebo、ROS Noetic相关依赖、MAVROS等一并装好。整个跑完大概需要20~40分钟取决于网络和机器性能。脚本跑完后再编一次确认环境make px4_sitl gazebo第一次编译会拉取很多子模块时间会比较长。看到终端输出类似[100%] Built target gazebo就说明通过了。这里有个经验如果编译过程中报“缺少某个cmake包”先试sudo apt install对应名字的-dev包不要立刻自己在网上找一个源码来编。90%的依赖问题apt都能解决源码编译引入的依赖树反而更乱。5.3 第一次启动仿真后要检查什么启动Gazebo后画面里会出现一架多旋翼停在跑道旁。看起来很简单但有几个东西一定要确认用QGroundControlQGC地面站连接仿真环境选UDP端口通常默认14550。连接成功后QGC会显示飞机状态为“MAVLink connected”。这时尝试发送一个起飞任务观察飞机是否正常离地、悬停是否稳定。如果一切正常恭喜你的仿真链路已经通了。另外要检查终端窗口的MAVLink输出是否持续打印INFO [commander] Takeoff detected之类的日志。这说明PX4状态机已经工作通过MAVLink渠道和外部沟通正常。如果飞机没有反应第一排查对象往往是UDP端口冲突或者QGC没切到UDP模式。仿真环境还有个容易被忽略的点Gazebo默认跑得很慢时可能是图形渲染拖了后腿。这时可以关掉Gazebo的GUI只用无头模式跑仿真在性能弱的电脑上会有明显改善。具体做法是在launch文件中设置headless:true。6. 从“能跑”到“能交付”工程化习惯与常见坑6.1 版本控制与SSH远程开发无人机项目代码的迭代速度很快特别是调PID、改控制逻辑时一天内一个参数要反复试。没有版本控制改乱了就只能靠记忆回滚迟早出事。所有代码工作第一步就是git init。最基础的一套流程是git init git add . git commit -m Initial commit: 完成仿真环境配置 git log --oneline如果看重历史清晰可以学一下分支管理。比如以main作为稳定版本每次开发新功能切新分支测试稳定后再merge。这个习惯在团队合作中尤为重要自己一个人开发时也能快速回溯“上周这个参数调整后的代码长什么样”。远程开发方面无人机常用的开发模式是SSH到机载电脑比如树莓派或NVIDIA Jetson上开发。这时候受益最大的不是图形界面而是SSH端口转发和screen/tmux。在机载电脑上跑长时任务时如果SSH断线导致任务中断就麻烦了。用screen或tmux把任务挂到后台即使断线重连任务还在跑screen -S px4_sim # 接着执行想长时间运行的命令 # 断线后重新连接 screen -r px4_sim6.2 实时性相关排查技巧无人机是强实时系统飞控的内环控制必须按时完成。虽然我们做的是Linux上层开发不是飞控本身但依然会遇到实时性问题比如订阅MAVLink消息的频率不稳定、PX4姿态消息卡顿等。排查时第一步看的是通信时延和丢包最直接的工具是mavlink_status话题和rosnode info。用rostopic hz /mavros/state看消息频率是否稳定在设定值通常是10Hz或30Hz。如果频率忽高忽低先排查是不是同一网络里有其他设备占用带宽再看CPU负载曲线。还有一点要牢记不要在需要实时响应的代码回调里做复杂计算比如在MAVLink订阅回调里跑YOLO检测那必然会阻塞消息处理。正确做法是回调里只做数据拷贝复杂计算放到独立线程去执行。6.3 日志管理思路日志是无人机开发和排错的生命线。出现过一种情况飞控日志在但ROS节点日志没有传感器数据的时间戳对不上最后只能“盲猜”问题出在哪。建议从一开始就建立起日志体制飞控日志QGroundControl里设置«日志下载»每次飞行后下载 .ulg 文件。ROS日志用rosbag record记录话题数据至少包含/mavros/state、/mavros/local_position/pose、传感器话题。终端日志用script命令录制终端输出script flight_log_$(date %Y%m%d_%H%M%S).txt日志文件按日期或飞行架次命名并集中放到一个目录定期归档。不要相信自己的记忆力写文档、写注释这都是老生常谈但确实管用的。6.4 几个值得养成的习惯第一条每次装完系统后把安装过的所有软件和配置写成markdown笔记。半年后你换新电脑照着笔记装环境一晚上就搞定而不是重新踩一遍所有坑。这个笔记就是你个人的环境备份。第二条使用别名简化高频命令。比如在~/.bashrc里加几行alias px4buildcd ~/PX4-Autopilot make px4_sitl gazebo alias wscd ~/catkin_ws catkin_make alias logscd ~/drone_ws/logs别小看这些操作每一条命令都少打半行一天下来省下的时间可以多看几篇论文。第三条不要用root账户做日常开发。安装软件用sudo开发过程全部用自己的普通用户。原因很实际普通用户的权限隔离能在你手滑时救你一把比如rm -rf打错路径root环境下可能连整个系统都没了普通用户至少有自己的home目录做缓存。第四条保持对“磁盘空间”的敏感。编译PX4时build目录轻松吃掉几十GB。养成定期跑du -sh ~/PX4-Autopilot/build的习惯隔一段时间就把build目录清理掉重新编译。这块本地空间的浪费最无谓。最后说点实在的从多年前第一次在Ubuntu上编译PX4固件到后来在机载电脑上部署整套无人机感知系统我发现在Linux这块花的时间从来不会白费。很多人在乎“学会了哪条命令”“装好了哪个环境”但真正拉开差距的是“遇到问题了怎么排查”。环境坏了不可怕可怕的是不知道从哪查起。这一模块把Linux工程基础打牢后面学串级PID、路径规划、目标检测你才有底气说“我来调”而不是“代码能跑就行”。如果这篇文章能帮你少走一些弯路那这个记录就值了。