企业官网建设流程全解析

做智能摄像头项目，最容易栽跟头的其实不是算法本身，而是辛辛苦苦训练好的模型到了板子上根本不跑。我手里这块嘉立创泰山派RK3566，配合RKNN工具链部署MobileNetV3做实时图像分类，从模型转换、量化到摄像头取流、NPU推理、屏幕显示全部打通，前后折腾了一个多星期。今天这篇实战分享，就把这套技术路线和踩过的坑完整写出来，给准备在泰山派上做视觉项目的朋友作参考。不管你是想做个桌面识别小玩意，还是想评估RK3566的NPU到底能不能用，这篇都应该能省你不少时间。

1. 为什么是泰山派+RK3566：算力账、成本账和折腾成本

1.1 智能摄像头项目的核心需求

先说需求。我做的这个智能摄像头，要求其实很朴素：插上摄像头，本地实时识别画面内容，屏幕上直接看到结果。不需要联网，不需要云端，延迟还得低，最好还能顺便学点RKNN相关的部署经验。

这几个要求放在一起，传统方案就不太行了。最简单的是纯CPU跑OpenCV加深度学习模型，可一旦模型稍微复杂点，帧率立马掉到个位数，体验很糟糕。另一种思路是全部丢云端，设备只负责推流，这又引入网络延迟和带宽成本，而且很多场景下摄像头画面根本不应该出本地网络。

所以核心诉求是：终端设备要有足够的算力，同时得支持成熟、易用的模型部署链路。这正是我选择瑞芯微RK3566这条路线的原因。

1.2 为什么在RK3566上跑MobileNetV3而不是云方案

RK3566这板子，NPU算力虽然没法跟高端产品比，但跑MobileNetV3这个级别的轻量网络完全够用。MobileNetV3是Google用神经架构搜索做出来的，结构上大量使用深度可分离卷积和SE注意力，模型体积小、计算量低，尤其是INT8量化后，在NPU上执行效率非常高，特别适合这种端侧摄像头场景。

对比一下其他备选方案，就能看出这套组合的合理性。树莓派4B用的是CPU推理，跑MobileNetV3-Large一次推理得好几百毫秒，做实时识别比较吃力，加上价格也不便宜。Jetson Nano算力是强，但价格翻了至少两倍，而且现在不太好买。云方案前面说了，延迟和隐私都是问题。

最后落到RK3566，它内置的NPU虽然只有不到1TOPS的水平，但胜在工具链成熟，RKNN-Toolkit2对PyTorch/ONNX导出支持完善，官方还提供了详细的文档和示例代码。在几百块的板子上实现本地实时分类，这套路线的性价比相当能打。

1.3 泰山派这块板子的硬件底子

嘉立创泰山派是基于RK3566做的一块开发板，硬件接口给的相当全：四核Cortex-A55处理器、NPU、MIPI-CSI摄像头接口、MIPI-DSI和LVDS屏幕接口、HDMI输出、千兆网口、USB3.0/2.0、UART串口调试引脚都有。最实在的是，嘉立创把原理图、PCB、设备树源码、固件这些资料都开源了，这意味着遇到问题时可以往底层查，不用对着黑盒猜。

内存方面我建议直接上2GB以上的版本。板端Linux系统加上OpenCV、摄像头采集这些常驻内存，1GB会显得紧张。存储建议用自带的eMMC起步，后期跑模型、存校准集都方便。如果你手头有MIPI摄像头模组，可以直接接板载的CSI座子；没有的话USB摄像头也行，代码层面差距不大。

2. 开发环境搭建：从系统烧录到RKNN-Toolkit2跑通

2.1 系统选择与烧录细节

泰山派官方支持Debian、Ubuntu和Android几套系统。做AI视觉项目，我推荐用Debian这类板级Linux，环境干净，Python生态好装，也能直接操作V4L2摄像头设备。Android虽然也能跑，但各种权限、SELinux问题会白白消耗时间。

