基于RK3576的YOLOv5s实时目标检测优化实践

1. 项目概述与硬件平台选型

在嵌入式AI视觉领域，实时目标检测一直是极具挑战性的任务。今天我要分享的是基于米尔MYD-LR3576开发板的YOLOv5s实时检测方案，这套系统成功实现了500万像素摄像头输入、640×640分辨率检测、1080P屏幕输出的全流程40ms延迟控制。不同于常见的纯软件优化方案，我们将重点放在如何充分发挥RK3576芯片的异构计算能力上。

选择RK3576作为核心处理器主要基于三个考量：首先，其内置的6TOPS算力NPU完全能满足YOLOv5s的推理需求；其次，RGA（Raster Graphic Acceleration）硬件加速单元可高效处理图像格式转换；最后，四核A72+四核A53的CPU配置为系统调度提供了充足余量。这套组合拳让我们在保持低功耗的同时，获得了媲美桌面级设备的处理性能。

2. 系统架构设计与性能目标

2.1 硬件配置详解

核心硬件组成包括：

• 主控板：米尔MYD-LR3576开发板（搭载Rockchip RK3576芯片）
• 图像采集：500万像素USB摄像头（支持MJPEG/YUYV格式）
• 显示输出：4K HDMI显示屏（通过Weston桌面环境显示）

特别需要注意的是摄像头接口选择。我们测试发现，USB3.0接口的UVC摄像头在传输640×480@30fps的YUYV格式时，实际带宽占用约180MB/s，这已经接近USB2.0的理论上限。因此强烈建议使用原生支持USB3.0的摄像头模组，避免因带宽不足导致的帧丢失。

2.2 软件栈构建

系统采用米尔官方V2.0.0 SDK提供的buildroot镜像，内核版本为6.1.118。关键软件组件包括：

• 视频采集：v4l2框架
• 图像处理：RGA驱动（版本1.2.3）
• NPU推理：rknn-toolkit2（版本1.3.0）
• 显示输出：Wayland-client + DRM框架

提示：在交叉编译环境搭建时，务必确认工具链的GLIBC版本与目标系统匹配。我们曾因版本不一致导致RGA驱动无法正常加载。

2.3 实时性指标分解

我们将端到端延迟拆解为三个关键阶段：

1. 采集阶段：摄像头输出一帧图像的时间（≤33ms @30fps）
2. 处理阶段：格式转换+NPU推理（目标≤25ms）
3. 显示阶段：检测结果渲染输出（目标≤5ms）

通过这样的分解，可以清晰地定位性能瓶颈所在。实测表明，在未优化状态下，仅YUYV到RGB的格式转换就会消耗15ms以上，这直接促使我们引入RGA硬件加速方案。

3. 数据处理流水线优化实践

3.1 原始CPU方案的性能瓶颈

初始方案采用纯CPU处理流水线：

code复制YUYV采集 → CPU转换RGB → CPU缩放640x640 → NPU推理 → CPU绘制结果 → 显示

使用v4l2-ctl工具检测摄像头参数：

bash复制v4l2-ctl -d /dev/video0 --list-formats-ext

结果显示摄像头最佳支持640×480@30fps的YUYV格式。在CPU上测试格式转换性能：

显然，CPU处理1080P分辨率时已接近能力上限，这促使我们转向硬件加速方案。

3.2 RGA硬件加速实现

RGA（Raster Graphic Acceleration）是RK芯片独有的2D加速引擎，支持：

• 色彩空间转换（如YUYV→RGB）
• 图像缩放（支持双线性插值）
• 旋转/镜像操作

关键优化点在于内存访问模式。RGA支持三种数据传输方式：

1. 物理地址直连（最快）
2. DMA传输
3. 虚拟地址访问（最慢）

实测性能对比：

实现代码示例（RGA初始化）：

c复制rga_info_t src = {0};
rga_info_t dst = {0};
src.fd = -1; // 使用物理内存
src.virAddr = yuyv_buffer; 
src.mmuFlag = 1;

dst.fd = -1;
dst.virAddr = rgb_buffer;
dst.mmuFlag = 1;

