2018/10/20 Create
2019/05/19 First update
2019/08/30 Second update
2019/09/15 Third update
博观而约取，厚积而薄发。这是我很喜欢的一句话。
Coder & Engineer，这是对我的职业目标的另外一种描述。
我的目标是成为自动驾驶系统(软件)工程师。因此，在掌握专业知识的基础上，足够广的知识面、旺盛的好奇心、超快的学习速度才是我一直找的核心竞争力。另外，知识面宽广和专精一处并不是矛盾的事，有自己的专业研究方向不一定意味着把其他领域的路限死。
这篇博客是我两年来在网上搜集到的各种自动驾驶学习资源，内容包括学术论文，书本，开源项目，甚至微信公众号等等等。在学习的过程中，我每次找到好的资源都会高兴一阵子，每次遇到不好的资源半途而废就会不开心。一年下来，去粗取精，大致有以下的结果。
这个标题我很满意，是从一位很厉害的前辈的github简介里学习到的。
博观而约取，厚积而薄发。是我的学习态度。
Coder & Engineer，则是我的学习目标。
我在“关于我”的标签里提到，我想投身的是计算机和实体的交叉领域，想要做的是软硬一体的工程师。
Coder和Engineer，我要成为这两者的结合体。
所以即使互联网非常火热，我也没打算投身于纯cs那一行，而是选择自动驾驶作为我工作的起点，因为它和我前边提到的目标匹配度非常高。
我用Coder和Engineer来概括我的职业目标，并不是刻意去割裂两者。Coder的官方招聘岗位也不会写程序员，写的一般也是软件工程师。之所以把这两者拆分开来，我更多是想去强调这两者的不同特质。因此以下提到的更多是狭义的概念。
作为车辆背景的工程师，我更多的是接受工程训练，过往的目标更多是被约束到Engineer中去。但对于自动驾驶，这是不够的。自动驾驶需要系统集成，需要功能安全，需要危险事件分析，需要线控底盘，但最终肯定还是要有一大部分工作落在编码上。而这时传统的车辆Engineer缺乏的东西。
最近一汽校招爆出来不再接受机械专业的学生，这种一刀切的做法非常的愚蠢，也给行业增添了很多不必要的焦虑。但是这从侧面说明了，当前Engineer需要提升自己的编码能力。
那么对于自动驾驶而言，只有coder够吗？跑一些视觉算法，做出来几个数据非常好看的实验，却根本不顾系统输入可能出现的各种问题，做了很好的规划，但在设计时没去考虑系统底盘的控制能力，这样可以吗？应该也是不行的。但就自动驾驶系统的技术层面，它也是一个系统工程，各个模块不应该是完全解耦的，需要一个系统的方法观把各项相关技术串联起来。
翻来覆去说了很多重复的话。总之，我的兴趣所在是实体与计算机的交叉部分，就目前而言，也就是自动驾驶的部分。因此，我想成为一名coder&Engineer。但我相对接受的工程意识训练略微多一些，因而在现在以及未来，我会更多去进行一些计算机科学方面的训练。
既有系统意识，又有实现能力，这是成为一名真正的自动驾驶工程师所真正需要的东西。
前几天写了这样一篇关于自动驾驶场景语言格式的文章。与之相关的还有这样一篇。起因就是看到了GeoSCENARIO。所以后来在选定要翻译的文章时，就推荐同学选了这篇文章，后续也参与了一部分校核。
文章由“同济智能汽车研究所”微信公众号编译，欢迎大家动手打几个字关注，公众号内容比较杂，但是做的很用心。
本文摘自 IV2019
原文题目:”GeoScenario: An Open DSL for Autonomous Driving Scenario Representation”
原作者： RodrigoQueiroz，Thorsten Berger，Krzysztof Czarnecki
作者单位：加拿大滑铁卢大学1’3，瑞典哥德堡大学2
2018/08/22 Create
2019/08/22 First Update
我是以工作为导向的类型，所以读博不在我的考虑范围内，但研究生也是需要接触科研的，且如果情商正常，科研能力和工作能力基本上可划等号。科研到目前为止还没有被社会发展成一个贬义词，想做好它在需要有一套完整的价值观和方法论，当然没有超强的行动力这些也都是空中楼阁。另外在往前冲时需要遵守规则和约定，在现在的学校以及未来的社会，过程正义都是不可绕过的。最后，做科研当然也离不开灵感。
本篇是对当前科研生活的粗浅琐碎的思考片段，有些是形而上的，有些也有具体的执行方案。有些我已经把它变成了习惯，还有些处于知道道理，但过不好这一生的阶段。科研路很长，未来的路也很长，想做好一件事，有几个能拿出手的优点，收获平静且充实的幸福，真的不容易。
建立自动驾驶场景格式有以下几个用处。其一，通过使用计算机可读的语言，实现测试的自动化，为大规模仿真测试提供基础。其二，标准化测试场景，提高多工具链下的仿真效率。
对于自动驾驶场景格式，需要解决静态场景和动态场景的编码方法，这可以对标OPEN系列的OpenDRIVE和OpenSCENARIO，按Open系列的想法，还得需要一个提供道路不平度的场景格式。
静态场景格式是测试场景格式的基础，它跟高精度地图有着很深的关系，需要提供测试场景所需的道路拓扑结构以及更具体的道路几何信息，除此之外，一些必须的环境信号信息也需要由它提供，典型的是道路标志、标识牌、信号灯信息。目前可参考的是OpenDRIVE和后起之秀Lanlets，后者是基于OpenStreetMap构建的。
动态场景格式的格式更复杂一些，它的设计可以参考一些泛化的，不是针对“自动驾驶”的场景理论基础，如经典文章《the blind men and the elephant: Views of scenario-based system design》，这篇文章可以提供关于动态场景设计格式的上层方法论。从已有的场景格式来看，目前可以参考的动态场景格式主要是OpenSCENARIO，GeoSCENARIO，由common roads提供的场景格式也可以思考。从设计语言上看，xml和json等格式化原因具有很强的优势，前者是目前已有场景格式的语言，但json因为其易于传输的特性，也在慢慢兴起。
对于场景格式的设计，应该满足简洁、高效、可扩展性强的特点。我目前正在研究自动驾驶场景格式设计，有对这个领域感兴趣的可以发邮件和我交流。
（未完待续）
本文主要内容来自Simon Chauvin,在进行翻译时融入了我自己学习过程中的认知和思考。