Apollo 用于模型验证和测试的基于 Web 的仿真平台 Dreamland 已经更新到能使用更强大的场景编辑器和环控制模拟。
基于 Apollo 流水线和机器学习的动力学模型，复杂度较高，同时基于 AI 的全景数据建模，模型精细度高，误差比传统方式可减少近 80% 。这样，模型的通用性和可扩展性大幅提升，对于开发者来说，这是基于 Apollo 流水线的数据应用，大大降低了开发成本。
在本文本次分享中，我们将会讨论：
1.什么是控制在环仿真能力2.Apollo 控制在环仿真使用方法和现有应用场景
希望 Apollo 开发者和合作伙伴可以参考学习并顺利完成高超的百度 Apollo 控制在环仿真技术。

TIPS
本次分享，我们有幸请到百度资深架构师——罗琦详细讲解百度 Apollo 控制在环仿真技术。
罗琦，百度资深架构师，百度 Apollo PnC 负责人。机器人与自动化方向博士，拥有多年机器人开发经验。曾在通用汽车，罗克韦尔自动化等公司工作，2016年加入百度自动驾驶。

  以下，ENJOY  

7月，Apollo平台迎来5.0的发布升级，从感知到控制，进而延伸到云端都进行了整体升级，而其中的新特点之一就是控制在环仿真。追溯一下，关于Simulation在2017年与Apollo平台同时开放，在历次Release中都进行了比较大规模的升级，现在5.0的版本中突出的创新点都在Simulation上，在此之上进行开发，充分测验之后才会进行Coder Release，下一步真正进入测试。
▲模拟概述
简单来说在5.0版本中，升级了Simulation，增加了Dynamic Model，使得控制可以入环仿真，做到由原来的决策-运动规划-完美控制闭环升级到现在的决策-运动规划-控制-动力学模型。 在5.0版本之前，Simulation主要服务于Routing，也就是针对Global的PassPlanning进行服务，还会涉及Prediction和Planning model，也就是关于预测模块、决策模块以及轨迹生成模块等.
5.0版本之后，加入了 一个车辆动力学模型，平台第一次成功把控制引入了仿真；另外一个大的进步则集中在Function level以及Coverage方面。

从Control-in-the-loopSimulation的架构出发，可以看到在5.0版本之前，Simulation的架构图中所有边界是黑色的，也就是说原来有一个决策，随后会进行轨迹规划，轨迹规划后进行完美的PlanningTrajectory，规划出来的轨迹再完成VehicleStatus转换。
▲Control-in-the-loopSimulation架构
所谓完美控制的闭环，作为Simulation的一个Callback，需要完成VehicleStatus的一些输出，例如车辆的速度、加速度、车辆转角、油门、刹车等信息，再反馈给Decision，然后提供给Planning进行使用，这就是之前说到的Decision、Planning、Perfect Control的闭环 。
之后在5.0版本中的主要升级则集中在控制端，主要在Simulation后端加上一个DynamicModel车辆动力学模型，这样就把之前Perfect Control的闭环变成了如今的PlanningTrajectory，控制模块会根据Planning指令和车辆来下发控制命令，由DynamicModel车辆的DynamicModel新生成VehicleStatus。
为什么要这么做？其中最重要的原因之一是可以让控制模块进行仿真入环，在开发和调试效率上得到很大提升，进一步摆脱对上车调试的依赖，极大提高整个算法的效率。
Apollo开放的控制在环仿真具体具备怎样能力呢？如果对于Apollo代码以及Apollo仿真环境比较熟悉的话，就可以发现，左边是显示页面，右边是PNCMonitor，也就是对于车辆信息进行的画图。
例如，左边是一个行人在通过道路、横穿道路的场景，针对这个场景，DynamicModel能够支持EgoCar，在行人过马路时真正刹车，着重体现的是纵向控制能力。着重需要看的是右边PNCMonitor的图，Planning浅蓝色，然后是PlanningTrajectory，了解Planning发出的轨迹之后，按照时间生成真正控制跟随的目标指令，这里的浅色就是所谓的目标指令。此外蓝色代表实车速度，控制命令经过Intelli-Sim转化成被下发的命令，通过引入Intelli-Sim成功将控制入环，这里主要讲的是一个纵向的模拟LongitudinalControl能力。▲Control-in-the-loopSimulation典型场景
因为在Apollo5.0中新增加了两个Planning跟控制的Scenarion，一个是Parking的升级与补足，另外一个是靠边停车的升级和补足，两个情况下都需要对倒车场景进行模拟。值得强调的一点，Intelli-Sim完全基于数据驱动以及Learning的模型。 

