企业官网建设流程全解析

上个月团队里来了个新同事，负责飞控软件的移植。发给他的是预装好Ubuntu 20.04的笔记本，结果他开机第一句话是问："这系统能装个桌面助手吗？" 我说可以，但接下来你会花两周时间适应它，然后庆幸无人机这行没有选择Windows当主流开发平台。后来他确实踩了不少坑，但也很快摸清了门道。这个Module 3的内容，就是把我这些年带新人、自己搭环境时沉淀下来的Ubuntu 20.04 + Linux工程基础，围绕无人机软件开发环境重新捋了一遍。如果你正要入门无人机软件，或者刚从Windows切到Linux，这篇文章可以帮你少走很多弯路。

1. 为什么无人机软件工程师要把Ubuntu 20.04当"母语"

1.1 无人机软件栈的Linux基因

很多人以为Linux只是"服务器用的系统"，跟飞机不搭边。但真正走进无人机软件开发环境你会发现，整个软件生态几乎是围着Linux转的。

先说飞控。PX4和ArduPilot这两个最常见的开源飞控，官方文档里的编译环境基本都是Linux优先，PX4的构建脚本make px4_sitl_default在Ubuntu 20.04上直接跑，虽然Windows + Cygwin也能编译，但USB透传、串口权限、实时日志这些环节，Windows下会平白多出一堆兼容性问题。

再说机载电脑。无人机除了飞控，往往还要挂一块负责视觉、导航、目标检测的计算单元，最常见的是Nvidia Jetson系列（Xavier NX、Orin Nano）或者树莓派。这些设备的官方系统镜像，Ubuntu是绝对的主流。就算你用的是预装好的SDK镜像，底层也还是Ubuntu 20.04或者22.04。这意味着你学的每一条Linux命令，都能直接用在目标设备上。

还有地面站和中间件。QGroundControl在Ubuntu下原生支持，ROS/ROS2更不用说，目前最主流的ROS2 Foxy Fitzroy官方支持的就是Ubuntu 20.04。如果你要做集群控制、室内定位、无人机编队，ROS生态里的功能包绝大多数是在Ubuntu上开发和验证的。

所以在这个行当里，Ubuntu 20.04不是一个可选项，而是整个无人机软件栈的"最大公约数"。

1.2 从Windows思维转换到Linux思维

从Windows切过来，最难受的往往不是记命令，而是思维模型的转变。

在Windows里，你习惯C盘、D盘这种盘符；Linux里没有盘符，整个文件系统从一个根目录/出发，你的U盘、硬盘、机载电脑的SD卡，全都挂载在某个目录下，比如/media/username/disk。这个概念叫"挂载"，理解了它，你就理解了为什么ls /media下面偶尔会冒出来一串看不懂的目录名。

第二个要转变的是"命令行优先"的习惯。Windows下你可以全程鼠标操作，但在Linux服务器、嵌入式设备、Docker容器里，很多时候没有图形界面，你只能靠终端。你不需要背几百条命令，但需要形成"遇到问题先想命令"的条件反射。

第三个是权限。Windows的Administrator基本是默认状态，Linux的root是一个需要反复强调安全的概念。日常操作用普通用户，需要提权时用sudo，而不是全程root跑。这一点在无人机开发里尤其重要，因为后面你配置串口、安装工具链、操作设备节点时，如果权限概念混乱，很容易把系统搞坏。

我常用的一个比喻是：Ubuntu 20.04对无人机软件工程师来说，就像木工的工作台。你不需要把工作台装修得多漂亮，但你必须知道每一把工具放在哪、什么时候用哪把、怎么保养它。这篇文章讲的"Linux工程基础"，本质就是给你这张工作台配齐工具并教会你使用规则。

2. 环境选型：双系统、虚拟机还是专用主机

2.1 三种方案的真实对比

很多人一开始纠结一个问题：Ubuntu 20.04到底应该装在虚拟机里，还是直接装成双系统？

我的建议是：取决于你拿它做什么。

我自己现在的组合是：一台Windows笔记本做日常办公，里面用VMware跑着Ubuntu 20.04做代码阅读和轻量编译；另外一台装了纯Ubuntu 20.04的主机，专门用来编译PetaLinux、连接飞控硬件和跑长时间仿真。原因是虚拟机在USB设备透传和磁盘IO上，偶尔会给你使绊子。比如你插上飞控，Windows弹窗提示"设备无法识别"，或者VMware右下角USB图标变成灰色，这种问题查起来特别耗时。而无人机开发恰恰需要频繁插拔USB转串口模块、数传、GPS模组，所以我宁可在物理机上做硬件相关的工作。

