无人车之美——软件架构篇

——刻意练习，不停地刻意练习！

接上一篇。

无人车之美——技术要点速览本文以自身经历回顾进入无人车领域的心路历程和心流变化，并在无人车软件架构的基础上，罗列各个板块所必须掌握的基础知识或技能，希望对无人车从业者有所帮助或启发。https://blog.csdn.net/slampai/article/details/127469210

目录

0. 写在前面——使用系统化思维

1. 常见软件框架——避免成为“调参侠”

2. 框架剖析——站在巨人肩膀上看问题

3. 框架扩展——引入底盘控制与SLAM功能

4. 架构重组——建立无人车系统大闭环

5. 最后的话

---

还是这张图，接上一篇《无人车之美——技术要点速览》。

0. 写在前面——使用系统化思维

在无人车领域遨游，面对层出不穷的车型分类和专业术语，你必然会感觉有些眼花缭乱。这时，就该强调一下系统化思维了。系统化思维是碎片化学习的粘合剂，能将点滴经验和知识浇铸成一座具有生命力的艺术之山。具有系统化思维的人才能真正看破事物本质。

1. 常见软件框架——避免成为“调参侠”

        当聚焦在无人驾驶领域，剥离无人车辆的物理结构和美学外形，从单体控制与集群调度的角度去思考，会发现，即便是需要囊括五花八门的车辆运动模型，也可以整合成统一形式的无人驾驶系统控制框架。

        心流流到这里，稍有经验的你肯定会想到常见的ROS，想到百度Apollo。

        但这里要指出的是，ROS基于广义上机器人系统，是一套通用工具，常用于快速验证算法和常规商业场景；而百度Apollo系统是为了帮助汽车行业及自动驾驶领域的合作伙伴结合车辆和硬件系统，快速搭建一套属于自己的自动驾驶系统。

        不可否认，有了这些工具，就可以借鉴这两者及类似系统的思想和方法，但你应当提醒自己注意，小心掉入沾沾自喜的狭隘心态里，把“对工具的熟练掌握”当做“对核心技术的深刻理解”，成为了“调参侠”而不知。

        当然，无论是软件操作或是算法实现层面，都有各自待解决的问题和优化的方向。所谓文无第一，武无第二，从技术角度而言，并不是说软件操作和软件实现相比算法层面的技术性逊色一些，而是说，算法背后的逻辑思路和数学推导更加抽象，可以不受限的选择任何一种语言在很多种平台上实现，即便是同一种语言也可以用很多中实现方式。

        但是，任何一种操作软件的流行或黯淡，受到天时地利人和的多重影响。受限于你的专业知识与项目经验的局限，不同工作环境下，你很有可能会选择完全不同的上层软件，甚至是一些小众的编程语言。

        因此，从更本质的角度去思考和选择的话，也许无人驾驶背后的算法原理和逻辑思路更像是基本功。

2. 框架剖析——站在巨人肩膀上看问题

        你进一步地问，无人驾驶的相关算法不计其数，那究竟什么才是整个技术框架里的树干，哪些又是枝干和树叶？

        带着这些问题，也避免重复造轮子，你选择先参考业内成熟的框架。你打算多接触业内的无人驾驶软件产品，无论开源或是商业产品，只要有机会就多了解，有条件就仔细问。

        经过一番对比，你觉得百度Apollo的架构相对完整，和自己的理解比较接近，那就试着从百度Apollo框架切入，剖析出形式更一般的无人驾驶框架，其意义如同获取未知世界的导航地图一样重要。

        当写下这些文字时，Apollo最新版是7.0，相比6.0主要变动在云端服务平台。此外，开源软件平台里，感知和预测模块里虽有更新，也只是增加了深度学习的新模型。

        值得注意的是，7.0与6.0比较而言，模块数量没有改变。这说明一个问题，到6.0版本时，Apollo的软件架构基本定型，可以认为能够覆盖住无人驾驶的大部分场景，解决绝大部分问题。

        所以，我们结合英文版的6.0软件架构，以中英文对照的方式继续进一步思考。

       首先是最上层的云服务平台，关键词是服务，体现形式是云，主要目的是为了使整套软件更好用，妥妥的“软装修”，所以，姑且归纳为软件层；

        接着是开源软件平台，除去RTOS·、pollo Cyber RT、V2X适配器（V2X adaptor）和HMI（人机交互）这些软件类的系统或工具实现，剩下的是一个个功能模块（对应Apollo V7.0架构图中红框内容），对应着丰富的算法，是我们需要关注的重点；

        再接着是，硬件开发平台（Hardware Dev Platform）主要是通讯接口的实现，便于这些硬件在RTOS和Apollo Cyber RT系统中进一步使用，每一类硬件都会有工程化的标准解决方案可以参考，因此，学习的重点在于硬件（大部分是传感器）原理的理解和总线协议的熟练掌握，之后便可轻松应对同类的所有产品；

        最后是车辆参考平台，百度Apollo侧重解决汽车行业的问题，对应的驱动形式是阿克曼底盘或是四驱模型，我们将拓展并延伸至更丰富的底盘形式（对应Apollo V7.0架构图中绿框内容）。

       随后，你可以轻松在网上搜索到这样一张关于百度Apollo的软件架构图，可能正好切合了你对无人驾驶技术架构的理解。