首先解决了为什么做DynamicModel的问题，也就是增加了PNC的开发以及迭代效率，包括重复验证的效率；下一个问题是为什么要用，为什么建立一个基于学习以及数据驱动的模型Learing-BasedModel，而不是像车厂一样建立ManufactoryModel。
▲车辆动力学模型仿真对比
首先与传统车厂相比，Learing-Based数据模型精度相对较好。车厂模型因为有深厚积累，其动力学模型开发周期在半年或一年甚至更长，相对来说它的精度还不错但相比ManufactoryModel来说稍有不足。
其次对于模型来说，都知道Apollo平台支持了很多种类的车型，与车厂动力学模型相比具有的模型通用性较好，在开发周期的费用相对较低，当然确实需要相关新的数据采集，涉及到一部分采集工作量，但开发的工作量确实下降很多。此外值得强调的一点，针对Apollo 平台来说，模型的灵活程度与泛化程度是十分重要的特质。
为什么花费很大精力讲到模型？这里我们把不同Development分成几个级别，首先是车端的Vehicles&DataGeneration以及Vehiclecollection；其次是Offline，也就是DataPipeline，在车端采集相应需要用来做模型训练以及做模型Validation需要的数据，由此把它输出到数据流水线。首先是Feature Extration特征值的抽取，然后是ModelTraining，简单来说就是机器学习的训练过程：得到ModelOutput之后，会有一个自动的Model Grading与Selection，这样根据结果自动Trigger Feature Extration以及 ModelTraining。
▲车辆动力学模型仿真网页
值得介绍的是，Model Output支持External Partners或者Developers的Contribution，不管是车厂的动力学模型还是自己不同的Learning-Based模型，会做同样的Grading，统一根据Grading高低进行Model Selection以及 ModelTraining的结果。具体应用会比较简单，直接在Simulation的下拉菜单中选择Simulation with Control-In-Loop或Simulation with Intelli-Sim；然后提供了两种不同的模型，基于车厂的动力学模型以及自己的Learing-Based DynamicModel。

▲数据管道自动学习程序图
大家如果对Apollo的Source Code比较熟悉的话，会发现在5.0版本中新加了一个不同的Mode，如果选择这个Mode，就会把Data collection的Type打开。简单来说，把需要采集的数据，包括前项、后项进行不同的切分，按照这样的Category进行自动录制数据，不同的Category会逐渐塞满，这就是针对需要训练的数据集进行采集完成，方便内部车辆运营的同学。
▲数据收集
当然如果数据量足够，就不需要专门的Data collection配置，可以从过往的自动驾驶数据里进行挖掘。针对数据采集过程我们也进行了相关实验，内部选择了两个车型，分别是开放的MKZ林肯数据集以及Ford Transit，虽然车的物理属性各有不同，但对于我们来说建模过程是完全一样的。

▲有选择性的学习结果
如果大家开发自己的Planning以及控制算法，可以提交到Simulation平台，通过检测右侧的PNCMonitor，看看自己的控制算法以及规划决策算法究竟效果怎样。如何利用Simulation后台来进行自己算法的调试这部分，其实更多是PNC，例如Planning模块、控制模块进行简单调整，可以在Simulation平台完成一个完美的复现或者测试。

我们需要明确的是，首先5.0模型可以极大提升PNC算法开发以及Debug的过程。其次现在的模型当然还有很多不足，未来会着重解决更细节的车辆延时，因为真正的车辆确实会有不同的车辆延时，延时细分还包括线控模型本身的传输延时以及油门、刹车、转向的延时等，确实应该对横纵向车辆物理延时进行分别的建模。
▲Apollo控制在环仿真技术出现的问题
其次是Vehicle Idling Speed，也就是车辆的怠速，很遗憾现在对于怠速的模型还没有做。此外，如今模型的输出纵向是加速度，但事实上如果看到定位模块的输出之后，会发现这个输出与Location并不是二次积分的关系，所以接下来需要把它表征成为一个更复杂的映射关系才行。
还有更重要的一点，但凡通过测量得到的东西都有误差，误差在实车上无处不在，也是影响车辆自动驾驶非常重要的部分。但在仿真中考虑的都是完美事件，所以仿真环境与实际环境还存在一个测量误差的Gap，也就是说，下一版DynamicModel会尽量在其中加入测量误差来测试，力求做到让测量值更接近实际的路测或者路跑值，其次通过这个机会测试PNC等。

如果大家对于Model本身Set up和更详细的性能分析有需求，可以看我们这篇paper：An Automated Learning-Based Procedure for Large-scale Vehicle Dvnamics Moding On Baidu Apollo Platform，到时候还会有更多技术细节可以分享出来。
▲详情参考论文
以上就是关于本次分享的全部内容。欢迎大家提出问题，关注【Apollo开发者社区】微信公众号，进入开发者社群进行交流。更多相关技术干货也可以继续关注后续的社区课程分享。
点击文章左下角『阅读原文』可看直播视频回放