機器人是一個復雜的智能系統，并不僅僅是鍵盤遙控運動、識別某個目標這么簡單，我們需要實現的是送餐、送貨、分揀等滿足具體場景需求的機器人。

在這些應用功能的實現中，另外一種ROS通信機制也會被常常用到——那就是動作。從這個名字上就可以很好理解這個概念的含義，這種通信機制的目的就是便于對機器人某一完整行為的流程進行管理。

通信模型

舉個例子，比如我們想讓機器人轉個圈，這肯定不是一下就可以完成的，機器人得一點一點旋轉，直到360度才能結束，假設機器人并不在我們眼前，發出指令后，我們根本不知道機器人到底有沒有開始轉圈，轉到哪里了？

OK，現在我們需要的是一個反饋，比如每隔1s，告訴我們當前轉到多少度了，10度、20度、30度，一段時間之后，到了360度，再發送一個信息，表示動作執行完成。

這樣一個需要執行一段時間的行為，使用動作的通信機制就更為合適，就像裝了一個進度條，我們可以隨時把控進度，如果運動過程當中，我們還可以隨時發送一個取消運動的命令。

客戶端/服務器模型

動作和服務類似，使用的也是客戶端和服務器模型，客戶端發送動作的目標，想讓機器人干什么，服務器端執行動作過程，控制機器人達到運動的目標，同時周期反饋動作執行過程中的狀態。

客戶端發送一個運動的目標，想讓機器人動起來，服務器端收到之后，就開始控制機器人運動，一邊運動，一邊反饋當前的狀態。

如果是一個導航動作，這個反饋可能是當前所處的坐標，如果是機械臂抓取，這個反饋可能又是機械臂的實時姿態。當運動執行結束后，服務器再反饋一個動作結束的信息。整個通信過程就此結束。

一對多通信

和服務一樣，動作通信中的客戶端可以有多個，大家都可以發送運動命令，但是服務器端只能有一個，畢竟只有一個機器人，先執行完成一個動作，才能執行下一個動作。

同步通信

既然有反饋，那動作也是一種同步通信機制，之前我們也介紹過，動作過程中的數據通信接口，使用.action文件進行定義。

由服務和話題合成

大家再仔細看下上邊的動圖，是不是還會發現一個隱藏的秘密。

動作的三個通信模塊，竟然有兩個是服務，一個是話題，當客戶端發送運動目標時，使用的是服務的請求調用，服務器端也會反饋一個應帶，表示收到命令。

動作的反饋過程，其實就是一個話題的周期發布，服務器端是發布者，客戶端是訂閱者。

沒錯，動作是一種應用層的通信機制，其底層就是基于話題和服務來實現的。