RV1103轻量化部署YOLOv5：从模型适配到实时检测的实践指南
1. RV1103与YOLOv5的轻量化适配基础
RV1103作为一款面向嵌入式场景设计的低功耗处理器，其内存和计算资源都相对有限。要在这样的硬件上跑通YOLOv5这样的现代视觉模型，首先得理解几个关键限制：
- 内存墙问题：开发板默认24MB的CMA内存区域，连最基本的摄像头帧缓存和模型推理都捉襟见肘
- 计算瓶颈：800MHz的主频处理640x640的输入分辨率，需要优化每一条指令
- 实时性要求：超过5FPS的检测速率才能算"实时"，这对流水线设计提出挑战
我实测发现，直接运行官方示例中的RTSP推流版YOLOv5会立即触发OOM（内存不足）错误。这就像试图用微型车载冰箱装下一头大象——必须做减法。轻量化的核心思路是：保留检测主干，剥离所有非必要组件。具体来说：
- 删除RTSP视频流传输模块
- 移除H264编码器（VENC组件）
- 简化结果渲染流程（OSD叠加改为终端打印）
提示：修改前建议用
grep -i cma /proc/meminfo确认当前CMA内存分配情况，我的开发板初始显示CmaTotal只有24576KB
2. 内存优化实战：从24MB到30MB的跨越
CMA（Contiguous Memory Allocator）是Linux内核专门为多媒体设备预留的连续物理内存区域。RV1103的摄像头采集和NPU推理都依赖这块内存。修改方法其实很简单：
- 找到SDK中的板级配置文件
BoardConfig-SPI_NAND-Buildroot-RV1103_Luckfox_Pico_Pro-IPC.mk - 修改这一行：
export RK_BOOTARGS_CMA_SIZE="30M" # 原值为24M但这里有个坑：修改后必须完整重新烧录固件，单纯重启是无效的。我当初在这里卡了半天，后来发现buildroot系统在启动时就会固定内存划分。烧录完成后，可以这样验证：
adb shell grep -i cma /proc/meminfo # 正确输出应包含：CmaTotal: 30720 kB内存增加的代价是用户空间可用内存减少，所以30MB是个平衡点。实测中：
- 24MB：YOLOv5推理必崩
- 28MB：偶尔能跑但帧率极低
- 30MB：稳定运行在5-6FPS
3. 代码瘦身：从RTSP推流到纯检测模式
官方示例代码luckfox_pico_rtsp_yolov5本质上是个视频流服务器，我们要把它改造成单纯的检测器。主要修改集中在main.cc文件：
3.1 删除视频编码相关代码
找到所有VENC（视频编码）组件调用，整段注释掉：
// RK_MPI_VENC_SendFrame(0, &stVpssFrame,-1); // RK_MPI_VENC_GetStream(0, &stFrame, -1); // RK_MPI_VENC_ReleaseStream(0, &stFrame);3.2 移除RTSP服务模块
删除rtsp_demo相关的初始化和传输代码：
// rtsp_demo_handle g_rtsplive = NULL; // rtsp_session_handle g_rtsp_session; // if(g_rtsplive) rtsp_del_demo(g_rtsplive);3.3 简化结果显示逻辑
原代码使用两种复杂方式渲染检测框，我们改为直接在终端打印结果：
printf("%s @ (%d %d %d %d) %.3f\n", coco_cls_to_name(det_result->cls_id), det_result->box.left, det_result->box.top, det_result->box.right, det_result->box.bottom, det_result->prop);修改后的数据处理流程对比：
| 原流程 | 优化后流程 |
|---|---|
| VI采集 → VPSS处理 → RKNN推理 → VENC编码 → RTSP传输 | VI采集 → VPSS处理 → RKNN推理 → 终端打印 |
4. 系统调优：榨干最后一滴性能
即使完成上述修改，直接运行可能还是卡顿。因为RV1103的CPU和NPU共享内存带宽，需要进一步优化：
4.1 杀掉非必要进程
通过adb shell连接开发板后，执行：
killall rkipc # 关闭IPC服务 killall smbd # 关闭Samba killall sshd # 关闭SSH（调试完成后可重启） killall ntpd # 关闭时间同步可以用top命令确认内存释放情况：
Mem: 18000K used, 10040K free # 理想状态应有10MB以上空闲4.2 模型输入优化
YOLOv5默认输入640x640对于嵌入式设备过大，可以尝试：
- 修改letterbox函数中的模型尺寸：
int model_width = 480; // 原值640 int model_height = 480;- 同步修改模型导出时的输入尺寸（需要重新转换rknn模型）
实测效果：
- 640x640：5.2FPS，准确率98%
- 480x480：8.1FPS，准确率95%
- 320x320：12FPS，准确率89%
4.3 帧率稳定性优化
添加简单的帧率控制逻辑，避免CPU过载：
RK_U64 frame_start = TEST_COMM_GetNowUs(); // ...处理帧... RK_U64 frame_cost = TEST_COMM_GetNowUs() - frame_start; if(frame_cost < 16666) { // 60FPS对应的每帧时间 usleep(16666 - frame_cost); }5. 编译与部署全流程
完整操作步骤备忘：
- 获取SDK和示例代码：
git clone https://gitee.com/LuckfoxTECH/luckfox-pico git clone https://github.com/luckfox-eng29/luckfox_pico_rtsp_yolov5- 编译项目：
mkdir build && cd build cmake -DCMAKE_TOOLCHAIN_FILE=../platform/linux/aarch64-gnu.toolchain.cmake .. make -j4- 部署到开发板：
adb push install/luckfox_rtsp_yolov5_demo /userdata adb push model/yolov5.rknn /userdata/luckfox_rtsp_yolov5_demo/model/- 运行检测：
cd /userdata/luckfox_rtsp_yolov5_demo ./luckfox_rtsp_yolov5常见问题排查：
- 如果报错"RKNN init fail"，检查模型路径和权限
- 出现"VI init timeout"可能是摄像头接触不良
- 内存不足时系统会直接kill进程，用dmesg查看内核日志
6. 进阶优化方向
当基础版本跑通后，还可以尝试这些提升：
模型量化增强：
# 在模型导出时增加量化参数 torch.quantization.quantize_dynamic( model, {torch.nn.Linear}, dtype=torch.qint8 )多线程流水线：
- 线程1：摄像头采集
- 线程2：图像预处理
- 线程3：RKNN推理
- 线程4：结果解析
自定义后处理：
// 修改nms阈值 float nms_threshold = 0.4; // 原值0.5我在实际项目中发现，针对特定场景（如只检测人）裁剪YOLOv5的类别输出，能进一步提升3-5FPS。这就像给模型"减肥"，去掉不必要的"脂肪"，只保留核心功能。