unity交通仿真_自动驾驶仿真该怎么玩

## 工作流水

过去的时间总是特别焦虑，应该是离理想渐行渐远了。不停地问自己，未来3年什么定位。也许才是解决眼前焦虑和不决的好办法。

回头看这一年，接触了一款新开源仿真平台:lgsvl。对每个新平台，前期会有几个月的学习，然后一些简单的二次开发：集成unity的地图插件，做城市道路/高速道路生成；引入了carla项目的python场景工具；然后一个很耗时的工程，把lgsvl迁移部署到docker/k8s环境下。包括搭建devops环境，lgsvl项目docker工程，解决在swarm中做gpu渲染问题, 集成ads算法为ros节点，接入lgsvl，实现headless模式的部署。最近的工作，从swarm环境迁移到k8s环境。

仿真团队成员同时期还参与了量产项目的仿真测试工作，定义和整理仿真工况，实现lgsvl-matlab的接口和调试工具，接入carsim车辆动力学模型，以及整个项目组的工具支持工作小的工具，诸如dlt解析；宏大而遥远的工具，诸如数据管理等。

最近看了google的devops开发。慢慢意识到，这一年的工作，也就是在一个传统的团队，落实了一些devops的开发思想，却非常缓慢。

## 自动驾驶仿真的知友们

周末搜了几位做仿真的知友：@鲨鱼观海，@王方浩，@黄浴。 感受同行们的工作：

1) 解决仿真工具本身的问题。诸如，场景建模，传感器模型，车辆动力学接口，ads算法接口，交通流模型，丰富的场景描述语法，云扩展等等。

之前有看到一名智加科技的同学的博客，吉大车辆科班，估计跟着一位做道路交通模型的导师，看他推导的交通模型，简直是清秀。创业团队，招了不少基础好做核心算法开发的年轻人。相比资金雄厚却缺乏底层积淀的大厂团队，简直是一股清流。过去一段时间也接触了下autox, 理想汽车，华为几家，估计其他几家互联网大厂，滴滴、美团、阿里、ponyai也差不多吧。会招到不错的人做仿真的核心模块，比如，传感器模型、车辆动力学、甚至建立场景语法等等。互联网背景的团队对运维、基础设施的经验，也助力他们的团队在开发/测试阶段，甚至量产阶段的车队运营也会信手拈来。

坊间也有个很强大的声音，就是尽量去产品的核心团队。比如，做仿真产品，那就要进入上述各个仿真模块的开发组。一方面对产品有直接把控力，另外薪资高。确实是更能彰显个人能力，也提供了不错的学习和成长空间。当然，扎实的算法团队，只是产品成功的必要条件。不觉心累，算法人才都在内卷。

2) 建立仿真工具在ads产品开发中的闭环能力。诸如，从实车采集数据清洗到场景重建，或实车数据回放的仿真调试环境，ads算法团队到仿真测试的无缝cicd，仿真测试的脚本自动化和kpi生成，仿真平台的devops环境运维能力。

这个能力因团队而异。互联网团队比较容易打通，架构师从规划仿真，就会考虑其在整个ads产品开发/运维中的位置，以及前后的依赖关系。相比，传统团队，各个模块之间缺乏统一规划，后期就变成了拼图游戏，生拉硬拽的多。传统团队，也逐渐开始吸收devops团队，也开始着手投资建设数据中心。

3）仿真价值输出。对于量产车项目，可以思考仿真对最终上市的量产车贡献几何；对于ads算法产品，甚至仿真系统可以当工具直接打包销售。

整体感受，价值低洼地在被快速填平，老人的好坑越来越少；年轻的人才还在大量涌入，业界会持续放出一些诱人的坑，向这些年轻人招手。但是，年轻人也应该意识到这类坑只有3～5年有效期。争取35岁（从一线）退休，是个很无奈又不得不面对的现实。如我的焦虑，不是个人的，而是时代的吧。谁说这不是个骚动的时代呢。