工作总结

自动泊车轨迹算法工程师工作总结。

干了五年自动泊车轨迹规划，前两年在供应商写代码，后三年到主机厂跟量产。最近整理工作笔记，翻出厚厚一沓A4纸——全是实车调试时随手记的曲线截图、参数组合和吐槽。借着这个机会，把几个印象深的坑和想明白的道理捋一捋。

先说那个被测试同事取名叫“画龙”的bug。去年新车做最终标定，有一天下午测试组的老周跑过来，手机里拍了一段视频：车辆在垂直车位上慢慢往里进，快到车位线还有两米的时候，方向盘开始左右哆嗦，幅度不大但频率很高，像新手在驾校练倒库。车最后能停进去，但坐在后排的人能明显感觉到车身小幅度晃悠。

我第一反应是检查重规划频率。我们当时设的是20毫秒一次，按理说足够快。把日志调出来一帧一帧看，发现一个问题：视觉感知给的车位线参考点，在最后两米区域内，横向偏差从±5厘米逐渐收敛到±1厘米。这个收敛过程不是平滑的，而是每帧都有1-2毫米的抖动。我的轨迹优化器里平滑项权重设得偏保守，结果算法把这个微小抖动当成了“需要修正的偏差”，每帧都产生一个反向的转角指令。高频指令叠加，就变成了方向盘哆嗦。

那周我基本住公司。试的第一个方案是把平滑项权重提高三倍。结果仿真跑出来，轨迹是平滑了，但车辆对真实障碍物的反应变迟钝了——有个场景是旁边车位突然倒进来一辆车，算法要等将近一秒才调整轨迹，这在实际场景里肯定不行。第二个方案尝试降低重规划频率，从20毫秒改到100毫秒，抖动确实减轻了，但控制模块不干了，说他们需要更密的轨迹点来做前馈。最后折中定在50毫秒，同时给参考线的横向变化率加一阶低通滤波。关键是要让滤波时间常数随车速变化：车静止时滤波可以轻一点，让算法快速响应；一旦开始蠕动，就把时间常数调大，滤掉高频抖动。

改完之后，老周拿车跑了三十遍，说“像老司机了”。但我心里清楚，这个问题的根子不在算法，而在我们之前的测试流程——仿真环境里用的是理想参考线，没有注入感知的真实噪声。后来我跟测试组商量，把感知模块的离线输出灌进仿真里做闭环，才把这类问题提前暴露。算是补了一个漏洞。

再说窄车位那个事儿。用户反馈是通过售后转过来的：某小区机械车位宽度2.05米，车宽1.92米，自动泊车每次剩半米就退出，提示“空间不足”。但用户自己停，慢慢揉能进去。售后的小姑娘转述时加了一句：“车主说你们算法还不如他老婆。”

我拿到车位尺寸和车型参数一看，明白了。我们把车身轮廓膨胀了15厘米作为不可通行区域，2.05米减去1.92米再减去两侧膨胀，可用空间成了负数，算法当然认为“不可用”。但现实里，机械车位的两侧是链条和立柱，后视镜可以折叠，轮胎和路沿石之间有弹性接触——这些边界其实有可压缩的空间。

怎么改？我做了两阶段策略。第一阶段粗规划，还是用标准膨胀模型，只要车头能进就行。第二阶段，当车辆距离车位入口小于1米时，切换到“紧贴模式”。在这个模式里，左侧膨胀半径按后视镜折叠后的实际宽度算，右侧则根据超声波雷达的实时回波做动态收缩——雷达测到距离越近，膨胀半径就压得越小，但设了一个下限3厘米作为安全冗余。同时把轨迹末端的曲率变化率限制从0.1放宽到0.3，允许车辆在最后一米做更急的揉库动作。

为了验证安全性，我在公司地库里用泡沫板和胶带搭了一个2.03米的模拟车位。前后跑了247次，每一次都记录车身各个部位与障碍物的最近距离。头几十次吓出冷汗——有一次右侧反光镜距离链条只有1.8厘米，我坐在副驾腿都绷紧了。后来逐步调整动态收缩的速率和触发阈值，才稳定下来。最终数据：平均最小间隙从原来的11厘米压缩到4.2厘米，泊入成功率从62%提升到89%。剩下的11%失败，基本都是因为超声波在链条结构的多次反射下产生误报，导致算法提前刹车——这个问题到现在还没彻底解决，我们正在试多帧时序滤波，但效果还不稳定。

这个案例让我学到一个东西：工程师容易把安全边界当成不可逾越的墙，但真实世界是有弹性的。关键是怎么找到那个“弹性区间”的边界，并且用足够多的实车数据把它量化出来。后来我写了一份文档，标题叫《窄车位参数调校指南》，里面画了一张表：不同车速下动态膨胀系数与超声波置信度的映射关系，以及每个参数的修改风险等级。新人拿到手，照着调不会出大问题。

