3. 自动驾驶软件栈概览

在 Orin 上做模型部署与性能优化，不能只盯着单个神经网络推理速度。真正决定系统能否稳定跑起来的，是整条自动驾驶软件栈的数据流是否顺畅、模块边界是否清晰、中间件通信是否高效。本章从工程视角梳理传感器数据流、感知/规划/控制三大模块，以及 ROS2 与 Autoware 的集成要点，为后续的模型量化、算子优化和端到端调优建立系统级认知。

一、核心原理：从传感器到执行器的闭环数据流

自动驾驶软件栈本质上是一条“感知—决策—执行”的实时数据流水线。传感器层产生原始数据，中间件负责传输与时间同步，感知模块把原始数据转成结构化环境模型，规划模块基于环境模型生成轨迹，控制模块把轨迹转成油门、刹车、转向指令，最终作用于车辆底盘。Orin 在其中承担的是高算力计算平台角色，通常承载感知、部分规划以及模型推理加速任务。

理解这条链路的关键在于三个约束：时间同步、数据吞吐和端到端延迟。摄像头、激光雷达、毫米波雷达、IMU、GNSS 的采样频率和触发方式各不相同，若时间戳对齐不准，感知融合就会产生“鬼影”或目标漂移。Orin 的 GMSL2 摄像头接口、PCIe 激光雷达接入、CAN 底盘反馈，都需要在软件栈中统一到同一时间基准。

二、方法流程：感知、规划、控制模块的职责边界

感知模块负责“看懂世界”。在 Orin 上，典型感知流水线包括图像预处理、CNN/Transformer 推理、后处理（NMS、解码）、点云体素化与 3D 检测、以及多传感器融合。部署时最容易出问题的是预处理和后处理：它们往往跑在 CPU 上，若没有与 GPU 推理重叠，就会成为瓶颈。建议用 CUDA 核函数或 NPP 库把 resize、归一化、颜色空间转换放到 GPU 上，并用 CUDA Stream 与推理并行。

规划模块负责“决定怎么走”。它接收感知输出的障碍物、车道线、地图和定位信息，先做行为决策（跟车、换道、避障），再做路径与速度规划，输出一条带时间戳的轨迹。规划模块对延迟敏感，但算力需求通常低于感知。在 Orin 上，规划可以跑在 CPU 上，也可以把部分优化问题卸载到 GPU。

控制模块负责“把轨迹变成动作”。它根据当前车辆状态与目标轨迹的偏差，计算横向转角与纵向加速度，通过 CAN 或线控接口下发。控制频率通常为 50～100Hz，要求确定性延迟，因此不适合与重负载推理共享同一线程。

三、ROS2 与 Autoware 集成要点

ROS2 是当前自动驾驶软件栈的主流中间件，Autoware 则是在 ROS2 之上构建的完整开源自动驾驶栈。在 Orin 上集成时，需要重点关注以下几点：

• QoS 配置：传感器话题通常用 SensorDataQoS（Best Effort），而控制指令需要 Reliable。QoS 不匹配会导致节点收不到数据，这是最常见的集成故障。
• 零拷贝：ROS2 的 loaned message 与 Iceoryx 可以避免大点云和图像在进程间复制，Orin 的共享内存带宽有限，零拷贝对吞吐提升明显。
• 组件容器：把感知、规划、控制节点放入同一个 component container，用 intra-process communication 减少序列化开销。
• 时间源：统一使用 /clock 或 PTP 硬件时间，避免各节点各自为政。
• Launch 与参数：用 YAML 管理模型路径、阈值、相机内参，便于在 Orin 上快速切换配置。

# 查看话题 QoS 与频率，排查数据流是否正常
ros2 topic info /perception/obstacles --verbose
ros2 topic hz /sensing/camera/front/image_raw
ros2 topic echo /planning/trajectory --once

# 使用组件容器启动 Autoware 感知流水线
ros2 launch autoware_perception perception.launch.xml \
  model_path:=/opt/models/yolov8s.engine \
  use_gpu:=true

四、案例与误区复盘

某项目在 Orin 上部署 Autoware 时，发现感知节点 CPU 占用不高但端到端延迟波动很大。排查后发现两个问题：一是摄像头话题使用 Reliable QoS，导致 DDS 重传；二是点云在进程间被复制了三次。改为 SensorDataQoS 并启用零拷贝后，端到端延迟从 180ms 降到 95ms。