4. IGX上的相机接口与配置

NVIDIA IGX平台面向机器人与边缘视觉场景，其相机接入能力是系统集成的第一道关口。IGX Orin开发者套件与量产模组在物理层提供了三类主流相机接口：GMSL2（千兆多媒体串行链路）、USB 3.x以及MIPI CSI-2。三者并非互相替代，而是分别对应不同的传输距离、带宽、同步能力与部署形态。理解它们的电气特性与软件栈差异，是后续多相机同步与稳定运行的前提。

三类接口的定位与关键参数

GMSL2通过同轴或屏蔽双绞线传输，单链路可同时承载视频、控制与供电（PoC），线缆长度可达10～15米，抗干扰强，适合车载与移动机器人上相机远离计算单元的布局。IGX通常通过GMSL解串器（如Maxim/ADI系列）将多路GMSL汇聚为MIPI CSI-2输入到SoC，因此GMSL在软件层往往表现为CSI设备。USB 3.x相机即插即用、协议通用、成本低，但带宽共享、延迟抖动较大，且多相机同步依赖UVC的有限控制能力。MIPI CSI-2是SoC原生接口，带宽高、延迟低、可直接接入ISP与硬件同步信号，但线缆短（通常小于30厘米），适合相机与计算单元同板或近距离的紧凑设计。

需要特别说明的是，IGX上的GMSL与MIPI CSI在Linux软件栈中通常统一由NVIDIA相机框架管理，设备节点表现为/dev/video*，但底层驱动、设备树与同步机制完全不同。因此“能出图”不等于“配置正确”，多相机场景下必须进一步验证时间戳与帧对齐。

驱动安装与设备树配置

IGX的相机驱动安装通常从JetPack/L4T BSP开始。GMSL相机需要厂商提供的解串器驱动与设备树叠加层（DTBO），MIPI CSI相机需要对应的sensor驱动（如IMX系列）与CSI端口配置，USB相机则依赖内核UVC驱动，一般无需额外安装。以GMSL为例，典型流程是：确认BSP版本与相机模组匹配，将厂商提供的.dtbo放入/boot，在/boot/extlinux/extlinux.conf的FDT或OVERLAYS字段中引用，然后重启。重启后通过dmesg | grep -i csi或dmesg | grep -i gmsl观察驱动是否成功probe。

# 查看已注册的视频设备
ls -l /dev/video*

# 查看相机能力与支持格式
v4l2-ctl --list-devices
v4l2-ctl -d /dev/video0 --list-formats-ext

# 抓取一帧验证通路
v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=UYVY \
  --stream-mmap --stream-count=1 --stream-to=frame.raw

如果/dev/video*未出现，优先检查设备树叠加层是否加载、I²C地址是否冲突、供电与PoC是否正常。对于MIPI CSI，还需确认lane数与时钟频率是否与sensor规格一致，否则会出现probe成功但无数据的情况。

多相机同步的实现与验证

多相机同步分为“硬件同步”和“软件同步”两个层次。硬件同步通过外部触发信号（FSYNC）同时驱动所有相机的曝光起点，是真正意义上的帧对齐；软件同步则依赖各相机时间戳，在应用层做近似对齐，精度受USB调度和驱动延迟影响。GMSL与MIPI CSI相机通常支持外部触发，USB相机则多依赖UVC的绝对曝光控制，能力有限。

以四路GMSL环视相机为例，合理做法是：由解串器或外部MCU产生一路周期性FSYNC，同时接入四路相机的触发输入；在驱动中配置相同的曝光时间与增益；应用层读取每路/dev/video*的V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC时间戳，计算同一帧序号下的时间差。若时间差稳定在毫秒级以内，可认为同步有效；若持续漂移，则需检查触发信号是否被正确分路、线缆长度是否一致。

调试要点与常见问题

调试阶段建议按“物理层→驱动层→应用层”顺序排查。物理层关注线缆、供电、连接器方向；驱动层关注dmesg报错、设备树匹配、I²C通信；应用层关注格式协商、缓冲区数量、时间戳。常见问题包括：GMSL相机出图但颜色异常（多为像素格式或Bayer顺序配置错误）、USB多相机带宽不足导致掉帧（需降低分辨率或使用独立控制器）、MIPI CSI相机probe成功但无数据（多为lane映射或时钟配置错误）。

完成上述配置后，建议用一段最小化的采集脚本连续运行10～30分钟，记录帧率、丢帧数与时间戳偏差，作为系统稳定性的基线。只有基线稳定，后续的视觉算法与机器人控制才有可靠输入。