如果你刚开始学，我建议先装虚拟机。因为虚拟机可以随便折腾，装坏了、改坏了，一个快照就还原。等你把常用命令练熟了，再考虑在主力机上装双系统，或者买一块独立SSD专门跑Ubuntu。

2.2 虚拟机配置的参考值

如果你选虚拟机路线，资源配置可以参考下面这套：

• CPU：4核以上。编译PX4固件时，make会并行编译，核数越多越快。
• 内存：8GB起步，16GB更稳。ROS仿真和打开多个终端时，8GB有点紧张。
• 虚拟磁盘：建议60GB以上，并且使用"单个文件"模式（VMware里叫"将虚拟磁盘存储为单个文件"），性能比拆分模式好一些。
• 网络：NAT模式足够日常用；如果要在虚拟机里连接局域网里的机载电脑，改成桥接模式更方便。

系统装完后，第一时间安装VMware Tools或者open-vm-tools（命令行执行sudo apt install open-vm-tools-desktop），否则虚拟机的剪贴板共享、窗口自适应分辨率、拖拽文件功能都不可用。这个小步骤很多人忽略，结果用起来奇卡无比。

2.3 独立的Ubuntu主机怎么选

如果走物理机路线，我强烈建议Ubuntu 20.04不要装在老的机械硬盘上，至少要放在SATA SSD上，有条件直接上NVMe。编译PetaLinux这种大型工程时，CPU在算，磁盘在写，IO瓶颈会被放得很大。

另外物理机装Ubuntu，第一件事就是在BIOS里关掉Secure Boot。不然后面装Nvidia显卡驱动、加载内核模块时，很容易因为签名验证失败而黑屏或者加载失败。这两个问题（硬盘性能和Secure Boot）是我见过物理机装Ubuntu翻车最多的两个原因。

3. 装机后的第一轮系统初始化：分区、换源、基础包

3.1 给无人机工程留足空间的分区方案

Ubuntu安装过程中的分区页面，很多人直接选"清除整个磁盘并安装Ubuntu"，图省事。但如果你的电脑打算长期用来开发，我建议手动分区。

我的习惯是分成三块：

• /（根分区）：80GB到120GB。系统、软件、依赖库都装在这里。
• /home：剩下的空间全给/home。你的源代码、下载的固件、PetaLinux工程、数据集，默认都会堆在这里。
• swap：如果你的内存超过16GB，可以设8GB；如果内存只有8GB，swap设成16GB，避免内存不够时编译进程被内核直接杀掉。

为什么单独强调给/home留大空间？因为后面装PetaLinux的时候，光一个工程动辄占20~50GB，加上build缓存，你很快会体会到什么叫"磁盘空间不足"。DFT（磁盘满了）的时候，各种莫名其妙的编译错误都会出现，我先帮你提前排雷。

3.2 换软件源

Ubuntu 20.04自带的是官方源，在国内网络环境下更新速度可能比较感人。装完系统第一件事就是换源。这里说的换源是使用国内开源镜像站的软件源，属于正常的系统配置。

具体做法是编辑/etc/apt/sources.list，把里面的archive.ubuntu.com和security.ubuntu.com替换成镜像站地址。以清华源为例，执行：

sudo sed -i 's@//.*archive.ubuntu.com@//mirrors.tuna.tsinghua.edu.cn@g' /etc/apt/sources.list sudo sed -i 's@//security.ubuntu.com@//mirrors.tuna.tsinghua.edu.cn@g' /etc/apt/sources.list sudo apt update sudo apt upgrade -y

换源后建议把update和upgrade日志看一遍，如果出现公钥错误，多半是密钥过期，按镜像站文档重新拉取公钥即可。这一步做完，后面安装软件包的体验会顺畅非常多。

3.3 无人机开发的基础软件包

换完源，安装下面这一批基础包，基本能覆盖80%的日常开发需求：

sudo apt install -y build-essential git cmake python3 python3-pip \ curl wget vim net-tools openssh-server htop tree bash-completion \ gcc g++ gdb make unzip zip p7zip-full net-tools

说明一下每个包的作用：

