【导航业务架构】Autoware和Apollo自动驾驶系统的对比

系列文章目录

提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加
TODO:写完再整理

---

前言

认知有限，望大家多多包涵，有什么问题也希望能够与大家多交流，共同成长！

在项目和平时的学习中，我对机器人/无人驾驶的决策规划模块进行了划分，当然划分的方法有很多，我的划分方式仅供参考
（1）动态障碍物行为预测模块（Behavior prediction）–结合感知和高精度地图信息，估计周围障碍物未来运动状态
（2）执行机构的轨迹规划模块（Trajectory_planning）–执行机构如机器人载体上的机械臂、串行云台等的运动轨迹规划
（3）任务决策模块（Mission_planning）–任务决策模块比较偏业务层了，处理机器人/无人驾驶的各种任务，主要分为三个方面：车底盘航线业务决策（交规、横向换道等等）、执行应用机构业务决策（机械臂、人机交互等等）、不同场景的导航方案切换决策（组合导航、融合导航）
（4）前端路径探索模块（path_finding）–全局路径规划算法难度不算复杂，找到一条可通行的（必须满足）、考虑动力学的（尽可能满足）、可以是稀疏的路径base_waypoints【由于其只考虑了环境几何信息，往往忽略了无人机本身的运动学与动力学模型。因此，其得到的轨迹往往显得比较“突兀”，并不适合直接作为无人机的控制指令】
（5）后端轨迹处理模块（motion_planning）–我主要归纳整理为三个方向：（1）对base_waypoints进行简单处理及生成方向、（2）对base_waypoints轨迹优化方向【一般是二次优化，这里用的较多的事优化方面的知识】、（3）进行对应功能的replan方向（replan之前的预处理、进入replan的条件、停障replan、避障replan、纠偏replan、换道replan、自动泊车replan、穿过狭窄道路replan等等），这部分内容使用的方法比较专
（6）路径跟踪模块（trajectory_following）–这个模块就得针对机器人载体了，如无人驾驶使用得阿克曼模型可以采用几何的pure pursuit纯追踪算法，更好的可以用模型预测控制MPC方法，还有强化学习做的（效果怎样我就没验证过了）；当然也可能事麦克纳姆轮车、差速车PID、还有无人机的三维轨迹跟踪等等
（7）碰撞检测模块
（8）集群多机器人规划模块

当然，这种划分方式是我权衡了原理和功能粗略划分的，在实际产品研发过程中，需要理解了各个算法的功能和定位的基础上融汇贯通，不能生搬硬套，如全段通过hybrid A探索出来的路径与A、RRT*探索出来的路径更平滑，后端轨迹优化的任务就不用这么重了；又如，机器人/无人驾驶项目研发的需求业务还没发展到能响应很多功能阶段，任务决策使用简单的状态机（fsm）就可以对现有任务进行状态转移了

本文先对Autoware和Apollo自动驾驶系统的对比做个简单的介绍，具体内容后续再更，其他模块可以参考去我其他文章

---

提示：以下是本篇文章正文内容

一、Autoware和Apollo自动驾驶系统区别

1.硬件系统底层方面

（1）Apollo推荐64位x86指令集的CPU加英伟达GPU架构

（2）Autoware主要使用英伟达的AGX Xavier或PX2，也就是推荐ARM的V8指令集架构CPU。当然，也支持64位x86指令集的CPU加英伟达GPU架构
.
.
.

2.软件系统上层方面

相比，Apollo的框架更加丰富和复杂

（1）Autoware使用ROS中间件

（1）优点

Ros作为世界上最丰富的机器人操作系统，积累了大量的经验，避免了开发者重复的开发工作，提高了开发效率

（2）缺点

由于Linux是一个极其开放的开发环境，内核调度器对于算法业务逻辑并不清晰，只能保证公平的分配资源。所以，ROS Node运行顺序并无任何逻辑。【防盗标记–盒子君hzj】但本质上自动驾驶是一个专用系统，任务应按照一定的业务逻辑执行
ROS是针对机器人整个领域的，不是针对无人驾驶车的
.
.
.

（2）Apollo3.5以后的版本使用了自己的CyberRT中间件

（1）CyberRT的介绍

