近一年的阶段性工作和一些方向上的经验总结，之前的一些经验也在自己专栏上有写。流水账凭记忆分月，也算是自己最近一年在创业公司的一览。分经验和流水账两部分吧。有一些之前专栏的总结也都在流水账里面。
由于特斯拉的原因，现在的 BEV 模型迎来了一次爆炸。甚至会有人说， BEV 就是解决自动驾驶的关键技术。但是，实际做过工业研发会知道，BEV 模型虽然有很多优势，但绝对不是一个银弹。
BEV 模型，只是提供了一个统一的空间，方便各项任务、传感器的融合；而且，这个空间还是贴合实际物理的。这样的话，
BEV 模型不是银弹，只是提供了一个相比图像更加贴近物理世界的空间，可以给后续的融合、规划提供更多的可能性。
上一点带来的一个可能性就是 E2E 模型的引入。相比传统的规划，可以利用上网络中的原始特征。起码对于一些常用的场景，使用神经网络是有不少优势的，包括算力利用、平滑性、更快速的响应、对各项噪音的容忍度。当然，我本人并不负责规控，但是从感知角度，暴露出更多的原始特征，是可以给下游提供更多想象力的。
对于神经网络，很多人诟病其黑盒、对异常处理能力不足、仅仅针对训练集合、数据量需求大。这些确实都是现实的问题，但是，传统方案的人肉调参，在这些问题上一样无法处理。嵌套一堆的代码、人工不断针对遇到的场景的调整，同样面对难以理解掌控、异常处理不足。
在 https://zhuanlan.zhihu.com/p/509693609 的数据闭环中的思路一致。一个公司可以继续用传统方法堆策略，慢慢的从 50 分爬到 60 分。但是使用 E2E 的模型，可以无脑的堆数据，在付出较少的时间成本和更快的迭代机制下，做到 65 分。而且很明确的一个经验：整体指标上，传统方法的上限是肯定没有神经网络方法高的。
还是感谢特斯拉的 AI day，现在不少公司都在开始弄 4D 数据的标注。所谓的 4D 数据，主要解决的还是静态元素的问题。动态目标由于引入时间维度，会有很多对齐的问题，使用传统方法标注更适合。
图商在 4D 标注数据上的先天优势
4D 标注，就是在视觉传感器上进行静态要素的生产。这里很大一部分的工具链是和高精地图的生产重合的，尤其是目前大部分公司不会像特斯拉一样，放弃激光传感器。利用好 Lidar + Camera 的传感器组合，然后使用高精地图的生产工具，是一个非常平滑的技术路径。
对于图商来说，其实仅仅需要补一块视觉 3D 重建的技术。剩下的标定、剔除、对齐、SLAM定位、标注工具、甚至标注规则等等，直接复用就可以。当然，这只是从技术角度看，从商业上、安全上看这个先天优势有没有意义并没有考虑。
4D 的一些问题
还是我的基本观点：追求所谓的厘米级的精度，除了可以 PR 以外毫无意义。甚至远距离下，米级别的误差也是可以接受的，重要的是误差的稳定。
使用 4D 数据去追求绝对精度厘米级，实际场景下根本做不到。误差来源非常多，比如：传感器标定与同步、定位和 SLAM 优化、标注本身、流程中的算法误差。
4D 数据依然要考虑静态遮挡。有些场景下，视觉本身看不到的要素。由于加入了时序融合，标注里面是有的。被遮挡的要素，在训练过程中会对模型有负面影响。
同理，动态遮挡也会带来类似的问题。比如，拥挤堵车场景下，视觉看见的全是周边的车辆，地面一点都看不到，没有给模型任何线索。
传感器优势与劣势
只简单说下 Lidar 和 Camera，毫米波我基本没有接触。
Lidar
很多人喜欢说 Lidar 对恶劣天气的容忍度。不过按照我自己的经验和了解，Lidar 对恶劣天气的容忍度并不高。列一列我理解的一些 Lidar 劣势：
优势也是很明确的：
Camera
摄像头长期以来都是备用传感器的角色，当然现在也有技术方案依靠 模型 + 算力 来支持摄像头作为主传感器的方案。
劣势：
优势：
按照我自己的观点，在不考虑光线负面影响的情况下，相机和激光之前的差异并没有大到不可替代。在测距误差这点上，虽然相机的测距肯定不如激光，但实际使用中并不需要精准到激光的测距水平。只要运动趋势能够稳定，30m 内精度分米级别，100m 内米级别，这样的测距精度就是可用的。单看精度的话，相机的模型很轻松就能达到这个标准。
传感器同步
最先的传感器同步方案是用的 nuscenes 的方案，不过 nuscenes 方案没有考虑相机曝光时间，等激光扫到 FOV 中心再曝光其实还是会差那么几十毫秒。所以为了更好的对齐点云和相机左右，应该是在扫到 FOV 中心前就需要触发。当然，即使这样的方案也还是有一些问题，尤其主传感器是摄像头的时候。
从经验上来看，即使传感器同步有一些时间差，影响也没有特别显著。起码在我们自己的私有数据上，标定带来的误差绝对大于同步的误差，即使这样模型层面也能有一定的容忍度。条件有限的，临时搞个软同步也可以先用上。
个人观点，从务实角度来看，纯相机的技术方案其实还是很有竞争力的。
纯相机方案是否可能的讨论基础不是纯相机能不能支持 L4 级别： 没有任何厂商敢说，我加了一堆贵重的传感器，几年内就能做出严格定义的 L4。
反正 L4 做不成，用一个相机方案解决掉 90% 的驾驶场景。相比一辆车贵上十几万，装一堆传感器，也只能解决 95% 的驾驶场景（甚至可能也就91%），前者还是更加务实一点。多装十几个摄像头的价格，要驾驶员随时接管，和多花一大笔钱，跑起来还是要随时接管，哪怕接管的概率低一点，后者可能还是更加显得自己是个冤种。
以下就是流水账部分
去年三月中，回到自己的旧领域，自动驾驶。
随后，首先开始 2D 车道线的研发，当时选定了两个方案：
其中方案 2 由我负责展开。
同时段，开始离线分割模型的研发。由于领域成熟，算法通用性强，本身目标也不是车端运行。三月份在这个方向上，主要是数据任务：标注规则、数据检查。
在四月，我们已经发现选定的端到端方案的算法缺陷。当时的观点是两种：
我当时持有后一观点，认为当时的缺陷直接来源是算法设计带来的，难以避免。同时也继续方案 2 的验证工作，作为备选计划，预防方案 1 的算法缺陷。
同时段，作为车道线的细分，开始了道路边缘任务。初期主要任务也还是标注规则确定，主要需要兼容两个方案，同时也按照我的想法，为未来的场景留存可能性。
本月基本是忙于模型训练，流程相对比较成熟，私有数据集的量也基本拉上来了。
车道线最终选定了方案 1 上车，当然问题还在。不过由于确定了方案上车，我就不需要花精力维护方案 2 的。
同时新的场景也来了，于是我的任务又增加了鱼眼的感知，包括车道线、目标检测、freespace。依然是基本套路：
由于整个鱼眼的任务都是我一个人弄，同时鱼眼由供应商提供了同步。于是整个方案可以统一到我的思路上来，标注上注意扩展性、城市场景，也注意到了多相机之间的 ID 关系。这些尝试也直接影响了自己后续的一些标注规则和模型的思路。
当然，带来的问题是，数据检查的工作量剧增，单鱼眼任务就有四个，供应商返回的标注质量也是一言难尽，基本没有质检可言。加上前几个月的任务，算是我干 Machine Learning 这么多年，见过的质量最差的数据了（分割的质量反而是最好的，可能是任务明确、成熟，而且基本没有差异化，供应商轻车熟路）。当时人员依然是捉襟见肘，基本上都是数据积压，没有精力做检查。或者先训练模型，如果发现问题，再检查数据。
同时，也开始确定采集车的几个前视摄像头位置。由于各方面原因，摄像头没法安装在量产位置上，只能退而求其次，尽量靠近。位置带来的负面影响，让遮光罩变得傻大黑粗，长期影响更是一直贯穿至今。对于摄像头的位置，我也总结过一些：https://zhuanlan.zhihu.com/p/442295409
帮着同事增加了 Lidar 的多任务训练，十分顺利，甚至有几个指标比较明显的加点，后面做了 case 分析后还进一步提升了指标。顺路改了下网络结构，整体运行性能也提升了很大（当时问了同事那里，说是应该有30%）。由于我的重心还是在视觉感知上，确认代码 OK，指标提升后，就继续弄视觉的事情。
数据上，由于有专人开始负责和我沟通，于是肉眼可见的一堆标注问题（主要是各种长尾、模糊案例）开始膨胀。
模型上，还是鱼眼相关任务，同时 BEV 相关的工作也已经开始，之前五月份的 PoC 玩具其实就是一个简单的验证。以及 Tesla 在CVPR 的 Workshop 也已经开始公开信息：
Captain Jack：[Notes] Tesla CVPR2021 Workshop
这个对于 AD，那么最大的事件应该是特斯拉的 AI day 了，https://zhuanlan.zhihu.com/p/403531148。即使从 PR 的角度反向分析，整个技术方案的完成度也很高，模块间配合也都符合逻辑。后续几个月的 FSD 的版本更新速度更是表明，流程成熟、整体的迭代已经开始。针对这个的总结在
Captain Jack：[Notes] Tesla AI Day - Vision篇数据篇起了个头就一直我硬盘里躺着，等后续有机会再补吧。
继续正常的工作任务：
不过这个月由于疫情原因，我大概有一半时间在居家。
九月份场景优先级发生变化，鱼眼的任务优先级降低；公司另外一位一起负责 BEV 任务的同事在这期间离职。于是 BEV 相关的探索就由我展开。中间还插了一个停止线的任务。
虽然当时还有很多标定问题，但是首先是视觉点云的验证模型：https://zhuanlan.zhihu.com/p/411908796
这三个月算是工作内容比较稳定和聚焦的时间段，在数据这里的探索按部就班：
同时也在尝试利用现有的这些模型来攒 BEV 视角下的车道线 GT 数据，以及一些原型模型的训练。
之前车道线方案1 的问题依然存在，此时的数据量实际上已经足够。但是同时面对的场景越来越复杂。
车道线最终还是成了老大难问题，这段时间后我又被重新安排负责车道线 2D 模型。这时候使用的依然是之前的方案 1 ，数据量也足够。我手头上已经有一个 BEV 的车道线方案准备做，于是就拿这套先在 2D 任务上做一次验证，同时放弃了之前的方案 1 和方案 2。最终通过一个多月的时间慢慢把模型方案平滑的替换到新方案上。
这些工作的一些总结也已经在其中：
Captain Jack：自动驾驶车道线检测相关问题### Feb && March
完成版本迁移后，基本结论就是 2D 车道线模型已经不是瓶颈，于是我又重新分配精力回到 3D 视觉/ BEV 模型的训练上。这时市面上的那一堆 BEV 模型还没发布，我在私有数据集上也遇到了不少问题，包括传感器标定误差、数据质量、模型本身的过拟合问题等等，算是一直在坑里摸索。
将就在三月底完成了目标和车道线在 BEV 空间上的模型，赶在公司宣传需要前出了demo：
https://www.zhihu.com/video/1537466229761859585https://www.zhihu.com/video/1537466469008371713随后就是将技术降级到 3D 车道线任务上，主要是算子兼容性、实用的标注数据、实际评测。
一年时间刚好到此，后续的工作等后面的总结了。