publish和subcribe是单向传输，但这种传输方式有时候并不能满足我们的要求
所以我们就有了service，同步通信方式，node间通过request-reply方式通信
过程描述：node A需要某个数据，发出了一个request调用service，然后在原地等候（阻塞），直到服务器端返回结果，然后nodeA继续执行。
和之前的topic的对比：
service通信的数据格式定义在*.srv文件中，可以类比topic中的*.msg（srv文件放在/Pkg/srv文件夹中）
srv文件格式：
在srv文件中有三个短横，上面是请求数据需要遵守的格式，下面是数据传回的格式
这个humanpose是一个msg自定义的格式（看第二个格子），也就是说srv可以嵌套msg，但是srv不能嵌套srv
而这个自定义的humanpose.msg中又嵌套了另外一个自定义的msg JointPos。也就是说msg中可以嵌套msg
在自定义完msg或者srv后一定要去修改CMakeList.txt和package.xml，添加编译和运行时依赖
（具体写法还是要百度一下）
常用指令：
Parameter Server：参数服务器（静态）
维护着一个字典，里面包含着参数和配置。方便一些数据的读写，可以用命令行，launch文件，API中进行读写
常用指令：
在launch文件中的配置方法：
（yaml文件可以视为一个字典文件）
之前提到过service通讯模型在请求后提出请求的节点会阻塞，但是有时候请求响应的时间比较长（大量计算，小车动作），这个时候service的client可能要等很久才可以知道结果。所以我们希望有一个实时的反馈。
Action：（升级版service）带有状态反馈的通信方式，通常用在长时间、可抢占的任务
可以中途取消，可以在运行中途知道运行了多少进度（或者其他状态信息）
action通讯的数据格式定义在*.action文件中，相当于.srv对应service，.msg对应于topic
action文件的书写：
一个 action文件分为三段，用“---”隔开
当然result可以空定义，只用多次回传的feedback信息
https://www.icourse163.org/learn/ISCAS-1002580008#/learn/content?type=detail&id=1004034129&sm=1
网课地址↑
143
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
