企业官网建设流程全解析

我做了近十年的无人机飞控与嵌入式开发，带过不少新人，也帮很多团队搭过开发环境。几乎每个从 Windows 切过来的同事，前两周都会在 Ubuntu 上栽跟头——不是装错依赖，就是编译工具链版本对不上，折腾一整天最后发现是 PATH 没配好。这篇文章就把 Module 3 里关于 Ubuntu 20.04 和 Linux 工程基础这部分彻底讲透，从磁盘分区到交叉编译，从 ROS 环境到串口权限，全是我实际跑过的流程，直接照着抄就行。

这篇文章适合谁？零基础但准备入行无人机软件开发的在校生，刚入职被分配了“搭环境”任务的嵌入式新人，以及想把手头的 Zynq、STM32、树莓派开发环境迁移到 Ubuntu 20.04 的工程师。核心就解决一件事：让 Linux 不再是你的开发瓶颈，而是你手里的趁手工具。

1. 环境选型与整体设计思路

1.1 为什么一定是 Ubuntu 20.04

先说结论：无人机相关的开源生态，目前兼容性最稳的 LTS 版本就是 20.04。这个版本对应的 ROS 发行版是 Noetic，而 Noetic 是 ROS 1 的最后一个长期支持版本，官方支持到 2025 年。很多飞控团队（尤其是基于 PX4 和 APM 的）到现在还在用 18.04 或 20.04 作为标准开发环境，不是因为懒，而是因为大量的依赖库、编译脚本、仿真工具都是在这两个版本上验证过的。

拿我之前带的一个项目举例，我们在一台 Ubuntu 22.04 的机器上编译 PX4 固件，gcc 版本和 Python 依赖链总是出小问题，虽然最终也能绕过去，但每次都要额外处理好几个 warning。而同样的代码在 20.04 上跑，一套脚本下来干干净净。开发环境这件事，稳定性比版本新更重要。如果你没有特殊需求非要上 22.04，就老老实实 20.04。

1.2 双系统还是虚拟机

这个选择题几乎每个入门者都会遇到。我的答案是：如果你要做飞控固件编译、交叉编译、串口连接真实飞控板，直接装双系统；如果只是在学习 Linux 命令、写写 Python 脚本、跑跑 Offboard 仿真，虚拟机或者 WSL 也能凑合。

为什么这么说？虚拟机的问题在于 USB 设备透传和性能损耗。虽然 VMware 和 VirtualBox 都支持 USB 直通，但偶尔会出现串口识别不稳定或者带宽不够的情况。而无人机开发中，串口和 USB 转串口是你的生命线，连接 Pixhawk、连接 GPS、连接数传模块，任何一步中断都可能导致误判硬件问题。另外交叉编译大型工程时，虚拟机的磁盘 I/O 瓶颈会非常明显，编译时间可能拉长 30% 以上。

当然，双系统也有代价：来回重启切换不方便。我个人的解决方案是一台高性能笔记本装双系统，工作区放一个移动硬盘专门放代码仓库，两个系统都挂载同一个仓库目录。这样 Windows 上开会议、写文档，Ubuntu 里跑编译、刷固件，互不干扰。

2. 磁盘分区与系统初始化实操

2.1 磁盘分区方案与交换分区大小计算

装双系统最容易忽略的坑就是分区。很多人图省事，装 Ubuntu 时选“清除整个磁盘”，结果 Windows 也没了。正确做法是在 Windows 的磁盘管理里先压缩卷，腾出空闲空间，然后在 Ubuntu 安装时选择“手动分区”，使用空闲空间创建分区。

推荐的分区方案如下（以 512GB SSD 为例）：

交换分区大小有个简单经验公式：内存小于 8GB 时，swap 设为内存的 2 倍；内存 16GB 及以上，swap 16GB 就够了。我笔记本是 16GB 内存，配 16GB swap，编译大型项目时偶尔内存吃紧也能撑住。如果你打算跑 Gazebo 仿真加上编译同时进行，建议 swap 再加大 8GB，别省这个空间。

2.2 系统安装后的基础配置清单

系统装好后，先别急着装 ROS，按这个顺序把基础层处理干净。

# 更新软件源并升级所有包 sudo apt update && sudo apt upgrade -y # 安装常用开发工具 sudo apt install -y build-essential cmake git vim curl wget \ net-tools openssh-server htop terminator # 安装 Python 开发环境（20.04 自带 Python 3.8） sudo apt install -y python3-pip python3-dev python3-venv # 配置 pip 使用国内镜像（大幅提升安装速度） pip3 config set global.index-url https://mirrors.aliyun.com/pypi/simple/

