編輯中未完成，先不要轉(zhuǎn)載……

工業(yè)機器人控制器調(diào)研

初稿完成于 2019-6-8 胡 robinvista2@gmail.com 　　

　　如同大腦之于人一樣，控制器也是機器人最重要的元部件，它定義了機器人的功能和行為。很多學(xué)者都對其進行了研究或給出了設(shè)計方案${}^{[1,2,3]}$，但是針對控制器總體架構(gòu)和具體實現(xiàn)的討論較少，而且與工業(yè)生產(chǎn)一線嚴重脫節(jié)，早已過時。本文比較了機械臂和移動機器人兩種工業(yè)機器人的控制器方案，對其功能需求和特點進行了分析，并探討開放式控制器的實現(xiàn)方案。

　 　　機械臂控制器　　　　　　　　　　　　　　　　　　　 　移動機器人控制器 　　以上分類的依據(jù)是機器人類型。目前市面上更多的控制器產(chǎn)品是通用型運動控制器或運動控制卡，即控制各種非標設(shè)備運動的，例如數(shù)控機床、激光切割機等自動化設(shè)備。當然這些產(chǎn)品也可以通過二次開發(fā)用于控制機器人。 通用運動控制器產(chǎn)品

1　軟硬件方案

　　我們首先考察常見工業(yè)機器人控制器的軟硬件方案。

1.1　機械臂

??機械臂控制器的發(fā)展較早，產(chǎn)品相對成熟，其實現(xiàn)方案見下表。國際一線品牌大多采用X86芯片，并采用實時操作系統(tǒng)構(gòu)造底層軟件。

廠家硬件操作系統(tǒng)

ABB	x86	VxWorks
KUKA	x86	VxWorks+Windows（VxWin）
KEBA	x86	VxWorks
B&R	x86	Windows 10/B&R Linux 9
固高	x86	Windows CE
MUJIN	x86	–
納博特	x86	VxWorks 或 Linux（PREEMPT_RT）或 SylixOS

1.2　移動機器人

　　移動機器人的控制器屬于較新的方向，AGV、無人機、工程機械等都可歸于此類，最近比較火的無人駕駛也可以認為是一種移動機器人，其控制系統(tǒng)底層方案見下表。

廠家硬件操作系統(tǒng)軟件外部接口

Hesmor	Infineon XC167	無	CoDeSys	CAN
Hirschmann	PowerPC	無	CoDeSys	CAN
EPEC	Infineon C166	無	CoDeSys	CAN
NDC	ARM Cortex-A8	Linux	–	內(nèi)置陀螺儀、CAN、WLAN、485
IFM	Infineon TriCore 1796	無	CoDeSys	CAN

1.3　對比

　　機械臂的功能要求多，自由度多，而且對運動精度和響應(yīng)速度的要求較高，比移動機器人一般要高1到2個數(shù)量級，因此控制器的計算量大、周期短；移動機器人一般對響應(yīng)速度要求不高，功能相對簡單，其配置相對較低，而且移動機器人通常采用電池供電，控制器內(nèi)置，因此對功耗和散熱有要求，其控制器多采用嵌入式芯片。
　　機械臂一般工作于固定的區(qū)域，其控制器通常放置于機箱內(nèi)，因此防護等級不高，一般是IP20；移動機器人由于需要經(jīng)常運動，尤其是室外工程機械，要考慮防水防塵，其防護等級較高，一般是IP65。

機械臂移動機器人

控制精度	0.01~0.5mm	1~20mm
控制周期	100us~10ms	10ms~100ms
插補	需要	不需要
軌跡規(guī)劃	需要	不需要
邏輯控制	需要	需要

2　商業(yè)控制器

　　介紹幾種有代表性的商業(yè)控制器方案。

2.1　CoDeSys

　　很多機器人控制軟件都是借助CoDeSys實現(xiàn)的，那么CoDeSys是什么呢？
　　CoDeSys是德國3S公司推出的一款付費的軟PLC開發(fā)軟件，簡單來說，它包括兩部分：Development System和Runtime System。Development System就是用來編程的軟件界面（就像Visual Studio、Eclipse等軟件，也可以稱為IDE），設(shè)計、調(diào)試、編譯PLC程序都在IDE中進行，這部分是用戶經(jīng)常打交道的；程序?qū)懞昧艘院?#xff0c;就要把它轉(zhuǎn)移到硬件設(shè)備中執(zhí)行。可是這時生成的PLC程序自己是無法運行的，它還要在一定的軟件環(huán)境中才能工作，這個環(huán)境就是Runtime System（也叫運行核），這部分是用戶看不到的。二者安裝的位置通常不同，IDE一般安裝在用戶的開發(fā)計算機上，Runtime System則位于起控制作用的硬件設(shè)備上，程序通過網(wǎng)線或串口線下載到Runtime中運行。
　　CoDeSys為什么要分成兩部分？最主要的原因是CoDeSys主要運行在嵌入式系統(tǒng)中，例如ARM或者DSP芯片。這樣的系統(tǒng)資源有限，不可能在其上建立龐大、復(fù)雜的開發(fā)環(huán)境，因而其開發(fā)環(huán)境和運行環(huán)境相互分離。因此，嵌入式軟件的開發(fā)方式一般是，在宿主機（Host）上建立開發(fā)環(huán)境，進行應(yīng)用程序代碼的編寫和交叉編譯，然后宿主機與目標機（Target）建立連接，將應(yīng)用程序下載到目標機上進行交叉調(diào)試，經(jīng)過調(diào)試和優(yōu)化，最后將應(yīng)用程序固化到目標機中實際運行。當然，隨著芯片的性能越來越強大，如果選擇資源豐富的芯片，那么CoDeSys的開發(fā)環(huán)境和運行環(huán)境放在一起也沒什么問題。我們自己的個人電腦不就是編譯和運行程序都能完成嗎。

