1. 为什么无人机软件要从 Linux 工程基础抓起做无人机软件开发这几年我最大的感触是很多人把精力全扑在算法和飞控逻辑上却忽略了最底层、最要命的环境工程能力。你想想一套无人机系统要正常工作涉及的东西远比写几行控制代码复杂得多。传感器数据要实时采集、图像要处理、通信链路要稳定、任务调度要精准这些模块跑在什么上面绝大多数情况下是跑在 Linux 系统上。Ubuntu 20.04 作为目前兼容性最好、资料最全的发行版之一基本是无人机行业的默认选择。我在 Module 3 里把“Ubuntu 20.04 Linux 工程基础”单独拎出来讲就是因为这个环节卡住了太多人。不是大家学不会飞控算法而是连最基本的交叉编译工具链、文件系统权限、服务管理、日志排查都没理顺后面开发无人机应用时寸步难行。这个模块解决的核心痛点很清楚不知道 Ubuntu 20.04 该怎么为嵌入式开发做系统配置不熟悉 Linux 命令行面对无人机的编译输出、日志信息一脸懵不理解交叉编译原理导致在 PC 上写好的程序无法部署到飞控/机载电脑上遇到环境问题不知道如何排查靠重启和重装系统解决一切适合谁来学准备入门无人机软件开发、嵌入式 Linux 开发的在校学生已经会写一些 Python/C 代码但从未在 Linux 环境下搭建完整工程的人工作中需要维护无人机地面站、机载电脑环境但 Linux 基础薄弱的技术人员说白了这个模块就是把无人机软件开发的地基打牢。地基不稳楼盖得再高也是危房。下面我把自己带项目时的完整思路和实操经验拆开来讲。2. Ubuntu 20.04 在无人机开发中的定位与选型分析2.1 为什么偏偏是 Ubuntu 20.04有些人会问现在 Ubuntu 22.04、24.04 都出了为什么无人机软件这行还用 20.04 这么多这不是保守而是硬件厂商的支持周期和生态惯性决定的。以 Xilinx 的 Zynq-7000 系列为例很多无人机视觉处理板、异构计算核心都用这颗 SoC。Xilinx 官方对 Ubuntu 20.04 的支持最成熟PetaLinux 工具链在 20.04 上的兼容性最好。你如果装个最新版 Ubuntu光解决依赖冲突就能折腾一整天。再比如 PX4、ArduPilot 这些主流飞控的仿真环境以及 ROSRobot Operating System生态Ubuntu 20.04 ROS Noetic 是官方长期支持的黄金组合。做无人机开发你很难绕开 ROS、MAVSDK 这些中间件它们对系统版本的依赖非常具体。还有一个实际理由团队协作和复现成本。同一个项目组七八个人如果系统版本不统一A 编译出来的库 B 用不了C 的路径配置和 D 不一样光环境对齐就很痛苦。全组统一到 Ubuntu 20.04配置文档写一份大家照着做出问题也好排查。2.2 虚拟机、双系统还是物理机我见过不少学员问环境装在哪里比较好这个得分场景。部署方式优点缺点推荐场景VMware 虚拟机与宿主机隔离快照回滚方便适合练习 Linux 命令和编译性能开销大USB 设备直通偶尔抽风实时性差初学者熟悉 Linux、学习交叉编译流程双系统性能接近物理机硬件访问完整切换系统要重启比较麻烦需要跑 Gazebo 仿真、连接大量外设的中期学习者纯物理机性能最大化环境干净日常办公不便装错环境难恢复专用构建服务器、长期固定的开发机如果你只是学 Module 3 这个阶段我强烈建议用VMware Ubuntu 20.04。理由很实在交叉编译工具链、Linux 命令、环境变量这些内容在虚拟机里完全够用。而且虚拟机的快照功能简直是手残党福音配置搞乱了一键恢复不用重装系统。等到后面要做实机联调、跑实时图像处理再切双系统或者用专门的编译服务器都不迟。2.3 Ubuntu 20.04 镜像选择与安装细节镜像下载这个事看似简单踩坑的人却不少。我见过有人下到第三方魔改版系统里一堆不明软件编译时各种诡异报错。老老实实去 Ubuntu 官方镜像站下载桌面版 ISO 就行。安装时有几个细节容易忽略安装类型一定要选“最小安装”无人机开发用不到 LibreOffice 这种办公套件省下的空间留给编译缓存分区时建议单独划分/home这样以后系统崩了重装源码和配置文件还在用户名建议用纯英文小写不要带特殊符号。有些交叉编译工具链对路径中的特殊字符非常敏感我踩过这个坑苦不堪言软件更新那里选择“正常更新”即可不必勾选“自动安装第三方驱动”装完系统第一件事先把build-essential、git、vim、net-tools这些基础包装上。命令很简单sudo apt update sudo apt upgrade -y sudo apt install -y build-essential git vim net-tools cmake这道命令跑完系统才勉强具备开发条件。注意apt update和apt upgrade要分开理解前者更新软件源索引后者才真正升级软件包。很多新手只跑前者然后抱怨“说好的升级呢”。3. Linux 工程基础无人机开发者的必备工具箱3.1 文件系统与权限理解无人机工程的骨骼Linux 和 Windows 最大的思维差异就是一切皆文件。无人机里面的传感器节点、串口设备、摄像头在 Linux 眼里都是文件。比如你要读取飞控通过串口发来的数据操作的是/dev/ttyUSB0你要访问 IMU 数据可能需要操作/dev/i2c-1。不理解这个逻辑后面调设备驱动会非常痛苦。文件权限这块我见过太多人直接chmod 777一把梭。这在个人电脑上问题不大但放在无人机机载设备上就是安全隐患。正确的做法是对于设备文件如串口把当前用户加入dialout组而不是把设备权限改成 777对于脚本只给可执行权限不要顺手加写权限对于配置文件普通用户只读需要改时用sudo临时提权把用户加入串口组的命令sudo usermod -aG dialout $USER执行完这个命令要注销重新登录才生效。这个步骤在做 PX4 飞控开发时官方文档里也有属于基础中的基础。目录结构方面无人机工程里常见的几个目录要心里有数/opt很多第三方工具链、SDK 装在这比如 Xilinx 的 Vitis、PetaLinux 默认路径/usr/local自己编译安装的软件默认前缀交叉编译工具链装这里很常见/etc系统配置文件所在地比如设置网络、环境变量全局生效的地方/var/log日志文件排查系统崩溃和驱动问题先看这里3.2 常用命令不是让你背是让你形成肌肉记忆网上“Linux 常用命令大全”一搜一大把但碎片化学习效率太低。我建议按照无人机软件开发的真实工作流来掌握命令跟着流程用几次自然就记住了。流程一源码获取与版本管理git clone https://github.com/PX4/PX4-Autopilot.git git branch -a # 查看所有分支 git checkout v1.13.2 # 切换到指定版本 git log --oneline -5 # 看最近提交记录无人机项目非常吃版本一致性。上游代码天天变今天能编译通过明天可能就报错。养成查看 commit、锁定版本的好习惯。流程二编译与排查make px4_sitl_default # 编译 PX4 仿真固件 make px4_fmu-v5 # 交叉编译 Pixhawk V5 硬件固件编译报错时不要只看最后几行。要用make px4_sitl_default 21 | tee build.log把完整输出存到文件里然后去中间找第一个error。第一个错误往往是根因后面的都是连锁反应。流程三日志查看与调试dmesg | tail -20 # 查看内核输出的最新日志USB 设备插拔信息在这 journalctl -u 服务名 # 查看系统服务的详细日志 tail -f ~/catkin_ws/logs/*.log # 实时跟踪日志输出我做地面站开发时排查串口通信问题全靠dmesg。设备插上去有没有被识别、驱动加载有没有报错一目了然。流程四进程管理与资源监控ps aux | grep ros # 查看 ROS 相关进程 htop # 实时监控 CPU 和内存占用 nvidia-smi # 如果机载电脑有 GPU看 GPU 占用无人机是资源受限系统机载电脑性能有限。为了跑视觉算法必须时刻关注 CPU 占用和内存余量。哪个进程吃资源用top一看便知。3.3 环境变量与 Shell 脚本让工程自动化环境变量是 Linux 工程里绕不开的环节。很多无人机 SDK 安装完后都需要把工具链路径加入环境变量否则终端找不到命令。你需要在~/.bashrc文件里加的内容典型的像这样export PATH/opt/xilinx/Vitis/2021.2/bin:$PATH export LD_LIBRARY_PATH/usr/local/lib:$LD_LIBRARY_PATH source /opt/ros/noetic/setup.bash修改完执行source ~/.bashrc生效。这里解释一个关键点$PATH里多个路径用冒号隔开系统是按顺序从前到后查找命令的。如果你把自定义路径放在前面会优先用你的版本这在需要覆盖系统自带工具时很有用但也要小心版本冲突。Shell 脚本是提升效率的利器。我带项目时习惯把整个编译流程封装成一个build.sh#!/bin/bash set -e # 任何命令出错立即退出 echo 开始编译无人机固件 cd ~/PX4-Autopilot make px4_fmu-v5 echo 编译完成准备打包 # 后续可以自动拷贝生成的固件到指定目录 cp build/px4_fmu-v5_default/px4_fmu-v5_default.px4 ~/firmware_output/脚本里那个set -e特别重要。没有它脚本前面出错了还会继续往下执行可能把错误的固件当成成功产物打包后面刷机就出大问题。4. 深度拆解Ubuntu 20.04 安装 PetaLinux 与 Zynq-7000 交叉编译工具链4.1 交叉编译到底是个什么概念开始实操之前先花两分钟把交叉编译这件事讲透。你在自己的电脑上编译程序编译出来的可执行文件直接在本机运行这叫本地编译。但无人机上的机载电脑通常是 ARM 架构而你开发用的 PC 一般是 x86 架构。x86 上编译出的程序ARM 芯片根本跑不了反过来也一样。那怎么办我们要在 PC 上安装一个能生成 ARM 指令的工具链编译出来的程序虽然跑在 PC 上会报“无法执行二进制文件”但拷贝到 ARM 设备上就能正常运行。这个过程就叫交叉编译。生活化类比你在中国写了一份英文说明书寄到美国给当地人看。你写的时候用的是中文思维但输出的是英文。交叉编译工具链就是那个“把中文转换成英文”的翻译官。4.2 准备工作与依赖安装PetaLinux 是 Xilinx 推出的嵌入式 Linux 开发套件专门用来配置、编译、打包 Zynq SoC 上的 Linux 系统。它和 Ubuntu 20.04 的兼容性搭配很成熟。安装前需要准备Ubuntu 20.04.3 或更新的 20.04.x 版本至少 100GB 磁盘空闲空间实际我建议留 150GB8GB 以上内存16GB 更舒服稳定的网络因为要下载大量依赖包先更新系统并安装基础依赖sudo apt update sudo apt install -y git-core diffstat unzip texinfo gcc-multilib \ build-essential chrpath socat libsdl1.2-dev xterm python3 \ python3-pip python3-venv locales这串命令里texinfo是用来编译文档的chrpath用来修改可执行文件的库路径socat用于串口网络转发。每个包都有它存在的意义不是随便凑的少了哪个到后面都会报错。还要配置默认 shell。PetaLinux 要求/bin/sh指向bash但 Ubuntu 默认可能指向dash。检查方法ls -l /bin/sh如果看到输出是dash就执行sudo dpkg-reconfigure dash弹出的界面选“No”这样/bin/sh就切换到 bash 了。这个细节不注意PetaLinux 的脚本很容易在中途意外退出。4.3 PetaLinux 安装步骤我用的是 PetaLinux 2021.2 版本和 Ubuntu 20.04 的搭配很成熟。下载安装包后放在一个专门目录比如~/petalinux_install。然后运行安装器cd ~/petalinux_install ./petalinux-v2021.2-final-installer.run安装器会先检查系统环境然后询问安装路径。我建议装到/opt/petalinux/2021.2保证所有用户都能访问。安装过程中会提示你接受许可协议按步骤走就行。整个安装可能需要 20-40 分钟取决于磁盘速度。安装完成后设置环境变量。每次开新终端都要执行source /opt/petalinux/2021.2/settings.sh为了方便可以把这行加到~/.bashrc末尾。验证安装是否成功petalinux-util --version能输出版本号就说明装好了。4.4 Zynq-7000 交叉编译工具链从源码到可执行文件PetaLinux 内部自带交叉编译工具链我们在工程里编译裸机程序或 Linux 应用时会直接用到。手动装一份独立的交叉编译工具链也很有必要特别是做裸机开发或者独立应用时。以 ARM 32 位 Cortex-A9Zynq-7000 用的核为例常用的工具链是gcc-arm-linux-gnueabihf。Ubuntu 20.04 源里直接有安装很简单sudo apt install -y gcc-arm-linux-gnueabihf验证工具链arm-linux-gnueabihf-gcc --version写个最简单的测试程序#include stdio.h int main(int argc, char *argv[]) { printf(Hello from Zynq-7000!\n); return 0; }编译arm-linux-gnueabihf-gcc hello.c -o hello_arm用file命令查看生成文件的格式file hello_arm你会看到类似输出ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV)。看到ARM字样就说明交叉编译成功了。把这个文件拷贝到 ARM 板上加执行权限后就能运行chmod x hello_arm ./hello_arm这里我要提醒一个新手最容易犯的错误在 PC 上直接执行./hello_arm会出现 “cannot execute binary file: Exec format error”。这不是你编译错了而是架构不匹配的正常表现别慌。4.5 交叉编译工具链与 PetaLinux 的配合实际无人机工程开发中PetaLinux 负责整个系统的构建包括内核、设备树、根文件系统你通常不需要手动编译内核。但当你需要编写跑在 Zynq 上的应用程序时交叉编译工具链就派上用场了。推荐的工作流是这样的在 PetaLinux 工程目录下用petalinux-create -t apps --name my_drone_app创建一个应用模板编辑源码文件my_drone_app.c修改my_drone_app.bb文件描述应用的编译方式和安装路径用petalinux-build -c my_drone_app单独编译这个应用用petalinux-package --boot --fsbl ... --fpga ... --u-boot ...打包整个启动镜像将生成的BOOT.BIN和image.ub拷贝到 SD 卡启动板子这一步一步看下来你就明白为什么 Module 3 要花这么大力气讲 Linux 工程基础了。整个流程全是 Linux 命令行操作、环境变量配置、脚本编译不熟悉 Linux 根本进行不下去。5. 实操过程从零搭建一个完整的无人机软件开发环境5.1 系统基础配置与中文化装好 Ubuntu 20.04 后建议按下面的顺序逐项配置做成一份自己的“环境搭建清单”。先处理软件源。默认的源在国外下载速度感人。换成国内镜像源后apt速度能快好几倍。修改源文件sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i s/archive.ubuntu.com/mirrors.aliyun.com/g /etc/apt/sources.list sudo apt update这里备份源文件是必须养成的习惯。改出问题随时能恢复。中文输入法方面Ubuntu 20.04 自带的中文输入支持一般。我习惯装搜狗输入法 Linux 版但要经历安装依赖、配置 fcitx、注销重登这几个步骤。如果觉得折腾直接用系统自带的中文拼音输入法也够用没必要在输入法上花太多时间。做开发多打字的场景反而不多。5.2 开发目录规划与工程管理无人机项目文件多、环境依赖重建议在 Linux 下切分清晰的工作目录。我的目录规划仅供参考~/workspace/ ├── drone_sdk/ # 飞控 SDKPX4/ArduPilot ├── ros_ws/ # ROS 工作空间存放各功能包 ├── zynq/ # Zynq-7000 相关工程 │ └── petalinux_prj/ ├── tools/ # 自定义工具脚本 └── logs/ # 编译日志、运行日志归档创建完目录后给每个目录写个简单的README.md标注这个目录放什么、如何编译、坑是什么。几个月后你回来看会感谢自己这个习惯。5.3 ROS Noetic 安装与配置虽然 PetaLinux 那套环境已经够复杂了但无人机软件开发基本离不开 ROS。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-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654 # 更新并安装完整版 ROS sudo apt update sudo apt install -y ros-noetic-desktop-full # 初始化 rosdep sudo rosdep init rosdep update # 配置环境变量 echo source /opt/ros/noetic/setup.bash ~/.bashrc source ~/.bashrc # 安装构建工具 sudo apt install -y python3-rosdep python3-rosinstall python3-rosinstall-generator python3-wstool build-essentialROS 生态里catkin或colcon工作空间是核心。创建常规工作空间mkdir -p ~/ros_ws/src cd ~/ros_ws catkin_make第一次运行catkin_make会输出一堆信息看到built 100 packages之类的总结就说明环境 OK 了。ROS 的调试也是一个重点。rostopic echo /mavros/state可以查看飞控状态rqt_graph可以可视化节点间的通信关系rosnode list可以列出所有在运行的节点。如果你连不上飞控先用这些命令检查 MAVROS 节点是否正常发布消息。5.4 串口与设备权限配置无人机开发绕不开串口设备。飞控通过 USB 转串口连接电脑默认设备名是/dev/ttyUSB0或/dev/ttyACM0。插上飞控后先检查设备是否被识别dmesg | grep tty ls -l /dev/ttyUSB*前面提过把用户加入dialout组后重启会话即可免 sudo 访问串口。这一条务必做掉避免后面每次都要 sudo 运行程序。有些飞控板比如 Pixhawk 系列可能识别为/dev/ttyACM0而不是/dev/ttyUSB0。两者区别在于 USB CDC 协议实现方式不同对开发来说一样用只是在配置 MAVROS 时别填错设备路径。设备拔插后设备名可能变化比如/dev/ttyUSB0变成/dev/ttyUSB1。这在多设备同时工作时很容易搞混。解决办法是通过udev规则给设备绑定固定别名详细做法后面单独讲。5.5 编译工具链的验证与测试环境和工具链都装好后做一次端到端验证确认链路畅通。我习惯写个完整的测试流程。验证本地编译gcc --version cmake --version make --version验证交叉编译arm-linux-gnueabihf-gcc --version写个多文件小工程用 CMake 构建一次确保 CMake 能找到交叉编译链。toolchain.cmake示例set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g)用这个工具链文件构建时指定路径cmake -DCMAKE_TOOLCHAIN_FILEtoolchain.cmake .. make交叉编译产物能正常生成说明你这套环境基本合格了。这个时候再去搞 Linux 驱动、BSP、ROS 功能包心里才踏实。6. 常见问题与排查技巧实录6.1 虚拟机网络不通VMware 里装完 Ubuntu 20.04最常见的问题就是上不了网。原因多半是网络适配器模式没选对。排查步骤检查 VMware 虚拟网络编辑器里的 NAT 模式是否启用在 Ubuntu 里执行ip addr看有没有拿到 IP 地址如果网络接口是ens33等但没有 IP尝试sudo dhclient ens33手动请求 DHCP 分配地址如果成功说明是 NetworkManager 的问题可能要用nmcli重新配置。另一个大招是用桥接模式。桥接模式下虚拟机直接走物理网卡的网络比较稳定但 IP 可能和宿主机一个网段要注意 IP 冲突。6.2 PetaLinux 安装时报依赖错误安装 PetaLinux 时最常见的是缺少某个.so库或者某个工具没装。解决方案很简单回到 4.2 节的依赖列表逐条核对。我遇到过的一个典型报错是chrpath未安装。用apt装上即可。还有一个是libsdl1.2-dev很多精简安装的 Ubuntu 都没有。这种依赖问题属于“装一次就不会再犯”的坑做完记录下次就快了。6.3 交叉编译后程序在 ARM 板上无法运行程序拷贝到 ARM 板上后报/bin/sh: ./hello: not found很多人第一反应是文件没拷贝对。其实大概率是动态链接库不匹配。用arm-linux-gnueabihf-readelf查看依赖arm-linux-gnueabihf-readelf -d hello_arm | grep NEEDED输出里如果出现libc.so.6而 ARM 板系统用的是不同版本的库就会出问题。解决思路尽量用静态编译arm-linux-gnueabihf-gcc hello.c -o hello_arm_static -static或者把板子上对应的库版本补全最省事的方法是让 PetaLinux 构建的根文件系统包含编译时用的库这样版本一定一致6.4 ROS 节点启动失败roscore起不来多半是环境变量没配对或者 11311 端口被占用。检查env | grep ROS看ROS_MASTER_URI是否指向http://localhost:11311。端口被占用时用ss -tlnp | grep 11311找到占用进程杀掉或改 ROS master 端口。如果是在虚拟机里跑 ROS宿主机的防火墙也可能拦截节点间通信。要么关掉宿主机防火墙要么把 ROS 的通信端口加入白名单。6.5 设备权限反复出问题加进dialout组了重启还是访问不了串口。这种情况可能是用户组缓存问题注销重登不行就彻底重启。还遇到过udev规则冲突的两个规则同时给同一个设备设了不同权限。这时候要排查/etc/udev/rules.d/目录下的规则文件找到冲突项删掉一个或调整优先级。我个人的做法是写一个清晰的udev规则给飞控设备固定别名并设置权限例如SUBSYSTEMtty, ATTRS{idVendor}0483, ATTRS{idProduct}5740, MODE0666, SYMLINKflight_controller插上飞控后设备就会以/dev/flight_controller出现不会因为插拔顺序改变设备名写脚本和配置文件时省心太多。6.6 常见问题速查表现象可能原因解决方法apt update很慢源在国外换国内镜像源交叉编译程序无法执行在 PC 上直接运行 ARM 程序拷贝到 ARM 板上执行/dev/ttyUSB0权限不足用户不在 dialout 组sudo usermod -aG dialout $USERVMware 虚拟机无法上网网络适配器模式问题改为 NAT 或桥接模式make报错信息很长第一行错误才是根因重定向日志后找第一个errorbash脚本运行到一半退出缺少set -e导致错误被忽略脚本开头加set -ePetaLinux 安装中断依赖缺失按依赖清单逐条核对ROS 启动后节点间通信失败防火墙/ROS_MASTER_URI 配置错误检查 env7. 经验心得环境工程能力比算法更稀缺模块带到第三期我越发觉得环境工程能力才是无人机开发中最稀缺的软实力。算法可以从论文里学框架可以从文档里看但把一套复杂环境从头到尾搭建流畅、出了问题能系统排查这个能力必须在一线项目中反复磨。说一个我自己的经历。前年做一个基于 Zynq 的视觉无人机原型要同时改 FPGA 逻辑、跑 Linux 系统、调飞控接口。前面两周全耗在环境上PetaLinux 构建失败、交叉编译库不匹配、串口权限不对、ROS 版本冲突。等项目真正跑起来我对整条链路的理解完全不一样了。后来我总结那些在“环境搭建”阶段就崩溃放弃的人不是不适合做开发而是缺少一个靠谱的 Linux 工程基础。所以 Module 3 这门课的定位从来不是“教你几条命令”而是用无人机软件开发这个具体场景把 Linux 工程能力训练到位。命令是死的场景是活的。你今天在无人机项目里学会了排查串口问题、配置交叉编译环境、管理进程和日志明天换到自动驾驶、机器人、边缘计算这些能力一样通吃。最后再分享一个小技巧。我习惯把自己的环境搭建过程全部记下来从装系统开始每个命令、每个报错、每个解决办法写成一篇带目录的 Markdown 笔记。当时觉得啰嗦后来团队来新人这份笔记直接变成 onboarding 文档学习成本直接减半。做环境工程的人最值得投资的就是这种能复用的、写下来的经验资产。