ROS通信架构（下）
ROS通信架構（下）
?徐凱_xp
0.3832019.05.02 19:24:46字數 1,895閱讀 261
將繼續介紹ROS通信方式中的service、parameter server、actionlib。
Topic是ROS中的一種單向的異步通信方式。然而有些時候單向的通信滿足不了通信要求，比如當一些節點只是臨時而非周期性的需要某些數據，如果用topic通信方式時就會消耗大量不必要的系統資源，造成系統的低效率高功耗。
為了解決以上問題，service方式在通信模型上與topic做了區別。Service通信是雙向的，它不僅可以發送消息，同時還會有反饋。所以service包括兩部分，一部分是請求方（Clinet），另一部分是應答方/服務提供方（Server）。這時請求方（Client）就會發送一request，要等待server處理，反饋回一個reply，這樣通過類似“請求-應答”的機制完成整個服務通信。
這種通信方式的示意圖如下：
Node B是server（應答方），提供了一個服務的接口，叫做 /Service ，我們一般都會用string類型來指定service的名稱，類似于topic。Node A向Node B發起了請求，經過處理后得到了反饋。
?
Service是同步通信方式，所謂同步就是說，此時Node A發布請求后會在原地等待reply，直到Node B處理完了請求并且完成了reply，Node A才會繼續執行。Node A等待過程中，是處于阻塞狀態的成通信。這樣的通信模型沒有頻繁的消息傳遞，沒有沖突與高系統資源的占用，
只有接受請求才執行服務，簡單而且高效。
Topic VS service
Srv
類似msg文件，srv文件是用來描述服務（service數據類型的，service通信的數據格式定義在*.srv中。它聲明了一個服務，包括請求(request)和響應（reply）兩部分。
舉例：
msgs_demo/srv/DetectHuman.srv
msgs_demo/msg/HumanPose.msg,Srv只能嵌套msg，不能嵌套srv
std_msgs/Header header string uuid int32 number_of_joints my_pkg/JointPose[]joint_datamsgs_demo/msg/JointPose.msg
string joint_name geometry_msgs/Pose pose floar32 confidence以 DetectHUman.srv 文件為例，該服務例子取自OpenNI的人體檢測ROS軟件包。它是用來查詢當前深度攝像頭中的人體姿態和關節數的。srv文件格式很固定，第一行是請求的格式，中間用---隔開，第三行是應答的格式。在本例中，請求為是否開始檢測，應答為一個數組，數組的每個元素為某個人的姿（HumanPose）。而對于人的姿態，其實是一個msg，所以srv可以嵌套msg在其中，但它不能嵌套srv。
修改部分文件
定義完了msg、srv文件，還有重要的一步就是修改package.xml和修改CMakeList.txt這些文件需要添加一些依賴：
<build_depend>** message_generation **</build_depend> <run_depend>** message_runtime **</run_depend>“**”所引就是新添加的依賴，又例如：
find_package(...roscpp rospy std_msgs ** message_generation **) catkin_package( ... CATJIN_DEPENDS ** message_runtime ** ... ...) add_message_file( FILES ** DetectHuman.srv ** ** HumanPose.msg ** ** JointPos.msg **) ** generate_messages(DEPENDENCIES std_msgs) **添加的這些內容指定了srv或者msg在編譯或者運行中需要的依賴。具體的作用我們初學者可不深究，我們需要了解的是，無論我們自定義了srv,還是msg，修改上述部分添加依賴都是必不可少的一步。
Paramater server
介紹另外一種通信方式——參
數服務器（parameter server）。與前兩種通信方式不同，參數服務器也可以說是特殊的“通信方式”。特殊點在于參數服務器是節點存儲參數的地方、用于配置參數，全局共享參數。參數服務器使用互聯網傳輸，在節點管理器中運行，實現整個通信過程。
參數服務器，作為ROS中另外一種數據傳輸方式，有別于topic和service，它更加的靜態。參數服務器維護著一個數據字典，字典里存儲著各種參數和配置。
維護方式
參數服務器的維護方式非常的簡單靈活，總的來講有三種方式：
- 命令行維護
- launch文件內讀寫
- node源碼
Action
Actionlib是ROS中一個很重要的庫，類似service通信機制，actionlib也是一種請求響應機制的通信方式，actionlib主要彌補了service通信的一個不足，就是當機器人執行一個長時間的任務時，假如利用service通信方式，那么publisher會很長時間接受不到反饋的reply，致使通信受阻。當service通信不能很好的完成任務時候，actionlib則可以比較適合實現長時間的通信過程，actionlib通信過程可以隨時被查看過程進度，也可以終止請求，這樣的一個特性，使得它在一些特別的機制中擁有很高的效率
Action規范
動作的內容格式應包含三個部分，目標、反饋、結果。
- 目標
機器人執行一個動作，應該有明確的移動目標信息，包括一些參數的設定，方向、角度、速度等等。從而使機器人完成動作任務。 - 反饋
在動作進行的過程中，應該有實時的狀態信息反饋給服務器的實施者，告訴實施者動作完成的狀態，可以使實施者作出準確的判斷去修正命令。 - 結果
當運動完成時，動作服務器把本次運動的結果數據發送給客戶端，使客戶端得到本次動作的全部信息，例如可能包含機器人的運動時長，最終姿勢等等。
Action規范文件的后綴名是.action，它的內容格式如下：
Action實例詳解
Actionlib是一個用來實現action的一個功能包集。我們在demo中設置一個場景，執行一個搬運的action，搬運過程中客戶端會不斷的發回反饋信息，最終完成整個搬運過程。
首先寫handling.action文件,類比如上的格式.包括三個部分,目標,結果,反饋.如下:
寫完之后修改文件夾里CmakeLists.txt如下內容:
1. find_package(catkin REQUIRED genmsg actionlib_msgs actionlib) 2. add_action_files(DIRECTORY action FILES DoDishes.action) generate_messages(DEPENDENCIES actionlib_msgs) 3. add_action_files(DIRECTORY action FILES Handling.action) 4. generate_messages( DEPENDENCIES actionlib_msgs)修改package.xml,添加所需要的依賴如下:
1. <build_depend>actionlib </build_depend> 2. <build_depend>actionlib_msgs</build_depend> 3. <run_depend>actionlib</run_depend> 4. <run_depend>actionlib_msgs</run_depend>然后回到工作空間 catkin_ws 進行編譯:
定義了一個搬運的例子,首先寫客戶端,實現功能發送action請求,包括進行目標活動,或者目標活動.之后寫服務器,實驗返回客戶端活動當前狀態信息,結果信息,和反饋信息.從而實現action.
?
?
?
?
-
機器人操作系統ROS(二)-文件系統架構及概念
?
-
ROS簡介
ROS的全名是Robot Operating System，即機器人操作系統。雖然名字里有個“操作系統”，但它并不...
?
-
ROS通信架構（上）
Node&Master 在ROS的世界里，最小的進程單元就是節點（node）。一個軟件包里可以有多個可執行文件，可...
-
ROS機器人程序設計 | 期末知識點大總結
工作空間的框架是怎么樣的？有幾個文件夾？ 一個包含功能包、可編輯源文件或編譯包的文件夾。同時編譯不同的功能包時非常...
-
?
?
?
總結
以上是生活随笔為你收集整理的ROS通信架构（下）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ROS通信架构（上）
- 下一篇： rm -rf ~/.bashrc 的惨痛