1. 这不是“高不可攀”的黑箱，而是一套可拆解、可复现的工程流水线

“自动驾驶部署”这六个字，最近两年在技术社区里被反复咀嚼，但多数人看到的仍是模糊的轮廓：一边是论文里光鲜的BEVFormer、UniAD、VAD模型结构图，另一边是视频里无人车平稳穿行十字路口的实拍画面。中间那条看不见的路——从PyTorch训练完的.pt文件，到嵌入式域控制器上稳定跑满30FPS、延迟低于80ms、功耗压在45W以内的完整系统——恰恰是新手最易卡死、最缺地图、也最容易被“概念轰炸”劝退的环节。我带过三届校招新人做实车部署，90%的人第一周都在反复确认：“我的模型导出后为什么在TensorRT里报错？”“摄像头标定参数改了，但感知结果没变，是没生效还是缓存没清？”“CAN信号发出去了，但底盘没响应，该查驱动层还是应用层？”——这些问题没有标准答案，只有真实车机环境里的日志、波形和一次又一次的“断点-注入-观测”循环。

这篇指南不讲“什么是端到端”，不堆砌Transformer架构图，也不复述ISO 26262功能安全流程（那是另一篇的事）。它只聚焦一件事：当你手头有一份在仿真环境验证过的算法模型（比如一个YOLOv8n+ByteTrack的轻量级检测跟踪pipeline），如何把它变成一辆能真正在园区里按指令巡检、避障、泊车的实体车辆上的可运行服务。核心关键词——“部署”、“算法模型”、“实车落地”——每一个都对应着明确的动作：模型格式转换与推理加速、硬件资源调度与进程隔离、传感器数据闭环与控制指令下发。整套流程不依赖特定芯片厂商SDK（虽然会以NVIDIA Orin和地平线J5为双主线示例），不绑定某家云平台（全程离线本地化），所有命令、配置、脚本均来自我们过去三年在17台不同车型（从物流小车到重卡）上踩坑沉淀的真实快照。如果你刚跑通一个KITTI数据集上的检测demo，正对着torch.jit.trace输出的.pt文件发愁下一步该干啥；或者你已写好ROS2节点，却卡在JetPack 5.1.2与CUDA 11.4的版本兼容性上；又或者你发现模型在PC端推理飞快，一上车就掉帧、发热、偶发崩溃——那你来对地方了。这不是理论推演，这是把扳手、万用表和SSH终端一起塞进你手里的实战手册。

2. 内容整体设计与思路拆解：为什么必须绕开“端到端幻觉”，先建稳态基座

2.1 拒绝“一步登天”：从模型到实车，本质是三次关键跃迁

很多新手误以为“部署=把模型转成ONNX再加载进C++”。这是典型的一阶思维。实际工程中，从算法模型到实车落地存在清晰的三阶跃迁，每一阶失败都会导致后续全部归零：

• 第一阶：模型可执行性跃迁
  目标不是“能跑”，而是“在目标硬件上确定性地、低延迟地、低功耗地跑”。这要求模型必须通过算子级兼容性审查（如Orin不支持torch.nn.functional.interpolate的某些mode）、内存带宽适配（避免频繁CPU-GPU拷贝）、量化敏感度验证（INT8量化后mAP下降是否可控）。我们曾因一个未替换的torch.where操作，在Orin上触发隐式CPU fallback，导致单帧推理从12ms飙升至217ms——而这个操作在PC端完全无感。

• 第二阶：系统可集成性跃迁
  模型只是组件，不是系统。它必须无缝接入车辆的时间同步体系（PTP或GPS授时）、数据流管道（Camera→ISP→DMA→Shared Memory→Inference→Shared Memory→Control）、故障熔断机制（当检测置信度连续5帧低于0.3，自动降级为纯视觉SLAM模式）。这里的关键不是写代码，而是理解整车EEA（电子电气架构）的通信拓扑。比如某款国产域控制器采用AUTOSAR CP+AP混合架构，其AP侧ROS2节点若直接访问CAN FD总线，会因底层驱动未开放用户态接口而永远收不到报文——必须通过CP侧的COM模块中转。

• 第三阶：场景可鲁棒性跃迁
  实车不认“平均精度”，只认“极端case下的不死锁、不误动”。这要求部署方案必须内置多维度监控探针：GPU显存占用率突增时自动dump推理输入tensor；IMU数据中断超200ms时触发紧急制动；甚至摄像头镜头被泥水覆盖时，通过图像熵值骤降识别并切换至毫米波雷达主导模式。这些不是附加功能，而是部署完成的必要验收项。

