近年來，隨著國家科技的不斷發(fā)展，機器人也得到了突破性的發(fā)展。下面是小編為大家精心推薦的機器人科技論文3000字，希望能夠對您有所幫助。

　　機器人科技論文3000字篇一

　　《試論開放式機器人智體》

　　摘要：針對機器人功能的更新、修改、升級、維護等工作，普遍只能采用離線、靜態(tài)方式進行的問題，將“軟件人”引入機器人平臺中，搭建了以宿主“軟件人”為管理中心的機器人系統(tǒng)架構，并重點對宿主“軟件人”進行了研究。首先，構造了宿主“軟件人”的體系結構;然后，提出了宿主“軟件人”知識行為一體化描述模型，并對其知識模型進行了基于數(shù)據(jù)結構的構造和實現(xiàn)，對其主要服務類行為給出了相應的設計規(guī)范及算法的參考實現(xiàn);最后，句子不通順，前面說平臺，后面是系統(tǒng)，將平臺和系統(tǒng)合一嗎請核實描述，此句中的機器人平臺改為機器人系統(tǒng)。將引入宿主“軟件人”的機器人系統(tǒng)與網(wǎng)絡平臺中的“軟件人”系統(tǒng)進行合一，經(jīng)測試，機器人功能的在線、動態(tài)更替取得成功，什么意義，且此句過于抒情，摘要應簡潔明了將”引入宿主‘軟件人’的意義得以實現(xiàn)“這句去掉。同時也驗證了對宿主“軟件人”設計、實現(xiàn)方法的正確性和可行性。

　　關鍵詞：機器人;宿主“軟件人”; 知行模型;“軟件人”系統(tǒng);合一系統(tǒng)

　　0 引言

　　目前，機器人控制結構的開放化、模塊化[1]，機器人控制器的標準化、網(wǎng)絡化以及PC(Personal Computer)化已成為機器人領域的研究熱點。實際上，早在20世紀90年代初開始，美國三大汽車制造公司就已聯(lián)合發(fā)表了它們對未來開放式模塊化控制器的需求白皮書，提出了“開放式、模塊化體系結構控制器(Open Modular Architecture Controllers，OMAC)”的概念，并于1997年成立了OMAC用戶組織[2]。歐洲共同體的22家控制器開發(fā)商、機床生產(chǎn)商、控制系統(tǒng)集成商和科研機構于1990年聯(lián)合發(fā)起“自動化系統(tǒng)中開放式體系結構(Open System Architecture for Controls within Automation System，OSACA)的研究和開發(fā)”的倡議[3]。近二十幾年間，機器人系統(tǒng)的開放可重構研究更是受到了極大的重視。White等[4]從物理運動學理論的角度證明了任意尺寸自重構機器人的存在性，并于2005年設計了Molecubes模塊化機器人;Ferenc等[5]提出了一種實時的基于公共對象請求代理體系結構 (Common Object Request Broker Architecture，CORBA)協(xié)議的分布式機器人控制系統(tǒng);麻省理工學院(Massachusetts Institute of Technology， MIT)的Gilpin等[6]于2006年設計了Miche晶格式模塊化機器人，實現(xiàn)了機器人任意形狀的組建。國內(nèi)對機器人的研究起步相對較晚，但在開放可重構機器人研究方面也取得了一定的成果。劉明堯等[7]提出一種基于多智體(Agent)的機器人控制方法;張玉華等[8]提出了一種新型模塊化可重構機器人(Hit Modular Selfreconfigurable Robot，HitMSR)系統(tǒng)的硬件和軟件系統(tǒng)實現(xiàn)方案;謝峰等[9]以異構多Agent 系統(tǒng)(MultiAgent System， MAS)理論為基礎，提出了一種可在多個層次上動態(tài)重構的控制系統(tǒng)設計方案。

