硬件平台选型：主流边缘计算板卡对比
做边缘智能摄像头，第一步就是选硬件。我这些年折腾过不少板子，从最早的树莓派，到后来的Jetson Nano，再到最近很火的RK3588。说实话，没有完美的板子，只有最适合你项目的板子。
今天我就把这三款主流板卡掰开揉碎讲清楚。你想想看，选错了硬件，后面算法移植、性能调优全白费。这个坑我踩过，不希望你也踩。
三款板卡的核心定位
先给个直观的对比。这三款板卡代表了三个不同的方向：
| 特性 | Jetson Nano | RK3588 | 树莓派4B |
|---|---|---|---|
| AI算力 | 472 GFLOPS | 6 TOPS (NPU) | 无专用NPU |
| CPU | 4核Cortex-A57 | 4核A76+4核A55 | 4核Cortex-A72 |
| GPU | 128核Maxwell | Mali-G610 MP4 | VideoCore VI |
| 内存 | 4GB LPDDR4 | 8/16GB LPDDR4X | 2/4/8GB LPDDR4 |
| 价格 | 约800元 | 约1200元 | 约400元 |
| 功耗 | 5-10W | 8-15W | 3-7W |
嗯，光看参数你可能觉得RK3588最猛。但实际项目里，事情没那么简单。
Jetson Nano：AI入门的黄金标准
我个人习惯把Jetson Nano叫做「AI开发者的瑞士军刀」。为什么？因为它有NVIDIA完整的软件生态。
我在项目中遇到过最头疼的事，就是模型移植。你用PyTorch训练好的模型，想部署到边缘设备上，中间要过好几道坎。但Jetson Nano有TensorRT，直接帮你把模型优化成硬件能跑的形式。这个体验，其他板子暂时比不了。
核心优势：
- TensorRT推理引擎，模型优化一步到位
- DeepStream SDK，视频分析全家桶
- 社区资源丰富，遇到问题基本能搜到答案
但Jetson Nano也有短板。它的CPU是A57架构，说实话有点老了。我做过一个项目，需要同时跑目标检测和图像预处理，CPU直接飙到100%。后来只能把预处理挪到GPU上做，才勉强稳住。
避坑指南：我曾经在Jetson Nano上跑YOLOv5s，帧率只有15FPS。后来发现是没开TensorRT的FP16模式。开了之后直接到30FPS。记住，默认设置往往不是最优的。
RK3588：国产芯片的逆袭
说实话，两年前我对国产芯片做AI还有偏见。直到我拿到RK3588的样片，跑了一遍MobileNet...嗯，真香。
RK3588最大的亮点是那个6 TOPS的NPU。它不是通用GPU，而是专门为神经网络设计的加速器。说白了，跑AI模型的时候，功耗比Jetson Nano低，算力还更高。
我建议你重点关注它的多核架构。4个A76大核+4个A55小核，这个组合很灵活。你可以把视频解码、图像预处理扔给A76，把网络通信、日志管理扔给A55。我在一个8路视频分析项目里就是这么干的，CPU占用率从来没超过60%。
个人经验：RK3588的NPU目前只支持INT8量化。如果你模型精度要求高，得先在PC上做量化校准。我一般用RKNN Toolkit，流程还算顺畅。但注意，有些算子NPU不支持，会回退到CPU跑，性能直接掉一半。
不过RK3588的软件生态还在追赶。比如你想用OpenCV的GPU加速，Jetson Nano有现成的，RK3588就得自己编译。这个学习成本，你得算进去。
树莓派：学习可以，生产慎用
树莓派4B，我估计很多人入门都是从它开始的。我自己也是。但说句实在话，做边缘智能摄像头，它真的不太够用。
为什么？因为没有专用的AI加速器。你跑个轻量级的MobileNet SSD，帧率也就5-8FPS。做实时视频分析？基本没戏。
但树莓派有个不可替代的优势：生态。你想接什么传感器、用什么通信模块，基本都有现成的方案。我建议你把它当「原型验证平台」用。先在树莓派上把整个流程跑通，再迁移到Jetson Nano或RK3588上做性能优化。
适合场景：
- 学习Linux、Python、OpenCV基础
- 验证摄像头选型、接口兼容性
- 做低帧率的图像采集和上传
摄像头选型与接口
板卡选好了，接下来是摄像头。这里面的坑，比板卡还多。我见过太多人，板子买回来发现摄像头不兼容，或者画质根本达不到要求。
三种接口的对比
| 接口类型 | 带宽 | 传输距离 | 适用场景 |
|---|---|---|---|
| USB摄像头 | USB 3.0: 5Gbps | 5米以内 | 快速原型、单路视频 |
| CSI摄像头 | MIPI: 1Gbps/lane | 30厘米以内 | 低延迟、多路视频 |
| IP Camera | 百兆/千兆以太网 | 100米以上 | 分布式部署、远程监控 |
USB摄像头：最省心的选择
如果你只是想快速验证算法，USB摄像头是最省心的。插上就能用，OpenCV的VideoCapture直接读。我在做第一个边缘摄像头原型时，就是用的罗技C920，从拆包装到跑出画面，不到10分钟。
但USB摄像头有个致命问题：带宽共享。你插一个USB 2.0的摄像头，占掉480Mbps带宽。如果同时接两个，帧率直接掉一半。我试过在Jetson Nano上接4个USB摄像头，结果每个只能跑10FPS，根本没法用。
避坑指南：我曾经买过一个号称1080P 60FPS的USB摄像头，结果在树莓派上只能跑30FPS。后来发现是USB控制器瓶颈。记住，标称帧率是在PC上测的，在嵌入式板卡上要打对折。
CSI摄像头：低延迟的王者
CSI接口是直接连到SoC的MIPI控制器上的。说白了，数据不走USB总线，延迟极低。我在做实时人脸识别时，用CSI摄像头延迟只有30ms，USB摄像头要80ms。这个差距，在安防场景里就是能不能抓到关键帧的区别。
但CSI摄像头也有麻烦。不同板卡的CSI接口定义不一样。Jetson Nano用15针的CSI接口，树莓派用22针的。你买摄像头之前，一定要确认排线是否匹配。我建议你直接买板卡官方推荐的摄像头型号，省得折腾。
个人经验：RK3588的CSI接口支持4路摄像头同时输入。我做多路视频分析时，用4个IMX415摄像头，每路1080P 30FPS，总延迟控制在50ms以内。这个性能，USB摄像头根本做不到。
IP Camera：分布式部署的利器
如果你的摄像头要装在几十米外，或者需要远程访问，IP Camera是唯一选择。它通过以太网传输，距离不是问题。而且现在很多IP Camera支持RTSP协议，OpenCV可以直接拉流。
但IP Camera的延迟是个大问题。我测过海康威视的摄像头，从拍摄到画面显示，延迟在200-500ms之间。做实时控制肯定不行，但做视频存储和事后分析，完全够用。
另外要注意，IP Camera的解码很吃CPU。一个1080P的H.265流，解码就要占掉一个CPU核心。如果你要同时处理4路，CPU基本就满了。我建议你用支持硬件解码的板卡，比如RK3588就有专门的视频解码单元。
选型决策树
说了这么多，到底怎么选？我画了个决策流程图，你照着走就行。
这个决策树是我在实际项目中总结出来的。你照着走，基本不会出大错。但记住，选型只是第一步。真正考验人的，是后面的驱动调试、算法移植和性能优化。
好了，硬件选型就聊到这儿。下一章我们开始搭建开发环境，到时候我会手把手教你配置Jetson Nano和RK3588。有什么问题，欢迎随时交流。
公众号:蓝海资料掘金营，微信deep3321