ROS核心框架
對(duì)于第一個(gè)問題,我也沒仔細(xì)研究過源碼,核心代碼基本由python和C++組成,運(yùn)用了xmlrpc機(jī)制,每個(gè)運(yùn)行的節(jié)點(diǎn)可以理解成一個(gè)進(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)行時(shí)需要一個(gè)主控制器ROS Master(通過roscore指令開啟),ROS Master通過RPC(Remote Procedure Call Protocol,遠(yuǎn)程過程調(diào)用)提供了登記列表和對(duì)其他計(jì)算圖表的查找。
沒有控制器,節(jié)點(diǎn)將無法找到其他節(jié)點(diǎn),交換消息或調(diào)用服務(wù)。節(jié)點(diǎn)與節(jié)點(diǎn)之間的連接是直接的,控制器就像一個(gè)DNS(Domain Name System)服務(wù)器。
ROS的框架還是挺復(fù)雜的,光看一些理論性的介紹可能還有點(diǎn)概念,但真正去實(shí)現(xiàn)里面肯定還有不少細(xì)節(jié)問題。
真正在應(yīng)用ROS框架時(shí),其實(shí)也有一些不足的地方,比如:
1、ROS節(jié)點(diǎn)相互之間通信時(shí)如何知道另外一個(gè)節(jié)點(diǎn)的狀態(tài),是宕掉了還是正常,因?yàn)樗鼜?qiáng)依賴于于中心節(jié)點(diǎn)ROS Master。本身在系統(tǒng)中頻繁創(chuàng)建話題就不是一件很好的事,會(huì)造成多少內(nèi)存碎片。
在使用ros::Subscriber sub = n.subscribe(“chatter”, 1000,chatterCallback)時(shí),這個(gè)1000是隊(duì)列消息的緩存數(shù)目,如果是圖像或者點(diǎn)云比較大的數(shù)據(jù),就不要隨便寫1000了,不然內(nèi)存會(huì)被消耗光。
2、系統(tǒng)中存在大量話題和數(shù)據(jù)時(shí),本地傳輸?shù)臄?shù)據(jù)延時(shí)大而不確定,遠(yuǎn)程傳輸?shù)臄?shù)據(jù)更是受帶寬和處理性能的影響。對(duì)于機(jī)器人的控制而言,想要達(dá)到精確更多,通信延時(shí)就要做得更小,而ROS這種通信機(jī)制實(shí)時(shí)性和穩(wěn)定性不太好。
3、ROS的msg采用md5碼去進(jìn)行校驗(yàn),如果一個(gè)人改了沒通知另外一個(gè)人,經(jīng)常導(dǎo)致另外一個(gè)人的包運(yùn)行不起來的尷尬局面。
4、ROS與可視化界面通信時(shí),有時(shí)不知道是界面還是ROS機(jī)制問題,界面會(huì)莫名閃退(rviz就經(jīng)常出現(xiàn)這樣的問題)。
5、關(guān)于ROS的動(dòng)態(tài)參數(shù)保存問題,比如在rqt_reconfigure上調(diào)好的參數(shù)如何在重啟roscore后加載調(diào)試后的參數(shù)。我曾花費(fèi)過很久的時(shí)間,參見《在ROS中處理yaml文件》和《ROS動(dòng)態(tài)調(diào)參(dynamic
reconfigure)客戶端服務(wù)端之C++ Python實(shí)現(xiàn)》
但也沒有很好地解決。很多功能可能僅適用于給開發(fā)者用,但當(dāng)作產(chǎn)品去使用還是有很多地方值得去優(yōu)化。
-
機(jī)器人
+關(guān)注
關(guān)注
210文章
27986瀏覽量
205533 -
主控制器
+關(guān)注
關(guān)注
2文章
28瀏覽量
10884 -
ROS
+關(guān)注
關(guān)注
1文章
276瀏覽量
16919
發(fā)布評(píng)論請先 登錄
相關(guān)推薦
評(píng)論