　　“軟件人”[10]是近年來在軟計算、智能化領域提出并發(fā)展較快的一個課題方向。它是將人工生命、人工社會研究方法與現(xiàn)有(多)智體(Agent)[11-12]的研究成果結合起來的、網(wǎng)絡世界中的虛擬機器人，是“智體(Agent)”和“對象”的升華，比通常的Agent更富有“人工生命”的特性和活性，具有感知、通信交互、任務分解、局部規(guī)劃、任務分配、學習、控制與決策、進化(自適應)等功能，其中學習與進化特征是其區(qū)別于Agent的關鍵所在[13]。作為人的“自然生命”在軟件世界里的模擬、延伸和擴展，“軟件人”能進入、遷移并駐留各種計算機信息網(wǎng)絡中，完成計算、通信等各種信息處理工作，因此“軟件人”屬于軟件范疇，它需與類人機器人(humanoid robot)有所區(qū)分。類人機器人是外觀和功能與人一樣的智能機器人，通常是由傳感器、微型處理器等組建搭建的機器人系統(tǒng)，它包含了硬件和軟件兩個范疇。 　　1.2.1 宿主“軟件人”知識模型實現(xiàn)研究

　　“軟件人”知識模型(SoftMan KnowLedgebase Model，SMKM)定義為一個三元組[14]：

　　SMKM=〈Data， Type， Relation〉。

　　1)Data為“軟件人”知識的數(shù)據(jù)部分，表述為一個三元組：Data=〈DataType， DataContent， DataLen〉其中： DataType表示數(shù)據(jù)類型，DataContent表示數(shù)據(jù)內(nèi)容，DataLen表示數(shù)據(jù)長度。

　　2)Type為本“軟件人”知識節(jié)點的邏輯類型，即資源類型知識節(jié)點或屬性類型知識節(jié)點。

　　3)Relation用于描述本知識節(jié)點與其子節(jié)點之間的模糊關聯(lián)，表示為：

　　Relation=∪〈SubSKMi， tValuei， fValuei〉;0≤i≤n其中：tvaluei表示第i個子知識節(jié)點相對于本節(jié)點的隸屬度， fvaluei表示第i個子知識節(jié)點相對于本節(jié)點的假隸屬度[14]。

　　“軟件人”知識模型SMKM主要是由以下4個數(shù)據(jù)結構來構造和實現(xiàn)的。

　　1)枚舉類型SMKMType表示“軟件人”知識Data部分的DataType，其成員包括：無數(shù)據(jù)類型smkm_no_type， 整數(shù)類型smkm_int_type， 浮點類型smkm_float_type，字符串類型smkm_str_type， 結構體類型smkm_struct_type， 鏈表類型smkm_list_type。

　　2)枚舉類型SMKMLogicType表示“軟件人”知識Type部分的邏輯類型，其成員包括：資源類型smkm_logic_res_type， 屬性類型smkm_logic_attr_type。

　　3)結構體smkmTerm表示“軟件人”知識的基本構造元素，其成員包括：smkmType表示“軟件人”知識Data部分的DataType，*p表示“軟件人”知識Data部分的DataContent，len表示“軟件人”知識Data部分的DataLen，logicType標明“軟件人”知識的邏輯類型Type，wMs和wUnMs表示本知識節(jié)點與其父節(jié)點的模糊關聯(lián) 。

　　4)結構體smkmStructType為軟件人”知識基本構造元素提供了一種靈活的組裝方式。

　　根據(jù)以上對“軟件人”知識模型與其數(shù)據(jù)結構的定義與說明，對圖3左邊宿主“軟件人”的知識庫Knowledge Base部分進行實現(xiàn)，其實現(xiàn)示意圖如圖4所示。行為集Behaviors的實現(xiàn)邏輯與此類似，不再詳細贅述。

