📚 课程目录第2章 Jetson硬件与系统环境搭建

2. Jetson硬件与系统环境搭建

Jetson 平台的开发体验与普通 x86 主机差异很大：算力来自 GPU 与专用加速器，系统镜像由 NVIDIA 定制的 L4T 提供，软件栈则通过 JetPack 统一分发。如果选型、刷机、SDK 安装和远程开发链路没有一次理顺，后续的感知与自主系统调试会反复被环境问题打断。本节围绕“选对板子、装对系统、配好工具链、能远程开发、能测出真实性能”这条主线展开。

一、Orin / Xavier / Nano 选型：先看算力与接口，再看功耗与预算

Jetson 各代产品的核心差异体现在 GPU 架构、AI 算力（常以 INT8 TOPS 标注）、内存带宽、编解码能力和接口丰富度上。以常见型号为例：Jetson Nano（4GB）约 0.5 TFLOPS FP16，适合入门视觉与轻量推理；Jetson Xavier NX 约 21 TOPS，适合多路摄像头与中等规模模型；Jetson AGX Xavier 约 32 TOPS，接口最全；Jetson Orin Nano 约 40 TOPS，Orin NX 约 70–100 TOPS，AGX Orin 可达 275 TOPS，面向多传感器融合与 Transformer 类模型。选型时建议按以下顺序判断：

模型规模与实时性：需要跑 YOLO 系列、BEV、分割网络时，优先 Orin 系列；仅做传统 CV 或小模型，Nano/Xavier NX 足够。
传感器路数：多路 GMSL/MIPI 相机、激光雷达、CAN 总线同时接入时，关注 CSI 通道数、PCIe 通道与网口数量，AGX Orin 与 Xavier 更具优势。
功耗与散热：Nano 约 5–10W，Xavier NX 约 10–20W，Orin 系列 10–60W。机器人本体若靠电池供电，功耗直接决定续航与散热方案。
软件支持周期：新版本 JetPack 通常优先支持 Orin，老型号可能停留在较早的 L4T 版本，影响 CUDA/TensorRT 版本选择。

一个实用的判断是：如果目标模型在桌面 GPU 上单帧推理已接近 30ms，且需要 30FPS 以上，就应选择算力至少为桌面 GPU 1/3 的 Jetson 型号，并预留 30% 余量。

二、JetPack SDK、Ubuntu 与 L4T 的关系

很多初学者会把 Ubuntu、L4T、JetPack 混为一谈。准确地说：L4T（Linux for Tegra）是 NVIDIA 为 Tegra 芯片提供的底层 BSP，包含引导、内核、驱动和根文件系统；Ubuntu 是 L4T 之上呈现给用户的发行版形态；JetPack 则是把 L4T、CUDA、cuDNN、TensorRT、VisionWorks、DeepStream 等打包在一起的 SDK 安装器。三者关系可以概括为：JetPack = L4T + Ubuntu 根文件系统 + CUDA 生态组件。

刷机时，官方推荐使用 NVIDIA SDK Manager（在 Ubuntu 主机上运行）或直接烧写 SD 卡镜像。以 Orin Nano 为例，若使用 SD 卡启动，需先下载对应 JetPack 版本的镜像，用 balenaEtcher 写入，首次启动后完成用户名、语言和网络配置。若使用 NVMe 启动，则需通过 SDK Manager 或 flash.sh 脚本烧写，并在 UEFI 中调整启动顺序。刷机后可用以下命令确认版本是否匹配：

cat /etc/nv_tegra_release        # 查看 L4T 版本
cat /etc/os-release              # 查看 Ubuntu 版本
nvcc --version                   # 查看 CUDA 编译器版本
dpkg -l | grep -E "cudnn|tensorrt"  # 查看 cuDNN / TensorRT 包

如果 nvcc 提示找不到命令，通常是因为 CUDA 未加入 PATH，可在 ~/.bashrc 中追加 export PATH=/usr/local/cuda/bin:$PATH 与 export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH，再执行 source ~/.bashrc。

三、CUDA / cuDNN / TensorRT 的安装与验证

JetPack 已预装 CUDA、cuDNN 和 TensorRT，一般不需要单独安装。真正需要做的是验证它们能否被 Python 和推理框架正确调用。常用检查方式：

CUDA：运行 nvidia-smi（部分型号需 tegrastats）或编译 deviceQuery 示例，确认 GPU 被识别。
cuDNN：dpkg -l | grep cudnn 查看版本，或在 Python 中 import torch; print(torch.backends.cudnn.version())。
TensorRT：python3 -c "import tensorrt; print(tensorrt.__version__)"，并用 trtexec 对 ONNX 模型做一次转换测试。

一个常见的坑是 Python 环境混用：系统自带 Python 与 conda 环境中的 PyTorch 可能链接到不同版本的 CUDA 库。建议在 Jetson 上优先使用系统 Python 或官方提供的 wheel 包，避免自行 pip 安装通用版 PyTorch。若必须使用虚拟环境，应确认 torch.version.cuda 与 nvcc --version 一致。

四、远程开发：SSH、VSCode Remote 与文件同步

Jetson 通常作为机器人本体上的计算单元，不适合直接接显示器键鼠调试。推荐链路是：主机与 Jetson 接入同一局域网，通过 SSH 登录，再用 VSCode Remote-SSH 打开远程目录进行编辑与调试。基本步骤：

在 Jetson 上确认 SSH 服务已启动：sudo systemctl status ssh，若未安装则 sudo apt install openssh-server。
查看 IP：hostname -I，记下如 192.168.1.50。
主机上 ssh nvidia@192.168.1.50 测试登录，建议配置 SSH 公钥免密。
VSCode 安装 Remote-SSH 插件，连接该 IP，即可在远程环境中使用终端、调试器和 Git。

若需要图形化查看相机画面或 RViz，可在 SSH 中使用 X11 转发（ssh -X），或在主机上运行 RViz、Jetson 只负责数据发布，通过 ROS 2 的 DDS 跨设备通信。后者对带宽和实时性更友好。

五、性能基准：用数据判断环境是否达标

环境搭好后，必须做一次基准测试，否则无法判断后续优化空间。建议至少测三项：CPU 算力、GPU 推理延迟、内存带宽。常用工具包括 tegrastats（实时查看功耗、温度、内存、GPU 利用率）、jetson_clocks（锁定最高频率）、trtexec（TensorRT 推理基准）以及 sysbench（CPU）。

以 Orin Nano 8GB 为例，一个合理的示例测试流程是：先用 sudo jetson_clocks 锁定频率，再用 trtexec --onnx=yolov8n.onnx --fp16 --iterations=200 测推理延迟，同时另开终端运行 tegrastats --interval 1000 观察功耗与温度。若 FP16 下 YOLOv8n 单帧延迟在 15–25ms 区间、功耗稳定在 15W 以内、温度低于 80°C，说明环境与散热基本达标；若延迟明显偏高，应检查是否误用了 FP32、是否未锁定频率、或模型输入分辨率过大。

建议把选型结论、JetPack 版本、CUDA/cuDNN/TensorRT 版本、基准测试命令与结果记录成一份环境清单，后续换板或升级 JetPack 时可快速对比，避免“换了环境却不知道哪里变了”。

完成以上步骤后，Jetson 就具备了可远程开发、可复现基准的稳定环境，接下来才能把精力投入到传感器接入、感知模型部署与自主系统集成上。