// 设置转换参数
RECT src_rect = {0, 0, 640, 480};
RECT dst_rect = {0, 0, 640, 640};
rga_set_rect(&src.rect, src_rect.x, src_rect.y, src_rect.w, src_rect.h, 640, 480, RK_FORMAT_YUYV_422);
rga_set_rect(&dst.rect, dst_rect.x, dst_rect.y, dst_rect.w, dst_rect.h, 640, 640, RK_FORMAT_RGBA_8888);

// 执行转换
c_RkRgaBlit(&src, &dst, NULL);

3.3 NPU推理流水线优化

YOLOv5s模型通过rknn-toolkit2转换为RKNN格式后，推理流程包含：

1. 模型加载（约500ms，启动时一次）
2. 输入张量准备（依赖前级RGA输出）
3. 推理执行
4. 结果解析

实测各阶段耗时：

• rknn_inputs_set：0.8ms（DMA传输）
• rknn_run：26-31ms（NPU推理）
• rknn_outputs_get：1.2ms
• 后处理（NMS等）：8ms

我们发现NPU利用率仅60%左右，通过以下手段进一步优化：

1. 双缓冲流水线：当NPU处理第N帧时，CPU正在准备第N+1帧的输入
2. 固定量化参数：避免动态量化带来的额外开销
3. 输出结果异步处理：将检测框绘制与下一帧处理重叠

优化前后对比：

4. 显示通路优化与系统集成

4.1 从OpenCV到Wayland直显

开发初期常用OpenCV的imshow显示结果，但其存在两个问题：

1. 需要CPU参与图像传输
2. 无法直接访问DRM显示层

我们最终采用Wayland-client方案，关键步骤：

c复制// 创建Wayland显示连接
struct wl_display *display = wl_display_connect(NULL);
struct wl_registry *registry = wl_display_get_registry(display);

// 获取Surface
struct wl_surface *surface = wl_compositor_create_surface(compositor);

// 配置缓冲区
struct wl_buffer *buffer = create_shm_buffer(width, height, stride, format);

// 提交渲染
wl_surface_attach(surface, buffer, 0, 0);
wl_surface_commit(surface);

实测显示延迟从8ms降低到3ms以下。

4.2 多摄像头资源管理

在多路摄像头场景下，内存带宽成为瓶颈。我们对比了两种方案：

虚拟内存方案（4路摄像头）：

• CPU占用：320%
• 内存带宽：4.2GB/s
• 帧率：18FPS

DMA方案（4路摄像头）：

• CPU占用：95%
• 内存带宽：1.8GB/s
• 帧率：25FPS

关键配置项：

bash复制# 启用DMA缓冲区
echo 1 > /sys/module/videobuf2_core/parameters/dma_contig_mode

# 设置RGA DMA模式
export RGA_DMA_BUFFER=1

5. 实测性能与优化建议

5.1 端到端性能指标

最终系统在以下配置下的表现：

• 输入分辨率：640×480@30fps (YUYV)
• 检测分辨率：640×640 (RGB)
• 输出显示：1920×1080@20fps

各阶段耗时：

1. 采集：16.6ms
2. 格式转换：1.1ms (RGA DMA)
3. NPU推理：28.5ms
4. 结果显示：2.8ms
   总计：49ms（实测稳定在20FPS）

5.2 关键优化经验

1. 内存访问模式决定性能：物理地址>DMA>虚拟内存
2. 流水线并行化：采集/处理/显示应使用独立线程
3. NPU预热：连续推理时，前5帧耗时可能是平均值的2倍
4. 温度管理：持续高负载时，CPU降频会影响NPU性能

注意：RKNN模型转换时的量化参数会显著影响精度。建议先用float16模式验证模型正确性，再尝试int8量化。

6. 扩展应用与未来优化

当前系统已成功应用于工业质检场景，但仍有优化空间：

1. 动态分辨率调整：根据检测目标大小自动切换输入分辨率
2. 多模型级联：先用轻量级模型做区域推荐，再用精确模型检测
3. 异构任务调度：将预处理、后处理任务分配到不同计算单元

一个实际应用中的技巧：当检测到连续10帧无目标时，可自动降低帧率至10FPS，待重新检测到目标后再恢复全速运行。这种方法在电池供电场景下可节省30%以上功耗。

这套方案的核心价值在于展示了如何通过系统级优化（而不仅是算法优化）来释放嵌入式AI硬件的全部潜力。无论是R3576还是其他异构计算平台，硬件加速单元的高效协同都是实现实时性能的关键。