ROS核心框架

對于第一個問題，我也沒仔細研究過源碼，核心代碼基本由python和C++組成，運用了xmlrpc機制，每個運行的節(jié)點可以理解成一個進程。進程間通訊有些是共享內存的方式（比如message_filter），有些應該是通過socket。

不過ROS的核心框架也就是ros-base主要由Willow Garage公司和一些開發(fā)者設計、提供以及維護，它提供了一些分布式計算的基本工具。

sudo apt install ros-melodic-ros-base

分布式計算框架可以理解為ROS的所有節(jié)點運行時需要一個主控制器ROS Master（通過roscore指令開啟），ROS Master通過RPC（Remote Procedure Call Protocol，遠程過程調用）提供了登記列表和對其他計算圖表的查找。

沒有控制器，節(jié)點將無法找到其他節(jié)點，交換消息或調用服務。節(jié)點與節(jié)點之間的連接是直接的，控制器就像一個DNS（Domain Name System）服務器。

ROS的框架還是挺復雜的，光看一些理論性的介紹可能還有點概念，但真正去實現(xiàn)里面肯定還有不少細節(jié)問題。

真正在應用ROS框架時，其實也有一些不足的地方，比如：

1、ROS節(jié)點相互之間通信時如何知道另外一個節(jié)點的狀態(tài)，是宕掉了還是正常，因為它強依賴于于中心節(jié)點ROS Master。本身在系統(tǒng)中頻繁創(chuàng)建話題就不是一件很好的事，會造成多少內存碎片。

在使用ros：：Subscriber sub = n.subscribe（“chatter”， 1000，chatterCallback）時，這個1000是隊列消息的緩存數(shù)目，如果是圖像或者點云比較大的數(shù)據(jù)，就不要隨便寫1000了，不然內存會被消耗光。

2、系統(tǒng)中存在大量話題和數(shù)據(jù)時，本地傳輸?shù)臄?shù)據(jù)延時大而不確定，遠程傳輸?shù)臄?shù)據(jù)更是受帶寬和處理性能的影響。對于機器人的控制而言，想要達到精確更多，通信延時就要做得更小，而ROS這種通信機制實時性和穩(wěn)定性不太好。

3、ROS的msg采用md5碼去進行校驗，如果一個人改了沒通知另外一個人，經(jīng)常導致另外一個人的包運行不起來的尷尬局面。

4、ROS與可視化界面通信時，有時不知道是界面還是ROS機制問題，界面會莫名閃退（rviz就經(jīng)常出現(xiàn)這樣的問題）。

5、關于ROS的動態(tài)參數(shù)保存問題，比如在rqt_reconfigure上調好的參數(shù)如何在重啟roscore后加載調試后的參數(shù)。我曾花費過很久的時間，參見《在ROS中處理yaml文件》和《ROS動態(tài)調參（dynamic
reconfigure）客戶端服務端之C++ Python實現(xiàn)》

但也沒有很好地解決。很多功能可能僅適用于給開發(fā)者用，但當作產(chǎn)品去使用還是有很多地方值得去優(yōu)化。