机械臂类的控制器发展较早，相对成熟，先来看看现有的控制系统底层方案。

 

 

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

 

 

机械臂对精度和运动稳定性的要求较高，因此计算量大、周期短，比移动机器人一般要高1到2个量级。移动机器人一般对同步精度要求不高，其配置相对较低。

机械臂一般工作于固定的区域，其控制器通常放置于机箱内，因此防护等级不高，一般是IP20。

移动机器人由于需要经常运动，尤其是室外工程机械，要考虑防水防尘，其防护等级较高，一般是IP67。

 

 

 

你会发现，很多的机器人控制软件都是借助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的缺点

 

CoDeSys给我们开发控制器带来了便利，省去了从零开始的麻烦，但是依靠CoDeSys这类商业软件开发自己的控制器产品也存在不少的缺点：

 

 

CoDeSys集成的运动控制组件、总线协议栈都是封装好的，用户无法了解其内部细节，也无法针对自己的具体需求进行定制优化，只能简单地调用。用户只能依附于CoDeSys平台，难以形成自己的核心技术。

 

 

现在以机器视觉、人工智能、自动驾驶等为代表的新技术突飞猛进，而工业控制上的很多技术仍然停留在20年前。以移动机器人中的导航场景为例，基于视觉或者激光的导航方法需要采集大量的数据并对其进行处理，其中涉及相当多的矩阵计算。

 

而现在PLC只能进行落后的一维数字计算，难以实现复杂的算法。与人工智能圈子喜欢开源的风格正好相反，工业控制圈子相互封闭，谁都不肯开放自家的函数库，开源函数库极少（OSCAT），就连*基本的滤波算法、矩阵计算都要自己从头开始写。而且，国际标准提供的基本函数太过有限，完全无法适应新的场景，急需扩展。

 

由于完全依赖CoDeSys，客户自己产品硬件的升级换代需要重新定制移植，导致成本增加。

 

 

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

 

开发机器人控制器是个繁重的工作，要明确一系列性能要求，首先是实时性。

 

实时性对于工业机器人来说一般是必须的，对于服务或娱乐机器人则未必。一般人很容易错把“实时性”理解为处理或者响应速度快，但是其实“实时性”表示时间上的“确定性”，例如实时操作系统（RTOS）中的中断响应或者进程切换的延迟时间一定是在一个时间范围内。

 

我们常用的操作系统（Windows、Linux）都不是实时操作系统，因为它们设计的初衷是吞吐量，不能保证每个事件都在一定范围内得到处理。再比如，标准以太网的传输速度比实时工业以太网快多了，但是它也却不是实时的，因为它同样不能保证数据在给定的时间内完成传输。

 

     

                                                                                                                                        来源：网络