上位机编程-工业机器人

工业机器人主要应用于一些焊接，搬运等工作站上，他们往往使用PLC作为主控，或者利用工业机器人本身的软PLC系统作为主控，来协调机器人和外部IO，传感器，外部轴，执行单元；那么什么时候需要上位机呢?最主要的可以区分为两大块：1.机器视觉；2.离线编程；

机器视觉在市场上区分也可分为两大块：一个是智能相机，另外一个是PC-based自开发的视觉系统。后一种的市场份额目前超过50%,机器人和视觉结合主要应用在，跟踪，识别，定位等等场合，以焊缝跟踪这个特定的应用场合为例：视觉系统检查焊缝的偏差，由像素坐标转为机器人可用的坐标（一般转为机器人基坐标系），然后机器人调整位置使得焊枪对准焊缝。由于焊接有速度要求，这个周期最好控制在150-200ms以内。这就需要视觉系统和机器人控制部分在local范围内运行，所以需要开发机器人上位机系统，PC一般都有网口，机器人也有网口。这样相对于其它总线类如profinet等节约成本，且调试较为方便，容易产生复用性。

离线编程普遍是由专门的软件（robotmaster,DELMIA，ABB的robotstudio等）做开发，形成机器人末端所需要的轨迹，应用在打磨，切割等应用场合。做过实际开发的都知道，离线编程软件吹的再怎么邪乎，导出来的轨迹应用到机器人上也是用不了的。必须要经过修正，修正主要来源于三块，一个末端TCP的修正，一块是工件本身所在的坐标系的修正，当然还有更致命的如客户给的CAD和实际工件尺寸不符合的情况，这个就很难求解了；还有一块是增加工艺的功能语句；这些工作都完成后，离线编程往往使用用户坐标系来执行加工。由两种选择，一种上位机直接控制，还有一种是把修改后的程序下载到机器人控制器上，由操作者执行。

总结上来，机器人上位机开发需要这几个功能：上位机能够控制机器人运动（相对坐标，绝对坐标，连续插补等），机器人变量，IO读取和写入，机器人子程序调用，读取机器人当前坐标，坐标系转换等等功能；

二.架构设计：

机器人上位机接口本质上是一个通信程序，我们需要借助通信的通用架构来解决这个问题，在这个领域最经典就是request-response和publish-subscribe架构了。

request-response：主要用于机器人下发控制命令，控制机器人运动，request一般是下发机器人的绝对坐标，response回的是机器人是否收到命令，当前机器人是否是ready的状态；

publish-subscribe:主要用于读取机器人状态（位置，关键变量，IO，Force）等；机器人端publish这些信息，上位机subscribe这个event，当收到报文后解析，解析出当前机器人的状态信息；

三.详细设计：

落实到具体的详细设计通信有三个难点，第一是通信连接过程的管理，第二是报文的设计，第三是异常的处理；对应机器人上位机接口来说最难的还是报文的设计以及异常的处理：

通信连接过程的管理这部分主要看那种模式的，是阻塞socket还是非阻塞socket，阻塞socket比较简单，可以应用的request-response这个模式；非阻塞socket可以用于pub-sub这个环节，可以使用如select模型这些方法，来管理轮询这个过程，检测是否收到数据，也可用callback的方式；

报文的设计需要考虑设计帧结构，帧结构根据下位机的不同往往有三种形式，一种是字符串；一种是数字（有可能为16进制）组成的帧结构；还有一种XML数据流（极少用）；但无论哪一种，都需要区分报文头+报文这两种模式，报文头包含报文的功能码信息，长度信息等等；

字符串模式：这个模式的好处是不用考虑大小端的问题，但需要考虑如何断开信息帧，如采用,#等等作为分隔符；

数字帧结构:这个模式的好处是可扩展性更好一些，不需要字符串转数字等操作；

异常的处理是难点中的难点，首先机器人连接建议最好为长连接，用心跳包文来保持这个来保持这个功能，如果必须用短连接，重复连接机器人，有比较把断开的连接作为异常抛出，但需要注意的是抛出前必须要断开执行器的控制（因为如果执行器还在运动，而机器人已经停止连接了，这就失去对下位机的控制了，在工业现场属于重大错误）

用之前用的一个图来总结

四.评估：

风险评估：该架构已经稳定运行几家主流的工业机器人上了，最大的风险还就是异常的处理……；

可扩展评估：每一种机器人可作为一个节点合并统一起来，从控制的角度上看，要远远好于ros的moveit。因为ros的moveit功能太弱。很多没有连续运动，IO等选项；