　　CoDeSys在工業(yè)控制領(lǐng)域的應(yīng)用非常廣泛，上面提到的很多機器人公司都使用了它的產(chǎn)品，例如KEBA、倍福、固高、臺達、廣州啟帆機器人、新時達機器人。3S公司只賣底層軟件，不賣硬件和上層應(yīng)用程序，應(yīng)用程序和硬件電路需要由用戶自己設(shè)計，3S公司負責將Runtime System移植到客戶的硬件上。Runtime System可以裸跑在硬件上，但一般是運行在操作系統(tǒng)上，配置操作系統(tǒng)也是客戶的工作。如果客戶要求，CoDeSys的IDE可以定制，換成客戶的logo和外觀，這就是為什么你會發(fā)現(xiàn)不同廠家的開發(fā)平臺長得不一樣，但風格又比較相似。當然，用戶也可以使用其它IDE，例如倍福就使用了Visual Studio，而背后的編譯器等內(nèi)核功能以及函數(shù)庫仍然采用CoDeSys的方案。CoDeSys的Runtime具有強大的適應(yīng)性，支持絕大多數(shù)的操作系統(tǒng)和芯片類型。

　　CoDeSys的IDE部分是免費的，你可以從官網(wǎng)下載體驗。真正收費的是運行系統(tǒng)Runtime System以及一系列的通信、運動控制組件。

　　CoDeSys采用.Net技術(shù)開發(fā)，其在設(shè)計之初就將功能劃分為若干組件模塊，例如總線協(xié)議棧、可視化界面、運動控制、安全控制等等，用戶可以像搭積木一樣選購必需的模塊搭建自己的系統(tǒng)，最后形成一個定制化的控制軟件平臺。一些初次接觸軟PLC的用戶可能對這部分感到陌生，但其實這種設(shè)計方式非常普遍。舉幾個例子，MATLAB Simulink的實時工具箱（Real-Time）就是這樣的工作方式，用戶在Simulink的圖形界面里通過拖拽設(shè)計控制程序，然后下載到真實的硬件中跑，可以在這里了解。還有像倍福也是這樣的使用方式，用戶在TwinCAT IDE里進行編程，然后下載到倍福的控制器中，控制器里面其實已經(jīng)預(yù)裝了一個Runtime。西門子的STEP7也是一款I(lǐng)DE，它的PLC中也存在一個配套的Runtime。只不過西門子（包括日系PLC）的系統(tǒng)封閉而保密，外人不知道他的系統(tǒng)架構(gòu)。
　　用戶編寫的PLC程序就像我們電腦里的應(yīng)用程序，它運行在Runtime System上，而Runtime System又運行在操作系統(tǒng)之上。由于Runtime System位于應(yīng)用程序和操作系統(tǒng)中間，所以又被稱為中間件（Middleware）。簡單來說，你可以把中間件看成是由驅(qū)動程序、基本的函數(shù)庫等等模塊組成的軟件系統(tǒng)。因為這些程序模塊主要與硬件或者底層軟件打交道，與用戶關(guān)系不大，所以被組織成了單獨的一塊。這些軟件呈現(xiàn)給用戶的是函數(shù)調(diào)用接口，也就是說你只需要會使用就行了，不用操心具體怎么實現(xiàn)，因為這些是驅(qū)動工程師和算法工程師的活兒。當然，大多數(shù)時候你也看不到這部分的具體實現(xiàn)，因為它們是以編譯后的二進制文件的形式提供給你的，根本無法閱讀，你頂多能看到一些頭文件，其中只是一些函數(shù)和變量定義，沒有什么干貨。在機器人軟件里面，處于同樣地位的還有ROS、OROCOS等。
　　機器人的控制，像數(shù)控機床一樣，對實時性有要求，因此我們選擇的操作系統(tǒng)最好是實時操作系統(tǒng)（RTOS）。遺憾的是，我們經(jīng)常用的操作系統(tǒng)都不是實時的，例如Windows和Linux。實時操作系統(tǒng)有兩種實現(xiàn)方式：
　　1. 放棄通用的操作系統(tǒng)，從底層重新開始設(shè)計，代表性的有VxWorks、QNX、WinCE、μC/OS、LynxOS等；這種方式的缺點是所有的任務(wù)都是實時的，即使任務(wù)本身沒有實時的必要，例如網(wǎng)絡(luò)訪問、文件系統(tǒng)訪問，因此你得專門開發(fā)適用于這種操作系統(tǒng)的應(yīng)用程序，工作量可能比較大。VxWorks在軍事和工業(yè)應(yīng)用較多，例如被應(yīng)用于戰(zhàn)斗機和火箭上。VxWorks留下了一個空白，這就是車載領(lǐng)域，現(xiàn)在這個市場被QNX占據(jù)了。
　　2. 通過對通用的操作系統(tǒng)打補丁（添加擴展），使其具備實時性，代表性的有Windows RTX、Xenomai、RT Linux、RTAI，這種方式的缺點是，對實時任務(wù)的支持（資源）沒有第一種方式多；
　　考慮到Windows和Linux這兩款操作系統(tǒng)的用戶較多，CoDeSys推出了相應(yīng)的實時補丁（RTE），為用戶免去了改造的煩惱。想了解更多的CoDeSys Runtime信息可以閱讀官方的文檔$[1][2]$。
　　CoDeSys runtime如果不安裝在操作系統(tǒng)之上，則需要其自己備有簡單的調(diào)度程序。CoDeSys自帶的調(diào)度程序比較簡單，有兩種${}^{[5]}$：
　　1　Embedded Scheduler 這種是簡單的輪詢，一個任務(wù)結(jié)束前另一個任務(wù)不能運行，任務(wù)之間不能搶占，實際上這種方式并不是實時的；
　　2　Timer Scheduler 為每個任務(wù)分配一個定時器，定時觸發(fā)；
　　CoDeSys給機器人廠家開發(fā)控制器帶來了便利，但是依靠CoDeSys這類商業(yè)軟件打造自己的控制器產(chǎn)品也存在不少的缺點：
　　1　底層算法不公開
　　CoDeSys集成的運動控制組件、總線協(xié)議棧都是封裝好的，用戶無法了解其內(nèi)部細節(jié)，也無法針對自己的具體需求進行定制優(yōu)化，只能簡單地調(diào)用。用戶只能依附于CoDeSys平臺，難以形成自己的技術(shù)。
　　2　功能有限，難以擴展
　　現(xiàn)在以機器視覺、人工智能、自動駕駛等為代表的新技術(shù)突飛猛進，而工業(yè)控制上的很多技術(shù)仍然停留在20年前。以移動機器人中的導(dǎo)航場景為例，基于視覺或者激光的導(dǎo)航方法需要采集大量的數(shù)據(jù)并對其進行處理，其中涉及相當多的矩陣計算。而現(xiàn)在PLC只能進行落后的一維數(shù)字計算，難以實現(xiàn)復(fù)雜的算法。與人工智能圈子喜歡開源的風格正好相反，工業(yè)控制圈子相互封閉，誰都不肯開放自家的函數(shù)庫，開源函數(shù)庫很少，就連最基本的濾波算法、矩陣計算都要自己從頭開始寫。而且，國際標準IEC提供的標準函數(shù)太過有限，完全無法適應(yīng)新的場景，急需擴展。
　　3 成本高、難以更新
　　商業(yè)軟PLC成本動不動幾十萬，這還不包括各種總線通信庫、運動控制庫、可視化庫，這些仍需單獨購買，而且需要從售出產(chǎn)品上提成，對于小團隊來說成本難以接受。由于完全依賴CoDeSys，客戶自己產(chǎn)品硬件的升級換代需要重新定制移植，導(dǎo)致成本增加。這讓筆者想起來曾經(jīng)微軟給手機打造的操作系統(tǒng)Windows Phone，微軟在移動端是如何一步步作死的呢？其中關(guān)鍵的一條就是向手機廠商收取高額的授權(quán)費，可能微軟當大爺當慣了，而且更不要臉的是給用戶設(shè)置障礙，同一款手機系統(tǒng)不能連續(xù)升級。