这里有个很多人忽略的细节：默认的 bash 提示符太朴素，建议安装terminator作为终端工具，支持分屏操作。无人机开发时经常要同时打开四个终端——一个看串口日志、一个编代码、一个跑仿真、一个监控系统资源，分屏终端能省掉一半的窗口切换时间。

另外，一定改掉默认的软件源。Ubuntu 20.04 默认的 archive.ubuntu.com 在国内下载速度非常慢，装 ROS 和 PetaLinux 的时候动辄几个 GB 的依赖包，速度慢真的会让人崩溃。换源的操作很简单，直接把/etc/apt/sources.list里的archive.ubuntu.com替换成mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn，然后sudo apt update即可。

2.3 显卡驱动与 CUDA 环境选配

如果你要做目标检测、视觉 SLAM、或者用 GPU 跑仿真，NVIDIA 驱动必须第一时间弄好。Ubuntu 20.04 安装 NVIDIA 驱动最简单的办法是图形界面里“软件和更新”->“附加驱动”里选择一个 recommended 版本，然后重启。

注意一个非常容易踩的坑：不要从 NVIDIA 官网下载.run文件手动安装，尤其是在已经装了开源驱动 nouveau 的情况下。手动安装驱动和系统里已有的库很容易冲突，轻则分辨率异常，重则开机黑屏进不了桌面。如果真的不小心进了黑屏状态，重启时长按 Shift 进 recovery 模式，选择 root shell，执行：

# 卸载所有 nvidia 相关包 sudo apt purge nvidia-* sudo apt autoremove # 如果手动装过 .run 驱动，需要先清理 sudo nvidia-uninstall

然后再回到图形界面重新选择驱动。CUDA 的安装建议直接用sudo apt install nvidia-cuda-toolkit，Ubuntu 20.04 自带的版本虽然不算最新，但稳定性足够满足大部分无人机视觉项目。

3. 交叉编译工具链搭建

3.1 为什么无人机开发绕不开交叉编译

交叉编译这个概念对刚入门的人来说有点绕——不就是 Linux 上的 C/C++ 编译吗？为什么还要单独搭一套工具链？这里用一个实际场景解释你就明白了。

我们常用的飞控板，比如 Pixhawk 系列，上面跑的是 ARM Cortex-M4 或者 Cortex-M7 处理器。你的开发机是 x86 架构的 Intel/AMD CPU，两种 CPU 的机器指令完全不通用。你在电脑上编译出可执行文件，直接传到飞控板上是跑不起来的。交叉编译工具链就是让 x86 的开发机能生成 ARM 指令集可执行文件的整套工具。

换句话说，交叉编译的本质是“在一种架构的机器上，编译出另一种架构能运行的程序”。理解了这一点，下面这些工具链的用途就很清晰了。

3.2 为 Zynq-7000 搭建 PetaLinux 编译环境

标题里特别提到了 PetaLinux，这是 Xilinx（现在的 AMD）官方提供的嵌入式 Linux 开发套件，专门用于 Zynq SoC 平台。无人机里用 Zynq-7000 的场景很典型：一边用 ARM 核跑 Linux 做上层图像处理、通信协议，一边用 FPGA 逻辑做实时性要求高的传感器接口和电机控制。

PetaLinux 对宿主机的系统版本要求极其严格。我记得 2020.2 版本开始官方只支持 Ubuntu 18.04 和 20.04，而且要求 bash 作为默认 shell，要求/bin/sh指向 bash 而不是 dash。很多人在这一卡就是一天。设置默认 shell 为 bash 的命令：

# 设置 bash 为默认 shell sudo dpkg-reconfigure dash # 选择 No，保持 /bin/sh 指向 bash

安装 PetaLinux 之前，还需要安装一堆依赖库。下面这个清单是我在干净系统上验证过的：

sudo apt install -y gcc git make net-tools libncurses5-dev \ libncursesw5-dev libssl-dev libelf-dev libtool autoconf \ automake diffstat chrpath socat xterm python3 python3-pip \ python3-setuptools python3-venv python3-wheel \ zlib1g-dev g++ g++-multilib libgmp-dev libmpc-dev \ libusb-1.0-0 libtinfo5 libc6-dev-i386 \ gawk flex bison texinfo file unzip graphviz # 如果系统提示缺少 libtinfo5（20.04 默认只有 libtinfo6） # 需要从旧版本源手动安装 wget http://archive.ubuntu.com/ubuntu/pool/universe/n/ncurses/libtinfo5_6.3-2ubuntu1_amd64.deb sudo dpkg -i libtinfo5_6.3-2ubuntu1_amd64.deb

