通常，一个完整的动态目标感知包括激光目标感知、视觉目标感知、毫米波目标感知和传感器融合（目标级后融合）四个模块。其中，传感器融合模块，同时接收前端激光、毫米波、视觉的感知目标结果，加工处理后，以目标的形式，输出给下游。
自入行以来，本人一直在融合组，先是从开发人员成为融合模块的负责人，后来成为动目标感知模块的版本交付leader，再到现在作为动目标感知模块的功能和方案设计专家。这些经历让我意识到，很多从事动目标感知的同事，都不愿意加入传感器融合小组做相关的开发工作，甚至对这个模块嗤之以鼻。
因为，单传感器感知中的目标检测算法涉及很多当前学术界和工业界前沿的深度学习成果（比如，bev和transformer是每个做深度学习人挂在嘴边的家常便饭，听起来就很高大上），显然更符合个人的职业发展方向；相比之下，传感器融合算法，本身是一个基于规则设计的兜底模块——而兜底，就意味着要帮上游的感知模块“擦屁股”。
解决上游感知模型性能不足导致的误检、漏检、精度不准等各种各样的问题（利用另外一个或多个传感器的结果），需要用到的规则本身并不会有多复杂，这更多依赖开发者的经验及其对上游传感器特性的理解。这种特别工程化的，依赖经验的开发内容，显然不太能在自己的简历上出彩，甚至会让别人觉得你做的这些事很“low”。
因此，有人形容传感器融合是“夜壶”一般的存在。但我认为，很多开发人员不仅低估了传感器融合模块在整个感知系统中的价值，而且也忽略了从事融合模块开发对自身职业发展的意义。
传感器融合模块是感知的最后一个环节，负责将感知的结果输出给下游消费。因此，融合组的开发人员，一定最了解下游对于动态目标的需求是什么，最清楚感知系统要做成什么样子。
很多做感知的模块负责人，容易沉迷于自己的模型“在这一轮迭代中涨了几个点，模型在car或者vru的mAP有百分之几的提升”，而你要是问他，“这个模型发布后，我们在车上相应的体验有什么优化”，他多半是回答不上来的。这就是上游模块对于业务和端到端体验的理解不够深刻，导致做的事情不聚焦，收益不明显。
而融合模块开发者们需要做的事情，就是明确指出上游发力的方向。比如这个版本要优化路口横穿和汇入车辆的处理能力，对感知的需求就是横穿目标的检出距离、位置朝向速度精度的提升，那么，融合对上游的感知需求就是“提升横穿目标的检出能力和检出精度，模型就需要针对性的补充横穿和汇入场景的目标数据”。
明确了迭代的方向，才能使各个模块发力的方向一致，才能使各个模块形成合力，整个智驾系统才能快速的演进。
简言之，融合模块的开发者们可以基于对需求的正向分解，将需求传递给上游各个传感器感知模块，形成了各自模块的ODD。不夸张地说，融合就像是整个感知的发动机，一个优秀的融合模块设计者，应该是基于整个智驾系统的功能定义，不断地向上游提出明确的、边界清晰的需求，指导上游的开发和模型迭代方向。
感知融合团队作为感知的对外接口，是处理外部问题单和需求的“第一负责人”。所有的感知问题和对感知的需求，下游都是首先找融合模块确认和沟通。因此，融合模块是感知系统里任务量最重的模块，但也接触到了更多的第一手、未经阉割的信息。
一个长期从事融合开发工作的同事，不仅仅熟悉上游传感器的各种性能优劣和常见问题，也清楚下游使用感知目标的各种属性的具体策略，对各种属性的依赖程度，也能敏感地认识到感知端的各种问题对智驾的影响，哪些是高感知的，非预期的，用户容易抱怨的问题。哪些是为了确保产品的竞争力而必须要做好的关键属性。
举个例子，在开发拨杆换道这个功能中，融合组的同事能够接触到如下信息：当前友商对换道功能的设计逻辑是什么，依赖哪些传感器，存在什么问题；换道过程中的人机交互过程如何设计；换道支持的最大车速和速度差是多少；哪些场景不能激活拨杆换道功能；我们的拨杆换道功能要做成什么样；对感知的性能需求是什么；对规控的需求是什么；规控如何消费感知的相关属性；功能开发测试中，存在哪些设计缺陷和非预期问题等等各个方面的信息。
在这样一个开发流程中，融合的开发者能接触到一个功能从定义到开发的方方面面的一手信息，而在对这些信息消化吸收的过程中，开发者就会自然培养出了“自顶向下”的思维方式和“端到端”的看问题思维。
因而，在解决问题的过程中，就不会轻易地陷入单点的算法优化，而是从功能定义的角度，首先去思考“我们预期的功能表现应该是什么样子的，这是不是一个问题”；再去进一步分解“这个问题应该在归属于哪个模块优化”；最后才是有针对性的优化算法。
因此，我认为，在融合组开发，更容易培养出“端到端”的大局观，这显然更有利于一个人在后续的职业生涯中更轻松地上手其他更需要统筹全局的岗位。
写到这里，我想起组里有很多同事都羡慕那些能够做前融合预研工作的人，因为在他们看来，前融合是深度学习更高大上的一个分支，做前融合更有前（钱）途。大家都盯着前融合算法开发本身，却不去思考我们为什么要做前融合、前融合要做成什么样子、前融合要解决什么问题、相比于当前的后融合，有哪些收益。
行业的现状是，做过前融合开发的人一抓一大把，大家的水平不会有特别大的差别，简历上看也大同小异；而对前融合模块有深刻认识，能够真正lead前融合模块，快速将前融合上线并拿到预期收益的人才，却很难看到。
也许你会反驳我说：“就一直做开发不好吗？”。实话说，没什么不好，但当前自动驾驶行业卷的程度，谁能有机会干一辈子开发呢。
在我的团队里，像某个项目的牵头人这种需要负责端到端事务的岗位，往往是从融合组的开发者中优先选拔。
没有一个做融合的人喜欢兜底，因为兜底就意味着写“脏逻辑”，而写“脏逻辑”是没有任何价值和成就感可言的。但兜底又是融合模块存在的天然使命，这导致做融合的人都不喜欢干融合，没干过融合的人对融合模块敬而远之。
确实，如果只是一味地无底线兜底，融合模块最后就变成了一个鸡肋般的存在。在传感器性能还不太行的时候，融合是要做必要的兜底。模型的迭代需要一个过程，炼丹的结果也不一定每次都和预期一致，为了保证系统的正常演进和测试，对上游感知的兜底是必须的。但这里有一个原则，就是一定要“有所为有所不为”。
我认为作为融合模块，首先要清醒地认识到下游对感知端的需求是什么，再基于最终的需求做兜底的决策。
比如融合对于毫米波感知的需求，就是动态目标不能有任何漏检，那你就要适当地对毫米波的一些误检的和多检的目标做兜底。而反过来，如果毫米波的动态目标漏检了，即使融合有别的传感器可以确认这个目标报出，也不应该去兜底，因为这不符合你的设计需求；而且，如果你做了（兜底），也会导致上游漏检的问题无法暴露。
融合组在做每一个兜底的决策前，一定要先问一问自己，你期望的融合设计方案是什么样的、你期望的传感器感知上游做成什么样，基于这个指导思想，再去审视要不要兜底。而兜底也不是将问题全部推给融合解决，一些明显应该由上游保证的输出质量，也是要推动上游自己解决。
结语：
融合模块是一个工程化程度比较高的模块，现在业内也想用深度学习的方法替代后融合的功能，从而让整个感知系统更简化，更容易基于数据驱动。
在我看来，这只是“术”的不同而已，融合的“道”还是不变的——作为感知的输出端，融合是一个承上启下的模块，对上游而言，融合是感知模块的功能定义方；对下游而言，融合是感知模块的解释方。
做好融合模块，也就具备了感知专家需要的基本能力，希望以此文，勉励做融合的各位同事。