海思开发：行人检测部署到3516D V300上运行

一、前言

最近项目因一些原因停止，空下来的我给自己找点事做，所以就把眼光瞄上了行人检测，该模型是我一个目标检测群群主发的，他在知乎和git都有账号，不过我忘了。。。不说其他了，开始吧。

二、模型的选择与转换

模型是一切的基础，之所以选定这个模型也是因为它的op海思都支持，没什么很新的op，使得转换模型成为可能。模型平面图就不看了，太大了，我等下提供gitee仓库的地址，有需要自己下去看吧。

1.模型转换

原模型是pytorch版本，所以先要转化成onnx，再转化成caffe，最后转化成nnie-wk格式，在这里费了点时间，时间过去有点久了，我尽量回忆下（抱歉抱歉）。
转换路线为 pytorch->onnx->caffe， 其中onnx->caffe demo: https://gitee.com/huiwei13/onnx2caffe?_from=gitee_search ,这样的demo网上基本都差不多，不知道初始版本是谁写的。我pytorch版本是1.5的，网上也有pytorch直接转caffe的demo，但是都要求0.4及以下的pytorch版本，不好下而且这样的版本打开pytorch1.5的模型也容易报错，此外pytorch与caffe两个框架对于maxpool的实现有所不同，即使转换成功，可能最后模型还是不能用。所以还是建议用onnx做中转，毕竟pytorch直接提供了pt转化为onnx的官方接口，省心省力，再用上面的demo转为caffe的格式就OK了。
不过还要多说一句，转换后的onnx模型不能直接用，还需要做一下简化，简化后才能转换为caffe格式。onnx简化demo ：https://gitee.com/rsmeng/onnx-simplifier 。
pytorch转onnx无报错，但是onnx转为caffe时遇到点麻烦，具体如下图：


上图onnx的两个输出都经过了reshape再输出的，可是到了caffe里面却成了flatten，使得最后的结果输出十分怪异。不过没关系，对于这种无参数的layer,直接改就好。

上图是原始的prototxt文件，下图是更改后的，最后可用的prototxt文件。大致改了这几处：
（1） 改"reshape_274"处的“type:Flatten”为“type:Reshape”,参数配置参考"reshape_272"的写法，之后测试运行正常，这点解决；
（2） 发现softmax输出很怪异，其值非常小，10e-5这个样子，经过试验怀疑是axis参数原因，因为前一层输出维度是三维的，而原始prototxt文件里 axis = 1对应输出的行，这样推断来看，softmax输出确实很小。改为 axis = 2，测试发现，问题成功解决；
（3） 原始prototxt文件里，reshape下面的参数第一维度是dim:1,查看海思开发文档，他们建议换成dim:0，这样的改动对caffe模型也没什么影响；
经过上面几处改动，成功搞定caffe模型，下面就是将caffe转换为wk模型，一开始没有修改原始prototxt文件时，试过直接转换为wk模型，无一例外都报错失败。所以，还是先搞定caffe模型，再来转换为wk模型。而我把可用的caffe来转换时，无报错，一次性成功转换成功，所以就不多说了。
caffe->wk ：https://zhuanlan.zhihu.com/p/107548509 ,可以看看这位老哥的，很有帮助。

2.模型比对

搞过海思的都知道，模型转换后要做向量比对，以提高精度。但是在这个阶段遇到一些很令人费解的问题，所以特意说一下，希望能对大家有所帮助。
具体表现为ruyi的比对结果很离谱，为什么说是离谱而不是很差，是因为从输入开始比对结果就飘很远，让人摸不准头脑，为此特意换了批量化图片，重新量化但还是不行，输入图片比对相差十万八千里。按理说，中间层、输出层偏差我理解，输入凑什么热闹，与同行交流后觉得是ruyi的原因，故不理这个问题，直接在板端跑，最后发现结果不错。
所以，有时ruyi的结果并不能说明什么，按照我所在海思开发群里的大佬经验，在板子上跑个数据集，保存结果，然后计算map或准确率。

三、结果

最后在板子上跑了一下，3516d下能做到实时，基于ssd的模型就是推理快，但是性能不怎么强，对远距离识别不怎么准。贴出代码地址，有需要自取吧，写的比较仓促，如有不理解，评论中说吧。至于pytorch版本与caffe版本，我找找作者的git，你们自己去下吧，caffe模型我倒可以提供，作者原模型是pytorch的，没有caffe。 demo : https://gitee.com/shopping-tang/pedestrain_detec_ssd 。