　　GEB Automation也推出了與CoDeSys類似的軟PLC，支持編程、調(diào)試、仿真，面向OEM的產(chǎn)品售價9500美元，比CoDeSys好的是一次性付費不再收取單機提成，可以移植到常用的硬件平臺，其IDE基于Eclipse開發(fā)。

2.2　菲尼克斯PLCnext

　　2019年菲尼克斯高調(diào)推出了新一代PLC，被稱為PLCnext技術(shù)。PLCnext采用通用的軟硬件，例如ARM處理器和RTLinux操作系統(tǒng)，因此其也可視為一個軟PLC安裝于標準硬件平臺之上，而PLCnext在中間層仍然采用了KW的軟運行核。由于PLCnext的底層操作系統(tǒng)是Linux，用戶可以自己在PLCnext上安裝ROS系統(tǒng)以使用其中的機器人算法，目前支持最新的melodic版本。PLCnext還支持C/C++、IEC 61131-3標準PLC語言、Matlab等編程語言，為不同用戶開發(fā)項目提供了便利。PLCnext底層是一個實時操作系統(tǒng)RTLinux，其上允許客戶運行自己的非實時應(yīng)用程序，并且提供非實時應(yīng)用程序于PLC實時程序的數(shù)據(jù)訪問接口。開放式PLC是未來的潮流，可以看到PLCnext符合這一趨勢，反之如果你用西門子的PLC，想做一點擴展是連門都沒有滴。

　　菲尼克斯PLCnext的核心技術(shù)體現(xiàn)在兩個方面：任務(wù)執(zhí)行管理器（ESM）和全局數(shù)據(jù)管理器（GDS）。菲尼克斯為ESM和GDS申請了專利。
　　任務(wù)執(zhí)行管理器確保不同優(yōu)先級的任務(wù)按照正確的優(yōu)先級和時序運行，并保證低優(yōu)先級的任務(wù)被搶占時數(shù)據(jù)的一致性。下圖是一個簡單的例子，其中有兩個任務(wù)（上面一行是任務(wù)1，下面一行是任務(wù)2），任務(wù)1每5ms運行一次，它的優(yōu)先級比任務(wù)2高，所以在任務(wù)2運行過程中會被任務(wù)1搶占。

