1.1机械手类。

 

机械手的控制器发展较早，也比较成熟，首先介绍了现有控制系统的基本方案。

1.2人类移动机器。

 

运动机器人控制器属于较新方向，工业移动机器人有AGV、无人驾驶工程机械等形式，控制系统底层方案如下：

1.3对比。

 

机械手对运动精度和稳定性有很高的要求，所以计算量大，周期短，比一般移动机器人高1——2个量级。移动机器人一般对同步精度要求不高，配置相对较少。

 

机械手一般工作在固定区域，其控制器一般放置在机箱内，所以防护等级不高，一般为IP20。

 

由于移动机器人需要频繁运动，特别是户外工程机械，要考虑防水防尘，其防护等级较高，一般为IP67。

2　CoDeSys介绍。

 

2.1构成CoDeSys。

 

许多机器人控制软件都是借助CoDeSys实现的，那么CoDeSys又是什么呢？

 

CoDeSys是一个付费的软PLC开发软件，它由两部分组成：开发系统和运行系统。DevelopmentSystem是用于编程的软件界面（如VisualStudio、Eclipse或IDE等软件），PLC程序的设计、调试、编译都在IDE中进行，而PLC程序的设计、调试、编译是用户经常使用的；

 

当PLC程序写好后，要将其转到硬件设备上运行。但此时生成的PLC程序本身并不能运行，它还需要在一定的软件环境下工作，这个环境就是RuntimeSystem，这部分用户看不到。

 

IDE一般都安装在开发电脑上，RuntimeSystem是在硬件设备上进行控制，两者一般都使用网线连接，程序是通过网线下载到Runtime运行的。

 

CoDeSys在国内并不出名，但在欧洲很久，特别是在工业控制领域。许多机器人公司都在用他们的产品，如KEBA、倍福、固高，以及几乎所有的移动机器人控制器制造商。

 

负责设计CoDeSys的3S公司只卖软件，不卖硬件。系统的硬件电路由用户自行设计，3S公司负责移植RuntimeSystem到客户硬件。RuntimeSystem可以无休止地运行在硬件上，但是通常运行在操作系统上，用户也需要配置操作系统。

 

根据用户的要求，CoDeSys的IDE可以被定制，用logo和客户的外观代替，这就是为什么你会发现不同厂商的开发平台长得不一样，但风格更相似。

 

自然，用户也可以使用其他IDE，比如倍福公司就用了微软的VisualStudio，以及其背后的编译器等函数库仍然是采用CoDeSys的方案。

 

CoDeSys的Runtime支持大多数操作系统和硬件芯片架构，适应性强。

2.2　CoDeSysRuntime原理。

 

IDE版CoDeSys是免费的，你可以从它的官网下载体验。实际付费的是运行系统运行的系统。

 

CoDeSys在设计之初就把功能分成了几个组件模块，如总线协议栈、视觉界面、动作控制、安全控制等，用户可以像积木一样挑选必需的模块搭建自己的系统，***后形成一个定制化的软件平台。

 

有些初接触软PLC的用户可能对这部分感到陌生，但实际上这种设计方法是很常见的。举例来说，MATLABSimulink的实时工具包（Real-Time）就是这样一种工作方式，用户通过拖动Simulink的图形界面设计控制程序，然后下载到真实的硬件，在这里就能知道。

 

也有类似于倍福的使用方法，用户在TwinCATIDE上编写程序，然后下载到倍福的控制器上，实际上预装了一个运行时间控制器。西门子公司的STEP7同样是IDE，在其PLC中有一个与之配套的Runtime。

 

使用者写的PLC程序就像电脑中的程序一样，运行在RuntimeSystem上，RuntimeSystem则运行在操作系统之上。

 

运行系统位于应用程序和操作系统之间。这就是所谓的中间件（Middleware）。在机器人软件中，ROS、OROCOS（Real-TimeToolkit）等处于同等位置。

 

由于机器人的控制，像数控机床一样，对实时性要求很高，所以我们选用的操作系统***好是实时操作系统。可惜，我们经常使用的操作系统没有一个是实时的，比如Windows和Linux。但是幸运的是，有些人已经改变了它们，即加入实时补丁。

 

常见的实时操作系统有：VxWorks、QNX、WindowsRTX、Xenomai、RTLinux、LinuxRTAI、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）并不都是实时操作系统，因为它们***初设计的是吞吐量，并不能保证在一定范围内处理每一个事件。比方说，标准以太网比实时工业以太网传输速度更快，但它并不是实时的，因为它同样无法保证数据在给定的时间内完成传输。

 

了解实时性并不难，但是需要实时执行机器人哪些任务？程序运行的间隔时间如何基于机器人的性能需求来决定（1毫秒还是10毫秒）？实时性取决于硬件还是软件？

 

具体的软硬件是基于实时性的，应该选择ARM还是X86,Linux。

 

目前工业机械臂的控制周期是1ms左右，性能较高的伺服驱动器位置环的控制周期可以达到125[Math Processing Error] mu sμs。

 

PLCopen定义了伺服和运动控制的一些标准，包括编程语言、运动控制基础函数块（Function Block）、输入输出接口的参数等[Math Processing Error] ^{[3]} 

 

[3]具体的实现代码细节，这个是由各个厂家提供的。