　　圖4頂層方框表示要描述的是知識Data部分的DataType為結構體類型smkm_struct_type的知識節(jié)點“HostSoftMan”。第二層左分支方框描述的是“軟件人”名稱，名稱的數(shù)據(jù)類型為字符串類型smkm_str_type;LogicType=smkm_logic_res_type表明該“軟件人”知識的邏輯類型為資源類型;*p表示名稱的數(shù)據(jù)內(nèi)容為“HostSoftMan”;len=11表明名稱的數(shù)據(jù)長度為11個字符;wMs=1、wUnMs是否應為wUnMs，圖中表述為wUnMs將wUnM改為wUnMs=0表明與其父節(jié)點隸屬度為1、假隸屬度為0。第二層右分支方框枚舉了圖3宿主“軟件人”知識庫Knowledge Base的下層組成要素名稱及個數(shù)。由*p可看出組成知識庫要素的數(shù)據(jù)名稱分別為Node Data、Message Buffer、Host Abstract 和InitROT， 枚舉類型SMKMType的數(shù)據(jù)類型為字符串類型smkm_str_type;len=4表明組成要素數(shù)據(jù)個數(shù)為4;wMs=1、wUnMs=0表明與其父節(jié)點隸屬度為1、假隸屬度為0。對圖4中第三層與第四層的理解可分別參照對頂層和第二層的解釋，不再贅述。

　　1.2.2 宿主“軟件人”行為規(guī)范及算法實現(xiàn)

　　服務類行為集SrvBehs是與宿主“軟件人”的職能所對應的，因篇幅有限，本節(jié)選取其服務類行為集SrvBehs中典型的信道建立行為CreateChannelBeh和節(jié)點容錯行為FaultToleranceBeh進行相關設計規(guī)范及算法的參考實現(xiàn)。

　　1) 信道建立行為CreateChannelBeh。

　　“軟件人”之間通過消息傳遞進行交互[21]，因此，在機器人平臺中擔當守護、信息處理角色的宿主“軟件人”需先創(chuàng)建通信信道。在嵌入式Linux系統(tǒng)中，支持多種進程間通信(InterProcess Communication，IPC)，常用的IPC方式有：共享內(nèi)存、信號量、管道、消息隊列、socket等。本文選取socket作為進程間通信的方式，建立機器人平臺上的通信信道。信道建立后，宿主“軟件人”可為機器人端提供消息守護功能。節(jié)點內(nèi)部的附體“軟件人”能通過信道與宿主“軟件人”進行通信，同時，“軟件人”平臺上的消息節(jié)點也能通過連接該信道與機器人平臺上的“軟件人”進行通信。宿主“軟件人”消息守護流程如圖5所示。

　　2) 節(jié)點容錯行為FaultToleranceBeh。

　　容錯機制是系統(tǒng)可靠性的一種保證。宿主“軟件人”作為機器人系統(tǒng)的守衛(wèi)者和管理者，關鍵是要保障機器人節(jié)點的正常運行。因此，需討論宿主“軟件人”為使系統(tǒng)可靠運行而提供的容錯行為。對于宿主“軟件人”的容錯行為，首先需要能為異常結束的附體“軟件人”提供重新啟動的功能。宿主“軟件人”處理附體“軟件人”進程退出信號過程如圖6所示。

　　在宿主“軟件人”監(jiān)聽到附體“軟件人”退出時，通過查看“軟件人”狀態(tài)來判斷是否有異常。若已申請退出，則宿主“軟件人”釋放維護的相關信息;否則認為該“軟件人”進程為異常退出，重新啟動附體“軟件人”。當宿主“軟件人”接收到操作系統(tǒng)內(nèi)核傳來的信號時，附體“軟件人”進程已經(jīng)結束，且尚未處理的輸入消息也將丟失。若采用直接重新啟動從初始化狀態(tài)開始工作，雖然避免了附體“軟件人”異常退出，但并未能保證其對外服務的連續(xù)性。因此，為了避免附體“軟件人”服務的中斷，宿主“軟件人”采取了檢查點容錯機制。即宿主“軟件人”定期的保存運行期附體“軟件人”的相關信息(檢查點)，當附體“軟件人”因意外終止而重啟時，利用保存的信息初始化附體“軟件人”，使得“軟件人”能從檢查點繼續(xù)執(zhí)行，以此保持“軟件人”對外服務的持續(xù)性。