ROS基础知识

1.ROS基本概念

ROS全称Robot Operating System(机器人操作系统)
ROS是适用于机器人的开源元操作系统
ROS集成了大量的工具，库，协议，提供类似OS所提供的功能，简化对机器人的控制
还提供了用于在多台计算机上获取，构建，编写和运行代码的工具和库，ROS在某些方面类似于“机器人框架”
ROS设计者将ROS表述为“ROS = Plumbing + Tools + Capabilities + Ecosystem”，即ROS是通讯机制、工具软件包、机器人高层技能以及机器人生态系统的集合体

2.ROS计算图级

WorkSpace — 自定义的工作空间

|--- build:编译空间，用于存放CMake和catkin的缓存信息、配置信息和其他中间文件。

|--- devel:开发空间，用于存放编译后生成的目标文件，包括头文件、动态&静态链接库、可执行文件等。

|--- src: 源码

    |-- package：功能包(ROS基本单元)包含多个节点、库与配置文件，包名所有字母小写，只能由字母、数字与下划线组成

        |-- CMakeLists.txt 配置编译规则，比如源文件、依赖项、目标文件

        |-- package.xml 包信息，比如:包名、版本、作者、依赖项...(以前版本是 manifest.xml)

        |-- scripts 存储python文件

        |-- src 存储C++源文件

        |-- include 头文件

        |-- msg 消息通信格式文件

        |-- srv 服务通信格式文件

        |-- action 动作格式文件

        |-- launch 可一次性运行多个节点 

        |-- config 配置信息

    |-- CMakeLists.txt: 编译的基本配置

3.ROS工作空间

1.创建工作空间
mkdir -p ~/catkin_ws/src
cd ~/catkin_ws/src
catkin_init_workspace

#编译工作空间
cd ..
catkin_make

#设置环境变量
source devel/setup.bash
gedit ~/.bashrc
source ~/catkin_ws/devel/setup.bash
source ~/.bashrc
echo $ROS_PACKAGE_PATH #检查

2.创建功能包
catkin_create_pkg <package_name> [depend1] [depend2] [depend3]
catkin_make   #编译功能包

4.ROS话题

话题通信实现模型是比较复杂的，该模型如下图所示,该模型中涉及到三个角色:
ROS Master (管理者)
Talker (发布者)
Listener (订阅者)
ROS Master 负责保管 Talker 和 Listener 注册的信息，并匹配话题相同的 Talker 与 Listener，帮助 Talker 与 Listener 建立连接，连接建立后，Talker 可以发布消息，且发布的消息会被 Listener 订阅
假设节点1为发布节点，节点2为订阅节点，话题通信过程如下：
1）节点1向master注册，包括发布话题名称，节点所在地址等
2）节点2向master注册，包括订阅话题名称、节点所在地址等
3）master将信息匹配，完成后将节点1的地址给节点2
4）节点2根据master发来的地址向节点1发送连接请求，包括订阅话题名，通信协议等
5）节点1收到请求后反馈确认，包括自身TCP地址
6）节点2收到TCP地址后与节点1建立TCP网络连接
7）节点1将数据发送给节点2

5.ROS服务

服务通信较之于话题通信更简单些，理论模型如下图所示，该模型中涉及到三个角色:
ROS master(管理者)
Server(服务端)
Client(客户端)
ROS Master 负责保管 Server 和 Client 注册的信息，并匹配话题相同的 Server 与 Client ，帮助 Server 与 Client 建立连接，连接建立后，Client 发送请求信息，Server 返回响应信息。
服务通信过程如下：
1）节点1向master注册，包括发布话题名称、节点所在地址等；
2）节点2向master注册，包括订阅话题名称、节点所在地址等；
3）master将注册列表中的信息进行匹配，匹配完成后将节点1的地址发送给节点2；
4）请求节点与服务节点建立TCP连接并发送请求数据；
5）服务节点处理请求数据并反馈应答数据

6.ROS动作

为什么要用action？
导航是一个过程，是耗时操作，如果使用服务通信，那么只有在导航结束时，才会产生响应结果，而在导航过程中，节点A是不会获取到任何反馈的，从而可能出现程序"假死"的现象，过程的不可控意味着不良的用户体验，以及逻辑处理的缺陷(比如:导航中止的需求无法实现)。更合理的方案应该是:导航过程中，可以连续反馈当前机器人状态信息，当导航终止时，再返回最终的执行结果。在ROS中，该实现策略称之为:action 通信。
概念和算法
ROS中有actionlib功能包集，实现action通信，在请求和响应的过程中，服务端还可以连续的反馈当前任务进度，客户端可以接收连续反馈并且还可以取消任务。如图。

一般用于耗时的请求响应场景，以获取连续的状态反馈。