paddle2onnx --model_dir=./det_ch_PP-OCRv2/
--model_filename=inference.pdmodel
--params_filename=inference.pdiparams
--save_file=./det.onnx
--opset_version=11
--input_shape_dict="{'x': [-1, 3, -1, -1]}"
--enable_onnx_checker=True
在这里我遇到了第一个坑，RK不支持动态输入，也就是说转模型命令中的输入维度需要写成固定某个值，比如[1, 3, 480, 640], 即 batchsize=1, channel=3, height=480, width=640。这一点对检测模型影响不大，但对识别模型影响很大，在PaddleOCR中，识别模型的输入是[-1, 3, 32, -1]，即固定文本高度为32，但宽度不定，那是因为不同的待识别文本的宽高比差异可能会很大，如果强行将所有待识别文本resize到固定大小，比如（32，96），会使得某些文本被拉伸/压缩变形严重，导致识别效果很差。
我尝试了两种解决方案，识别效果差不多。第一种，固定一个很大的宽高比进行模型转换，但不是直接对待识别文本进行resize，而是对待识别文本进行边缘填充。第二种，固定好几个宽高比转换多个模型，根据待识别文本的宽高比，自适应选择与其最接近的模型做识别。
第一种方案优点是简单直接，缺点是耗时，尤其是对于宽高比很小的文本，非常的浪费。第二种方案优点是省时，缺点是要初始化好几个模型，比较占内存。在实施第二种方案的时候，我遇到了第二个坑，当识别模型的输入宽度设的太小时，pc连板推理会一直卡在rknn.init_runtime()不动，也不报错，经过测试，当识别模型输入的宽度>96（这个值可能还能更小一点，还没进一步做更细致的测试），都是可以正常转模型和推理的。
有了onnx模型之后，接着就是将onnx模型转为rknn模型。需要在PC上安装RK板的rknn-toolkits2，参考里面example的模型转化代码，以及Rockchip_Quick_Start_RKNN_SDK_V1.3.0_CN.pdf 文档，即可完成模型转化和模型推理。
在这里我遇到了第三个坑，rknn.config()里mean_values, std_values需配合输入数据谨慎设置，起初我对这两个参数的理解是对模型的输入数据做前处理（均值和方差），而我最开始设的mean_values=[0, 0, 0], std_values=[1, 1, 1]，这么设置相当于没有做均值和方差处理，之所以这么设置是因为我把输入数据的前处理已经做了，具体是从BGR转为RGB,再经过 0～255的uint8到0～1 float32，最后经过均值{0.485f, 0.456f, 0.406f}, 方差{1 / 0.229f, 1 / 0.224f, 1 / 0.225f}处理，才喂给模型去推理，所以不需要额外再做处理。然俄，奇怪的事情发生了，PC连板推理（python接口）的非量化fp16模型可以正常推理，但量化模型int8效果非常差，可以说和正常结果毫不相关，最奇怪的是我将非量化的fp16模型进行板端推理（C接口），推理结果也是错的，这说明同一个模型，在不同接口推理结果不一样。
由于我的fp16模型连板推理可以成功，所以我从来没有怀疑我的模型转换设置有问题，直到我找到了PaddleOCR在rv1104部署，对比之后发现他并没有单独对输入数据做前处理，而是直接将uint8图像作为输入，但转模型的参数设的是mean_values=[127, 127, 127], std_values=[127, 127, 127]，于是我死马当活马医，去掉输入数据的前处理（仅仅保留resize和BGR2RGB），更改转模型参数，最终，居然可以了，无论是PC连板推理的fp16, int8模型，还是板端推理的fp16, int8模型，都可以正常推理。
为了找出这种奇怪现象的内在逻辑，在输入不做前处理的基础上，我测试了不同转模型参数，发现不同的mean_values, std_values对模型推理结果有影响，尤其是设为[0,0,0], [1,1,1]时，文本检测模型没有检到任何东西； 在输入做了前处理的基础上，只有设为[0,0,0], [1,1,1]附近才能有检测结果，否则检不到任何东西。
现在对这两个参数的理解是，不仅仅是对输入数据做前处理，还对模型量化后的模型参数有影响，最好是根据模型训练的均值方差（取值范围0～1）换算到0～255范围，作为转模型的参数设置，并且输入模型的数据不需要额外做前处理。
git clone rknpu2，参考doc里Rockchip_Quick_Start_RKNN_SDK_V1.3.0_CN.pdf文档，以及example里的ssd demo写PaddleOCR板端推理代码。
以上所有代码可参考我的github仓库：https://github.com/zwenyuan1/PaddleOCRv2_rk3566/tree/master
如果您的机器安装的是CUDA9或CUDA10，请运行以下命令安装
python3 -m pip install paddlepaddle-gpu==2.0.0b0 -i https://mirror.baidu.com/pypi/simple
如果您的机器是.
前段时间一直在摸索如何在RKNN上部署paddleOCR的模型，花了好长一段时间，终于把模型部署到了rv1126的NPU上，过程虽然不是很困难，因为在RKNN群中交流过一些OCR部署时遇到的问题，经常有同学看到聊天记录加了我Q问相关问题，趁着最近周末，打算写一篇文章记录下我的部署全过程，作为分享，也方便以后复习、加深印象。
一、准备工作
硬件支持：
PC端主机（ubuntu）系统
rv1126板子
双头USB线（用于PC和板子间adb调试）
软件支持：
PC端安装好
YOLOv8（You Only Look Once version 8）是一种实时目标检测算法，它通常用于计算机视觉领域，比如安防监控、自动驾驶等场景。RK3566是由瑞芯微(Rockchip)开发的一款嵌入式系统单芯片平台，集成了CPU和GPU，常用于低成本、低功耗的边缘计算设备。
将YOLOv8部署到瑞芯微RK3566上通常涉及以下步骤：
1. **安装依赖库**：首先需要在RK3566平台上安装支持深度学习的开发环境，如TensorRT、OpenCV或MNN等，以便运行模型。
2. **模型优化**：由于RK3566的硬件资源有限，可能需要对YOLOv8模型进行轻量化处理（如剪枝、量化）或转换为适合该硬件的格式（如MACE、TVM等中间表示），以降低内存消耗和提高推理速度。
3. **移植SDK**：找到开源的YOLOv8 SDK，例如Darknet或YOLOv8官方提供的源码，并将其适配到RK3566的架构和API上。
4. **硬件驱动**：确保GPU驱动已针对RK3566更新，这对于模型在GPU上高效运行至关重要。
5. **测试与调试**：在实际硬件上进行性能测试，调整网络配置和参数，以达到最佳的检测效果。