　　全局數(shù)據(jù)管理器負責任務(wù)間的通信，也就是交互數(shù)據(jù)。除了任務(wù)之間，每個任務(wù)內(nèi)部可能有不同語言編寫的函數(shù)模塊，它們之間也需要交互數(shù)據(jù)。全局數(shù)據(jù)管理保證所有的數(shù)據(jù)在交換過程中的一致性。同樣是上面的例子，任務(wù)2從被搶占恢復(fù)后，數(shù)據(jù)應(yīng)該與被搶占前是一樣的（即綠色箭頭所示的變量5和8），如果不一樣就會出現(xiàn)所謂的“數(shù)據(jù)不一致”現(xiàn)象，對于實時系統(tǒng)這一般是不允許的。全局數(shù)據(jù)管理器的作用就是負責數(shù)據(jù)交換的一致性。

2.3　KEBA

　　KEBA是一家奧地利機器人控制器制造商，其編程和控制軟件全部建立在CoDeSys軟PLC之上，CoDeSys為KEBA提供了基本的編輯、編譯、調(diào)試等功能。CoDeSys本身與機器人相關(guān)的功能很少，因此機器人涉及的功能和函數(shù)是由KEBA開發(fā)的，以庫的形式在CoDeSys中調(diào)用。為了保證實時性，控制器里的CoDeSys Runtime安裝在了VxWorks之上。

2.4　KUKA

　　KUKA的新一代控制器稱為KR C4，其同樣采用了軟PLC的方案。該方案由KW公司提供${}^{[4]}$，軟PLC由IDE部分（被稱為Multiprog）和Runtime（被稱為ProConOS）組成。ProConOS由C#開發(fā)。ProConOS Runtime同樣運行在VxWorks之上，它們安裝在控制器硬件中，其硬件采用了Intel雙核CPU。

　　

2.5　歐姆龍

　　歐姆龍(OMRON)推出了“機器人集成控制器”——NJ501-R，將PLC，運動和機器人控制集成在單個控制器中。PLC和機器人的編程語言統(tǒng)一在通用的IEC語言中，這使通常管理PLC的工程師也可以管理機器人。PLC與NC程序在同一個機器上執(zhí)行，能讓多個任務(wù)同步。

2.6　百度自動駕駛計算平臺

　　百度的Apollo無人車項目推出了無人車自動駕駛專用計算平臺——ACU (Apollo Computing Unit)。在網(wǎng)絡(luò)直播《百度ACU軟硬件結(jié)合優(yōu)化的實踐經(jīng)驗分享》中介紹了ACU的原理和實現(xiàn)。ACU采用了賽靈思的ZU5芯片，這是一個異構(gòu)多核SoC處理器，上面集成了CPU（ARM V8核）、FPGA、DDR內(nèi)存（2GB）、還有一個很小的GPU。

　　研發(fā)工程師認為算力并不與幀率嚴格成正比，例如常用芯片的算力是TFLOPS級別的，而內(nèi)存帶寬是GFLOPS級別的，也就是說算力是內(nèi)存讀取速度的1000倍，此時單純增加算力已經(jīng)不能提高計算速度，因為內(nèi)存是這時的瓶頸。 　　為什么采用這種芯片是和自動駕駛中執(zhí)行的具體計算任務(wù)有關(guān)的。自動駕駛中包含多種計算任務(wù)，其中最主要的就是人工智能算法，也就是深度學(xué)習。深度學(xué)習需要的計算量是其它任務(wù)的10倍以上，所以必須有強大的計算硬件支持。FPGA是算力最強大的可以執(zhí)行計算密集型任務(wù)，非常適合深度學(xué)習這樣的任務(wù)。雖然深度學(xué)習的計算量占總體任務(wù)的絕大多數(shù)，但是自動駕駛中還有大量的其它任務(wù)，例如圖像處理、SLAM，它們的計算量不大但是計算時間并不可忽略，這時需要由CPU完成。百度針對深度學(xué)習的底層計算進行了很多優(yōu)化，例如采用8bit INT型數(shù)據(jù)類型減少計算量（同時不降低準確度），把常用的“多個算子組合”融合成一個，用Average pooling替代Max pooling，采用共享內(nèi)存實現(xiàn)零拷貝。

3　開源控制軟件

　　目前存在一些開源的控制系統(tǒng)方案，例如ROS、Orocos、OpenRTM、Beremiz、OpenPLC、XBotCore、ArmarX、ORCA、AMiRo-OS。
　　PLCopen定義了伺服和運動控制的一些標準，包括編程語言、運動控制基礎(chǔ)函數(shù)塊（Function Block）、輸入輸出接口的參數(shù)等${}^{[3]}$，但是并沒有給出具體的實現(xiàn)代碼細節(jié)，這個是由各個廠家提供的。

3.1　ROS

