提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加
TODO:写完再整理
- 系列文章目录
- 前言
- 一、导航业务系统架构设计的出发点
- 二、系统架构思想分类（系统设计思想）
- 1.单功能包应用的系统特点
- 2.多功能包应用的系统
- 三、机器人模块的六个层次划分（自己的看法)
- 1.对模块进行划分的原因
- 2.模块层次划分标准
- 3.单个机器人模块层次划分类型
- 1、业务需求层（模块功能）
- 2、模块被调API及服务接口层（对外服务）
- 3、私有数据结构接口层（私有内部数据）
- 4、私有算法层（移植相关）
- 5、模块逻辑层（模块内部处理流程）
- 6、支持模块层（其他模块支持）
- 四、导航业务架构案例
- 1.navos
- 2.navigation(move_base)
- 3.Autoware
- 4.Apollo
- 等等
前言 认知有限，望大家多多包涵，有什么问题也希望能够与大家多交流，共同成长！
本文先对导航业务系统架构做个简单的介绍，具体内容后续再更，其他模块可以参考去我其他文章
提示：以下是本篇文章正文内容
一、导航业务系统架构设计的出发点第一步：定义市场场景与业务需求【方向–表层】
第二步：通过技术模块的组合成系统来解决场景需求【实现–重心】
第三步：考虑具体部署条件，具体问题具体分析，如系统架构设计也要有软件系统支持等等
.
.
.
move base和navos2.0仅仅只有一个功能包应用处理整个导航，包括裸奔一个main的单片机（上了实时系统的单片机可以虚拟出多任务线程，允许其他架构），一个应用处理整个导航更具有稳定性，不会出现偶尔挂一个功能包的情况导致系统崩溃（ros经常这样），但是兼容性不好，中心化的系统很多东西移植进去要考虑其他模块是否兼容，系统也更难维护，维护的时候不仅仅要考虑各个模块的接口，更要考虑各个模块的配合逻辑【防盗标记–盒子君hzj】
.
.
autoware实现导航的功能是通过多个功能包协助完成导航，每个功能包只负责自己的功能，系统子功能很分散，用通用统一数据的数据接口去统筹所有的功能包（navos1.0的思想）【防盗标记–盒子君hzj】，弊端就是有一个功能包挂了整体就挂了，这也是ros分布式的思想，功能分布式所以通讯和设备都是分布式的，部署比较容易，兼容性也较好，只要数据接口满足，可以插入各种平台和插件rqt，rviz【防盗标记–盒子君hzj】
.
.
因为机器人感知（传感器研发+理解+定位+地图）、路径规划、执行控制与业务决策（导航）的关系是非常紧密的，【防盗标记–盒子君hzj】进行每个模块的层次划分才能更好的把模块独立出来分工合作，更好的交互
.
.
模块按照自身标准划分，因为每个模块都有自身模块的特殊性，同时也具有共性
.
.
当然这五个层次相对比较抽象，而每个机器人模块的原理和实现方式都不太一样，但是我觉得总是可以按照下面五个层次对机器人单个模块进行划分，使得机器人单个模块内的逻辑更加清晰，什么原理功能能更好的定位是干什么的，重要型到哪里
一个好的导航系统，不仅仅是模块之间定义清晰不耦合，单一模块内的逻辑特使条条有理的，一个好的架构师很重要的，不然后面系统代码上来后，增加功能很难，系统耦合厉害，【防盗标记–盒子君hzj】加一个需求代码要修其他原有需求代码的好几个bug，然后程序员效率很低挂掉了~~
1、业务需求层（模块功能）状态机mission，业务执行secton（前端适合用工厂的设计方法）（连接业务需求和任务实现逻辑）
.
把本模块看成一个小黑盒子，通过提供SDK和API的形式，或者通过服务启动本模块，实现本模块输入输出的数据接口
.
1、各种驱动，传感器，各模块数据代理收发、日志备份、数据+代理中心【防盗标记–盒子君hzj】
代理一方向，把读取的数据都放在数据中心， 这样模块读取的接口不用重复写这么多订阅函数（交集的地方，避免冗余程序和订阅算力） （算法数据流更直观统一去查）
2、数据接口文件中心
模块交互的数据接口用protobuf写在protobuf的文件管理，【防盗标记–盒子君hzj】 模块内部自己用的数据结构.h也行）放在一个目录更直观（把握住不要随便合并和新建接口文件）
.
4、私有算法层（移植相关）每个模块的理论算法
.
.
.
.
包括自己自己写的库、系统内的通用的共用模块【防盗标记–盒子君hzj】，这个可以转战我那篇《机器人常用的库使用》的博客
还有支持导航的各个模块API，如地图、定位、控制、规划等等
.
.
.
公司内部导航业务系统，不能公开
2.navigation(move_base)转战navigation(move_base)导航架构的博客【防盗标记–盒子君hzj】
.
转战Autoware导航架构的博客
.
转战Apollo导航架构的博客
.
