3. DRIVE AGX开发套件与工具链部署

DRIVE AGX Orin 开发者套件是把“算法想法”变成“车上可运行程序”的第一块物理载体。它并不是一块普通 Jetson 板卡，而是包含车规级 SoC、液冷/风冷散热、车载以太网与 GMSL 摄像头接口、PCIe 扩展以及独立 MCU 的完整开发平台。理解它的硬件构成，是后续部署 DriveWorks、CUDA、TensorRT 以及刷机流程的前提。

一、开发者套件的硬件构成与接口

以 DRIVE AGX Orin Developer Kit 为例，其核心是两颗通过 NVLink-C2C 互联的 Orin SoC，提供约 254 TOPS 的稀疏算力。板载接口大致分为四类：

• 感知输入：最多 16 路 GMSL2 摄像头接口，用于接入车载摄像头；另有 CAN/LIN 接口用于接收车速、转向角等车辆信号。
• 计算与存储：Orin SoC、LPDDR5 内存、NVMe SSD 插槽，用于存放系统镜像、模型与数据集。
• 网络与调试：千兆/万兆车载以太网、USB、DisplayPort、串口调试口（UART）以及用于刷机的 USB Type-C。
• 安全与实时：独立 MCU（如 Aurix）负责安全监控与实时控制，与主 SoC 通过以太网/PCIe 通信。

开发阶段通常采用“主机 + 目标板”的模式：主机（x86 Ubuntu）负责编译、打包与刷机，目标板（DRIVE AGX Orin）负责运行。二者通过 USB 或以太网连接，这一分工直接决定了后面交叉编译与刷机流程的组织方式。

二、DriveWorks SDK 的定位与核心模块

DriveWorks 是 NVIDIA 面向自动驾驶的中间件 SDK，它把底层 CUDA、TensorRT、摄像头驱动、传感器抽象封装成统一 API，使开发者不必从零编写图像采集与推理调度代码。其核心模块包括：

• Sensor Abstraction Layer：统一管理 GMSL 摄像头、雷达、LiDAR 的采集与时间戳同步。
• Image Processing：提供去畸变、格式转换（如 RAW→RGBA）、缩放等 GPU 加速算子。
• DNN Framework：封装 TensorRT，负责模型加载、推理执行与后处理。
• Rig / Vehicle：描述传感器在车身上的安装外参，用于多传感器融合。
• Data Recorder / Replayer：录制与回放传感器数据，便于离线调试。

在目标板上，DriveWorks 以动态库（libdw*.so）和头文件形式提供，通常随 DriveOS 一起安装。开发时需要在主机上安装对应版本的 DriveWorks SDK，才能进行交叉编译。

三、CUDA / cuDNN / TensorRT 环境

三者构成推理加速的软件栈：CUDA 提供 GPU 并行计算基础，cuDNN 提供深度神经网络算子库，TensorRT 负责模型图优化、层融合、精度校准与内核自动调优。在 DRIVE AGX Orin 上，它们由 DriveOS 统一管理，版本必须与 DriveOS 版本严格匹配。

一个典型的推理流程是：PyTorch 训练得到 .pth 模型 → 导出 ONNX → 在主机上用 TensorRT 的 trtexec 或 Python API 生成 .plan 引擎文件 → 部署到目标板由 DriveWorks DNN 模块加载。需要注意，TensorRT 引擎与 GPU 架构、TensorRT 版本强绑定，主机上生成的引擎不能直接拿到目标板上运行，必须在目标板上重新构建或使用与目标板一致的构建环境。

# 在目标板上构建 TensorRT 引擎（示例）
trtexec --onnx=model.onnx \
        --saveEngine=model.plan \
        --fp16 \
        --workspace=2048 \
        --minShapes=input:1x3x256x512 \
        --optShapes=input:1x3x512x1024 \
        --maxShapes=input:1x3x1024x2048

其中 --fp16 表示启用半精度推理，--workspace 指定显存工作区大小（MB），动态 shape 参数用于适配不同分辨率输入。构建完成后可用 trtexec --loadEngine=model.plan --dumpProfile 查看各层耗时，判断瓶颈所在。

四、交叉编译流程

由于主机是 x86 架构、目标板是 aarch64 架构，应用程序需要在主机上使用交叉编译工具链编译。NVIDIA 提供的工具链通常位于 DriveWorks SDK 的 tools/cross 目录下，或通过 aarch64-linux-gnu-gcc 配合 sysroot 使用。

交叉编译的关键是正确指定 sysroot 与库路径，使编译器能找到目标板的头文件和动态库。一个典型的 CMake 配置如下：

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)
set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++)
set(CMAKE_SYSROOT /opt/nvidia/drive/targetfs)
set(CMAKE_FIND_ROOT_PATH ${CMAKE_SYSROOT})
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

编译完成后，将可执行文件与依赖库通过 scp 或 rsync 拷贝到目标板，使用 ldd 检查动态库依赖是否齐全，再运行程序。若出现 GLIBC 版本不匹配，通常说明主机 sysroot 与目标板系统版本不一致，需要更换匹配的 sysroot。

五、刷机流程

刷机是把 DriveOS 系统镜像写入目标板 eMMC/NVMe 的过程。NVIDIA 提供 SDK Manager 图形化工具，也支持命令行方式。典型步骤为：

1. 在主机上安装 SDK Manager，选择 DRIVE AGX Orin 对应的 DriveOS 版本。
2. 将目标板置于恢复模式（Recovery Mode）：按住恢复按键后上电，通过 lsusb 确认能看到 NVIDIA 设备。
3. 在 SDK Manager 中选择刷机目标（eMMC 或 NVMe）与文件系统配置，开始刷写。
4. 刷写完成后目标板自动重启，通过串口或 SSH 登录，执行 nvsipl_query 等命令验证摄像头与驱动是否正常。

六、部署检查清单