我其实不是科班出身，刚入行时写轨迹规划代码，满脑子都是曲线平滑、曲率连续这些数学概念。后来带我的老工程师说了一句：“你先别管什么五次多项式，你就想，如果你是这辆车，你怎么打方向能让自己和旁边的车都不紧张。”这句话我后来经常讲给新人听。带过七八个刚毕业的同事，我发现一个规律：大多数人卡住的不是算法推导，而是不知道怎么把数学公式翻译成车辆的真实运动。所以我养成了一个习惯，每个模块写完，会额外写一份“教学设计”式的文档。不写API调用，写三件事：这个模块解决什么场景下的什么问题？输入输出在真实传感器数据长什么样？最容易出错的三个地方是什么，第一步查哪个变量？

★心得体会大全内容组内部黑话词典:
• 自动泊车轨迹算法工程师工作总结 | 算法工程师工作总结 | 无线通信算法工程师工作总结 | 自动化工程师年终工作总结 | 自动泊车轨迹算法工程师工作总结 | 自动泊车轨迹算法工程师工作总结

举个例子。有一次一个新同事调泊出车位的轨迹，总是在出口处规划出一个大角度转向，导致车头扫过旁边车位的虚线。他没头绪，我让他拿笔在纸上画出他认为合理的路径——先直着往前，到了某个点再开始打方向。画完之后他对比算法输出的轨迹，马上意识到代价函数里“转向平稳”项的权重设得太低了，算法为了缩短路径长度不惜一开始就猛打方向。这种“先手画再对答案”的方法，比直接告诉他改参数管用得多。 （正能量句子 wWw.277433.coM）

团队协作这块，我跟感知组有个固定安排：每周四下午用一小时过“边界案例”。不是开会，就是大家坐在一起，把这一周实车遇到的感知输出跳变、漏检、误检的原始数据铺在桌面上。有一次感知组的小赵拿了一段夜间下雨的视频，车位角点检测在五帧内丢了三次。我当时的规划算法一丢角点就报错退出。后来我加了一个兜底逻辑：当角点丢失时，用最近三帧的历史轨迹做匀速外推，最多撑10帧。10帧也就200毫秒，但往往够车辆完成最后一脚入库。小赵后来跟我说，以前他们觉得规划组总在抱怨感知不准，现在至少有了一个具体的不丢帧阈值可以去优化。

说几个实在的心得。第一，别太相信仿真。仿真跑通了只说明逻辑没死锁，轮胎的非线性、地面摩擦系数变化、传感器时间戳对齐误差，这些东西只有上车才能看到。我现在要求自己和组里的人，每个新算法必须先在仿真里跑通，然后两周内安排实车验证，否则就永远停在“看起来很美”的阶段。第二，数据记录要细。我不只看通过/不通过，还会记“第几秒驾驶员想踩刹车”“第几次轨迹重规划引起了车身闯动”。这些主观感受才是用户真正在乎的。第三，保持“教”的心态。把你踩过的坑写成有场景、有数据、有教训的案例，讲给新人听。讲的过程会让你重新审视自己的假设，有时候新人问一句“为什么这里不直接那样做”，就能让你发现一个存在两年的思维定势。

最近在跟一个新项目，记忆泊车。用户从地库入口开始，让车自己开到固定车位。我们遇到的新问题是地库的环氧地坪，有些区域摩擦系数特别低，同样的曲率，在柏油路上能过，在地坪上就侧滑。这事又得从头开始调。但我发现，有了前面这些教训，现在处理问题的心态不一样了——不急着一上来就改算法，而是先问自己：我有没有足够多、足够脏的真实数据？我对这个场景的物理边界摸清楚了吗？

回到开头那本笔记。最近翻到去年写的一句话：“算法不是数学，是妥协。”现在再看，觉得还可以加一句：“妥协要有数据撑腰。”这个行业没有那么多惊天动地的创新，大部分时间是在和误差、噪声、延迟这些不起眼的敌人做斗争。但正是这些琐碎的细节，决定了用户是愿意每天用自动泊车，还是试一次就再也不碰。作为工程师，我的成就感来自售后转来的那条简短反馈：“窄车位能进了，谢谢。”——简单，真实，不带修辞。

推荐阅读: 自动泊车轨迹算法工程师工作总结 自动泊车轨迹算法工程师工作总结(模板十八篇) [全面]算法工程师工作总结 无线通信算法工程师工作总结(锦集15篇) 自动化工程师年终工作总结(合集16篇) PLC自动化工程师工作总结(精品十七篇)

欲了解工作总结网的更多内容，可以访问：工作总结

热门标签: 计算机视觉算法工程师工作总结 PLC自动化工程师工作总结 it工程师工作总结 工程师工作总结 机器学习算法工程师工作计划 测绘工程师工作总结

文章来源：//www.xd63.com/xindefanwen/191313.html