本文比較了機械臂和移動機器人兩種工業機器人的控制系統方案，對其特點進行了介紹。

以上分類是根據應用對象，此外，市面上更多的是通用型運動控制器，即控制非標設備的。

1控制器底層方案1.1機械臂類機械臂類的控制器發展較早，相對成熟，先來看看現有的控制系統底層方案。

1.2移動機器人類移動機器人的控制器屬于較新的方向，工業移動機器人有AGV、無人駕駛工程機械等形式。

1.3對比

機械臂對精度和運動穩定性的要求較高，因此計算量大、周期短，比移動機器人一般要高1到2個量級。移動機器人一般對同步精度要求不高，其配置相對較低。

機械臂一般工作于固定的區域，其控制器通常放置于機箱內，因此防護等級不高，一般是IP20。

移動機器人由于需要經常運動，尤其是室外工程機械，要考慮防水防塵，其防護等級較高，一般是IP67。

2CoDeSys介紹2.1CoDeSys的組成

你會發現，很多的機器人控制軟件都是借助CoDeSys實現的，那么什么是CoDeSys呢？

CoDeSys是一款付費的軟PLC開發軟件，簡單來說，它包括兩部分：Development System和Runtime System。Development System就是用來編程的軟件界面（就像Visual Studio、Eclipse等軟件，也可以稱為IDE），設計、調試、編譯PLC程序都在IDE中進行，這部分是用戶經常打交道的；

PLC程序寫好了以后，就要把它轉移到硬件設備中運行。可是這時生成的PLC程序自己是無法運行的，它還要在一定的軟件環境中才能工作，這個環境就是Runtime System，這部分是用戶看不到的。

二者安裝的位置通常不同，IDE一般安裝在開發電腦上，Runtime System則位于起控制作用的硬件設備上，二者一般使用網線連接，程序通過網線下載到Runtime中運行。

CoDeSys在國內知名度不高，但是在歐洲久負盛名，尤其在工業控制領域。我們上面提到的很多機器人公司都使用了它的產品，例如KEBA、倍福、固高，還有幾乎所有的移動機器人控制器廠家。

設計CoDeSys的3S公司只賣軟件，不賣硬件。硬件電路需要由用戶自己設計，3S公司負責將Runtime System移植到客戶的硬件上。Runtime System可以裸跑在硬件上，但一般是運行在操作系統上，配置操作系統也是客戶的工作。

如果客戶要求，CoDeSys的IDE可以定制，換成客戶的logo和外觀，這就是為什么你會發現不同廠家的開發平臺長得不一樣，但風格又比較相似。

當然，用戶也可以使用其它IDE，例如倍福就使用了微軟的Visual Studio，而背后的編譯器等內核以及函數庫仍然采用CoDeSys的方案。

CoDeSys的Runtime具有強大的適應性，支持絕大多數的操作系統和硬件芯片架構。

2.2CoDeSys Runtime原理CoDeSys的IDE部分是免費的，你可以從其官網下載體驗體驗。真正收費的是運行系統Runtime System。

CoDeSys在設計之初就將功能劃分為若干組件模塊，例如總線協議棧、可視化界面、運動控制、安全控制等等，用戶可以像搭積木一樣選購必需的模塊搭建自己的系統，最后形成一個定制化的控制軟件平臺。

一些初次接觸軟PLC的用戶可能對這部分感到陌生，但其實這種設計方式非常普遍。舉幾個例子，MATLAB Simulink的實時工具箱（Real-Time）就是這樣的工作方式，用戶在Simulink的圖形界面里通過拖拽設計控制程序，然后下載到真實的硬件中跑，可以在這里了解。

還有像倍福也是這樣的使用方式，用戶在TwinCAT IDE里進行編程，然后下載到倍福的控制器中，控制器里面其實已經預裝了一個Runtime。西門子的STEP7也是一款IDE，它的PLC中也存在一個配套的Runtime。

用戶編寫的PLC程序就像我們電腦里的應用程序，它運行在Runtime System上，而Runtime System又運行在操作系統之上。

