基于sm32的p2p通信的研究與實現(xiàn)

基于sm32的p2p通信的研究與實現(xiàn)

0lego的單機器人仿真模型legogrouplego組件（以下簡稱lego組件）是一種廣泛用于青少年創(chuàng)新能力培訓(xùn)的智能“電子積木”組件。該組件實際上是一個自定義的嵌入應(yīng)用程序。中央控制器nxt是一個獨立的應(yīng)用程序模塊（系統(tǒng)通訊設(shè)備，套），此外還有各種傳感器模塊、時間統(tǒng)計模塊和機械傳動模塊。面向LEGO套件的軟件開發(fā)工具也越來越多,目前流行的有基于C、C++、JAVA、C#、G(Labview)等軟件開發(fā)環(huán)境和平臺,從原理上講,除了資源有限和積木式肢體脆弱,LEGO機器人與科學(xué)機器人具有相似的研究過程,能夠完成類似的任務(wù),例如LEGO行走機器人、棋類機器人、舞蹈機器人等。與目前流行的LEGO單機器人相比,多機器人系統(tǒng)由于涉及到機器人間協(xié)同,需要對人類行為的理解和仿真、乃至簡單的分布式和并行計算方面的知識和實踐,而且在構(gòu)建具體系統(tǒng)和編寫控制軟件過程中,大量的歸納/演繹等思維方法被反復(fù)應(yīng)用,因此,多機器人系統(tǒng)更加適合青少年創(chuàng)新能力的培養(yǎng)。然而多機器人系統(tǒng)的建立要比單機器人系統(tǒng)復(fù)雜得多,即便是作為系統(tǒng)基礎(chǔ)的多機器人間組網(wǎng)通信就不是一個簡單問題,尤其是對LEGO套件而言,其控制核心部件NXT的資源十分有限,雖然LeJOSNXJ提供了藍牙通信機制,但由于復(fù)雜多機器人將使用很多NXT,所以常用的藍牙Scatternet技術(shù)難以在LEGO復(fù)雜多機器人系統(tǒng)中實現(xiàn)對等(Peer-to-Peer,P2P)通信,另外,晦澀難懂的組網(wǎng)通信底層細節(jié)也讓人望而卻步。本文針對LEGONXT特點,基于LEGO套件的藍牙通信技術(shù),采用對資源需求比Scatternet小得多的Piconet,通過Piconet主設(shè)備上的數(shù)據(jù)轉(zhuǎn)發(fā),實現(xiàn)了多NXT組網(wǎng)和P2P通信,該組網(wǎng)通信機制命名為基于Piconet的P2P通信(PiconetBasedPeer-to-Peer,PBP2P)。1pc上的養(yǎng)分通信對于2節(jié)點藍牙通信而言,通信鏈路建立之初,兩個節(jié)點分別被定義為具有initiator(初始化模塊)的主設(shè)備和具有receiver(接收模塊)的從設(shè)備,從設(shè)備的recerver提出通信請求,而主設(shè)備的initiator則用來建立通信連接通道。多節(jié)點藍牙通信組網(wǎng)方式有兩種:其一為Piconet網(wǎng)絡(luò),該方式簡單,對資源需求低,網(wǎng)絡(luò)設(shè)備分為1個主設(shè)備和多個從設(shè)備,主從設(shè)備間可直接雙向通信,從設(shè)備間不能直接通信;其二是Scatternet網(wǎng)絡(luò),該網(wǎng)絡(luò)將Piconet從設(shè)備同時作為其他Piconet主設(shè)備,因此可為每個設(shè)備都建立一個以其為主設(shè)備的Piconet形成Scatternet網(wǎng),該網(wǎng)絡(luò)功能強大,可實現(xiàn)節(jié)點間P2P通信,但需要較多資源。顯然,如果以n個LEGONXT建立Scatternet,則每個NXT至少要含有n-1個與其他NXT的receiver對應(yīng)的initiator,即需要在NXT上建立眾多獨立運行的線程,而NXT的資源十分有限,難以負擔。考慮到NXT資源有限、多機器人系統(tǒng)規(guī)?？缮炜s性、以及系統(tǒng)運行監(jiān)控的需求,本文以帶有藍牙模塊的PC為中控機(以下簡稱PC),建立以PC為主設(shè)備,所有NXT為從設(shè)備的Piconet。盡管NXT只能與主設(shè)備PC通信,NXT之間不能直接通信,但通過在PC上提供通信服務(wù)模塊CCommServer用于轉(zhuǎn)發(fā)來自NXT的通信數(shù)據(jù)到其目標NXT,通過封裝底層通信細節(jié),在較高的軟件層次上實現(xiàn)了多機器人間的P2P通信。其具體通信機制和過程如圖1的UML活動圖所示。由圖1可知,具體通信功能由CCommServer、相關(guān)機器人的CCommunicator、CMsgProxy對象協(xié)作而共同完成。機器人調(diào)用函數(shù)CCommunicator:SendMsgToAnotherRobot(StringsRobotName,intnMsgID,intnParam,StringsTxt)向名字為sRobotName的機器人發(fā)送消息,消息類型為nMessageID,兩個消息參數(shù)分別為nParam和sText。該函數(shù)根據(jù)sRobotName查找通信錄得到目標NXT端口地址,然后將整條消息放置到NXT的待發(fā)隊列CMsgProxy:m_qMsgToSend尾部。CCommServer為獨立線程,運行時會交替進入“讀取”和“轉(zhuǎn)發(fā)”消息時段。在“讀取”時段,遍歷所有NXT,從其讀取發(fā)送到PC的消息,將它們存放至轉(zhuǎn)發(fā)隊列CCommServer:m_msgpQue尾部;在“轉(zhuǎn)發(fā)”時段,解析轉(zhuǎn)發(fā)隊列CCommServer:m_msgpQue隊首消息,如其目標為當前正連接著的NXT,則將其傳送到該NXT。此過程反復(fù)進行,直到隊首不再有發(fā)往該NXT的消息為止。各NXT的CMsgProxy也是獨立線程,運行時交替進入“發(fā)送”和“讀取”時段。“發(fā)送”時段將待發(fā)隊列CMsgProxy:m_qMsgToSend隊首消息拆分并轉(zhuǎn)換成LeJOSNXJ藍牙通信格式的數(shù)據(jù),然后逐一將其發(fā)送給目標NXT;“讀取”時段從當前連接的NXT讀取數(shù)據(jù),然后調(diào)用CCommunicator:DispatchMsgToUnit(CMsgPkgmp),將消息散發(fā)至本地CRobot的各個相關(guān)對象。2基于android的對象消息機制由于leJOS等Java軟件開發(fā)平臺沒有類似MFC之類的對象消息機制,這對協(xié)同多機器人系統(tǒng)的軟件開發(fā)十分不變,為此,作者在參考文獻后建立了基于Java語法標準的對象消息機制,而本文機器人間通信是該對象消息機制的底層支撐,因此其具體實現(xiàn)與對象消息機制的實現(xiàn)密切相關(guān)。2.1管理系統(tǒng)的結(jié)構(gòu)由于LEGO多機器人組網(wǎng)硬件由多個NXT和帶有藍牙通信模塊的PC機構(gòu)成,因此宏觀上系統(tǒng)的軟件可以看作主要由三個部分組成,如圖2所示。1ccpmnser維度位于中間控制臺上的通信服務(wù)器上承擔向NXT發(fā)送通信數(shù)據(jù)或從NXT接收通信數(shù)據(jù)的任務(wù),這些任務(wù)包括解析通信目標地址、通信數(shù)據(jù)緩存等。2ccommserper-ccummserpers新通信NXT與中控機的通信實際上由該類控制和實施,接收通信數(shù)據(jù)時,該類讀取CCommServer發(fā)送給本地NXT的數(shù)據(jù);發(fā)送通信數(shù)據(jù)時,該類將本地NXT發(fā)送的數(shù)據(jù)傳送給CCommServer。作為通信代理,CMsgProxy的實現(xiàn)調(diào)用了LeJOSNXJ的藍牙通信功能。3壓力和狀態(tài)信息封裝該模塊封裝了機器人之間通信的接口,該接口支持以面向?qū)ο笙⒌男问竭M行機器人之間的通信,即數(shù)據(jù)格式不是LeJOSNXJ規(guī)定的底層通信數(shù)據(jù)格式。為了封裝底層硬件相關(guān)信息和更好地處理多機器人之間系統(tǒng)動作,機器人所有行為和狀態(tài)信息均封裝在抽象類CRobot內(nèi)部成員對象中,任何機器人從軟件角度看都是CRobot派生類的對象實例,例如與通信相關(guān)模塊的CCommunicator、CMsgProxy均為CRobot內(nèi)部對象。本文聚焦于多機器人組網(wǎng)通信機制,僅重點介紹CMsgProxy和CCommServer,關(guān)于Java對象間消息機制請參見參考文獻,而CRobot的其他細節(jié)將另行撰文,在此不加贅述。2.2osi數(shù)據(jù)鏈路層和物理層雖然PBP2P的實現(xiàn)并不復(fù)雜,但是其功能也基本覆蓋了OSI模型七層中的表示、會話、傳輸、網(wǎng)絡(luò)等四層(圖3),而OSI數(shù)據(jù)鏈路層和物理層由LEGO藍牙通信模塊和leJOSNXJ提供。當然,為了提高效率,PBP2P實現(xiàn)中的軟件層次界限并不十分嚴格。2.2.1ccommserper控制CCommServer類是中控機上的獨立線程,作為Piconet主設(shè)備,提供3種功能:通信初始化與通信過程控制、消息發(fā)送與接收、通信設(shè)備管理與轉(zhuǎn)發(fā)控制,分別對應(yīng)于OSI的會話、傳輸、網(wǎng)絡(luò)等三層,為了實現(xiàn)上的方便和運行效率,CCommServer實現(xiàn)中沒有追求明確的劃分;關(guān)于另一重要模塊CMsgProxy,由于將來與應(yīng)用層程序有密切關(guān)系,因此在具體實現(xiàn)時層次和模塊劃分相對明確,各模塊與OSI對應(yīng)關(guān)系如圖3所示。2.2.2發(fā)送或發(fā)送其他機器人CMsgProxy類是CRobot的組成部分之一,每個機器人的NXT中均有其一個運行實例,這也是一個并行運行的線程,主要用來負責接收中控機轉(zhuǎn)發(fā)來的其他機器人發(fā)來的消息,同時負責將本機器人所要發(fā)往其他機器人的消息發(fā)送給中控機中的CCommServer,將接收到的消息調(diào)用CCommunicator中的函數(shù)voidDispatchMsgToUnit(CMsgPkgmsgp)分發(fā)到具體部件的消息隊列中(目前規(guī)定其他機器人不能與本機器人的部件之間直接消息聯(lián)系,外界的消息只能發(fā)給本機器人的執(zhí)行機構(gòu)CExecutive)。該函數(shù)在通信連接建立過程中的角色是扮演initiator,對于消息的發(fā)送和收取過程與CCommServer類似。2.2.3基于x-msg的對象消息支持消息封裝對應(yīng)于OSI的表示層,由CRobotMsg和CMsgPkg兩個類實現(xiàn),其中CRobotMsg定義了機器人系統(tǒng)的對象消息模式,即應(yīng)用層通信數(shù)據(jù)格式,而CMsgPkg提供了消息的會話層數(shù)據(jù)格式。2.2.4面向網(wǎng)絡(luò)的方案該部分對應(yīng)于OSI網(wǎng)絡(luò)層部分功能。CCommServer承擔的消息轉(zhuǎn)發(fā)需要根據(jù)所接收消息的目標地址,調(diào)用網(wǎng)絡(luò)路由功能并將消息發(fā)送給目標機器人。與復(fù)雜網(wǎng)絡(luò)不同,PBP2P網(wǎng)絡(luò)的路由功能十分簡單,各節(jié)點的路由信息以通信錄的形式加以維護,由類CAddrInfo和類CAddrList承擔,其中所含主要數(shù)據(jù)信息及功能如圖4所示。CAddrList除維護通信錄外,還提供各機器人及中控機上通信錄的同步等功能。由于有了通信錄,通信時可以直接