安装完成后，把 PetaLinux 安装包解压到/opt或者~/tools目录，执行安装脚本。安装结束后一定要 source 一下环境变量：

# 假设安装到 ~/tools/PetaLinux source ~/tools/PetaLinux/settings.sh

测试环境是否正常，可以用petalinux-util --version查看版本号。接下来进入工程目录创建一个新的 PetaLinux 项目：

# 创建一个名为 drone_zynq 的工程 petalinux-create -t project --name drone_zynq cd drone_zynq # 导入硬件描述文件（从 Vitis 导出的 XSA 文件） petalinux-config --get-hw-description=/path/to/hardware.xsa # 构建完整镜像 petalinux-build

构建完成后生成的 BOOT.BIN、image.ub 和 boot.scr 就在images/linux目录下，这些就是要烧写到 SD 卡里的东西。

PetaLinux 编译时最大概率出的问题就是网络。它的构建系统要从网上下载大量的源码包，如果网络不稳定，经常会在某一个包下载时报错。解决方法是提前把下载缓存目录配好，或者用代理。但这里不展开，后面问题排查里我会给出更具体的方案。

3.3 面向 PX4 飞控的 ARM 交叉编译工具链

除了 Zynq 这种高端平台，绝大多数无人机项目用的还是 Pixhawk 这类通用飞控。PX4 固件的交叉编译通常不需要你手动装 ARM 工具链，因为 PX4 的构建脚本会自己处理。但了解底层是什么，能帮你排查各种诡异问题。

PX4 在 Ubuntu 20.04 上用的工具链主要是gcc-arm-none-eabi，这个可以从 ARM 官网或 PX4 官方脚本里安装。手动安装也很简单，用 PX4 官方提供的一键脚本最快：

git clone https://github.com/PX4/PX4-Autopilot.git --recursive cd PX4-Autopilot ./Tools/setup/ubuntu.sh

这个脚本会把你系统里折腾 ROS、Gazebo、交叉编译依赖一口气装好。但我要提醒一句：这个脚本可能会改你系统里已有的 Python 包，如果之前配过什么深度学习环境，最好还是手动装。手动装的话，核心就三步：

# 1. 安装 ARM 编译器 sudo apt install gcc-arm-none-eabi # 2. 安装 ninja 构建系统 sudo apt install ninja-build # 3. 安装 PX4 的 Python 依赖 pip3 install --user kconfiglib pyros-genmsg empy

然后测试编译固件：

cd PX4-Autopilot make px4_fmu-v5_default

第一次编译会下载很多子模块，时间比较长，耐心等。编译完成后在build/px4_fmu-v5_default目录下找到px4_fmu-v5_default.px4固件文件，这个就是可以烧录到 Pixhawk 4 的固件。

3.4 工具链验证与 PATH 配置的避坑细节

交叉编译工具链装好之后，不是能用就完事了，一定要花两分钟验证一下环境。

# 查看 ARM 编译器版本 arm-none-eabi-gcc --version # 查看交叉编译器的搜索路径 arm-none-eabi-gcc -print-search-dirs

然后写一个最小的 C 程序测试一下能不能正确生成 ARM 指令的二进制：

// test.c int add(int a, int b) { return a + b; }

arm-none-eabi-gcc -c test.c -o test.o file test.o

如果file命令输出里包含ARM字样，说明交叉编译链已经正常工作。如果输出的是x86-64，说明调用的不是交叉编译器，而是本机的 gcc，这时要检查 PATH 环境变量是不是被覆盖了。

PATH 配置是新人最容易翻车的地方。比如你手动安装了 ARM 工具链到/opt/gcc-arm-none-eabi/bin，但系统里的/usr/bin里有同名的arm-none-eabi-gcc，那执行命令时系统会先找到/usr/bin下的版本。验证当前使用的是哪个：加which arm-none-eabi-gcc。

建议把交叉编译器的路径写进~/.bashrc，并放在export PATH的最前面：

export PATH=/opt/gcc-arm-none-eabi/bin:$PATH