　　ROS的前身最早可以追溯到2007年斯坦福大學(xué)的博士生Eric Berger和Keenan Wyrobek的工作，主要開發(fā)語言是C++。雖然ROS的名字聽起來是一個機器人操作系統(tǒng)，但其實它不是。ROS是一個中間件，它安裝在真正的計算機操作系統(tǒng)之上。剛開始，ROS有點像一個大雜燴，包括一些通信用的組件、可視化和仿真組件、坐標系管理組件。很多人將ROS描述為軟件框架，但筆者盡量避免使用這些抽象而又嚇人的名詞，因為大多數(shù)人并不熟悉機器人軟件系統(tǒng)，它容易讓本來就稀里糊涂的讀者更摸不著頭腦。
　　ROS提供的功能有：
　　1　節(jié)點定義和節(jié)點間的通信方式：節(jié)點是一個應(yīng)用程序模板，用戶將自己的算法代碼添加進去，剩下的交給ROS
　　2　基本工具：機器人常用的函數(shù)庫（運動規(guī)劃、SLAM、逆運動學(xué)）、可視化工具、數(shù)據(jù)記錄等機器人開發(fā)常用的功能
　　3　設(shè)備驅(qū)動：用戶拿到硬件不再需要從零開發(fā)，節(jié)省時間
　　ROS在工業(yè)界用的并不多，這一點也不奇怪，因為它在設(shè)計之初考慮更多的是通用性和代碼重用能力，不太關(guān)心可靠性、實時性等。最開始百度公司在其無人駕駛車輛上使用了ROS作為平臺，當時的考慮可能是快速完成無人駕駛算法的驗證。隨后，意識到ROS自身的一些問題，百度無人車團隊嘗試對其進行改造。但是，他們最終放棄了轉(zhuǎn)而選擇重新搭建一套軟件——Apollo Cyber RT。
　　ROS變得像今天這么火完全出乎設(shè)計者的意料，他們并沒想到ROS會被用在各種各樣的機器人上。中國也有一些人計劃設(shè)計自己的機器人軟件系統(tǒng)，例如上海交通大學(xué)中國科學(xué)院的micROS。

3.2　Orocos

　　Orocos是一個開源的機器人控制程序開發(fā)軟件，由比利時魯汶大學(xué)的Herman Bruyninckx及其博士生Peter Soetens開發(fā)，編程語言為C++。 Orocos的介紹文檔偏軟件開發(fā)，非程序員不容易讀懂。
　　Orocos的地位與ROS有些類似，但定位于控制，其位于實時操作系統(tǒng)之上，提供的基本功能包括：生成實時控制程序的工具鏈（編譯器），組件模板、機器人常用基本函數(shù)。Orocos替用戶解決了模塊功能和接口定義、模塊間實時通信這些基本功能，借助這些軟件模塊，用戶可以更快速的開發(fā)部署自己的應(yīng)用軟件。Orocos既關(guān)注上層應(yīng)用層，也關(guān)注底層控制層。與ROS相比，Orocos在設(shè)計之初就考慮了實時性。在Peter Soetens的博士論文${}^{[4]}$里，對于實時性的討論占了很大篇幅。Orocos直接使用了底層操作系統(tǒng)（例如Xenomai）的任務(wù)調(diào)度模塊，因此Orocos必須安裝在實時操作系統(tǒng)上才能保證實時性。

3.3　Beremiz

　　Beremiz是一個免費、開源的軟PLC控制系統(tǒng)，由法國人Edouard Tisserant開發(fā)${}^{[4]}$，主要開發(fā)語言是Python。出于對傳統(tǒng)PLC壁壘森嚴的不滿，Tisserant倡導(dǎo)了開源項目Beremiz，他也是CANfestival的作者。

　　Beremiz項目始于2005年，雛形只是一個編輯器，隨后其它功能逐漸加入從而形成了一個完整的軟PLC開發(fā)環(huán)境，其功能特點如下：
　　1　支持多任務(wù)，多任務(wù)可配置不同的優(yōu)先級，任務(wù)運行方式可以是周期式或中斷觸發(fā)式
　　2　支持ST、梯形圖等五種標準PLC編程語言
　　3　提供IEC 61131-3標準規(guī)定的基本函數(shù)（定時器、比較、數(shù)學(xué)運算、類型轉(zhuǎn)換、位操作、字符串等上百個函數(shù)）
　　4　可擴展Modbus、CANopen、EtherCAT總線通訊模塊（需自己移植到所選平臺）
　　5　支持C和Python語言，用戶可以在PLC中調(diào)用C程序或者調(diào)用Python程序，也可以在Python中調(diào)用C程序
　　6　支持仿真，但是不支持在線調(diào)試
　　7　具有可視化界面（HMI），變量值可直觀顯示為圖表
　　Beremiz的工作方式為：用戶使用PLC語言編寫應(yīng)用程序，不管用戶采用ST語言還是梯形圖或者其它PLC語言，Beremiz都將其翻譯成C語言，這是由MatIEC組件完成的。隨后，gcc編譯器將生成的C語言程序與總線通信程序一起編譯鏈接得到二進制目標文件（Linux下是so文件，Windows下則是dll文件）。再之后，二進制目標文件被下載到目標設(shè)備上，目標設(shè)備上預(yù)先安裝了runtime，runtime對目標文件進行調(diào)用完成相應(yīng)的控制功能${}^{[6,7,8,9]}$。