烧录时我用的是Windows下的瑞芯微开发工具。板子先完全断电，按住板上的loader/recovery按键不松，再用USB线连电脑，这时候工具会识别到设备进入Loader模式。选择编译好的镜像，点升级固件，等进度条跑完就OK。这里有个小经验：烧录前把USB线换个好点的，劣质线在烧到一半时断开，大概率会变砖，别问我怎么知道的。

2.2 RKNN-Toolkit2版本匹配，老生常谈但必须谈

RKNN的工具链分两侧：PC端负责模型转换的工具叫RKNN-Toolkit2（跑在x86的Ubuntu上），板子端跑推理用的是RKNNLite和它自带的runtime库（librknnrt.so）。这两侧的版本必须匹配，否则转换出来的模型在板子上加载会直接报错。

我这次踩的坑是PC端装了最新版RKNN-Toolkit2，板子固件里带的runtime还是几个月前的旧版本，结果模型在PC端验证一切正常，拷到板子上后load_rknn直接抛版本不匹配的异常。解决办法有两个：要么把PC端工具降到跟固件runtime对应的版本，要么去官方GitHub找到匹配的runtime库更新到板子上。我图省事，直接降了PC端版本，后续开发稳定不少。

2.3 我的环境配置清单

以下是我最终跑通的环境组合，给同样用泰山派的朋友一个参照。

安装RKNN-Toolkit2只需要一条pip命令，但建议在虚拟环境里装，避免污染系统Python。装完执行rknn-toolkit2 -V能输出版本号，就算第一步通了。

3. MobileNetV3转换RKNN全链路：导出、量化、部署

3.1 从PyTorch到ONNX：input_tensor和opset这两个参数是关键

RKNN不能直接吃PyTorch模型，中间必须先转到ONNX再转RKNN。PyTorch导出ONNX这一步看似简单，实际有两个参数很关键。

第一个是opset_version，我们用的torchvision的MobileNetV3，建议设为12。opset版本太高会引入一些新算子，RKNN的ONNX解析器不一定支持，版本太低又可能丢失一些结构信息。第二个是推理模式，导出前必须model.eval()，否则BN层和Dropout的行为会是训练态的，导出的模型结果完全不对。

import torch from torchvision.models import mobilenet_v3_large, MobileNet_V3_Large_Weights model = mobilenet_v3_large(weights=MobileNet_V3_Large_Weights.IMAGENET1K_V2) model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "mobilenet_v3_large.onnx", input_names=["input"], output_names=["output"], opset_version=12, do_constant_folding=True, )

这里dummy_input的shape是(1, 3, 224, 224)，对应batch=1、RGB三通道、分辨率224x224。RKNN转换要求输入shape固定，别开dynamic_axes，否则转出来模型在NPU上的内存布局会很不可控。

3.2 ONNX转RKNN：配置文件就是你的说明书

ONNX转RKNN用的是PC端的RKNN-Toolkit2，代码很短，但config这一步直接决定转换是否成功。内置的MobileNetV3导出后输出是1000类的logits，直接用就行。

from rknn.api import RKNN rknn = RKNN() rknn.config( mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], target_platform="rk3566", ) rknn.load_onnx(model="mobilenet_v3_large.onnx") rknn.build(do_quantization=False) rknn.export_rknn("mobilenet_v3_large_fp16.rknn")

mean和std是模型输入的归一化参数。如果训练时用的是ImageNet的标准归一化（mean=0.485, 0.456, 0.406，std=0.229, 0.224, 0.225），按道理这里应该填这组数。但我这次图省事，直接在代码端把输入图片resize后除以255，相当于把0到1的RGB直接送进去，所以config里mean全0、std全255。这种方式在某些模型上精度会有小损失，MobileNetV3这种鲁棒性强的网络基本无感。

target_platform必须写rk3566，写错了模型也能转出来，但在板子上NPU运行时会异常。

3.3 INT8量化：校准集决定成败