写完之后source ~/.bashrc，再用which确认。这个细节决定了你编译出来的东西能不能在硬件上跑，真的重要。

4. 无人机软件开发的关键依赖与中间件

4.1 MAVLink 协议栈与消息定义

无人机软件开发的另一个核心基础是通信协议。地面站、机载电脑和飞控之间怎么对话？靠的就是 MAVLink——一个专门为微型飞行器设计的轻量级通信协议。MAVLink 的消息格式非常紧凑，每帧数据只有 8 到 12 字节开销，非常适合在数传带宽有限的条件下传输。

MAVLink 的代码是生成出来的，不是手写的。它先定义了一套 XML 格式的消息标准（存放在mavlink/message_definitions目录），然后通过代码生成器生成对应语言（C、C++、Python 等）的库。我们在 Ubuntu 20.04 上用 Python 开发机载程序时，通常用pymavlink：

pip3 install pymavlink

一个最简单的读取飞控姿态信息的 Python 脚本：

from pymavlink import mavutil # 连接飞控串口（注意改成你自己的串口设备） master = mavutil.mavlink_connection('/dev/ttyUSB0', baud=115200) # 等待第一个心跳信号 master.wait_heartbeat() print("收到心跳，飞控连接正常") # 请求所有数据流 master.mav.request_data_stream_send( master.target_system, master.target_component, mavutil.mavlink.MAV_DATA_STREAM_ALL, 10, # 频率 10Hz 1 ) # 循环打印姿态信息 while True: msg = master.recv_match(type='ATTITUDE', blocking=True) print(f"Roll: {msg.roll:.2f}, Pitch: {msg.pitch:.2f}, Yaw: {msg.yaw:.2f}")

这里最常见的坑是串口权限问题。Ubuntu 下普通用户默认没有权限访问/dev/ttyUSB0，运行上面的脚本会报Permission denied。解决办法是把当前用户加入dialout组：

sudo usermod -a -G dialout $USER

然后一定要注销重新登录（或者重启），组权限才会生效。这个坑我见过太多次了，提醒一次就不再多说。

4.2 Ubuntu 20.04 下的串口与 USB 设备管理

无人机开发会用到大量 USB 转串口设备，比如 CP2102、CH340、FTDI 等。每个厂家的芯片对应的驱动内核模块不一样：

当多个设备同时插入时，系统分配的设备名是随机的。比如你今天插的是/dev/ttyUSB0，明天可能变成/dev/ttyUSB1。这对自动化脚本来说是致命的。解决办法是用 udev 规则绑定固定的设备名。

创建文件/etc/udev/rules.d/90-usb-serial.rules：

# CP2102 设备绑定为 /dev/ttyPixhawk SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyPixhawk" # CH340 设备绑定为 /dev/ttyCH340 SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyCH340"

查看设备的 idVendor 和 idProduct 用lsusb命令。配置完成后用sudo udevadm control --reload-rules重载规则，重新插拔设备，/dev/ttyPixhawk这个固定名称就能用了。

4.3 ROS Noetic 安装与工作区初始化

无人机上层应用十有八九绕不开 ROS。Ubuntu 20.04 对应的版本是 ROS Noetic，这也是 ROS 1 的收官之作，生态最成熟，文档最完善。

安装 ROS Noetic 官方给出的步骤，我简化过但流程一致：

# 1. 添加 ROS 软件源 sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list' # 2. 配置密钥 sudo apt install curl curl -s https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | sudo apt-key add - # 3. 更新并安装完整桌面版 sudo apt update sudo apt install ros-noetic-desktop-full # 4. 初始化 rosdep sudo rosdep init rosdep update # 5. 配置环境变量 echo "source /opt/ros/noetic/setup.bash" >> ~/.bashrc source ~/.bashrc

安装过程中 rosdep 是最容易出问题的。rosdep init需要访问 GitHub 上的 raw 文件，这一点在网络环境不好时要折腾很久。我的经验是先测一下网络连通性，如果连不通，可以手动下载ros.asc文件和 rosdep 源列表放到本地。

验证 ROS 环境是否正常，开两个终端，一个跑roscore，一个跑rosnode list。能正常输出节点信息，说明 ROS 核心已就绪。

接着初始化一个 Catkin 工作区：

mkdir -p ~/drone_ws/src cd ~/drone_ws catkin_make

