機器人作業系統

機器人作業系統

ROS(機器人作業系統,Robot Operating System),是專為機器人軟體開發所設計出來的一套電腦作業系統架構。它是一個開源的元級作業系統(後作業系統),提供類似於作業系統的服務,包括硬體抽象描述、底層驅動程式管理、共用功能的執行、程式間訊息傳遞、程式發行包管理,它也提供一些工具和庫用於獲取、建立、編寫和執行多機融合的程式。

基本信息

簡介

ROS的運行架構是一種使用ROS通信模組實現模組間P2P的松耦合的網路連線的處理架構,它執行若干種類型的通訊,包括:

基於服務的同步RPC(遠程過程調用)通訊;

基於Topic的異步數據流通訊,還有參數伺服器上的數據存儲。

1.

基於服務的同步RPC(遠程過程調用)通訊;

2.

基於Topic的異步數據流通訊,還有參數伺服器上的數據存儲。

產品功能

Turing OS是一款人工智慧級機器人作業系統,集成人機對話、視覺識別及運動控制等人工智慧核心技術,強技術、穩服務、周期短、成本低,幫合作夥伴更快開發出屬於自己的實體機器人與智慧型套用。

Turing OS具有的多模態互動能力,讓人機互動更流暢多元,能綜合處理文字、語音、視覺、觸覺等多維度信息,精確解析用戶意圖,做出擬人化回響。

Turing OS具有多種AI能力,包括身高檢測、人臉檢測、人臉識別、人臉跟蹤、聲音情緒識別、顏色識別、特徵識別和線上物體識別等,助力合作夥伴開發出更豐富、體驗更好的智慧型機器人。

基於Turing OS 1.5版本,開發了機器人套用服務,涵蓋遠程、遊戲、教育、工具、社交等諸多領域,當前套用總數達30餘種。

發展經歷

2015年11月6日,人工智慧創業團隊圖靈機器人對外發布了人工智慧機器人作業系統Turing OS。

2016年7月28日,在首屆圖靈機器人創新大會上再次推出人工智慧機器人作業系統Turing OS 1.5。

圖靈機器人CEO俞志晨宣布:為了支撐機器人套用創新,TuringOS已從原1.0版本升級至1.5版本,視覺能力、運動控制及硬體模組得到增強。

發展目標

ROS的首要設計目標是在機器人研發領域提高代碼復用率。ROS是一種分散式處理框架(又名Nodes)。這使執行檔能被單獨設計,並且在運行時鬆散耦合。這些過程可以封裝到數據包(Packages)和堆疊(Stacks)中,以便於共享和分發。ROS還支持代碼庫的聯合系統。使得協作亦能被分發。這種從檔案系統級別到社區一級的設計讓獨立地決定發展和實施工作成為可能。上述所有功能都能由ROS的基礎工具實現。

為了實現“共享與協作”這一首要目標,人們制訂了ROS架構中的其他支援性目標:

•“輕便”:ROS是設計得儘可能方便簡易。您不必替換主框架與系統,因為ROS編寫的代碼可以用於其他機器人軟體框架中。毫無疑問的,ROS更易於集成與其他機器人軟體框架。事實上ROS已完成與OpenRAVE、Orocos和Player的整合。

•ROS-agnostic庫:【agnostic:不可知論】建議的開發模型是使用clear的函式接口書寫ROS-agnostic庫。

•語言獨立性:ROS框架很容易在任何程式語言中執行。我們已經能在Python和C++中順利運行,同時添加有Lisp、Octave和Java語言庫。

•測試簡單:ROS有一個內建的單元/組合集測試框架,稱為“rostest”。這使得集成調試和分解調試很容易。

•擴展性:ROS適合於大型實時系統與大型的系統開發項目。

行業展望

隨著機器人產業鏈的深入發展,越來越多的科技巨頭認同“機器人產業發展將遵循PC發展軌跡”這一觀點,而在PC普及及標準化的過程中,體驗良好、操作簡單的作業系統的出現扮演了重要角色。

從該方面來看,TuringOS的發布對推動機器人產業發展及普及而言意義重大,或許,這只是圖靈機器人實現“智慧型機器人走進每個家庭”的第一步。

ROS

ROS 的 Filesystem Level

檔案系統層概念就是你在碟片裡面遇到的資源,例如:

•Packages:ROS的基本組織,可以包含任意格式檔案。一個Package 可以包含ROS執行時處理的檔案(nodes),一個ROS的依賴庫,一個數據集合,配置檔案或一些有用的檔案在一起。

•Manifests:Manifests (manifest.xml) 提供關於Package元數據,包括它的許可信息和Package之間依賴關係,以及語言特性信息像編譯旗幟(編譯最佳化參數)。

•Stacks: Stacks 是Packages的集合,它提供一個完整的功能,像“navigation stack” Stack與版本號關聯,同時也是如何發行ROS軟體方式的關鍵。

•Stack manifests :提供關於Stack元數據,包括它的許可信息和Stack之間依賴關係。

•Message (msg) types: 信息描述, 位置在路徑:my_package/msg/MyMessageType.msg, 定義數據類型在ROS的 messages ROS裡面。

•Service (srv) types: 服務描述,位置在路徑:my_package/srv/MyServiceType.srv, 定義這個請求和相應的數據結構 在ROS services 裡面。