• build-essential：包含了gcc、g++、make等编译工具链，C/C++开发的地基。
• git：版本控制，后面拉取PX4、ArduPilot源码必备。
• cmake：跨平台构建工具，很多无人机相关项目（包括ROS功能包）都用CMake组织构建。
• python3-pip：Python包管理，地面站工具、算法脚本都靠它。
• openssh-server：让这台机器可以被SSH远程登录，方便你用笔记本连接办公室的编译服务器或者机载电脑。
• htop：比top更好看的进程监控工具，编译时看CPU占用很直观。

这些包看着多，其实一次性装完也就几分钟，但能避免你后面每装一个工具就卡在依赖缺失上。

4. 终端基本功：无人机开发真正高频的Linux命令清单

4.1 文件和目录操作是每天的肌肉记忆

虽然网上有"Linux常用命令大全"，但我觉得不需要背那么多。你只需要把下面这一组练成肌肉记忆，然后在使用中按需扩展。

# 查看目录和文件 ls -lh # 以易读方式列出文件及大小 ls -a # 显示隐藏文件（.git、.bashrc 等） cd ~/uav_ws/src # 切换目录 pwd # 显示当前路径 # 复制、移动、删除 cp -r config config_backup # 递归复制目录 mv old_name new_name # 重命名/移动 rm -r build # 删除目录（谨慎！） rm -f log.txt # 强制删除文件 # 软链接（相当于Windows的快捷方式） ln -s /dev/ttyUSB0 ~/serial_link

这里想特别说一下rm -rf。它确实是开发中经常用到的，因为清理编译缓存时你要删除整个build目录，格式通常是rm -rf build。但也是我见过新手翻车最多的命令，一个手滑变成rm -rf /或者rm -rf ~，系统就废了。我的建议是：

1. 永远不要在root用户下用rm -rf。
2. 重要的目录删之前，先ls确认路径。
3. 可以考虑给rm加一个保护别名，比如让rm默认进入回收站模式（可用trash-cli工具实现），防呆。

4.2 权限管理决定你能不能操作设备

无人机开发里，你最常碰到的权限问题是：插上USB转串口模块，然后用ls /dev/ttyUSB0能看见设备，但用串口工具连接时报"Permission denied"。

这就是权限问题。Linux里，串口设备属于dialout用户组。你需要把当前用户加入这个组：

sudo usermod -aG dialout $USER sudo usermod -aG plugdev $USER

执行完这两条命令后，一定要注销重新登录，组权限才会生效。

另外，sudo和su的区别也值得理解。sudo是用自己的密码临时提权，执行完回到普通身份，适合日常单个命令；su是切换到root用户，之后所有命令都以root身份执行，容易误操作。在开发机上，我几乎只用sudo，很少直接切root。

4.3 系统资源与进程管理：编译不卡死的秘诀

无人机软件工程免不了编译大型项目，看着终端刷屏是日常。编译过程中最常用的监控命令是htop，可以直观看到CPU核数和占用率。

如果发现编译时内存不足，可以用free -h查看。如果CPU有8核16线程，可以显式指定并行编译参数来加快速度：

make -j$(nproc) # 用全部核心编译 make -j4 # 用4个核心编译（内存不够时更稳）

nproc命令会输出CPU核心数，直接嵌在命令行里非常方便。

进程管理方面，你可能需要杀掉一个卡死的编译进程或者后台进程：

ps aux | grep make # 找到make进程的PID kill -9 PID # 强制结束 pkill make # 按名称批量结束

4.4 网络与远程连接：和机载电脑打交道的基本功

无人机行业经常需要SSH登录到机载电脑（比如Jetson），或者用网线直连飞控调试。网络命令绕不开这几条：

ip addr # 查看IP地址（新系统用这个，ifconfig已逐渐弃用） ping 192.168.1.100 ssh user@192.168.1.100 scp file user@192.168.1.100:/home/user/ # 跨机器拷贝文件

如果你在配置网络的时候碰到DNS问题，比如ping域名报"Temporary failure in name resolution"，多半是DNS解析没配好。Ubuntu 20.04默认用systemd-resolved管理DNS，查询状态用systemd-resolve --status，修改DNS可以通过编辑/etc/systemd/resolved.conf，或者直接改网络管理器的连接配置：

# 修改 /etc/systemd/resolved.conf [Resolve] DNS=223.5.5.5 119.29.29.29

改完执行sudo systemctl restart systemd-resolved生效。这里给的是通用排障步骤，具体以你的网络环境为准。