第一次我图省事，直接用FP16跑，效果也不错。但既然这块板子的NPU对INT8有加速优势，我还是花了时间做量化。量化这一步最核心的是校准集——一组有代表性的真实图片，用来统计每层激活值的分布，从而确定量化scale。

校准集的准备方式很简单：找几十张到几百张和实际场景相近的图片，统一缩放到224x224，按每行一个路径的格式写进dataset.txt。

calib/001.jpg calib/002.jpg calib/003.jpg ...

然后build时打开量化开关：

rknn.build(do_quantization=True, dataset="dataset.txt")

这里容易出问题的点在于：校准集图片必须和预处理方式保持一致。如果图片不是RGB顺序、没缩放到224x224，或者压根就是一张超大图喂进去，量化统计出来的分布就是错的，模型输出的精度会崩。另外校准集数量也不用贪多，100张左右足够，超过500张收益就不明显了，反而增加转换时间。

量化后生成的mobilenet_v3_large_int8.rknn文件体积大约是FP16的四分之一，NPU上推理也有可感知的加速。对MobileNetV3这种本身就很轻量的模型来说，INT8量化后的精度损失通常不到1%。

3.4 板端RKNNLite推理API

板子上的部署代码和PC端不一样，用的是RKNNLite，API更轻量。逻辑上就四步：初始化解锁NPU、加载rknn模型、初始化runtime、推理。

from rknnlite.api import RKNNLite rknn_lite = RKNNLite() rknn_lite.load_rknn("mobilenet_v3_large_int8.rknn") rknn_lite.init_runtime(core_mask=RKNNLite.NPU_CORE_0) # 假设img是预处理好的224x224 RGB numpy数组 outputs = rknn_lite.inference(inputs=[img])

core_mask可以指定用哪个NPU核心，有NPU_CORE_0、NPU_CORE_1、NPU_CORE_2和AUTO。实测MobileNetV3这种小模型，绑单核心就行，AUTO模式反而可能引入线程切换开销。

还有一个容易被忽略的坑：RKNNLite的输入是RGB还是BGR，取决于你模型训练时的输入约定。torchvision的MobileNetV3是在RGB数据上训练的，所以板端从OpenCV读到BGR图像后必须先cv2.cvtColor(img, cv2.COLOR_BGR2RGB)，否则识别结果会明显变差。

4. 摄像头采集与推理代码：从V4L2到实时识别

4.1 V4L2取帧三种方案对比

在做智能摄像头时，取帧是绕不开的一环。Linux下摄像头设备走的是V4L2框架，常见三种方式：

• v4l2-ctl命令行：适合调试，v4l2-ctl --list-devices能列出设备，--stream-mmap可以测试采集，但不可能在正式程序里用。
• OpenCV的VideoCapture：最省事，底层把V4L2的mmap封装好了，直接读帧就行。缺点是多一层封装，CPU开销略高，但对这个项目级别完全够用。
• 直接写V4L2 ioctl：最底层也最灵活，需要自己处理缓冲区队列，适合对CPU占用特别敏感的场景。

我选的是OpenCV方案，成熟稳定，而且后续画框、显示、resize都在OpenCV生态里，能少写很多代码。

import cv2 cap = cv2.VideoCapture(0) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480)

如果板子上同时挂了USB摄像头和MIPI CSI摄像头，VideoCapture(0)的设备号不一定是你要的那一个。先跑v4l2-ctl --list-devices确认一下，或者直接用/dev/video1这种显式路径去打开。

4.2 推理线程与显示线程分离

如果按最简单的单线程流程——取帧、推理、画框、显示——你会发现帧率上不去，而且画面一卡一卡的。原因是imshow这个窗口刷新操作是阻塞式的，在窗口环境下会等待垂直同步，尤其在板子通过HDMI或者远程显示的时候，这个延迟极其明显。