工作区建好后，所有无人机相关的 ROS 包都放在src目录下，编译产物体现在devel和build目录。这里有个新手常问的问题：catkin_make和catkin build有什么区别？catkin_make是老牌工具，简单直接；catkin build是后起之秀，并行编译效率高，但对包的依赖关系要求更严格。PX4 官方文档用的catkin build，我建议从一开始就统一用catkin_make，如果你不打算用 catkin_tools 的高级功能，catkin_make更省心。

5. 仿真环境验证与典型工作流

5.1 Gazebo 与 PX4 Offboard 模式的结合

环境搭建完成不等于万事大吉，真正的验证要放到仿真里跑一遍。无人机开发里最常用的仿真组合是 PX4 + Gazebo + MAVROS。Gazebo 负责模拟物理世界（重力、风、传感器噪声），PX4 跑的是和真机完全一样的固件，MAVROS 充当 ROS 和 PX4 之间的翻译官。

启动仿真的完整流程：

# 终端 1：启动 Gazebo + PX4 SITL 仿真 cd ~/PX4-Autopilot make px4_sitl gazebo # 终端 2：通过 MAVROS 桥接 ROS 和 PX4 roslaunch mavros px4.launch fcu_url:="udp://:14540@127.0.0.1:14557"

终端 2 看到FCU connection established的日志，说明 MAVROS 和 PX4 通信成功。此时再开终端 3，用rostopic echo /mavros/state能看到当前的飞行状态。

一个最简单的 Offboard 模式起飞测试脚本（Python）：

#!/usr/bin/env python3 import rospy from geometry_msgs.msg import PoseStamped from mavros_msgs.msg import State from mavros_msgs.srv import CommandBool, SetMode rospy.init_node('offboard_node') # 等待 MAVROS 服务可用 rospy.wait_for_service('/mavros/cmd/arming') rospy.wait_for_service('/mavros/set_mode') arming = rospy.ServiceProxy('/mavros/cmd/arming', CommandBool) set_mode = rospy.ServiceProxy('/mavros/set_mode', SetMode) # 发布目标位置 pose_pub = rospy.Publisher('/mavros/setpoint_position/local', PoseStamped, queue_size=10) pose = PoseStamped() pose.pose.position.x = 0 pose.pose.position.y = 0 pose.pose.position.z = 2 # 起飞到 2 米高度 rate = rospy.Rate(20) # 先发 10 秒 setpoint，进入 Offboard 模式前的标准流程 for i in range(200): pose_pub.publish(pose) rate.sleep() # 切 Offboard 模式并解锁 set_mode(custom_mode='OFFBOARD') arming(True) rospy.loginfo("Offboard 模式已启动，无人机开始执行任务")

这里有个原则必须记住：先发布 setpoint，再切 Offboard 模式。这是 PX4 的固有保护机制——如果没有持续收到有效的 setpoint，飞控拒绝切入 Offboard 模式。新手第一次写 Offboard 代码经常栽在这里，确认模式切不过去就怀疑飞控坏了，其实只是发布顺序错了。

5.2 地面站与机载电脑的通信链路验证

仿真跑通了，接下来要验证的是真机通信链路。地面站（QGroundControl 或 Mission Planner）通过数传模块和飞控通信，机载电脑（比如树莓派、NVIDIA Jetson）通过 UART 或 USB 和飞控通信。

在 Ubuntu 20.04 上验证链路的最简单方式是用mavproxy.py：

# 通过串口连接飞控 mavproxy.py --master=/dev/ttyPixhawk --baudrate=115200 # 在 MAVProxy 控制台里输入 status 查看连接状态 # 输入 arm throttle 测试解锁（注意螺旋桨移除！）

链路正常后你可以用mavlink-router或MAVSDK把数据同时转发给地面站和机载程序。比如用 MAVSDK-Python 写一个简单的航点飞行程序：

pip3 install mavsdk

import asyncio from mavsdk import System async def run(): drone = System() await drone.connect(system_address="serial:///dev/ttyPixhawk:115200") async for state in drone.core.connection_state(): if state.is_connected: print("飞控已连接") break print("开始起飞") await drone.action.arm() await drone.action.takeoff() await asyncio.sleep(10) print("降落") await drone.action.land() asyncio.run(run())

这里要特别注意串口的波特率。Pixhawk 的 TELEM2 口默认波特率通常是 57600 或 921600，具体要看飞控参数设置。如果你在 QGroundControl 里能连上，但串口脚本连不上，八成是波特率对不上。

5.3 终端分屏与效率工具配置建议