4.5 压缩与解压的乱码处理

从Windows传给Ubuntu的压缩包，经常会出现文件名乱码，这是编码不一致导致的。如果你碰到"linux 解压文件乱码"的问题，用unzip时可以指定编码：

unzip -O CP936 file.zip # 用GBK编码解压Windows压缩包

或者在安装p7zip-full后用7z处理，兼容性更好。这个小技巧在拿到同事从Windows发来的固件包或参考资料时非常实用。

5. 交叉编译与PetaLinux工具链：嵌入式飞控的核心环节

5.1 什么是交叉编译

先讲个概念。你在PC上写代码，代码要跑在飞控的ARM处理器上。你的PC通常是x86架构，飞控可能是Cortex-A9（Zynq-7000系列）或者Cortex-M4（STM32F4）。x86的编译器和ARM的机器码不通用，所以你需要一个在x86上运行、但能生成ARM机器码的编译器，这个编译过程就叫交叉编译。

我用一个类比：你写了一本中文书，要拿到英语国家出版，需要找一个懂中文和英语的译者，把书翻译成英文。交叉编译里的"译者"就是交叉编译工具链，它读你的C/C++源码，输出目标处理器能直接执行的二进制。

5.2 Ubuntu 20.04下安装常用交叉编译工具链

无人机相关的主流工具链有三类：

Ubuntu 20.04安装这些非常方便：

sudo apt update sudo apt install -y gcc-arm-none-eabi gcc-arm-linux-gnueabihf gcc-aarch64-linux-gnu

装完验证一下版本：

arm-none-eabi-gcc --version arm-linux-gnueabihf-gcc --version aarch64-linux-gnu-gcc --version

验证能正常输出版本信息，说明工具链工作正常。写一个最简单的hello_world.c，用arm-linux-gnueabihf-gcc编译，再用file命令查看输出文件，你会看到类似"ELF 32-bit LSB executable, ARM"的字样，说明交叉编译成功。

5.3 PetaLinux 2021.2在Ubuntu 20.04上的安装要点

如果你接触的是Zynq-7000平台（很多无人机飞控主控、图传模块、视觉处理板都用这颗芯片），那躲不开PetaLinux。PetaLinux是赛灵思（Xilinx/AMD）提供的一整套嵌入式Linux开发工具，用来配置内核、设备树、文件系统并生成启动镜像。它本身依赖大量的库和工具，在Ubuntu 20.04上安装有几个常见的坑。

第一个坑是依赖包缺失。PetaLinux 2021.2要求在Ubuntu 20.04上安装一堆依赖，我整理过一份能跑通的清单：

sudo apt install -y tofrodos iproute2 gawk xvfb gcc git make \ net-tools libncurses5-dev tftpd zlib1g-dev libssl-dev \ flex bison libselinux1 gnupg wget diffstat chrpath socat \ xterm autoconf libtool tar unzip texinfo zlib1g-dev \ gcc-multilib build-essential libsdl1.2-dev libglib2.0-dev \ screen pax gzip cpio python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 \ libegl1-mesa libsdl1.2-dev pylint3

第二个坑是默认的/bin/sh指向dash而不是bash，PetaLinux的某些脚本在dash下会报错。解决办法是重新配置dash：

sudo dpkg-reconfigure dash

在弹出的界面里选择"No"，让系统继续使用bash，或者保持dash也可，取决于你用的PetaLinux版本。实测中PetaLinux 2021.2要求sh指向bash，否则在配置阶段会报"sh is not bash"错误。

第三个坑是libtinfo5缺失。Ubuntu 20.04默认只带libtinfo6，但PetaLinux的某些工具链需要libtinfo5。可以从Ubuntu 18.04的软件源里下载libtinfo5包来安装，或者用apt直接搜索（如果软件源里没有，则手动下载deb包）。装好后再次执行安装脚本，一般就能顺利跑通。

PetaLinux本身的安装流程不复杂，把下载好的.run安装包解压出来，然后执行：

sudo mkdir -p /opt/pkg/petalinux sudo chown $USER:$USER /opt/pkg/petalinux ./petalinux-v2021.2-final-installer.run /opt/pkg/petalinux

安装完成后，每次使用前需要source环境变量。建议在~/.bashrc里加一行：

source /opt/pkg/petalinux/settings.sh

这样每次打开终端就自动加载PetaLinux环境，不用每次手动source。