　　Beremiz的IDE和runtime兩個部分的開發(fā)語言都是Python。只要可以運行Python的操作系都可以運行Beremiz，即其可在Windows、Linux、Mac OS等多種操作系統(tǒng)上運行，當然前提必須得有操作系統(tǒng)。Beremiz的任務(wù)調(diào)度完全依賴于操作系統(tǒng)，這意味著它的實時性受到操作系統(tǒng)的影響很大，因此最好選擇實時操作系統(tǒng)，例如Xenomai、WinCE。
　　Beremiz衍生出了一些軟件控制方案，例如OpenPLC、KOSMOS，在這些衍生物里更多的功能插件被加了進來，例如運動控制函數(shù)、總線通信函數(shù)、配置插件。
　　選擇Python進行開發(fā)是因為這種語言簡單易用，但是Python在工業(yè)控制領(lǐng)域很少使用，因為它無法提供實時性（受內(nèi)存分配等因素影響）。即便如此，$[10]$對Beremiz runtime的實時性進行了分析，并與CoDeSys runtime做了對比，結(jié)果表明Beremiz的實時性反而還優(yōu)于CoDeSys。這可能是由于核心程序被翻譯成C代碼的原因，Python編寫的runtime只是負責調(diào)用。這篇文章比較了C和用Python調(diào)用C的性能，性能差距并不是特別懸殊。
　　Beremiz的介紹資料很少，并且其中一部分還是由俄文和法文撰寫的，缺少深入探討內(nèi)部原理的文獻。

3.4　OpenPLC

　　OpenPLC是一個免費開源的軟PLC軟件系統(tǒng)，它由Beremiz項目衍生而來，由美國阿拉巴馬大學(xué)博士生Thiago Rodrigues Alves開發(fā)${}^{[13]}$。

3.5　對比

　　大多數(shù)軟件將任務(wù)的調(diào)度交給操作系統(tǒng)，這就帶來一個問題：對于通用的操作系統(tǒng)的來說，每個進程基本是相互獨立的，而對于機器人應(yīng)用，任務(wù)間通常是相互依賴的，這就造成了操作系統(tǒng)的調(diào)度程序無法用于任務(wù)有依賴的任務(wù)調(diào)度。

4　控制器的開發(fā)

　　機器人控制器開發(fā)涉及的專業(yè)眾多，需要一個團隊完成。精通控制算法的機器人專業(yè)的博士對于軟件開發(fā)可能也一竅不通，看到進程、任務(wù)調(diào)度、mutex這些計算機名詞頭大；訓(xùn)練有素的軟件工程師對于齊次變換矩陣、旋量這些概念則是一頭霧水；除此以外，項目還需要驅(qū)動工程師、硬件工程師，還要有工程師懂總線通信、熟悉工藝。如果想找業(yè)務(wù)能力扎實的員工，就要承擔高昂的成本，沒有誘惑力的工資是很難留住這些專業(yè)人士的。更何況中國的機器人教育其實還是相當落后的，能找到專業(yè)能力扎實的員工并不容易。筆者撰寫本文的初衷也是為了向各方普及基礎(chǔ)知識，鏟平知識不對稱的大山。
　　由于開發(fā)機器人控制器成本高而且困難，大部分的廠家會選擇在別人的基礎(chǔ)上開發(fā)。

4.1　控制器方案的選擇

　　單處理器還是多處理器？
　　早期CPU的計算能力較弱，為了提高運行速度，不得不采用多CPU方案，一些計算量大的任務(wù)被剝離出來獨占一個CPU。比較有代表性的就是各種控制板卡的方案，例如PMAC、固高。固高的GUC-ECAT控制器單獨設(shè)計了一個DSP和一個FPGA來執(zhí)行插補、軌跡規(guī)劃等任務(wù)，另一個CPU一般執(zhí)行非實時的人機交互，編程開發(fā)等任務(wù)。如果你拆開固高的機器人控制器，就會發(fā)現(xiàn)它有兩個計算核心（Intel CPU和 DSP/FPGA），就像游戲電腦會有獨立的顯卡一樣。當然，多一個核總沒有壞處，比如NI的機器人控制器roboRIO除了有ARM核還帶了一個FPGA，可以想象它的數(shù)據(jù)采集會比較快。也難怪它被用在了對控制周期和采樣速率要求較高的場合，例如MIT的四足機器人（用的是cRIO-9082）。