最后推荐一套我日常用的终端效率配置。安装terminator后，右键选择“水平分割”或“垂直分割”，可以把一个窗口切成多个终端。我的习惯是左侧跑编译和代码编辑，右侧分上下两格，上方跑串口日志，下方跑系统监控。

系统监控用htop关注 CPU 和内存占用。编译大型工程时如果内存接近满载，立即用free -h确认 swap 是否正常使用。另外强烈建议配置 ssh 无密码登录，方便从 Windows 远程连到 Ubuntu 开发机：

# 在开发机上生成密钥 ssh-keygen -t rsa -b 4096 # 将公钥复制到需要远程登录的机器 ssh-copy-id 用户名@目标主机IP

6. 常见问题与排查技巧实录

6.1 环境类问题速查表

整个 Module 3 的实操过程中，我整理了一份高频问题速查表，基本可以覆盖 90% 的踩坑场景：

6.2 PetaLinux 与交叉编译的专项坑

PetaLinux 的坑值得单独写一节，因为它足够折磨人。我遇到最经典的一个问题：执行petalinux-build时提示/bin/sh: 1: dash: not found或者大量奇怪的语法错误。这个问题的根源在于 Ubuntu 的/bin/sh默认指向dash，而 PetaLinux 的构建脚本要求/bin/sh是bash。解决方法前面已经提过，但这里再强调一次：

sudo dpkg-reconfigure dash # 选择 No

如果这个问题已经导致 PetaLinux 安装半途失败，不要原地重试，直接把安装目录删掉重新解压一遍，否则残留文件会让你疯掉。

还有一个和磁盘空间相关的坑。PetaLinux 构建过程中会产生大量的临时文件，一个默认配置的工程构建一次大约需要 10-20GB 空间。如果根分区只有 50GB，很容易在构建到一半的时候报No space left on device。建议确保根分区至少预留 30GB 剩余空间，并且不要和/home放在同一个分区导致碎片化问题。

6.3 串口工具选择与日志分析技巧

排查通信问题时，串口工具的选择能帮你省下大量时间。minicom是老牌工具，稳定但配置稍麻烦；screen轻量但功能有限；我更推荐picocom，配置简单，退出快捷键好记（Ctrl+A Ctrl+X）。

# 安装 picocom sudo apt install picocom # 连接串口查看飞控日志 picocom -b 115200 /dev/ttyPixhawk

连接上去后你会看到飞控持续输出 NuttShell 或者 MAVLink 调试信息。这里有个细节：飞控在正常运行时不一定会主动输出日志，需要按回车或发送特定命令。PX4 启动时通常会有 NuttShell 的提示符nsh>，这时候输入top可以查看系统资源占用，输入listener可以查看指定 uORB 主题的实时数据。

6.4 网络与下载问题的通用解法

Ubuntu 20.04 环境下很多工具链安装都要从 GitHub 拉取源码，网络问题几乎是每个人都要面对的。我总结了几种可用的应对手段：

• 使用ghproxy这类 GitHub 加速代理，把git clone地址的github.com前缀替换成代理地址前缀。
• 配置git使用浅克隆减少下载量：git clone --depth=1。
• 对于大文件（比如 PetaLinux 安装包），用带断点续传的下载工具更稳。
• pip 包一律配镜像源（前面已提到，再强调一遍）。

另外提醒一句：不要轻易尝试在虚拟机里跑 PetaLinux。PetaLinux 构建对 CPU 虚拟化支持有要求，虚拟机里经常出现莫名其妙的编译中断，排查成本极高。物理机上跑一次构建可能 30 分钟，虚拟机里可能折腾一下午也不一定成功。

7. 从环境搭建到工程思维

环境搭建这部分内容，本质上是在帮你建立一套工程方法论。我在带团队的时候发现一个规律：环境搭得快的工程师，后面写代码和排查问题的效率通常也不会差。原因很简单，搭环境的过程就是和系统底层相处和熟悉的过程，你搞清楚了串口、权限、编译器、构建系统之间的关系，写代码时脑海里自然会有清晰的层次感。

以我自己的经验，第一次把 PX4 固件编译成功、烧进飞控板点亮的瞬间，是无人机开发路上最让人有成就感的一刻。而那一刻，往往就来源于一个干净、稳定的 Ubuntu 20.04 环境。希望这篇文章能让你少走一些弯路，把宝贵的精力留给真正的飞行控制算法和机器人应用开发。