本文比較了機械臂和移動機器人兩種工業機器人的控制系統方案，對其特點進行了介紹。
以上分類是根據應用對象，此外，市面上更多的是通用型運動控制器，即控制非標設備的。
1 控制器底層方案
1.1 機械臂類
機械臂類的控制器發展較早，相對成熟，先來看看現有的控制系統底層方案。
1.2 移動機器人類
移動機器人的控制器屬於較新的方向，工業移動機器人有AGV、無人駕駛工程機械等形式，控制系統底層方案如下：
1.3 對比
機械臂對精度和運動穩定性的要求較高，因此計算量大、週期短，比移動機器人一般要高1到2個量級。移動機器人一般對同步精度要求不高，其配置相對較低。
機械臂一般工作於固定的區域，其控制器通常放置於機箱內，因此防護等級不高，一般是IP20。
移動機器人由於需要經常運動，尤其是室外工程機械，要考慮防水防塵，其防護等級較高，一般是IP67。
2 CoDeSys介紹
2.1 CoDeSys的組成
你會發現，很多的機器人控制軟件都是藉助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.2 CoDeSys 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），為用戶免去了改造的煩惱。
2.3 CoDeSys的缺點
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）、輸入輸出接口的參數等[Math Processing Error] ^{[3]}
[3]具體的實現代碼細節，這個是由各個廠家提供的。
閱讀更多 未來工業互聯網 的文章
