ROS核心框架

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

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

sudo apt install ros-melodic-ros-base

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

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

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

真正在應(yīng)用ROS框架時，其實(shí)也有一些不足的地方，比如：

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

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

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

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

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

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

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