5.4 Zynq-7000工程的交叉编译工作流

用PetaLinux创建一个Zynq-7000工程，基础的流程是：

# 创建工程 petalinux-create -t project --template zynq --name uav_fw # 进入工程目录 cd uav_fw # 硬件配置（导入XSA硬件描述文件） petalinux-config --get-hw-description=../hw/ # 编译 petalinux-build

编译完成后生成的镜像在images/linux目录下。如果你需要单独的ARM交叉编译环境，PetaLinux也支持生成SDK：

petalinux-build --sdk

生成的SDK里包含完整的交叉编译工具链和系统rootfs，你可以用它来编译独立的应用程序，然后部署到Zynq板子上。整个过程在纯命令行下完成，所以前面花时间练的Linux命令基本功，在这里会成倍回报你。

6. 串口权限与设备管理：连接飞控之前必须解决的问题

6.1 设备节点的识别与权限

USB转串口模块（CH340、CP2102、FT232）、飞控自带USB接口、数传模块，这些设备插到Ubuntu上后，内核会把它映射为一个设备节点，常见的是/dev/ttyUSB0、/dev/ttyACM0或者/dev/ttyS0。

插上设备后，先用dmesg看重最新的内核日志：

dmesg | tail -20

如果看到ch341-uart或者cp210x之类的字样，说明驱动加载成功了，设备节点已经生成。再用ls -l /dev/ttyUSB*确认权限。如果显示crw-rw----、所属组是dialout，说明只要你的用户加入dialout组就能访问。

组加好之后，如果还是提示无权限，或者设备节点不存在，多半是驱动没加载，可以手动加载：

sudo modprobe ch341 sudo modprobe cp210x

这两个是USB转串口最常用的驱动。

6.2 串口调试工具怎么选

连接飞控的串口，我用过几个工具，最推荐的是picocom和screen，因为默认就能用、配置少。

# 安装 sudo apt install -y picocom minicom screen # 连接飞控串口（波特率按设备文档填写） picocom -b 115200 /dev/ttyUSB0

或者用screen：

screen /dev/ttyACM0 115200

退出方式要注意：picocom按Ctrl+A然后Ctrl+X退出；screen按Ctrl+A然后按K，再按Y确认退出。很多人进去了不知道怎么退，直接关终端，会导致串口没有正常释放，下次连接报"Device or resource busy"。

6.3 用udev规则固定设备名

一个很烦的问题是：今天插了飞控，设备是/dev/ttyUSB0，明天插了个数传，飞控又变成了/dev/ttyUSB1，你的脚本和工具链全部要改。解决办法是用udev规则，根据USB设备的ID或序列号，给它固定一个别名。

在/etc/udev/rules.d/下创建一个99-usb-serial.rules文件：

SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyFCU"

其中idVendor和idProduct可以通过lsusb命令查到。比如CH340通常是1a86:7523。写好后执行：

sudo udevadm control --reload-rules sudo udevadm trigger

之后你插上飞控，就会多出一个/dev/ttyFCU节点，无论它是物理插在哪个USB口，设备名都稳定。这个习惯在做无人机地面站对接时特别重要，因为QGroundControl或者你自己的程序里配置的是固定设备路径。

7. 工程目录与版本管理：团队的协作底线

7.1 一套清晰的无人机工程目录结构

环境搭好、命令练熟之后，真正进入项目开发，我强烈建议你先建立一套规范的目录结构，不要什么都丢在~/Download或者/home/xxx/桌面下。

我个人的参考结构是这样的：

~/uav_dev/ ├── src/ # 所有源代码 │ ├── firmware/ # 飞控固件（PX4/ArduPilot） │ ├── ros_ws/ # ROS工作空间 │ └── vcu/ # 视觉计算单元代码 ├── tools/ # 脚本和工具 ├── build/ # 编译输出，不用进git ├── images/ # 固件镜像、系统镜像 ├── docs/ # 文档和参考资料 └── backup/ # 各种备份

PetaLinux的工程我习惯单独放一个目录，比如~/petalinux_workspace，因为一个PetaLinux工程体积非常大，如果塞在src里会让仓库和目录都很臃肿。

7.2 Git不是可选项，是日常命令

版本管理这一块，我遇到过的最大问题不是不会用Git，而是"不愿意用Git"。刚开始单机开发时自己也图省事，代码改完直接覆盖。直到有一次连续调试三天，把一份能稳定运行的姿态解算代码改崩了，git救了我一次之后，我再也没有裸开发过。

