目前工作对YOLOP的一些解读、修改和部署方案

yhl

  近些天针对目前工作需求的车道线检测要求，找到两个现实可行的方案：基于Hough变换的滤波算法与深度学习算法。

  对比两种方案，初期的评估如下：传统方法受环境影响较大，且效果不一定符合预期，受到复杂环境影响较大，鲁棒性差，可能需要深入各个步骤做优化，这方面积累较少，且未来预期不好评估。所以暂时选择深度学习方案，基于海思NPU目前的优化更新来看，Transformer架构算法阻力较大，遇到的问题可能需要原厂去深入解决（此前客户遇到的transformer架构海思都要求提单原厂视情况解决），且CNN也有其不可替代性，最终选择先尝试CNN类深度学习算法。
  首先，对于ADAS系统来说，准确性与时效性都有着严格的要求，不能为了某一方面而舍弃另一方面。于是，One-Stage的YOLOP是目前笔者优先考虑的算法结构，并对其针对海思NPU进行差异化的修改并最终部署做一些规划：


·Graph

  由原作者论文可以明确得知其采用yolov5的backone，具体细节和性能效果笔者这里不再讲述；相对于object detection分支，新增drivable area与lane line的Segmentation分支。对于目标任务来说，只需要Lane line分支，多余的分支无疑会浪费NPU性能，对于一整个系统来说，同时运行的算法模型可能在两到三个，所以对于不必要的分支裁剪也是很有必要，但是裁剪远没有直观理解那么简单，笔者这里计划使用两种方案：

（1）在模型设计之初，从结构上减少Drivable lane分支，需要整体修改代码，如graph构建，criterion修改等，比较复杂，但是好处是可以从开始减少Drivable lane的loss贡献，其余分支可能会有一定的性能提升。

（2）按原结构train得到的模型，对Drivable lane分支直接裁剪，在部署到海思NPU上无论是NNIE还是Ascend都是比较方便的，缺点也是相应的。

（3）当然可以采用no-anchor的方式，提升网络性能，例如yolov8 yolox等，但是之前有在NNIE部署过相应算法，cpu 算子编写耗时不可忽略（ops_cpu大约在十个左右，也会因为客户实际业务占用的cpu过高，导致算法模块耗时进一步加长，适合单种需求的项目），只可以在海思新架构上考虑修改。

·Loss function

  论文中对三种分支独立采用BCELoss并加权得到L_all(其中det含有CIOU_Loss)：

  

  其中，object部分采用了focal loss（0-1）来优化样本的分布，聚焦hard object这点可以考虑后续优化。

·Training paradigm

  由图可以知道，YOLOP本身是分步训练，det->seg_all->det+seg_all,这边保持原有策略，根据网络修改方案来做实际调整（例如det+ll：det->seg_ll->det+seg_ll）。

·Activate function

  对于YOLOV5（SiLU左）以及YOLOP（Hardswish右）如下图所示：

  表达式分别为：

  对于笔者的工作来说，项目的成功与否首先在于是否能部署成功，部署离不开量化，虽然HardSwish相比swish更优，且又消除了sigmoid函数的精度误差，但是在嵌入式系统上很明显有着分步计算耗时，基本不考虑选用分段HardSwish，且查找Ascend部分也没有对此函数的支持，也就不用去做相应的算子编写了。SiLU在单检测头的部分与ReLU区别不大，在segment头中需要做对比实验，最终由性能指标来作取舍。

·Data augmentation

  对于YOLOP平台，设计团队虽然采用YOLOV5backone，仅仅采取HSV Transformer Augmentation，没有采取其他的Data augmentation。因为原论文团队基于BDD100k来实现，数据量充足，只考虑环境变换问题，但是对于笔者目前项目数据获取难得问题，YOLO系列的Mosaic还是比较重要的，以及之前分步train的策略似乎也可以用于segment头训练，这部分后续可能需要笔者码上。对于normalize等也将弃用，使用简单的归一化。

  红字部分为笔者修改的主要部分，对于算法具体原理以及C/C++实现、weights整体缩放、模型量化、裁剪部署（wk、om）、以及postprocess（cpu+rpn系列）等相关部分的工作请见具体项目。