ROS Node node是執行運算的進程。節點相互組合成gragh，並通過streaming topics、PRC service、Parameter Server來進行通信。 ROS中節點的使用為整個系統提供了幾個好處。由於崩潰被隔離到各個節點，所以還有額外的容錯功能。與單片系統相比，代碼複雜性 ...
ROS Node
node是執行運算的進程。節點相互組合成gragh，並通過streaming topics、PRC service、Parameter Server來進行通信。
ROS中節點的使用為整個系統提供了幾個好處。由於崩潰被隔離到各個節點，所以還有額外的容錯功能。與單片系統相比，代碼複雜性降低。由於節點向圖的其餘部分展示了最小的API，所以實現細節也被很好地隱藏起來，並且替換實現（即使在其他編程語言中）也可以很容易地被替換。
所有正在運行的節點都有一個資源名稱，用於唯一標識系統的其餘部分。節點也有節點類型，這簡化了引用文件系統上可執行節點的過程。這些節點類型是包資源名稱，其中包含節點包的名稱和節點可執行文件的名稱。為瞭解析一個節點類型，ROS用指定名稱搜索包中的所有可執行文件並選擇它找到的第一個可執行文件。因此，不要在同一個包中生成具有相同名稱的不同可執行文件。
node在交互的時候分成publishers和subscribers。
ROS Topic
Topic是node交換Messages的命名匯流排。三者的關係就像：
node是站點，topic是路線，而messages是路線上的車輛。
Topic具有匿名的publishers和subscribers，它將信息的生產從其消費中分離出來。通常，nodes不知道他們正在與誰通信。相反，對數據感興趣的nodes訂閱相關topic; 生成數據的nodes發佈到相關topic。一個topic可以有多個publishers和subscribers。
Topic旨在用於單向流式通信。需要執行遠程過程調用（即接收對請求的響應）的節點應該使用services而不是topic。此外，還存在用於維護少量狀態的Parameter Server。
ROS Message
Node通過將messages發佈到topic來相互通信。Message是一個簡單的數據結構，包含類型欄位。標準的基本類型（整型，浮點型，布爾型等）和原始類型的數組都是受支持的。消Message可以包含任意嵌套的結構和數組（很像C結構）。
Node也可以交換request message和response message作為ROS service call的一部分。這些request message和response message在srv文件中定義。
ROS Service
服務是節點之間通信的另一種方式。
發佈/訂閱模型是一種非常靈活的通信模式，但是它的多對多單向傳輸不適用於分散式系統中經常需要的RPC請求/應答交互。請求/回覆是通過service完成的，service由一對消息定義：一個用於請求，另一個用於回覆。提供的ROS node在字元串名稱下提供service，客戶端通過發送request message並等待回覆來調用service。客戶端庫通常將這種交互作用呈現給程式員，就像它是一個遠程過程調用一樣。
Service使用srv文件來定義，srv文件由ROS客戶端庫編譯成源代碼。
客戶端可以建立與服務的持久連接，從而以較低的服務提供者變更的魯棒性為代價實現更高的性能。
ROS Master
ROS Master為ROS系統的其餘節點提供命名和註冊服務。它跟蹤發佈者和訂閱者的主題以及服務。Master的作用是使各個ROS節點相互定位。一旦這些節點互相找到對方，就彼此通信。
Master還提供Parameter Server(參數伺服器)。
Master最常用的是使用roscore命令，它將ROS Master與其他重要組件一起載入。
示例：
例如，假設我們有兩個nodes: Camera node和Image_viewer node。一個典型的事件序列將開始於Camera通知master，它想要發表的topic“images”的圖像：
現在，Camera將圖像發佈到“images”topic，但是沒有人訂閱該topic，因此實際上沒有發送數據。現在，Image_viewer想訂閱topic“images”，看看是否有一些圖像：
現在主題“圖像”既有發佈者又有訂閱者，主節點通知Camera和Image_viewer有關相互的存在，以便他們可以開始傳送圖像到另一個：
ROS Bag
一個bag是ROS中用於存儲ROS message data的文件格式。Bags——因為擴展名為.bag而得名——在ROS中起著重要作用，並且ROS中已經編寫了各種工具來允許存儲、處理、分析和可視化它們。
Bags通常由諸如rosbag之類的工具創建，該工具訂閱一個或多個ROS topic，並且在接收到序列化的消息數據時將其存儲在文件中。
數據記錄是ROS的主要機制，這意味著它們有多種離線用途。研究人員已經使用bag文件工具鏈來記錄數據集，然後對其進行可視化標記，並將其存儲起來以供將來使用。
ROS Parameter Server
Parameter server是可通過網路API訪問的共用的多變數字典。Nodes使用此server在運行時存儲和檢索參數。由於它不是為高性能而設計的，因此最好用於靜態非二進位數據，例如配置參數。它全局可見，以便工具可以輕鬆檢查系統的配置狀態併在必要時進行修改。
ROS Action
ROS中常用的通訊機制是topic和service，但是在很多場景下，這兩種通訊機制往往滿足不了我們的需求，ROS中有一個actinlib的功能包集，實現了action的通訊機制。那麼什麼是action呢？action也是一種類似於service的問答通訊機制，不一樣的地方是action還帶有一個反饋機制，可以不斷反饋任務的實施進度，而且可以在任務實施過程中，中止運行。
調試信息巨集：五個等級
ROS_DEBUG()
ROS_INFO()
ROS_WARN()
ROS_ERROR()
ROS_FATAL()
ROS_DEBUG()和ROS_INFO()通常顯示在stdout上。其它的則顯示在stderr上。且顏色也不同。
package和stack的關係
stack和distribution的關係