3. 框架扩展——引入底盘控制与SLAM功能

        为了便于后续知识积累更加系统化，也为了将算法类知识和软件类知识稍作区别，我们将Monitor（监控系统，监控车辆中所有的软硬件）和HMI（人机交互，帮助使用者与系统之间进行信息交互）剔除，并认为Guardian（监控模块，监控检测故障并进行干预）属于一种安全模块，侧重于软件工程实现，可在control模块和CANbus模块里分布式考虑和实现。

        同时，为支持多种形式的运动底盘，将CANbus模块升级为更一般的Chassis底盘控制模块。更特别的，在上图基础上，增加了Routing路由模块，以实现全局范围内的路径规划。

        考虑到，在特殊的场景里，比如底下车库或工厂内部等，需要车辆自行建图，因此将原来的HD map高清地图换成了更一般的mapping建图模块。

        因此，无人驾驶的技术框架归纳为如下形式。

      

4. 架构重组——建立无人车系统大闭环

        有一种观点认为，Apollo 无人驾驶平台是以高精地图和定位模块作为核心，其他的模块都是以这两个模块为基础。这种理解其实很自然。

        你也发现，在重新整理后的软件架构里，Mapping和Localization与绝大多数模块（除了Control控制模块和Chassis底盘模块）相关，而无人驾驶的核心算法集中在自主导航部分，由感知、预测、规划和控制四个子模块组成。在百度Apollo的每次版本更新中，这4个板块必有更新，perception尤为突出。

        因此，将高清地图和定位模块作为核心的理解是可以接受的，但是从系统性和控制论的角度来看，总觉得结构不够清晰，或者说，这张图只是理清了各个模块之间的信息交换关系，但并没有体现模块与模块之间的系统结构关系。

        基于这样的思路，结合控制论中对稳定系统闭环结构的基本要求，有了下面这张图。

        当然，这种结构可用作理解无人驾驶的技术架构。更特别的是，通过不同版本之间的自由组合，可以清晰地理解无人驾驶车辆的技术演变史。

        为了让整个系统结构更简洁，将架构图中功能相近的模块进行整合，形成5个组合板块（其实，也对应着无人驾驶系统开发公司的5种技术岗）。

        首先，本质上讲，无人驾驶问题的控制对象是以底盘所代表的车辆，改变的是车辆位姿，对应的是图中1号板块，解决的是正向和逆向运动学问题。如果车辆控制信息来自遥控器、手操器或者是直接驾驶，就形成了一个最简单的开环系统，由人来完成车辆的启停和控制。这对应着车辆控制的原始阶段。

        接着，2号板块解决的问题简称规控问题。在早期，无人驾驶的车道线巡线，园区内基于磁条或色带的自动导航，可以认为是定轨迹的规控问题。当后续第4板块的地图与实时定位技术纳入系统后，定轨迹问题就升级为了变轨迹的规控问题，也就是说，不用完全依靠环境中预设的轨迹，可以根据需求在多种可能的轨迹中寻优并进行控制。所以，这里的Planning规划指的是局部规划，属于轨迹优化、轨迹规划的范畴，有别与5号板块的全局规划。

        在3号板块里，早期的Perception感知比较单纯，仅仅是检测一定范围内障碍物的有无，属于静态的检测，起到安全保护的作用；随着神经网络的盛行，可感知的信息越来越丰富，与控制相关的有车道线和红绿灯以及导引标志等，与安全有关的有障碍物检测和360度环视等；而Prediction预测是静态感知的升级，增加运动环境中被检测对象的运动状态信息，进一步提升系统的安全性。同样，当第4板块的地图与实时定位信息加入系统后，从3号板块的检测范围进一步扩大和灵活，基于这些信息，第5板块的Routing路由模块可以灵活规划全局路径。

        4号板块的出现，对2号和3号板块的所有模块都有促进作用，作用体现在提高系统的灵活性。需要特别指出的是，SLAM技术能覆盖建图和定位的双重功能，但并不代表必须同时使用两种功能，多数情况下提到SLAM是为了构建一幅高精地图HD map，以便于在局部环境中达到更高的定位精度。

        最后，5号板块解决的是全局路径规划问题，与2号板块里的Planning局部路径规划有所区别，多在调度系统中进行实现。

        至此，有必要对整个系统中的所有子模块做一下简单定义：

        1） Chassis —— 底盘模块，将整车控制命令分解为轮组控制，并反馈车辆状态信息。

        2） Control——控制模块，通过产生加减速和转向等整车控制命令来执行计划的时空轨迹。

        3） Planning——规划模块，规划车辆要采取的局部时空轨迹。

        4） Perception——感知模块，识别车辆周围的环境，典型有障碍物检测和交通灯检测。

        5） Prediction——预测模块，预测障碍物未来的运动轨迹。

        6） Mapping——建图模块，实时构建或更新局部地图。

        7） Localization——定位模块，利用各种信息源（如 GPS、LiDAR 和 IMU）估计车辆位姿。

        8） Routing——路由模块，确定车辆到达目的地的全局路径。

5. 最后的话

        基于以上复盘与思考，为了更好地理解系统的组成，也为了便于展开无人车辆领域的知识积累和经验总结，后续将基于以下5大技术板块进行展开：

1. Chassis —— 底盘控制。
2. Planning&Control——规划与控制。
3. Perception——感知与预测。
4. SLAM——同步建图与定位。
5. Routing——全局规划。

        5个板块都值得好好探究，进一寸都有一寸的欢喜。

        兴趣是天生有的，专注需后天培养，而剩下的就是刻意练习核心技能。

        每个板块都会有很多的技术分支，若不加区分地学习会花掉大量时间而收获有限。而刻意练习核心技能的目的是，追根溯源找到每个分支里的源头活水，提升对整个系统的理解高度，从而丝滑地过渡到最前沿的新概念和新方法，并能游刃有余地掌握和使用。

        希望对你有所启发。

        好了，下次再聊。