　　隨著CPU核心數(shù)量增加和計算能力的提升，單CPU的性能越來越強，因此機器人控制器只使用一個CPU就夠了，所有的實時和非實時任務(wù)都運行在這一個CPU上，由操作系統(tǒng)進行調(diào)度。
　　操作系統(tǒng)還是裸跑？
　　一般認為操作系統(tǒng)會導(dǎo)致額外的開銷，畢竟上下文切換需要時間，但是半導(dǎo)體技術(shù)和軟件技術(shù)的進步已經(jīng)使這個差別非常小了。程序裸跑在硬件上適合比較簡單、邏輯不復(fù)雜的應(yīng)用場合，但是其缺點也是顯而易見的，如果升級或者改變硬件平臺，程序就要重寫。所以現(xiàn)在的機器人（尤其是機械臂、無人駕駛汽車）控制器無一例外都使用了操作系統(tǒng)。
　　半成品軟件還是軟PLC？
　　ROS和OROCOS是半成品，它們更適合學(xué)術(shù)研究，需要用戶對整個系統(tǒng)比較熟悉才能使用，對用戶的編程能力有較高的要求，一般用在產(chǎn)品還沒有定型的階段或者用戶不需要經(jīng)常變換應(yīng)用任務(wù)的場合。例如無人駕駛可以使用，因為無人駕駛的整個業(yè)務(wù)邏輯和任務(wù)基本不會有大的變動。正如手機或者汽車行業(yè)，廠家不會把電路板或者底盤直接賣給客戶，因為客戶不會使用。面向終端客戶的產(chǎn)品必須要考慮產(chǎn)品本身的易用性和客戶的能力。所以如果你的產(chǎn)品面向的是沒有研發(fā)能力的終端客戶，必須要有規(guī)范易用的編程界面和簡潔高效的編程語言，這是ROS或OROCOS這種軟件所不具備的。
　　而軟PLC自帶IDE，用戶可以直接在IDE中直觀地編寫自己的應(yīng)用程序。如果自帶的函數(shù)不夠用，用戶再去底層實現(xiàn)自己的函數(shù)。開發(fā)效率更高，使用更友好。因此，現(xiàn)在的機器人控制器都會采用軟PLC的實現(xiàn)方式。
　　筆者研究生畢業(yè)最早接觸的機器人控制器不管看起來還是用起來都像個PLC，這讓我很惱火。因為PLC是低級的玩意，它的編程語言居然是梯形圖這種看起來像小學(xué)生比賽一樣的東西，而且除了一些基本的函數(shù)，其它的什么都沒有，做個矩陣計算什么的想都別想。
　　是的，PLC編程簡單而且皮實耐用，這是它設(shè)計的目的，但是機器人正在變得越來越不簡單，更多的功能被加入進來，機器視覺、自主導(dǎo)航、運動規(guī)劃、多軸運動控制，這些要求控制器提供更強大的支撐，而不僅僅是低端的邏輯控制或者簡單的數(shù)值計算。所以，對于機器人控制來說，傳統(tǒng)的硬PLC應(yīng)該被淘汰了。
　　我們需要的控制器軟件應(yīng)該足夠開放，允許用戶隨時調(diào)整程序結(jié)構(gòu)、加入新的功能，同時它自身應(yīng)該提供足夠的底層基礎(chǔ)函數(shù)，例如線性代數(shù)、數(shù)學(xué)優(yōu)化、插值擬合、方程求解、甚至圖像處理、運動控制。在使用方式上，為了兼顧客戶（不能要求所有客戶都能自己開發(fā)高級功能），它還是盡量簡單好，最好與PLC的使用差別不大。

4.2　實時性

　　開發(fā)機器人控制器是個繁重的工作，要明確一系列性能要求，首先就是實時性。
　　如果問PLC或者機器人控制器與普通計算機的本質(zhì)區(qū)別是什么，你會如何回答？是PLC更穩(wěn)定嗎，還是它的抗干擾能力更強、又或者是接口更豐富、或是編程語言更符合工業(yè)控制。筆者認為這些都不是，真正本質(zhì)的區(qū)別在于PLC是實時的，而普通計算機不是實時的。家用電腦的信息處理能力可以輕松甩出PLC幾條街（想想你玩大型游戲或者看高清視頻的計算量），那么為什么工業(yè)上還是使用“落后的”PLC呢？答案就是實時性，實時性對于工業(yè)機器人來說是必須的（至于服務(wù)機器人筆者認為可以不強求）。一般人很容易錯把“實時性”理解為計算速度快或者響應(yīng)延時短，但其實“實時性”表示時間上的“確定性”，例如實時操作系統(tǒng)（RTOS）中的中斷響應(yīng)或者進程切換的延遲時間一定是在一個時間范圍內(nèi)，我們常用的操作系統(tǒng)（Windows、Linux）都不是實時操作系統(tǒng)，因為它們設(shè)計的出發(fā)點是大吞吐量，不能保證每個事件都在一定范圍內(nèi)得到處理。再比如，標準以太網(wǎng)的傳輸速度比實時工業(yè)以太網(wǎng)（比如EtherCAT）快多了，但是標準以太網(wǎng)卻不是實時的，因為它同樣不能保證數(shù)據(jù)在確定的時間內(nèi)完成傳輸。
　　以上都是定性的描述，能不能定量說明呢？當然了，確定性肯定是有具體指標的，脫離具體數(shù)字分析實時性沒有意義。如果我們將反應(yīng)時間規(guī)定為1個小時，那么就連Windows這樣的操作系統(tǒng)也是實時的了，因為它響應(yīng)再慢也不會花一個小時。工業(yè)上很多場合1個小時顯然是太夸張了，我們至少要縮小到10ms這樣的量級，例如一個控制或插補周期執(zhí)行時間不能超過1ms，這樣Windows系統(tǒng)肯定滿足不了要求。最近炒的比較火的5G通信技術(shù)可以將延時控制在1ms左右，雖然它也不是實時的，但是由于速度足夠快所以也可以用于工業(yè)控制領(lǐng)域取代有線通信，這就是為什么5G這么火的原因。
　　理解實時性不太難，但是影響實時性的因素有哪些呢？這方面討論涉及操作系統(tǒng)原理，各大機器人廠家肯定不會公開自己的測試和試驗結(jié)果。評價實時性的主要指標是latency和jitter，jitter受到操作系統(tǒng)調(diào)度算法的影響很大，其它的例如系統(tǒng)負載也有影響，調(diào)度算法的影響大概是十微妙級的。jitter對機器人性能的影響不容易量化，因為中間環(huán)節(jié)有些復(fù)雜（底層伺服閉環(huán)）。
　　影響實時性的另一個主要因素是內(nèi)存分配。動態(tài)內(nèi)存的分配耗時非常不確定，這也是為什么很多實時系統(tǒng)都避免采用動態(tài)內(nèi)存。這里我舉兩個例子：
　　1. 在PLC中不提供動態(tài)數(shù)組，只能用定長數(shù)組，也就是說使用之前必須先分配好數(shù)組長度。這顯然很不方便，例如我們有時在函數(shù)調(diào)用時傳遞一個數(shù)組，而事先并不想考慮數(shù)組的大小。這樣一來，我們只好計算好每次傳遞的數(shù)組長度，或者設(shè)置一個盡量大的數(shù)組，顯然這會造成空間的浪費。