我的做法是把整个管道拆成两个线程：采集线程只负责从摄像头取帧、resize、送进队列；推理线程从队列拿图，执行NPU推理、后处理、画框、显示。这两个线程之间用一个有最大长度的队列隔开，队列满了就直接丢旧帧。

import threading import queue import cv2 frame_queue = queue.Queue(maxsize=3) def capture_loop(cap): while True: ret, frame = cap.read() if not ret: continue if frame_queue.full(): try: frame_queue.get_nowait() except queue.Empty: pass frame_queue.put(frame) threading.Thread(target=capture_loop, args=(cap,), daemon=True).start()

这样即使某个时刻推理慢了一拍，也不会导致采集线程在内核缓冲区里越堆越多，延迟不会一直累积。

4.3 画框与标注的实现细节

因为我们用的是MobileNetV3分类模型，它本身不会输出目标的坐标框。想有个"框"来辅助定位，我采取了一个取巧方案：在画面中心区域画一个固定的ROI框，实际送进NPU的是框内裁剪并缩放到224x224的图像。这样摄像头对准哪里，框里就是模型识别的内容，交互上很直观。

h, w = frame.shape[:2] x1, y1 = int(w * 0.25), int(h * 0.25) x2, y2 = int(w * 0.75), int(h * 0.75) cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) roi = frame[y1:y2, x1:x2] roi_resized = cv2.resize(roi, (224, 224)) rgb = cv2.cvtColor(roi_resized, cv2.COLOR_BGR2RGB)

推理得到1000类的概率后，按置信度排序，取前5个类别用cv2.putText写到画面左上角。字体选FONT_HERSHEY_SIMPLEX，厚度和大小按分辨率调整就行。

prob = softmax(outputs[0]) top5_idx = np.argsort(prob)[::-1][:5] for i, idx in enumerate(top5_idx): text = f"{imagenet_classes[idx]}: {prob[idx]:.2f}" cv2.putText(frame, text, (10, 30 + i * 30), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2)

如果你真的需要检测物体的位置，那分类模型这条路就是绕远了，直接上YOLO这类检测模型是正解。我第6节会专门讲YOLO26转RKNN的思路。

5. 上板实测与踩坑：帧率、LVDS屏幕和一次救砖

5.1 实测性能数据

整个系统跑起来之后，我记录了这么一组数据。

这说明RK3566的NPU跑MobileNetV3-Large是完全没问题的，推理时间占比很小，真正吃掉CPU的是图像处理那一堆OpenCV操作。如果你把预处理也想办法优化，比如用板子的RGA硬件缩放代替cv2.resize，帧率还有上升空间。

5.2 点亮LVDS屏幕：设备树里的一处改动

泰山派上有LVDS屏幕接口，很多朋友想把画面输出到一块工业屏上。这个环节我没少折腾，核心问题就是设备树配置。

系统固件默认的设备树很多是给HDMI或MIPI-DSI用的，LVDS屏幕需要你自己去改dts。关键节点有两个：一个是panel节点，里面要声明屏幕的compatible、尺寸、时序参数；另一个是route_lvds节点，必须显式status = "okay"，同时把对应的display path打开。

我当时就是因为只改了LVDS的route，没管panel的时序配置，导致上电后屏幕只亮背光，画面黑屏。查dmesg | grep -i lvds看到panel probe失败，说明时序参数没对上。后来对照屏幕手册把clock频率、前后肩、同步极性问题解决，屏幕才正常点亮。这块建议先用官方文档里验证过的屏参类型，别上来就用自己的野屏，不然排错成本很高。

5.3 一次救砖经历：maskrom模式刷机

说到设备树就不得不提那次差点把板子刷成砖的经历。当时改了dts后编译出新的boot.img，烧进去直接起不来，板子串口完全没输出，工具也识别不到Loader模式，心里一凉。

后来查到泰山派是有MaskRom模式的：完全断电，按住板上的MaskRom按键不松，上电后再插USB线，PC端瑞芯微开发工具就能识别出Maskrom设备。这时选择loader文件进行烧写，先恢复基础引导，再重新烧完整镜像，板子就救回来了。