CyberRT从下到上依次的层
（1）基础库：高性能，无锁队列；
（2）通信层：Publish/Subscribe机制，Service/Client机制，服务自发现，自适应的通信机制（共享内存、Socket、进程内）；
（3）数据层：数据缓存与融合。多路传感器之间数据需要融合，而且算法可能需要缓存一定的数据。比如典型的仿真应用，不同算法模块之间需要有一个数据桥梁，数据层起到了这个模块间通信的桥梁的作用；
（4）计算层：计算模型，任务以及任务调度；
.
.

（2）CyberRT优点

（1）没有调度，无算法运算逻辑，为了解决这个不足Cyber RT 的核心设计将调度、任务从内核空间搬到了用户空间。调度可以和算法业务逻辑紧密结合。之所以能这么做，主要是“协程”的运用。线程分为内核态线程和用户态线程，用户态线程需要绑定内核态线程，CPU并不能感知用户态线程的存在，它只知道它在运行1个线程，这个线程实际是内核态线程。用户态线程实际还有个名字叫协程（co-routine），为了便于区分，我们使用协程指用户态线程，使用线程指内核态线程。协程跟线程是有区别的，线程由CPU调度是抢占式的，协程由用户态调度是协作式的，【防盗标记–盒子君hzj】一个协程让出CPU后，才执行下一个协程

（2）相比Ros，CyberRT增加了Component组件，组件之间通过 Cyber channel 通信。Cyber RT 中用Message实现模块间通信，其实现基于 protobuf。同时，CyberRT也支持异步计算任务，优化线程使用与系统资源分配，同时支持定义模块拓扑结构的配置文件

（3）CyberRT缺点

CyberRT也存在用户经验少的短板，同时资源也没有Ros全面

3.源码开源程度

Autoware的代码完全开源,Apollo的代码还处于非完全开源状态

二、Autoware和Apollo自动驾驶系统的安全程度比较

1.Autoware

Autoware自动驾驶安全包括行为安全、功能安全、碰撞安全、操作安全和非碰撞安全。每一个领域都需要各种测试方法的组合，这些测试方法可以让我们验证全自动驾驶汽车的安全性

（1）行为安全

行为安全是指车辆在道路上的行驶决策和行为。正如人类驾驶员，自动驾驶车辆也要遵守交通规则，必须在各种情况下安全地导航——无论是预料中的还是意外的。【防盗标记–盒子君hzj】autoware运用功能分析、仿真工具和道路驾驶，以充分了解在我们的业务设计领域提出的挑战，并制定安全要求和多管齐下的测试和验证过程

（2）功能安全

功能安全旨在确保我们的车辆安全运行，即使有系统缺陷或故障。这意味着要建立备份系统和冗余机制来处理意外情况。例如，我们所有的自动驾驶车辆都配备了第二台计算机——在主计算机出现故障时可立刻接管车辆，使车辆安全停车（即最小风险条件）。我们的每一辆车都有备用转向和制动，整个系统还有其他许多冗功能。

（3）碰撞安全性

碰撞安全性，即耐撞性，是指车辆通过各种措施保护车内乘客的能力，从保护车内人员的结构设计到具有座椅约束和安全气囊的功能，以减轻伤害或防止死亡。【防盗标记–盒子君hzj】碰撞安全性是由美国联邦机动车辆安全标准（FMVSS）定义的，由美国国家公路交通安全管理局（NHTSA）发布。汽车厂商必须证明他们的基础车模型满足FMVSS要求。

（4）操作安全

操作安全是指我们的车辆和乘客之间的互动。有了操作上的安全，我们可以确保消费者在自动驾驶车辆中拥有安全舒适的体验。
我们建立安全产品的方法是通过危险分析、现有安全标准、广泛测试和各种行业的最佳实践而得知的。例如，通过我们早期的乘坐项目（在4节中进一步介绍），我们已经开发和测试了一种能使乘客可以清楚地表明目的地，指挥车辆靠边停车，并联系autoware的用户界面

2.Apollo

Apollo的自动驾驶安全包含安全设计和安全运行两大主要内容，【防盗标记–盒子君hzj】其中细分为操作安全、环境安全、行为安全、功能安全、质量安全、机制安全和安全进化七大内容。

综合来看，阿波罗的势力最强，合作伙伴最多，但车规方面和嵌入式系统方面考虑还不够。Autoware考虑嵌入式系统最多，车规方面较少，双方各有优缺点