ROS 的 Computation Graph Level

Computation Graph Level(計算圖)就是用ROS的P2P(peer-to-peer網路傳輸協定)網路集中處理所有的數據。基本的Computation Graph的概念包括Node, Master, Parameter Server,messages, services, topics, 和bags, 以上所有的這些都以不同的方式給Graph傳輸數據。

Nodes: Nodes(節點)是一系列運行中的程式。ROS被設計成在一定顆粒度下的模組化系統。一個機器人控制系統通常包含許多Nodes。比如一個Node控制雷射雷達,一個Node控制車輪馬達,一個Node處理定位,一個Node執行路徑規劃,另外一個提供圖形化界面等等。一個ROS節點是由Libraries ROS client library寫成的, 例如 roscpp和rospy。

Master: ROS Master 提供了登記列表和對其他計算圖的查找。沒有Master,節點將無法找到其他節點,交換訊息或調用服務。

Server Parameter Server: 參數伺服器使數據按照鑰匙的方式存儲。參數伺服器是主持的組成部分。

Messages:節點之間通過messages來傳遞訊息。一個message是一個簡單的數據結構,包含一些歸類定義的區。支持標準的原始數據類型(整數、浮點數、布爾數,等)和原始數組類型。message可以包含任意的嵌套結構和數組(很類似於C語言的結構structs)

Topics: Messages以一種發布/訂閱的方式傳遞。一個node可以在一個給定的topic中發布訊息。Topic是一個name被用於描述訊息內容。一個node針對某個topic關注與訂閱特定類型的數據。可能同時有多個node發布或者訂閱同一個topic的訊息;也可能有一個node同時發布或訂閱多個topic。總體上,發布者和訂閱者不了解彼此的存在。主要的概念在於將信息的發布者和需求者解耦、分離。邏輯上,topic可以看作是一個嚴格規範化的訊息bus。每個bus有一個名字,每個node都可以連線到bus傳送和接受符合標準類型的訊息。

Services:發布/訂閱模型是很靈活的通訊模式,但是多對多,單向傳輸對於分散式系統中經常需要的“請求/回應”式的互動來說並不合適。因此,“請求/回應” 是通過services來實現的。這種通訊的定義是一種成對的訊息:一個用於請求,一個用於回應。假設一個節點提供了一個服務提供下一個name和客戶使用服務傳送請求訊息並等待答覆。ROS的客戶庫通常以一種遠程調用的方式提供這樣的互動。

Bags: Bags是一種格式,用於存儲和播放ROS訊息。對於儲存數據來說Bags是一種很重要的機制。例如感測器數據很難收集但卻是開發與測試中必須的。

在ROS的計算圖中,ROS的Master以一個name service的方式工作。它給ROS的節點存儲了topics和service的註冊信息。Nodes 與Master通信從而報告它們的註冊信息。當這些節點與master通信的時候,它們可以接收關於其他以註冊節點的信息並且建立與其它以註冊節點之間的聯繫。當這些註冊信息改變時Master也會回饋這些節點,同時允許節點動態創建與新節點之間的連線。

節點之間的連線是直接的; Master僅僅提供了查詢信息,就像一個DNS伺服器。節點訂閱一個topic將會要求建立一個與發布該topics的節點的連線,並且將會在同意連線協定的基礎上建立該連線。ROS裡面使用最廣的連線協定是TCPROS,這個協定使用標準的TCP/IP 接口。

這樣的架構允許解耦操作(decoupled operation),通過這種方式大型或是更為複雜的系統得以建立,其中names方式是一種行之有效的手段。names方式在ROS系統中扮演極為重要的角色: topics, services, and parameters 都有各自的names。每一個ROS客戶端庫都支持重命名,這等同於,每一個編譯成功的程式能夠以另一種形似【名字】運行。

例如,為了控制一個北陽雷射測距儀(Hokuyo laser range-finder),我們可以啟動這個hokuyo_node 驅動,這個驅動可以給與雷射儀進行對話並且在"掃描"topic下可以發布sensor_msgs/LaserScan 的信息。為了處理數據,我們也許會寫一個使用laser_filters的node來訂閱"掃描"topic的信息。訂閱之後,我們的過濾器將會自動開始接收雷射儀的信息。 注意兩邊是如何脫鉤工作的。 所有的hokuyo_node的節點都會完成發布"掃描",不需要知道是否有節點被訂閱了。所有的過濾器都會完成"掃描"的訂閱,不論知道還是不知道是否有節點在發布"掃描"。 在不引發任何錯誤的情況下,這兩個nodes可以任何的順序啟動,終止,或者重啟。

以後我們也許會給我們的機器人加入另外一個雷射器,這會導致我們重新設定我們的系統。我們所需要做的就是重新映射已經使用過的names。當我們開始我們的第一個hokuyo_node時,我們可以說它用base_scan代替了映射掃描,並且和我們的過濾器節點做相同的事。這些節點將會用base_scan的topic來通信從而代替,並且將不再監聽"掃描"topic的信息。然後我們就可以為我們的新雷射測距儀啟動另外一個hokuyo_node。

相關詞條

相關搜尋

熱門詞條

聯絡我們