百度为何选用 ROS 系统？
在百度为何选用 ROS 系统的问题上，何玮给出解释，ROS 是一个强大而灵活的机器人编程框架，同时也是学术界使用最广泛的框架，它具有三大特性：完整的开发工具包、灵活的计算调度模型以及丰富的调试工具，能够统一提供配置管理、部署运行、底层通信等功能，让开发者将更多精力放在算法功能的研发上，快速构建系统原型，验证算法和功能。
ROS 系统的优势显而易见，但其在 Apollo 平台的应用中也并非一帆风顺。百度在做研发调试到产品化的过程中，遇到的不少状况，针对这些问题，百度从通信功能优化、去中心化网络拓扑以及数据兼容性扩展三个方面做了定制化的改进。
1、通信性能优化：共享内存
问题：自动驾驶系统为了能够感知复杂的道路场景并完成驾驶任务，需要多种传感器协同工作，以覆盖不同场景、不同路况的需求。而主流的多传感器融合方案至少会包含一个激光雷达和多个相机，如此大的数据量对通信的性能有很大的挑战。
解决方案：百度采用的解决方案是共享内存，减少传输中的数据拷贝, 提升传输效率。
-
1 对 1 的传输场景下，同一个机器上的 ROS 节点之间是 socket 进行进程间通信，中间存在多层协议栈以及多次用户空间和内核空间的数据拷贝，造成了很多不必要的资源占用和性能损耗。共享内存的方式来替代 socket 作为进程间通信的方式，通过减少不必要的内存拷贝，来降低了系统的传输延时和资源占用。
-
单对多的传输场景下，ROS 在处理一对多的消息传输时，底层实现实际是多个点对点的连接，当把一份数据要发给四个节点时，相同的数据会传输四次，这会造成很大的资源浪费。共享内存的传输过程，能够支持一次写入，多次读取的功能，对于一对多的传输场景，相同的数据包只需要写入一次即可，成倍地提高了传输的效率。
2、去中心化的网络拓扑：使用 RTPS 服务发现协议
问题：ROS 并非完全的分布式框架，每个 ROS 网络中需要有一个中心节点 ROS Master, 各个节点在初始化时会像 Master 注册拓扑信息并获取其他节点的信息。这种方式有两个缺点：1、Master 作为系统的单点，一旦崩溃整个网络将不可用；2、Master 缺乏异常恢复机制，崩溃后无法通过监控重启等方式自动恢复。
解决方案：为了解决这个问题，百度在 ROS 在框架加入了基于 RTPS 协议的服务发现功能。
整个网络拓扑不再以 master 为中心构建，而是通过域的概念进行划分。当一个新的节点加入网络时，会通过 RTPS 协议向域内的所有其他节点发送广播信息，各个节点也会将自己的服务信息发送给新的节点，以代替 Master 的信息交换功能。
通过这种方式，能够使 ROS 网络的拓扑发现不再依赖 Master 单点，提高了系统的鲁棒性。同时该修改完全基于 ROS 底层的修改，对上层应用程序完全透明，开发者也不需要对此功能有任何的代码适配工作。
3、数据兼容性扩展：用 Protobuf 替换 Message
问题：ROS 系统为了保证收发双方的消息格式一致，会对 message 定义做 MD5 校验，任何字段的增减或顺序调整都会使 MD5 变化，以保证系统的健壮性。然而这种严格的限制也引起了兼容性的问题，当接口升级后，不同的模块之间不再能够通信，大大增加了模块版本之间的耦合。
解决方案：使用 protobuf 来替换 ROS 中的 Message 来作为消息定义的格式。protobuf 本身有良好的兼容性支持，只需要在使用中定义好 required 字段，后续新增 optional 字段并不会对消息的解析造成影响。
Apollo 框架使用介绍
随后，何玮简单介绍了 Apollo 框架的使用方法
From: 深度剖析Apollo自动驾驶平台