基于海思35XX的目标跟踪经验

        随着各家海思库存的消耗，号称史上最友好、最稳定、最诚实的IPC方案也将凋零。不过随着3403等芯片的逐步量产，似乎海思方案还可以再雄起一波。趁尚可继续苟延，总结一下海思芯片的目标跟踪心得。

 必说重点：

                1.电器控制尽量不要使用RS485，除非硬件必须（对于长距离、小目标、运动不规律的目标，运动控制反馈及其不友好，坑之多一页难言明）；

                2.末将一把尺子量到底。（海、陆、空，大、小、微，快、中、慢，等各种工况下的目标，其运动特性千差万别，跟踪策略也是风格各异。往往针对一种场景、一类目标的特化算法其普遍适用性不高，甚者对其他异类场景有百害而无一利的奇效。最好的方式就是，模块化底层控制+普适化中层逻辑+差异化场景算法）

                3.逻辑控制的健壮>片面的算法稳定

个人经验：

                1.越是复杂逻辑，c++的执行效率要高于c（当然，这仅仅限于我这种水平不高、能力有限的菜鸟）

                2.绑定跟踪执行的CPU具有意想不到的收获。（多个大佬一块验证，只绑定其中一个CPU运行跟踪算法，要比使用双核运算快30%）

关于速度提升：

        对于目标跟踪，绝大部分人关系的是速度，每秒处理的帧率越多，容错性就越好，平坦度就越高。但提升速率绝大数情况下，就要牺牲精度和稳定性。怎样完美的解决速度和精度的矛盾，使之达到所希望的程度，对我而已只能说您在指令集和汇编方面考虑一下。

        使用相同的代码，在PC端可以达到120Hz，跟踪效果也很想当满意，那怎么移植过去呢？移植过去效果怎样呢？其结果发现，移植只花了半天时间就搞定了，可是问题是运行一帧需要800ms，这还是跟踪吗？这真的是跟踪吗？于是我有尝试了，降低精度、提高反应阈值等一系列反人类的做法！！最终，终于可以运行到10Hz了，可是除非我们是跟踪老奶奶过马路还可以，老大爷都不行，更别说汽车了。在恐慌和烦乱中强行总结，PC上速度的效果可以验证跟踪算法是完美的，那问题只能在板卡端优化了。其思路如下：第一步，对代码进行耗时排序，针对性的分析耗时原因，一个一个的解决，提升10%；第二步，针对高频代码使用汇编优化（当然，搞不好有可能直接自挂东南枝）提升3%；第三步，使用全局大变量，存储中间图像信息，减少出入栈的频率。（使用空间换时间）提升5%；第四步，双手合实默念大悲咒。经上述一番操作，勉强可以跟踪逛街的老大爷和长腿大美女，至此第一阶段结束，算法验证和板端移植收关，移交智能吹牛部门大力宣传。

        然，资本怎可就此收手，毕竟金钱的车轮可以碾压一切。

        板端跟踪，第二阶段优化思路如下：第一步，移植裁剪Opencv，替换自定义函数，提升3%；第二步，使用Neon优化Opencv提升5%；第三步，使用fftw替换Opencv矩阵运算提升5%。至此，跟踪外卖小哥和快艇已不再是梦想。

        当然，你以为这就结束了？使用部分指令集优化的OPencv加持下，板端可以实现PC端相同的跟踪精度和运动控制。（后面，我会单独写一篇，关于跟踪提速的博客，并附上优化后的部分库）

时局使然：

        随着大毛和小毛旷日持久的互殴，能追人的又小、又便宜无人机和弹弹瞬间得到了真主们的赏识，有钱就愁花不掉，什么19、59啊已经一芯难求，于是就在梦想的加持下，我有了新的想法

         跟踪模块的开关机，完全取决于任务需求。这样既降低了总体工作任务能耗，也提高了整机的稳定性。