1. 课程导入与IGX平台全景

欢迎进入《NVIDIA IGX 多传感器融合与数据处理系统》课程。在动手写第一行融合代码之前，我们需要先建立一张"平台地图"：IGX 到底是什么、它由哪些硬件与软件层组成、它面向哪些真实场景，以及本课程会沿着怎样的路径把多传感器融合与数据处理一步步落地。只有先看清这张地图，后面每一章的具体配置、标定、时间同步与推理部署才有明确的坐标。

IGX 的定位：为工业边缘而生的安全级计算平台

NVIDIA IGX 是面向工业与医疗边缘场景的计算平台，它的核心诉求与数据中心 GPU 或消费级 Jetson 都不同。工业现场要求设备在粉尘、振动、宽温环境下长期运行，同时越来越多地需要与人协作——例如自主移动机器人（AMR）在产线旁与工人共享通道，手术机器人需要在患者身边实时决策。这类场景对"功能安全"提出了硬性要求：系统必须能检测故障、进入安全状态，并且行为可预测、可验证。

因此 IGX 的定位可以概括为三点：边缘实时性（数据在本地完成处理，不依赖云端往返）、功能安全与信息安全（支持安全岛、冗余与安全启动等机制）、多传感器原生支持（从设计上就为相机、激光雷达、毫米波雷达、IMU、GNSS 等多路异构输入预留了带宽与接口）。理解这三点，是理解后续所有技术选择的起点。

硬件架构：从传感器接口到算力核心

IGX 的硬件可以按"输入—计算—输出"三段来理解。输入侧是丰富的传感器接口：GMSL 相机通过串行链路接入，可支持多路高分辨率视频；以太网与 CAN 总线接入激光雷达、雷达和车辆/设备总线；GPIO 与 PPS 脉冲用于硬触发和时间戳对齐。计算侧以 IGX 计算模块为核心，内部集成 GPU（负责并行推理与点云处理）、CPU（负责调度与业务逻辑）、以及专用的安全岛（Safety Island）用于监控系统健康。输出侧则通过以太网、CAN 或显示接口把融合结果送给上层控制器或人机界面。

这里有一个关键概念需要提前建立：传感器的时间基准必须统一。相机曝光、激光雷达扫描、IMU 采样各自有独立的时钟，如果不在硬件层用 PPS 或 PTP 对齐，融合时就会出现"看到的不是同一时刻的世界"的问题。这是本课程后续章节反复出现的核心线索。

软件栈：从驱动到应用的分层结构

IGX 的软件栈是分层的，理解每一层的职责能帮你在遇到问题时快速定位。最底层是 BSP 与驱动，负责相机、雷达、CAN 等设备的枚举与数据搬运；往上是 CUDA 与 TensorRT，前者提供 GPU 并行计算能力，后者把训练好的模型编译成高效的推理引擎；再往上是 DeepStream，用于构建多路视频分析管线；最上层是 ROS 2，用节点、话题、服务的方式组织业务逻辑，也是多传感器融合最常用的框架。

一个常见的误区是把这些层混在一起写。例如在 ROS 2 节点里直接调用 CUDA 内核，虽然能跑，但会让时间同步和错误处理变得难以维护。更合理的做法是：驱动层保证数据带准确时间戳，中间件层完成对齐与缓冲，应用层只消费"已经对齐好的数据包"。本课程后续会按这个分层思路逐步展开。

目标应用场景

IGX 的典型场景包括：自主移动机器人（在仓库中避障、搬运）、智能视频分析（多路相机实时检测异常行为）、医疗影像与手术辅助（低延迟处理内窥镜或超声数据）、工业质检（结合相机与激光雷达检测产品缺陷）。这些场景的共同点是：多路异构传感器、严格的延迟要求、以及不能"死机"的可靠性要求。

本课程的学习路径

整门课程会沿着一条从"看得见"到"算得准"再到"跑得稳"的路径推进。第一阶段建立平台认知与开发环境；第二阶段处理传感器接入与时间同步，这是融合的地基；第三阶段构建数据管线，把多路数据组织成可处理的流；第四阶段进入融合算法本身，包括标定、坐标变换、点云与图像对齐；第五阶段做推理部署与性能优化；最后阶段关注安全机制与系统验证。