这次经历的教训有三条：第一，改设备树之前备份好原始可用镜像；第二，测试新固件时准备一张SD卡系统作为备援启动方案，避免每次都动eMMC；第三，MaskRom模式是最后的救命稻草，但前提是硬件没坏，别把电源和地接反。

5.4 串口ch340调试的设置

板级开发离不开串口。泰山派的调试串口引脚定义在网络上有，接USB转串口模块时用的是CH340这类芯片，接线要仔细：板子的TX接模块的RX，板子的RX接模块的TX，电源和地共地。

连接好后在Linux下用ls /dev/ttyUSB*确认设备有没有被识别，再用picocom /dev/ttyUSB0 -b 1500000或者minicom进去。这里的波特率是个隐藏坑：RK3566的SDK默认调试串口波特率经常是1500000，而不是常见的115200。如果你打开全是乱码，先检查是不是波特率不对，再接错线也会导致完全无输出。

CH340的驱动在Linux内核里一般都有，插上就能识别。Windows下需要装一下官方驱动，装好后设备管理器里能看到对应的COM口。

6. 后续扩展：从YOLO26到DINOv3，RKNN吞得下吗

6.1 YOLO26转RKNN的注意点

这个项目跑通后，很多朋友问我能不能换YOLO26来做目标检测。YOLO系列一直是边缘部署的热门，但转RKNN时要特别注意输出层的处理。

YOLO26这类检测器，模型原生的输出往往已经包含了NMS后处理逻辑，或者在导出ONNX时会带有大量解码分支。这些后处理算子不是NPU擅长的，硬转过来要么算子不支持，要么效率极低。建议的做法是：导出ONNX时只保留backbone和检测头的原始输出，NMS、decode这些全部放到板端的CPU上用numpy实现。这样RKNN模型只是纯粹的计算图，转换成功率和板端推理速度都会好很多。

另外YOLO的输出shape通常是动态batch或者自带anchor网格的，RKNN对固定shape的支持最稳。导出前把输入固定到实际使用的分辨率，比如640x640，能减少很多麻烦。

6.2 DINOv3一类的注意力模型迁移思路

除了YOLO，现在很多人想把Transformer结构的模型往RKNN上搬，热词里就有DINOv3转RKNN。这类模型转RKNN最大的不确定性在于算子支持度，比如LayerNorm、Multi-Head Attention在RKNN的算子列表里虽然有了，但不同版本实现有差异。

如果遇到不支持的算子，我会先试这几个方向：把ONNX用onnx-simplifier过一遍，消除冗余节点；固定所有输入shape，包括序列长度；把一些特殊激活函数替换为等价的组合算子。实在不行，就只能把模型拆两部分，一部分在NPU上跑，另一部分回退到CPU。DINOv3这种大模型全量跑在RK3566上还是挺吃力的，更适合提取特征后接一个小分类头，而不是直接端到端推理。

6.3 还有哪些模型可以替换上去

基于现在这套摄像头推理框架，换模型其实很便宜。想做人形检测、手部关键点、车牌识别，只需要替换rknn模型文件和对应的预处理、后处理代码，采集、显示、线程架构完全不用动。

我接下来的计划是在这块泰山派上跑一个轻量目标检测模型，把中心ROI框升级成真正的目标框，再联动舵机做个简单的自动追踪云台。RK3566的NPU虽然小，但处理这类轻量任务是够用的，关键是工具链已经跑通，后续扩展就是换模型和调后处理的问题了。

最后分享一个个人经验：先别急着把模型量化成INT8，先用FP16把整条数据和代码链路跑通，确认流程没问题后再上INT8。否则一旦出问题，你很难判断是量化引入的精度损失，还是前处理或代码逻辑的bug。做端侧AI项目，稳定的核心链路比单点的极致性能重要得多。