一、课程导论与硬件基础：多摄像头系统概述、同步需求分析、主流硬件平台介绍、摄像头接口对比
各位同学，欢迎来到《嵌入式多摄像头驱动同步开发实战》的第一课。
说实话，多摄像头系统这几年越来越常见了。从手机的后置三摄，到自动驾驶的环视系统，再到机器人的视觉导航——一个摄像头不够用，两个起步，四个不嫌多。我最早接触多摄像头项目是在2018年，当时给一台AGV小车做双目视觉避障。本以为就是两个摄像头同时采集，结果一上手才发现，同步问题差点让我把开发板砸了。
嗯，这节课我们就从最基础的开始聊。把硬件平台、接口类型、同步需求这些底层的逻辑先理清楚。地基打不牢，后面写驱动就是空中楼阁。
1.1 多摄像头系统概述
什么叫多摄像头系统？说白了，就是在一个嵌入式平台上，同时挂载两个或以上的摄像头，让它们协同工作。
常见的应用场景有这么几类：
- 立体视觉：两个摄像头模拟人眼，通过视差计算深度。我做过一个双目测距项目，两个OV5640摄像头并排安装，基线距离6cm。嗯，这个距离不是随便定的，跟被测物体的距离范围直接相关。
- 全景拼接：4个或6个摄像头覆盖360度视野。比如车载环视系统，四个鱼眼镜头分别朝向前后左右，通过算法拼接成鸟瞰图。
- 多视角同步采集：比如动作捕捉，十几个摄像头从不同角度同时拍摄。这种场景下，同步精度要求极高，帧级别的偏差都会导致重建失败。
- 多光谱融合：可见光+红外+深度，不同摄像头采集不同波段的信息，然后融合。我在一个安防项目中做过可见光与热成像的融合，白天用可见光，晚上切热成像，两个摄像头需要精确对齐时间戳。
你想想看，这些场景有一个共同点：所有摄像头必须在同一时刻采集图像。如果A摄像头比B摄像头晚了10毫秒，那对于高速运动的物体来说，画面就错位了。这就是我们为什么要讲同步。
3.2 同步需求分析
同步，到底同步什么？
我个人习惯把同步需求分成三个层次：
| 同步层次 | 精度要求 | 典型场景 | 实现方式 |
|---|---|---|---|
| 帧同步 | ±1帧（约33ms@30fps） | 多视角监控、全景拼接 | 软件触发、PTP时间同步 |
| 行同步 | ±1行（约30μs@1080p） | 立体视觉、深度计算 | 硬件触发、FSIN信号 |
| 像素同步 | ±1像素（约10ns） | 高速摄影、科学成像 | 专用同步芯片、同源时钟 |
这里我要特别强调一下：不是所有项目都需要像素级同步。我曾经犯过一个错误，在一个全景拼接项目里，花了大量精力去做硬件行同步，结果发现帧同步就足够了。因为拼接算法本身有图像配准步骤，几毫秒的偏差可以被算法补偿掉。嗯，这就是典型的过度设计。
所以，做同步需求分析时，先问自己三个问题：
- 我的应用对时间偏差的容忍度是多少？
- 摄像头之间是否需要共享曝光时刻？
- 我能不能接受后处理对齐（比如用时间戳）？
1.3 主流硬件平台介绍
做多摄像头开发，选平台是第一关。我这些年用过树莓派、Jetson Nano、RK3588、还有FPGA方案。这里重点讲两个最常用的：树莓派和Jetson Nano。
1.3.1 树莓派（Raspberry Pi）
树莓派，尤其是Pi 4和Pi 5，是入门多摄像头开发的首选。为什么？便宜、资料多、社区活跃。
树莓派的CSI接口支持两个摄像头（Pi 5支持三个），通过Unicam驱动可以同时采集。但要注意：树莓派的GPU和ISP资源有限。我试过在Pi 4上同时跑两个1080p@30fps的摄像头，CPU直接飙到80%。如果要做实时处理，建议降分辨率或者降帧率。
1.3.2 Jetson Nano
Jetson Nano是英伟达的入门级AI计算平台。它最大的优势是GPU，适合做实时图像处理。比如立体匹配、目标检测这些计算密集型的任务。
Jetson Nano的CSI接口支持最多4个摄像头（通过两个CSI接口，每个接口支持2-lane或4-lane）。它的驱动基于V4L2和Tegra的VIP（Video Input Processor）。我个人觉得Jetson Nano的同步机制比树莓派更灵活，因为它支持硬件触发和GPIO同步。
不过，Jetson Nano的功耗比树莓派高不少。我记得有一次在户外做测试，电池供电，Jetson Nano加上两个摄像头，续航不到两小时。嗯，选平台时一定要考虑功耗约束。
| 特性 | 树莓派 Pi 5 | Jetson Nano |
|---|---|---|
| CPU | BCM2712 (4核A76) | Quad-core A57 |
| GPU | VideoCore VII | 128-core Maxwell |
| 最大摄像头数 | 3 (CSI) | 4 (CSI) |
| 硬件同步 | 有限（依赖GPIO） | 支持（硬件触发） |
| 功耗 | 约5-7W | 约10-15W |
| 价格 | 约500元 | 约900元 |
1.4 摄像头接口对比：CSI、USB、以太网
摄像头怎么跟开发板连？目前主流的接口就三种：CSI、USB、以太网。每种接口的同步能力完全不同。
1.4.1 CSI（Camera Serial Interface）
CSI是MIPI联盟定义的串行接口标准。它直接连接摄像头传感器和SoC的ISP（图像信号处理器）。
CSI最大的优势是低延迟、高带宽、支持硬件同步。它通过差分信号传输，抗干扰能力强。CSI-2接口支持多数据通道（lane），每个lane最高可达2.5Gbps。对于多摄像头来说，CSI可以通过FSIN（Frame Sync Input）信号实现帧同步。
我在项目中用过IMX219和OV5640，都是CSI接口。同步时，只需要把两个摄像头的FSIN引脚连到同一个GPIO上，由SoC统一触发。嗯，这个我们在后面的驱动章节会详细讲。
1.4.2 USB
USB摄像头最大的优点是即插即用。UVC（USB Video Class）驱动是内核自带的，插上就能用。对于快速原型验证来说，USB摄像头非常方便。
但是，USB摄像头的同步是个大问题。为什么？因为USB是主从架构，所有数据都要经过USB Host控制器。两个USB摄像头同时传输数据，带宽是共享的。而且USB的传输延迟不确定，你没法保证两个摄像头在同一时刻完成曝光。
我试过用两个USB摄像头做双目视觉，结果发现两个画面的时间戳差了20-50毫秒。对于静止物体还好，一旦物体运动，画面就错位了。后来我改用CSI接口，问题才解决。
1.4.3 以太网（IP Camera）
以太网摄像头，也叫网络摄像头或IP Camera。它通过以太网传输视频流，通常使用RTSP或ONVIF协议。
以太网摄像头的优势是传输距离远（100米以上），适合分布式部署。比如一个工厂里装10个摄像头，通过交换机连接到中央服务器。
但同步问题更严重。以太网是网络传输，延迟和抖动都很大。即使你用PTP（精确时间协议）做时间同步，也只能做到毫秒级。而且IP Camera的帧率通常较低（15-30fps），不适合高速场景。
我记得有一次帮客户做多摄像头同步采集，客户坚持要用IP Camera，说布线方便。结果我们用了PTP协议，同步精度大概在±5ms。对于他们的应用（人员计数）来说，勉强够用。但如果要做运动分析，这个精度就不行了。
| 接口类型 | 同步精度 | 传输距离 | 带宽 | 适用场景 |
|---|---|---|---|---|
| CSI | 像素级（ns） | 短（<30cm） | 高（Gbps） | 嵌入式、实时同步 |
| USB | 帧级（ms） | 中（<5m） | 中（480Mbps-5Gbps） | 原型验证、非同步场景 |
| 以太网 | 毫秒级（PTP） | 远（>100m） | 中（100Mbps-1Gbps） | 分布式、监控系统 |
小结
这节课我们聊了多摄像头系统的应用场景、同步需求的三个层次、树莓派和Jetson Nano两个主流平台，以及CSI、USB、以太网三种接口的对比。
我个人觉得，做多摄像头开发，第一步就是明确你的同步需求。不要一上来就追求最高精度的同步，也不要随便用USB摄像头凑合。根据你的应用场景，选择合适的平台和接口，这才是正确的思路。
下一节课，我们会深入Linux内核的V4L2框架，看看摄像头驱动是怎么工作的。嗯，到时候我会带大家手写一个简单的摄像头驱动，敬请期待。