Runtime System位于應用程序和操作系統之間。所以可以被稱為中間件（Middleware）。在機器人軟件里面，處于同樣地位的還有ROS、OROCOS（Real-Time Toolkit）等等。

機器人的控制，像數控機床一樣，對實時性有要求，因此我們選擇的操作系統最好是實時操作系統（RTOS）。遺憾的是，我們經常用的操作系統都不是實時的，例如Windows和Linux。但幸運的是，有人對它們進行了改造，也就是加入實時補丁。

常用的實時操作系統有：VxWorks、QNX、Windows RTX、Xenomai、RT Linux、Linux RTAI、WinCE、μC/OS、SylixOs等等。考慮到Windows和Linux這兩款操作系統的用戶較多，CoDeSys推出了相應的實時補丁（RTE），為用戶免去了改造的煩惱。

想了解更多的CoDeSys Runtime信息可以閱讀官方的文檔［Math Processing Error］ ［1］［2］［1］［2］。

2.3CoDeSys的缺點

CoDeSys給我們開發控制器帶來了便利，省去了從零開始的麻煩，但是依靠CoDeSys這類商業軟件開發自己的控制器產品也存在不少的缺點：

（1）底層算法不公開

CoDeSys集成的運動控制組件、總線協議棧都是封裝好的，用戶無法了解其內部細節，也無法針對自己的具體需求進行定制優化，只能簡單地調用。用戶只能依附于CoDeSys平臺，難以形成自己的核心技術。

（2）功能有限，難以擴展

現在以機器視覺、人工智能、自動駕駛等為代表的新技術突飛猛進，而工業控制上的很多技術仍然停留在20年前。以移動機器人中的導航場景為例，基于視覺或者激光的導航方法需要采集大量的數據并對其進行處理，其中涉及相當多的矩陣計算。

而現在PLC只能進行落后的一維數字計算，難以實現復雜的算法。與人工智能圈子喜歡開源的風格正好相反，工業控制圈子相互封閉，誰都不肯開放自家的函數庫，開源函數庫極少（OSCAT），就連最基本的濾波算法、矩陣計算都要自己從頭開始寫。而且，國際標準提供的基本函數太過有限，完全無法適應新的場景，急需擴展。

（3）難以更新

由于完全依賴CoDeSys，客戶自己產品硬件的升級換代需要重新定制移植，導致成本增加。

3開源方案

目前存在一些開源的控制系統方案，例如Beremiz、Orocos、OpenPLC、OpenRTM、ORCA。

開發機器人控制器是個繁重的工作，要明確一系列性能要求，首先是實時性。

實時性對于工業機器人來說一般是必須的，對于服務或娛樂機器人則未必。一般人很容易錯把“實時性”理解為處理或者響應速度快，但是其實“實時性”表示時間上的“確定性”，例如實時操作系統（RTOS）中的中斷響應或者進程切換的延遲時間一定是在一個時間范圍內。

我們常用的操作系統（Windows、Linux）都不是實時操作系統，因為它們設計的初衷是吞吐量，不能保證每個事件都在一定范圍內得到處理。再比如，標準以太網的傳輸速度比實時工業以太網快多了，但是它也卻不是實時的，因為它同樣不能保證數據在給定的時間內完成傳輸。

理解實時性不太難，可是機器人哪些的任務需要實時運行呢？如何根據機器人的性能要求確定程序運行的時間間隔呢（是1ms還是10ms）？實時性取決于硬件還是軟件呢？

如何根據實時性選擇具體的軟硬件呢（該選擇ARM還是X86、Linux RTAI還是VxWorks）？網上缺少這方面的深入討論，各大機器人廠家也不會公開自己的測試和試驗結果，似乎這方面主要依靠經驗和試錯。

這里我也只能提供幾個指標，目前工業機械臂的控制周期是1ms左右，性能較高的伺服驅動器位置環的控制周期可以達到125［Math Processing Error］ mu sμs。PLCopen定義了伺服和運動控制的一些標準，包括編程語言、運動控制基礎函數塊（Function Block）、輸入輸出接口的參數等。

來源：工業機器人與智能制造，版權歸原作者所有，如有侵權，請聯系刪除，謝謝！

編輯：jq