　　2. 如果你有過在MATLAB Simulink中編寫S函數(shù)或者用戶自定義函數(shù)的經(jīng)歷，你就會發(fā)現(xiàn)，S函數(shù)中要求你在使用變量之前必須先進行定義或分配空間，不能像在m文件中一樣不事先定義就賦值（可以看這個MATLAB自帶的例子：Integrate MATLAB Algorithm in Model）。因為Simulink中的模塊是可以生成C語言并導(dǎo)出到硬件上直接運行的，這意味著它對實時性有要求。一些PLC，例如前面提到的菲尼克斯和倍福，都支持將Simulink中仿真好的控制模型直接生成為控制程序，而無需重新編程。難怪我們在Simulink中編寫S函數(shù)的時候總感覺不像在MATLAB寫程序那么自由隨意。

4.3　高精度定時器

　　我們經(jīng)常提到“實時”，實時需要高精度的時間標準，那么誰來提供這個高精度的時間呢？答案就是時鐘周期，它是是實時操作系統(tǒng)的心跳（或者脈搏）。周期性采集數(shù)據(jù)、任務(wù)定時切換、延時輸出，這些功能都要求實時操作系統(tǒng)必須要有一個穩(wěn)定的時鐘周期來作為整個系統(tǒng)的時間標準。
　　什么是時鐘周期呢？時鐘周期依賴一個定時器，它是個函數(shù)，其本質(zhì)是一個計數(shù)器。定時器開始預(yù)先存儲一個值，每次硬件（例如晶振）產(chǎn)生一個脈沖，就將這個值減一，減到0時再重置為初始值，同時產(chǎn)生一個中斷，這個特定的周期性的中斷稱為“時鐘周期”（Tick，有的也叫“時鐘節(jié)拍”、“心跳”或“滴答”）。舉個例子，假如晶振的頻率是72MHz，則時鐘周期（Clock Period）就是1/72M，如果預(yù)先存儲的值是72000，那么時鐘節(jié)拍就是1/72M $\times$ 72000= 0.001s，也就說1ms產(chǎn)生一個中斷，此時控制器無法分辨低于1ms的時間間隔。

5　參考資料
　　　　
[1]　機器人控制器的現(xiàn)狀及展望，范永，譚民，機器人，1999.
[2]　開放式機器人控制器綜述，孫斌，楊汝請，機器人，2001.
[3]　Robotics Middleware: A Comprehensive Literature Survey and Attribute-Based Bibliography，Ayssam Elkady，Journal of Robotics，2012.
https://zhuanlan.zhihu.com/p/28052497
[4]　CODESYS Control V3 Manual, Document Version 19.0.
[5]　CODESYS Control V3 Migration and Adaptation, Document Version 4.0.
[6]　Robots Count on Software，KW-Software.
[6]　https://www.plcopen.org/technical-activities/motion-control
[7]　A Software Framework for Real-Time and Distributed Robot and Machine Control，Peter Soetens，Ph.D. thesis，2016.
[8]　An Open Source IEC 61131-3 Integrated Development Environment，Edouard Tisserant，IEEE，2007.
[9]　OPC UA support for Beremiz softPLC，Martim Afonso，2018.
[10]　An Open-source Development Environment for Industrial Automation with EtherCAT and PLCopen Motion Control，I. Kim，IEEE ETFA，2013.
[11]　Conception and Implementation of a Secure Engineering and Key Exchange Mechanism for the Open Source PLC Beremiz using a Test Driven Approach，M A Rahman，2016.
[12]　Can We Use Beremiz Real-time Engine for Robot Programmable Logic Controller，S Chu，CACS，2015.
[13]　OpenPLC - A fully open source controller An open source platform for PLC research，https://motion.control.com/thread/1464718978
[14]　OpenPLC: An Open Source Alternative to Automation，Thiago Rodrigues Alves，IEEE Global Humanitarian Technology Conference，2014.
[15]　工業(yè)機器人控制器開放性、實時性分析方法以及單處理器模式下的實現(xiàn)，博士學(xué)位論文，談世哲，2002.
[16]　Bare-Metal, RTOS, or Linux? Optimize Real-Time Performance with Altera SoCs，Chee Nouk Phoon，2014.
[17]　Real-time Operating System Timing Jitter and its Impact on Motor Control，F. M. Proctor，SPIE，2001.

總結(jié)

以上是生活随笔為你收集整理的工业机器人控制器的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。