[备选]自动驾驶一线工程师工作总结。
去年下半年车队切了新感知算法，算力利用率提了20%，我正想着终于能消停两天，结果地库幽灵刹车就找上门了。好几个司机反映，进老旧地库时车会突然一脚重刹，提示有障碍物，可前面明明空荡荡。更邪乎的是，同一个地库，白天偶尔抽风，晚上几乎次次中招。
我跟了十几天夜班，抱着平板盯着点云数据。说实话，刚开始也蒙，各种参数扫过去没发现异常。后来把触发点的GPS、时间戳、传感器原始数据全捞出来，扔进Jupyter里画时序图，才看出门道：所有触发点附近都有连续减速带，而且车灯一打，金属反光让摄像头把地面反光斑认成了实心障碍。毫米波雷达在这个距离本来就飘，融合模块一看视觉得分高，就信了视觉。我把连续几帧的点云叠在一起看，真障碍物的点云像钉子一样钉在地上，而那个反光鬼影每帧位置都在跳——说白了，就是算法太着急，没等看清楚就踩了刹车。
问题找到就好办了。我们没简单调高雷达权重，那会带来新坑。而是在后处理加了一道“连续帧稳定性校验”：如果某个障碍物在连续五帧里横向位置抖得像心电图，就把它打低分。上线前我用历史数据回测了一百多个触发点，确认能滤掉八成假阳性，同时没有漏掉一个真障碍。改完后追踪半个月，地库误触发率降了82%，关键是再也没有司机半夜打电话骂娘了。
第二个坑是隧道跟车顿挫。高速测试报回来，说在隧道里跟大货车会偶尔轻微顿一下，不是每次都有，但体感很掉价。这种偶发问题最难复现，我调了十几段日志，把油门、刹车请求和相对速度、距离画在同一张图里。发现一个规律：只要前车是货车，雷达测距就在30米附近出现几厘米的跳变，换算成相对速度就成了波动，控制模块就开始微调刹车。为什么跳？因为雷达回波有时候打在后轴，有时候打在货箱底板，货箱底板离地高，回波位置就不稳。 （wWw.dJz525.coM 励志的句子）
当时两个方案：A平滑雷达数据，B在融合层做文章。平滑会引入延迟，跟车距离近时延迟就是风险，所以我们选了B。具体做法是在融合的配置文件里加了一条规则：如果视觉识别出前车是卡车或大巴，而且纵向距离变化率抖得厉害，融合模块就暂时以视觉测距为主，雷达只做参考——相当于告诉系统：“这辆大车的数据可能晃，你悠着点信。”改完再拉加速度曲线，那个0.1g的毛刺彻底平了，司机再也没叨叨过。
-
●范文人Fwr816.com精选特推:
- 自动驾驶工作总结 | 自动驾驶标注工作总结 | 线束工程师工作总结 | 线束工程师工作总结1800字 | 自动驾驶算法工程师工作总结 | 自动驾驶算法工程师工作总结
第三个事是关于验收标准的。之前算法团队定的规矩：车道线检测必须在200米内波动小于0.1米。结果他们为了达标，在模型里加了很强的时序平滑，线是稳了，但到了南浦大桥那种360度匝道上，线被拉直了，车提前往弯心切。我跟算法同学争论，他说“我明明把线画稳了，怎么还不满意？”我没多解释，直接把车开到那段匝道上跑了一圈，录下轨迹给他看：“你觉得这么切内线，乘客会投诉吗？”后来我们坐下来重新定标准，不再单看静态误差，而是加入动态工况下的“预瞄误差”——也就是看前车轨迹和预测线的吻合度。新标准一推，算法优化方向也跟着变，最后匝道上的表现才真正能用。
这一年下来，我最大的感受是：自动驾驶没有一劳永逸的灵丹妙药。每一个坑都得靠数据刨出来，靠跟车体感验证。数据科学家的活儿，不是调个模型就跑，得能从十六进制报文里嗅到问题，得能在司机骂娘之前从散点图里找出规律。
-
范文人小编为您推荐工作总结专题，欢迎访问：工作总结