我们的设计逻辑就是严格遵循这三阶跃迁，逐层夯实。不追求“最快上线”，而追求“首次上车即稳定运行8小时无重启”。因此，整套方案放弃“大模型端到端直出控制指令”的炫技路径，选择“模块化解耦+强契约接口”的务实路线：感知（Detection/Tracking/Depth）→定位（VIO/LiDAR SLAM）→预测（LaneGCN轻量版）→规划（Hybrid A* + ST Graph）→控制（Pure Pursuit + PID Tuning）。每个模块独立部署、独立升级、独立监控，接口协议采用Protocol Buffers v3定义，确保跨语言、跨平台、跨时间的向后兼容。

2.2 工具链选型：为什么Docker是起点而非终点，为什么拒绝“一键部署”脚本

当前社区充斥着“3分钟Docker部署自动驾驶”的宣传，这极具误导性。Docker确实在开发阶段提供了环境一致性保障，但它解决不了实车部署的核心矛盾：实时性、确定性、硬件亲和性。

• Docker的适用边界：我们仅将其用于非实时任务的封装，如数据回传服务（将ROS2 bag压缩上传至NAS）、OTA升级包校验、Web监控前端。所有与传感器采集、运动控制强相关的进程，必须运行在Host OS的实时调度策略下（SCHED_FIFO优先级10以上）。曾有团队将整个感知pipeline打包进Docker，结果因cgroup对CPU bandwidth的限制，导致关键帧处理延迟抖动达±45ms，远超控制环路要求的±5ms容忍度。

• “一键部署”脚本的陷阱：这类脚本往往硬编码了特定Ubuntu版本、CUDA patch号、内核模块路径。而实车环境千差万别：某物流车使用Yocto定制Linux，内核为5.10.120，无systemd；某测试车预装了NVIDIA DRIVE OS 6.0.6，其nvtop工具与标准版行为迥异。我们提供的所有自动化脚本（见后文）均采用声明式配置+运行时探测：先执行detect_hardware.sh识别SoC型号、CUDA版本、内核ABI，再动态加载对应模块（如jetson_clocks.sh仅在Orin上启用，J5则调用hobot_sdk_init）。

• 真正的核心工具链：

  • 模型编译层：TensorRT 8.6.1（Orin） + Horizon BPU SDK 4.1.0（J5）——二者均需手动编译针对目标硬件优化的plugin（如自定义Deformable DETR插件）；
  • 中间件层：ROS2 Humble（实车主力） + Cyclone DDS（替代默认FastDDS，降低UDP丢包率）；
  • 硬件抽象层：自研sensor_bridge（统一Camera/IMU/LiDAR时间戳对齐） +can_gateway（将SocketCAN报文映射为ROS2 topic，支持CAN FD速率自适应）；
  • 监控层：eBPF程序实时捕获GPU kernel launch latency，Prometheus暴露指标，Grafana看板聚合显示。

这套选型不是凭空而来。它源于我们对比测试12种组合后得出的结论：在Orin上，TensorRT+ROS2 Humble+Cyclone DDS的端到端延迟标准差为3.2ms，而ONNX Runtime+ROS2 Foxy+FastDDS为11.7ms；在J5上，Horizon SDK的BPU推理吞吐比TVMScript手工调度高2.3倍。每一个选择背后，都有实测数据支撑，而非“听说很火”。

2.3 架构分层：为什么坚持“四层解耦”，以及每层的不可妥协原则

我们采用严格分层架构，每层有明确定义的输入/输出契约、性能SLA和故障域隔离：

这种分层不是为了“看起来专业”，而是为了解决实车中最痛的三个问题：

1. 故障定位难：当车辆突然转向异常，是IMU数据漂移？是规划模块轨迹生成错误？还是CAN指令被干扰？分层后，可通过L4层日志快速锁定是/control/cmdtopic数据异常，再下钻到L3层查看/perception/tracks是否为空，最终定位到L1层IMU驱动在-20℃低温下采样率跌落；
2. 迭代成本高：更换新摄像头只需重写L1驱动，L2-L4完全不动；升级规划算法只需替换L3中一个ROS2 package，无需重新编译整个系统；
3. 安全认证易：L4层的安全状态机可单独进行ASIL-B认证，其代码行数仅1200行，而传统单体架构动辄数万行，认证成本呈指数增长。