无人机软件项目，最少最少要掌握这组Git命令：

git init # 初始化仓库 git clone <repo_url> # 拉取远程仓库 git status # 查看工作区状态 git add . # 添加所有改动 git commit -m "feat: add attitude control" # 提交 git push origin main # 推送到远程 git pull origin main # 拉取更新 git log --oneline # 查看提交历史 git branch feature/x # 创建分支 git checkout feature/x # 切换分支 git merge feature/x # 合并分支

一个容易被忽略的文件是.gitignore。PX4这类大型工程都有自己的.gitignore规则，你的项目里至少要把build/、*.o、*.bin、*.img这类编译产物排除掉，否则仓库会越来越大，clone一次等到怀疑人生。

7.3 CMake快速上手

最后聊一下构建工具。Linux下的C/C++项目，Makefile能写但不利于跨平台和大型项目管理，CMake是目前最主流的选择。下面是一个最小示例：

cmake_minimum_required(VERSION 3.16) project(uav_utils) set(CMAKE_CXX_STANDARD 17) add_executable(imu_reader src/imu_reader.cpp) target_link_libraries(imu_reader pthread)

构建时执行：

mkdir build && cd build cmake .. make -j$(nproc)

很多开源飞控、机载视觉库、ROS功能包都用CMake组织，你不需要成为CMake专家，但至少要能读懂CMakeLists.txt，会改源文件列表和链接库，这件事会在你移植代码时反复用到。

8. 踩坑记录与验收自测清单

8.1 我在这套环境里踩过的真实坑

这部分是我最想分享的，因为很多问题不是看文档能提前知道的，必须花时间踩一遍才有体感。

第一个坑是虚拟机识别不到USB设备。有次我准备在VMware的Ubuntu 20.04里连接飞控，插上USB后Windows能识别，虚拟机里怎么lsusb都看不到。折腾一圈发现是Windows的"VMware USB Arbitration Service"服务没启动。在Windows服务管理器里找到这个服务，设为自动并启动，虚拟机菜单里"可移动设备"才会出现新的USB设备。如果是VMware Workstation，有时还需要重新安装一次VMware Tools。

第二个坑是编译PetaLinux时磁盘空间不足。当时我只给虚拟机分配了40GB磁盘，结果编译到中途直接报错，日志里全是"No space left on device"。后来删了build缓存，又给虚拟磁盘扩容，才勉强跑完。现在我的规则很简单：涉及到PetaLinux的机器，磁盘至少100GB起步，/home单独分区。

第三个坑是串口工具占用导致的"Device or resource busy"。这个问题经常发生在串口工具异常退出之后，你以为程序关了，但串口资源没释放。解决办法是检查占用并杀掉对应进程：

sudo fuser -k /dev/ttyUSB0

这个命令会强制释放串口，非常实用。

第四个坑是dash和bash的问题。除了PetaLinux，有些编译脚本会用到source命令，而source是bash内建命令，如果在dash下执行会报错。所以遇到"source not found"这类问题，先检查当前shell环境，用echo $SHELL看一下，必要时用bash script.sh显式运行。

第五个坑是误删文件。我承认我删过build目录结果发现路径写错了，把src删了半个，好在有git，最后全找回来了。从那以后我装机就装trash-cli，把rm替换成trash-put，重要文件误删后还能从回收站里捞。

8.2 新环境能不能用？来自测一遍

环境搭建完毕，我建议按下面的清单做一次开发环境自测，通过之后基本可以放心开始项目开发：

这些测试不需要一次全做完，但至少保证"能编译、能交叉编译、能连接串口、能远程登录"这四项，因为这是后续所有无人机开发任务的公共前提。

我带过不少新同事，观察下来觉得Linux的学习曲线其实不是陡，而是"散"。你不需要背命令大全，只需要每天在终端里完成真实任务，两周后就会自然形成肌肉记忆。Ubuntu 20.04这套环境，一旦你熬过最初的适应期，后面搞PetaLinux、交叉编译、机载电脑部署，都会顺畅得多。最后再分享一个小习惯：我把所有环境配置过程都写成了Markdown笔记存在~/docs里，包括踩过的坑和对应的解决方案，每次重装系统只要照着笔记执行一遍就行。这个习惯帮我节省了无数次重复排障的时间，你也可以试试。