VTD学习记录——八大进程概括（一）

 0.说明

→ 方块是程序，圆柱是数据； 黑色是通信协议，灰色是用户组件，橙色是 VTD 组件，黄色是硬件

→ 八大进程：SimServer / TaskControl / ParameterServer / GUI ModuleManager / Traffic / ScenarioEditor / IG

→ 三大标准：OpenDRIVE / OpenCRG / OpenSCENARIO + OdrMgr + OdrViewer → 工具组件：ROD / RDBSniffer / OdrGateway / Docker / RosGateway / etc

→ 开发 SDK：Communication / Module / Traffic / IG / Content(Cars) / etc

1.四大流程

→ 建立静态道路（更宽泛的理解：静态内容开发） 输入：国家道路规范，合格外部模型，已有的 tile 输出：逻辑道路数据库 xodr，图形道路数据库 osgb

→ 建立动态工况（更宽泛的理解：仿真故事的脚本） 输入：逻辑道路数据库 oxdr(关键），图形道路数据库 osgb(如果不在乎 IG 这里可以随便赋值） 输出：场景文件 xml

→ 仿真 输入：Setup（根据 simServer.xml 启动各进程，及配置文件）和 Project 及 Scenario 输出：traffic 数据输出(RDB)，IG 数据输出(Monitor or Shm or RDB)

→ 后处理 输入：仿真结果，评价标准 输出：评价结论，测试报告

2.最小系统描述 （standard SampleProject/trafficDemo.xml）

→ 当在 bin 文件夹下执行$ ./vtdStart.sh -select 并且选择了一个 Setup 后 脚本会启动 SimServer，并且根据 setup/config/SimServer/simServer.xml 中的 process 标签逐个启动 GUI 启动，也就是图形化界面 TaskControl 启动，没有图形界面，但是有一个 Xterm 小窗口显示它的状态 ParamServer 启动，同上 Traffic 待命， ModuleManager 待命，igGroup 待命，ScenarioEditor 待命

→ 当在 GUI 上按下 Apply 以后，除了 TC 和 PS，以外 Traffic,IG,MM 也启动，可以看到他们三个的小窗 Traffic 启动，即它知道了需要执行的场景文件 xml 和逻辑道路文件 xodr 是谁 ig 启动，即它知道了需要执行的场景文件 osfb，天空模型材质数据，车辆模型等等都在哪里 MM 启动，即它让由它管理的传感器和动力学模型都初始化，准备开始工作 注意：刚刚按下按钮的操作，实际上是 GUI 向 TC 发送了一条 SCP 报文，从而导致以上行为

→ 当在 GUI 上按下 Start 按钮以后，仿真正式开始。 TC 会根据我们在 ParamServer 的配置开始统筹所有模块进行仿真，再次忽略同步等具体细节。

1.Traffic 根据场景文件 xml 开始运算第一帧下交通场景的状况 如：交通灯这一帧 phase，internal 车辆这一帧的位置姿态，各个 trigger 的状态等等。 重要的是，根据 extern 车辆的驾驶员配置，制作出当前这一帧的驾驶行为信息。 当然了，Traffic 还需要通过 OdrMgr 访问 xodr 文件获取信息进行计算。

2.TC 从 Traffic 得到场景全部逻辑信息后进行分发。 如：驾驶信息传递给 MM，场景信息也要给 MM，如果 SE 启动了，也会给它。以及重要的是给 IG。

3.MM 从 Traffic 得到了数据以后，按照 plug-in 的优先级调用他们 如：传感器 plugin 得到了数据，会根据传感器的参数，对数据过滤，然后组织结果，发到指定端口。 动力学 plugin 得到了数据，计算出 extern 车辆的位置姿态，发送给 TC

4.SE 从 TC 获得数据后，可以实时显示场景当中各交通参与者的状态。 SE 也可以用 Monitor 向 TC 发出 SCP 指令；GUI 也可以发 SCP 指令，来影响下一次的仿真状态。 如果 SCP 是关于交通的，比如让某车换道，那么信息会给 Traffic 里的驾驶员模型来执行。 如果 SCP 是关于环境的，比如改变天气，那么信息会给 IG 渲染除相应的雨雪效果。

5.IG 从 TC 获得数据后，进行渲染 如：根据当前环境调整关照，根据当前摄像头信息进行画面渲染，根据当前交通信息摆放车辆等。 如：如果 IG 有 plug-in，也要根据优先级分别调用，例如完成激光雷达的感知工作。 → 就这样一帧一帧向前跑，每个模块都有自己的工作，具体每个模块的运行收到配置文件影响。 例如 IG 有非常多的配置文件，MM 则只需要维护一个文件。

→ 外加的模块要参与进来，就是通过 SCP 和 RDB 的方式。 Mockup 接进来一个方向盘和踏板，其实就是 USB 信号进来解析并且打包成 RDB 发给 Dynamics 了。 Sound 接进来就是通过 TC 得到本车的信息，作为参数触发声音发出。 任何 3rd Party 只要知道 RDB 和 SCP 的数据结构和含义，就可以影响整个仿真。 例如用手机发送指令改变天气，或者用手机驾驶本车在路上行驶，当然这需要开发手机客户端。 → 而生成数据如果要外接设备则根据具体情况分析，例如如果视频流需要到处，则可能需要融合机。 如果 RDB 的数据需要给到 ECU，那么需要转换成 CAN 信号。 具体的工程问题就需要具体分析了。

总结：上面的过程是四大流程中的仿真过程，其中涉及到了 八大进程。其中数据流通信使用了 RDB/SCP。

→ 就这样一帧一帧向前跑，每个模块都有自己的工作，具体每个模块的运行收到配置文件影响。 例如 IG 有非常多的配置文件，MM 则只需要维护一个文件。

→ 外加的模块要参与进来，就是通过 SCP 和 RDB 的方式。 Mockup 接进来一个方向盘和踏板，其实就是 USB 信号进来解析并且打包成 RDB 发给 Dynamics 了。 Sound 接进来就是通过 TC 得到本车的信息，作为参数触发声音发出。 任何 3rd Party 只要知道 RDB 和 SCP 的数据结构和含义，就可以影响整个仿真。 例如用手机发送指令改变天气，或者用手机驾驶本车在路上行驶，当然这需要开发手机客户端。

→ 而生成数据如果要外接设备则根据具体情况分析，例如如果视频流需要到处，则可能需要融合机。 如果 RDB 的数据需要给到 ECU，那么需要转换成 CAN 信号。 具体的工程问题就需要具体分析了。

总结：上面的过程是四大流程中的仿真过程，其中涉及到了 八大进程。其中数据流通信使用了 RDB/SCP。

3.自动驾驶数据流框架（最简形式）

1.环境：交通环境和自然环境，也就是 VTD 所提供的最核心的部分。 交通环境包括了静态道路（ROD 制作，依照 OpenDRIVE）和动态场景 ScenarioEditor 自然环境则由 IG 进行渲染

2.传感器：完美传感器，直接获取 Object List 级别信息，信息源是 Traffic 物理传感器，根据传感器类型，通过 IG 或者 MM 计算的 Raw Data，主要供给感知算法

3.感知算法：被测设备之一，针对 Raw Data 进行处理得到语义学信息。

4.融合算法：感知和决策之间的桥梁，针对多传感器之间不同的结果给决策统一的输入

5.决策算法：被测设备之一，给出顶层级别的指令，属于规划范畴

6.控制算法：据测和动力学之间的桥梁，最终都要落实到车辆横向纵向控制上去

7.动力学：根据车辆本身的参数，道路信息，和控制信息，以及上一时刻的状态，计算出当下的状态。

总结：VTD 仿真环境中环境车辆（背景车辆）中传感器到控制都是由 Traffic 模块实现的。 使用 VTD 仿真环境对被测车辆进行仿真则可根据上述过程进行针对性拆分。

4.八大进程

→ SimServer 管理进程初始化

→ TaskControl 管理进程的运行和 IO

→ ParamServer 管理基本参数

→ GUI 用户界面 → Traffic 交通仿真

→ ModuleManager 管理 Module Plugin 负责完美传感器和动力学

→ ScenarioEditor 动态场景的编辑和仿真监控

→ ImageGenerator 相机仿真/激光雷达仿真

5.三大标准

→ OpenDRIVE 道路的逻辑描述，包括了几何信息，车道线信息，交通信息，周遭建筑物信息

→ OpenCRG 道路的微观特性比如减速带等

→ OpenSCENARIO 交通动态信息

6.数据流与通信

→ RDB 高频率的信息内容，每仿真布长都会变化的量

→ SCP 低频率的信息内容，命令型

→ TCP/UDP/SHM 通信方式包括网络和共享内存