3. 核心细节解析与实操要点：从模型导出到实车启动的12个生死关

3.1 模型导出：为什么torch.jit.trace是起点，onnx.export是陷阱，trtexec才是终局

新手常陷入一个误区：认为“模型训练完→torch.save()→torch.load()→model.eval()→model(input)”这条链路在实车上也能走通。这是灾难的开始。PyTorch的Python解释器在嵌入式设备上内存占用超1.2GB，且GIL锁导致多线程推理无法真正并行。我们必须将模型固化为硬件可直接执行的二进制。

• Step 1：TorchScript trace —— 锁定计算图

  # 关键：必须用真实输入shape，且禁用dynamic_axes（实车无动态batch） example_input = torch.randn(1, 3, 640, 640).cuda() # 注意：必须.cuda()！否则trace无法捕获GPU kernel traced_model = torch.jit.trace(model, example_input) traced_model.save("yolov8n_traced.pt") # 生成静态图

  提示：example_input必须与实车摄像头分辨率严格一致。我们曾因仿真用640x480、实车用1280x720，导致traced model在Orin上触发隐式resize，引入额外23ms延迟。

• Step 2：ONNX export —— 仅作中间格式，绝不直接部署

  torch.onnx.export( traced_model, example_input, "yolov8n.onnx", input_names=["input"], output_names=["boxes", "scores", "labels"], opset_version=16, # 必须≥15，否则不支持GroupNorm do_constant_folding=True, dynamic_axes=None # 实车严禁dynamic batch！ )

  注意：ONNX在此仅为跨平台交换格式。TensorRT 8.6不支持ONNX的全部op（如NonMaxSuppression在某些版本有bug），直接加载ONNX会导致推理结果错误。必须作为trtexec的输入。

• Step 3：TensorRT build —— 真正的部署时刻

  # Orin平台：指定GPU型号、精度、workspace大小 trtexec --onnx=yolov8n.onnx \ --saveEngine=yolov8n_fp16.engine \ --fp16 \ --workspace=2048 \ --minShapes=input:1x3x640x640 \ --optShapes=input:1x3x640x640 \ --maxShapes=input:1x3x640x640 \ --timingCacheFile=timing.cache \ --buildOnly

  关键参数解析：

  • --fp16：Orin的FP16 tensor core性能是FP32的2倍，且yolov8n量化后mAP仅降0.8%；
  • --workspace=2048：单位MB，太小导致kernel无法优化，太大浪费显存；实测1024MB在640p下已足够；
  • --min/opt/maxShapes：三者相同，强制静态shape，消除runtime shape inference开销；
  • --timingCacheFile：缓存优化结果，下次build跳过耗时的kernel autotuning。

  实操心得：首次build耗时约18分钟（Orin），但生成的.engine文件可直接dlopen加载，推理延迟稳定在8.3ms±0.4ms。而ONNX Runtime在同一硬件上为14.7ms±3.2ms。

3.2 硬件初始化：为什么jetson_clocks不是万能钥匙，而nvpmodel才是性能基石

Orin的功耗墙（TDP）是30W/40W/50W三档，但jetson_clocks.sh只是暴力拉频，不区分CPU/GPU/NVENC负载特性。实车需要的是按需供电。

• 正确姿势：nvpmodel+ 自定义profile
  编辑/etc/nvpmodel.conf，新增profile：

  [PROFILE_4] CPU { min_freq=1152000 max_freq=2265600 } GPU { min_freq=300000000 max_freq=1300000000 # 关键：GPU上限设为1.3GHz，非max } DLA { min_freq=0 max_freq=0 # 实车不用DLA，关闭省电 }

  然后sudo nvpmodel -m 4激活。此配置下，GPU在推理峰值时稳定1.3GHz，功耗38W，温度72℃；若用jetson_clocks全频，GPU达1.9GHz，功耗冲至49W，温度91℃，触发thermal throttle，反而降频至800MHz。

• J5平台：必须调用hobot_sdk_init
  地平线J5的BPU频率由SDK严格管控：

  # 启动前必须执行，否则BPU clock为0 sudo /opt/hobot/bin/hobot_sdk_init -c 4 -g 2 # -c: CPU core数, -g: BPU group数 # 验证：cat /sys/class/hobot/bpu/freq

3.3 时间同步：为什么PTP比NTP可靠1000倍，以及如何让Camera帧精准对齐

实车所有传感器（Camera/IMU/LiDAR）必须在统一时间轴上。NTP误差达100ms，PTP（IEEE 1588）可做到亚微秒级。

• Orin主时钟配置（假设使用PCIe网卡）：

  # 安装ptp4l sudo apt install linuxptp # 启动PTP主时钟（网卡eth0需支持硬件timestamp） sudo ptp4l -i eth0 -m -f /etc/linuxptp/ptp4l.conf # 同时启动phc2sys，将PTP时间同步到系统时钟 sudo phc2sys -s eth0 -c CLOCK_REALTIME -m -w

  /etc/linuxptp/ptp4l.conf关键配置：

  [global] time_stamping hardware # 强制硬件打戳 priority1 128 priority2 128 clock_class 6 clock_accuracy 248 offset_from_master_threshold 100 # 超过100ns偏差即告警

• Camera帧时间戳对齐：
  V4L2驱动需开启V4L2_CAP_TIMEPERFRAME，并在struct v4l2_buffer中读取timestamp_ns。但实测发现，部分IMX490模组的timestamp有2-3ms系统性偏移。解决方案：在L2 Data Hub层，用PTP master时钟对camera timestamp做在线校准：

  // 伪代码：校准函数 int64_t calibrate_camera_ts(int64_t raw_ts) { static int64_t offset = 0; static int64_t last_ptp = 0; int64_t ptp_now = get_ptp_time_ns(); // 从PTP socket读取 if (last_ptp != 0) { offset = (ptp_now - last_ptp) - (raw_ts - last_raw_ts); } last_ptp = ptp_now; last_raw_ts = raw_ts; return raw_ts + offset; // 返回校准后时间戳 }

  此校准使Camera与IMU时间戳对齐误差从±5ms降至±8μs。

3.4 ROS2节点部署：为什么rclcpp_components比Node更健壮，以及如何避免DDS风暴

ROS2 Humble默认使用FastDDS，但在车载千兆网络下，topic洪泛（如/camera/image_raw30fps * 1280x720 * 3bytes ≈ 83MB/s）极易导致UDP丢包。

• 方案：Cyclone DDS + 自定义QoS
  rmw_cyclonedds_cpp配置文件/etc/cyclonedds.xml：

  <CycloneDDS xmlns="https://cdds.io/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd"> <Domain id="any"> <General> <NetworkInterfaceAddress>auto</NetworkInterfaceAddress> <AllowMulticast>false</AllowMulticast> <!-- 关闭multicast，改用unicast --> </General> <QualityOfService> <Durability>TransientLocal</Durability> <Reliability>BestEffort</Reliability> <!-- 图像类topic用BestEffort，避免重传阻塞 --> <History>KeepLast</History> <Depth>1</Depth> <!-- 只保留最新一帧，节省内存 --> </QualityOfService> </Domain> </CycloneDDS>

  启动时指定：RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run perception_node detector_node

• 组件化部署：rclcpp_components实现热更新
  将感知节点编译为shared library：

  // detector_component.cpp #include "rclcpp_components/register_node_macro.hpp" class DetectorNode : public rclcpp::Node { ... }; RCLCPP_COMPONENTS_REGISTER_NODE(DetectorNode)

  运行时动态加载/卸载，无需重启整个ROS2 daemon：

  # 加载 ros2 component load /ComponentManager perception_detector detector_component # 卸载（如需更新模型） ros2 component unload /ComponentManager 1

3.5 CAN通信：为什么不能直接用can-utils，而必须自研can_gateway

candump只能监听，cansend只能发单帧。实车控制需要周期性、高精度、带校验的CAN FD报文流。

• 自研can_gateway核心逻辑：

  • 使用AF_CANsocket，设置CAN_RAW_FD_FRAMESflag启用FD模式；
  • 通过setsockopt(..., SOL_SOCKET, SO_BINDTODEVICE, ...)绑定到指定CAN interface（如can0）；
  • 采用timerfd_create实现μs级精度定时（非usleep，后者不可靠）；
  • 报文结构体强制packed，并添加CRC16-CCITT校验：

    struct __attribute__((packed)) vehicle_cmd_t { uint16_t steering_angle; // 0.1° uint16_t throttle; // 0-100% uint16_t brake; // 0-100% uint16_t gear; // 0=N,1=D,2=R uint16_t crc16; // CRC over first 8 bytes };

• 实车验证：在2Mbps CAN FD速率下，can_gateway可稳定输出100Hz控制指令，抖动<±5μs；而cansend脚本方式抖动达±120μs，导致PID控制震荡。

3.6 安全监控：为什么需要独立进程运行“安全状态机”，以及它的最小可行集

L4层安全状态机（SSM）必须满足：

• 独立于主控进程（即使ROS2 crash，SSM仍运行）；
• 输入仅限硬件信号（IMU失效、CAN心跳丢失、急停按钮）；
• 输出仅限安全指令（最大减速度、方向盘回正、挂P档）；
• 代码行数<2000，便于形式化验证。

其最小可行集包含三个状态：

1. NORMAL：所有传感器在线，控制指令正常下发；
2. DEGRADED：单传感器失效（如Camera遮挡），降级为雷达主导，限速20km/h；
3. EMERGENCY：双传感器失效或急停触发，立即执行0.8g减速度，方向盘回正，挂P档。

SSM用C编写，编译为静态链接binary，通过systemd以Type=oneshot启动，优先级设为SCHED_FIFO 99，确保最高调度权。

4. 实操过程与核心环节实现：从零搭建一辆可行驶的自动驾驶小车

4.1 环境准备：Orin与J5双平台的最小化系统镜像构建

我们不推荐直接刷JetPack或Horizon SDK官方镜像，因其预装大量无关软件，占用宝贵eMMC空间。我们构建了精简镜像：

• Orin精简镜像（基于Ubuntu 20.04）：

  • 基础：Kernel 5.10.120，仅启用必需驱动（tegra-camera, tegra-nvdec, nvhost-as-gpu）；
  • 删除：snapd、apt-daily、unattended-upgrades、bluetooth、wifi相关服务；
  • 保留：systemd,rsyslog,chrony（PTP时间同步基础）；
  • 大小：仅2.1GB，为AI模型和日志留足空间。

• J5精简镜像（基于Yocto Kirkstone）：

  • 使用meta-horizonlayer，DISTRO_FEATURES_remove = "x11 wayland"；
  • 仅编译hobot_sdk,hobot_vio,hobot_rdk；
  • 禁用所有GUI组件，rootfs大小1.8GB。

构建脚本build_image.sh自动完成分区、格式化、文件拷贝、grub配置，全程无人值守。

4.2 模型部署全流程：以YOLOv8n检测模型为例的12步实操

以下是在Orin上部署YOLOv8n的完整步骤，每步附实测耗时与常见错误：

1. 克隆模型仓库（git clone https://github.com/ultralytics/ultralytics.git）→ 耗时：12s
2. 安装依赖（pip3 install torch==1.13.1+cu117 torchvision==0.14.1+cu117 -f https://download.pytorch.org/whl/torch_stable.html）→ 耗时：47s；错误：未指定cu117，导致CUDA版本不匹配
3. 下载预训练权重（wget https://github.com/ultralytics/assets/releases/download/v0.0.0/yolov8n.pt）→ 耗时：8s
4. 导出TorchScript（python3 export.py --weights yolov8n.pt --include torchscript --imgsz 640）→ 耗时：32s；错误：未加--imgsz 640，默认640x480，与实车不符
5. 导出ONNX（python3 export.py --weights yolov8n.pt --include onnx --imgsz 640 --opset 16）→ 耗时：28s
6. 验证ONNX（onnxsim yolov8n.onnx yolov8n_sim.onnx）→ 耗时：15s；简化计算图，提升TRT兼容性
7. TRT Build（trtexec --onnx=yolov8n_sim.onnx --saveEngine=yolov8n_fp16.engine --fp16 --workspace=1024 --minShapes=input:1x3x640x640 --optShapes=input:1x3x640x640 --maxShapes=input:1x3x640x640）→ 耗时：1080s（18min）
8. 测试Engine（trtexec --loadEngine=yolov8n_fp16.engine --shapes=input:1x3x640x640 --duration=10）→ 耗时：22s；输出：avg latency 8.3ms，stable
9. 编写C++推理Wrapper（detector_trt.h/cpp，封装IExecutionContext、ICudaEngine）→ 耗时：45min；关键：cudaMalloc显存必须与engine profile匹配
10. 编译ROS2节点（colcon build --packages-select perception_detector）→ 耗时：3min12s
11. 配置Cyclone DDS（复制cyclonedds.xml到/etc/）→ 耗时：2s
12. 启动验证（ros2 launch perception_detector detector_launch.py）→ 耗时：1s；成功标志：ros2 topic hz /perception/detections显示30.0Hz

实操心得：第7步TRT Build是最大瓶颈，但只需执行一次。后续模型更新，只要输入shape不变，可复用timing.cache，耗时降至90s内。务必在build前执行sudo nvpmodel -m 4锁定性能模式，否则build过程GPU降频，生成engine性能劣化。

4.3 传感器集成：Camera/IMU/LiDAR三合一时间对齐实战

以实车搭载的IMX490 + BMI088 + RoboSense M1组合为例：

• Camera初始化：

  # 加载驱动 sudo modprobe tegra-camera-platform sudo modprobe imx490 # 设置分辨率与帧率 v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat=RG10 v4l2-ctl -d /dev/video0 --set-parm=30

• IMU时间戳校准：
  BMI088的INT1引脚接Orin GPIO，中断触发时读取CLOCK_MONOTONIC_RAW作为硬件时间戳。但实测有1.2ms固定延迟，需在L2 Data Hub中补偿。

• LiDAR同步：
  RoboSense M1支持PTP硬件同步。配置其Web界面：

  • Time Sync Mode: PTP Master
  • PTP Priority1: 128
  • PTP Clock Class: 6
    启动后，M1自动加入PTP域，其点云时间戳与Camera/IMU同源。

• L2 Data Hub融合：
  创建共享内存区/dev/shm/perception_input，结构体：

  struct __attribute__((packed)) sensor_fusion_t { int64_t camera_ts; // ns, from V4L2 buffer int64_t imu_ts; // ns, from GPIO interrupt + calibration int64_t lidar_ts; // ns, from M1 PTP char camera_data[1280*720*2]; // RAW10 float imu_acc[3]; float imu_gyro[3]; uint8_t lidar_points[128000]; // compressed point cloud };

  L3感知节点从该shm读取，确保所有数据来自同一物理时刻。

4.4 控制指令下发：从ROS2 topic到CAN FD报文的毫秒级闭环

控制节点control_node订阅/planning/trajectory，发布/vehicle/cmd：

• Trajectory Topic解析：
  每帧含100个点（2s@50Hz），每个点含x,y,theta,kappa,v。控制节点提取前5个点，拟合五次多项式，生成steering_angle和throttle。

• CAN FD报文构造：

  vehicle_cmd_t cmd; cmd.steering_angle = (int16_t)(target_angle * 10); // 0.1°精度 cmd.throttle = (int16_t)clamp(target_throttle, 0, 100); cmd.brake = (int16_t)clamp(target_brake, 0, 100); cmd.gear = current_gear; cmd.crc16 = crc16_ccitt((uint8_t*)&cmd, 8); // CRC over first 8 bytes

• 发送循环（100Hz）：

  struct canfd_frame frame; frame.can_id = 0x123; frame.len = CANFD_MTU; memcpy(frame.data, &cmd, sizeof(cmd)); write(can_socket, &frame, sizeof(frame)); // 非阻塞socket

  实测端到端延迟（规划输出→CAN报文发出）：3.7ms ± 0.3ms。

4.5 实车首启：从“绿灯亮起”到“车辆移动”的17个检查点

首次上电启动，必须按顺序验证以下17项，任一失败即停止：

1. dmesg | grep -i "tegra"→ 确认Camera驱动加载成功；
2. ls /dev/video*→ 确认video设备存在；
3. sudo jetson_clocks && nvpmodel -q→ 确认性能模式激活；
4. sudo ptp4l -i eth0 -m -f /etc/linuxptp/ptp4l.conf &→ PTP主时钟运行；
5. sudo phc2sys -s eth0 -c CLOCK_REALTIME -m -w &→ 系统时钟同步；
6. ip link show can0→ CAN interface up；
7. candump can0 | head -5→ 确认CAN总线有心跳报文；
8. ros2 node list→ 确认/ComponentManager存在；
9. ros2 component types→ 确认perception_detector组件注册；
10. ros2 component load /ComponentManager perception_detector detector_component→ 加载成功；
11. ros2 topic list | grep detection→/perception/detections出现；
12. `ros2 topic hz /perception/detections