AGVs调度管理系统开发技术框架简介

AGVs管理系统开发技术专题

    • 前言
    • 关于博主
    • 系统框架总览
    • 引言
    • 一、AGV接口组件
    • 二、AGV/AGV模拟器
    • 三、交通管理者组件
    • 四、运输组织者组件
    • 五、信号处理者组件
      • 未完待续
      • 解释与声明

前言

由于近期受疫情影响,工作之中少了很多“繁杂琐事”,从而得到一些闲暇时光。旅游是不可能旅游的,还是保命要紧,所以计划在接下来一段时间开一版关于AGV调度管理系统开发的专栏,计划先写个几 万字吧,后期如何主要看疫情影响+工作情况+读者响应,毕竟没人吃饭的网吧不是好球场。
AGVsTD:AGVs管理系统开发技术的简称。至于为什么不叫DT,原因是我感觉TD更好看一些,就是这么任性。
AGVsTD并不同于市面上已有的类似ROS等从国外传入国内的“应用型”二次开发调度管理系统,而是一个从zero开始的全新的AGV调度管理系统,基于.NET环境。因为是从0开始,所以如果后期想要把整个AGVsTD讲完可能需要上百万字。所以这是一个漫长的过程,并且博主很可能会在半截跑路哦[手动滑稽]。

关于博主

欧洲某不知名的AGVs管理系统开发团队核心技术担当----系统方案架构师。

中外合资公司AGV管理系统开发团队leader。

主要担当:智能逻辑(Logic)组织、机器人模型搭建、管制算法实现、系统架构整合。

系统框架总览

AGVs调度管理系统开发技术框架简介_第1张图片

引言

随着国内工业智能化的发展,工业生产和智能物流的结合不谋而遇,从而出现了智能工厂概念,这其中最耀眼的就数移动搬运机器人–AGV了。

说到AGV就不得不提起它的两大核心技术:

1、 AGV车载控制器开发技术。

2、 AGVs(agv集群)调度管理系统开发技术。

AGVsTD主要讲解AGVs调度管理系统开发技术。

一套完整的AGV调度管理系统应该包括如下组件:

一、AGV接口组件

Agv接口组件(AgvInterface,以下简称AI)负责与Agv车载控制器(以下简称AGV)通讯,是Agv调度管理系统(以下简称AGVs)与AGV之间的桥梁。

AI主要负责两件事情,其中一个就是负责实时将AGV的数据发送到AGVs,当然也负责将来自AGVs其他组件的数据发送到AGV。AI与AGV之间采用TCP/IP Socket通讯协议,AI作为Socket客户端,或者说在整个AGV智能系统中,AGVs作为Socket客户端,AGV作为Socket服务端,也就是说一个客户端对应多个服务端。

AGVs调度管理系统开发技术框架简介_第2张图片

关于AI与AGV之间的数据传输,使用16进制数组报文,具体数据传输协议由双方(AGVs与AGV)共同商定。为什么使用16进制数组传输呢?因为AGVs开发采用的是面向对象的高级语言,而AGV控制器系统开发需要考虑到与底层(下层核心板)外设的通信,一般采用C或C++,由于语言的阶级不同,所以采用Socket进行数据传输

上面说到AI负责两个担当,这第二个就是AI与AGVs之间的通讯,其实AI本身就属于AGVs的一部分,但是这里为了说明整个AGVs的通讯方式只能暂时将其从AGVs中脱离出来。

AI与AGVs之间的通信采用.NET下的Remoting。

AGVsTD第一阶段并不包括AGV车载控制器的开发,但是AGVsTD开发了AGV模拟器,AGV模拟器具备实际agv的大部分“功能“。后续可能也会推出AGV基础控制器(AbcTD)开发板块,但目前尚未制定详细计划。

二、AGV/AGV模拟器

由于MockBird并不精通车载控制器开发技术,所以只能非常浅显的班门弄斧一下。首先从车载控制器的硬件来讲,其应该包括:

1、主机板(cpu+外设接口)

即使非常强大的agv开发团队也不具备主机板的开发能力,当然也不需要具备,通过从其他供应商处购买比重新开发一个更高效更可靠。

2、电源板

3、FPGA板。

一个控制器开发团队的硬件核心技术可能就在于FPGA板的开发了。

车载控制器软件的开发一般是将裁剪后的Linux安装在主机板上,之后在该系统中开发自己的ABS(agv基础软件)。一般主机板供应商都会提供相应的系统,只不过Linux一般是免费提供的,比如Gentoo。

AGV模拟器(Agv Simulator,以下简称AS),前面已经介绍过AGV与AI的通讯方式,这里就不多做解释,等讲到“AGV模拟器“组件开发专题时再详细讲解。

三、交通管理者组件

AGV交通管制(AGV Traffic Control,以下简称TC)是整个AGVs的核心组件,它不但充当着路面交警的角色还要负责当司机。上面说到的AI与AGVs的通讯其实就是AI与TC之间的通信,AI将来自AGV的16进制数组报文解析后得知AGV的意图并将其意图发送到TC。下面举一个小例子来说明AS(AGV)、AI、TC之间的数据交互:

AGV本身应该具备一个或一组功能:将自己加入AGVs或者从AGVs中移除,这可以是AGV显示屏上的一个按钮。因为AGV本身并没有预知其他AGV位置的功能,所以AGV需要向AGVs发出Insert请求,让AGVs判断此处是否可以Insert AGV到AGVs布局,具体步骤:

1、当触发将AGV加入AGVs的按钮时,AGV将插入消息(InsertMessage)反串行序列化为16进制数组报文后使用Socket.Send()发送给AI;

2、AI使用Socket.BeginReceive()接收16进制数组报文后解析,得到AGV的意图是(InsertMessage),之后AI使用Remoting将“验证插入消息(VerifyInsertArgs)“发送到TC,为什么要发送给TC?前面已经说过了,TC是AGVs的核心组件,所以TC的责任非常之大,Agv插入消息也属于交通管制(Traffic Control)类消息,因为AGV不可以在已经在AGVs布局中的agv附近插入系统(具体原因和AGVs之间的交通管制算法有关,后面关于TC组件开发时会讲解AGVs的两种锁,这两种锁会处理两种情况:一是从软件层面避免AGV之间的碰撞,在避免了AGV之间的碰撞后还要避免AGV集群出现死锁,也就是管制,所以第二个锁(预防死锁)就出现了,在避免了agv之间的碰撞又解决了死锁后,AGV集群就可以如鱼得水了,这里说的已经脱离本章主题了,后面会详细介绍)

3、TC使用Remoting收到VerifyInsertArgs后开始验证,当然在VerifyInsertArgs应该包含几个参数:

①AGV发送到AGVs的InsertMessage中的坐标点;

②一个insert选项,这个选项将表示agv是否在insert系统时将之前自身的运输删除。

③其他参数

Insert坐标用于找到agv附近的线段(segment/line),TC将验证该线段是否可以insertAGV;insert选项将处理agv已经开始运输的订单(删除或者继续执行),当然详细的验证过程并没有这么简单,比如还需要验证当前agv的角度与插入线段之间的夹角是否<90°(agv插入角度与segment方向角如果>90°将对设备(舵轮)有很大损害,另外如果agv车体长度过长将造成原地旋转,对安全性也有考虑)具体验证过程这里不多做介绍,后续TC组件开发时再做详解。

4、当TC验证通过来自AI的VerifyInsertArgs后会向AI发送InsertVerifiedArgs,之后AI将消息解析为16进制数字数组Send到AGV通知agv可以在此处insert系统。当然从TC伴随而来的还有一个驱动命令到达AGV,以驱驶agv从一个坐标点行驶到另一个坐标点,此时,AGV才算是插入到AGVs系统。

5、关于AGVs与AGV之间数据收发的确认消息,有一些消息需要对方确认而有一些则不需要,具体由双方协商

TC除了要处理来自AI的插入报告,还要处理来自AI的agv的状态报告、任务完成报告(包括舵轮驱动命令、货叉升降命令等)、从布局中添加/移除命令、错误报告等;当然也要负责向AI发送消息,比如驱动命令、执行任务命令、请求agv状态、从系统添加/移除agv、插入验证通过、agv显示文本命令、软件更新命令、请求agv停止、请求agv睡眠、请求唤醒agv等等。

TC在处理上述报告和命令时需要进行动态交通管制验证,即动态路径规划,它包括检测agv之间的管制和尝试agv间的“推动“让路以及尝试选择其他线路绕过前方阻碍的agv等等,后续TC专项开发过程中会详细介绍动态路径规划

通过上面这个例子可以看到AGV-AI-TC是具有一定“级别“的,越往上”级别“越高,这就形成了”框架“,软件工程师做到最后便是架构师,一个庞大的AGVs系统需要一个经验丰富的架构师去完成整体架构,那么问题来了,TC是否还有上一级别?答案是肯定的,虽然TC的责任很重,但是TC就是TC,他不多拿一份工资,所以它只负责交通管制问题,运输组织分配、订单管理、信号处理等任务还需要其他组件负责,而TC的上一级别就是”运输组织组件

四、运输组织者组件

运输组织者组件(Transport Organizer,以下简称TO)负责运输(Transport)的分配与优化,即将AGVs现有的且未分配的运输分配给正在闲置的agv,然后交给TC去实施分步解析最终驱驶agv执行动作。除了负责为运输分配agv之外还需要负责为agv分配运输,或者说是agv池与现有运输池之间的轮询分配。TO除了添加/删除运输外还负责优化现有运输。

优化运输的说明:当一个运输被分配到一个agv后,这个运输并不应该被“完全绑定“到这台agv上,此时应该是“临时绑定“,当这个运输找到一个可以更快到达的agv时会重新为运输分配agv,直到agv与该运输完全绑定(比如当agv拾起负载后就不可以再为运输更换agv了)。

用比较粗俗的语言来讲就是一个人(运输)找到对象(agv)后并不能代表两个人以后会在一起(不会完全绑定),假如这个人找到了更高富帅/白富美的之后就可能换掉现有的对象(第一次分配给运输的agv),但是等到两人结婚生子之后就属于完全绑定状态,(负载)上了车(agv)就不能轻易下车,除非出现重大事故(比如agv出现故障无法继续执行运输时),这时候就可能出现离婚情况(这取决于agv事故的修复时间和负载需求指数),就好比它对象出了车祸一病不起,而它本身又非常优秀有很多追求者,到最后说不定两人就gg了。

上面我们重复提到的一个词叫“运输Transport”,不叫“订单Order”,它非常单纯,就是一个运输,从A到B的运输,不再有其他任何意义。那么TO会不会有上一级呢?我们后面再说,因为TC还没有讲完,what?TC还没有讲完?没错,上面说到TC责任很重,那么他还需要和一些“平级”组件交互,比如IO处理组件

五、信号处理者组件

信号处理者组件(IoHandler,以下简称IH),它负责处理整个AGVs中涉及到的信号源数据,信号源包括数据库虚拟IO、外部设备PLC(Opc)、外部IO模块(SIOX)、看门狗(Watchdog)、以及AGVs系统内部信号点

IH的主要功能包括但不限于:

1、获取/设置信号状态

2、请求/报告信号状态

3、设置单脉冲信号

4、启动/停止重复脉冲信号

IH组件没什么可介绍的,任何一个系统都有该IO,有IO就有IO处理器(IoHandler)。

TC和IH的关系就是TC会将消息传入IH以达到其目的。

下面阐述一个例子–一个运输Trp是如何在各组件间确认分工的,这会将AS、AI、TC、TO、IH联合起来:

1、当TO拥有一个来自AGVs或者外部源的“Transport”时,首先验证其可执行性,验证是TO的工作,TO不可以向TC发送一个不可能完成的AddTrpArgs(Transport简称),比如Trp的任务类型是“交付Deposit”,那么TO就不能为其选择一个负载状态为低(low/0/false)的agv去执行,交付的意思是首先你(agv)要有负载才能交付,没有负载的agv你(TO)不能让他空手套白狼。就好比快递员手里没有A的件,但是快递公司非要让快递员去给A送货,这不是扯犊子嘛。当TO找到合适的agv去执行Trp时,便会创建AddTrpArgs并通过Remoting发送给TC

2、TC拿到AddTrpArgs后需要做什么呢?当然是处理它了,TC首先应该找到从A到B的最快(时间最短)路径,为什么不是路径最短呢?因为智能工厂要的是效率,效率就是最快,路径最短并不意味着时间最短,假如从A到B有两条路径,一条路径短但是通道很窄,另一条路径长一点但是通道很宽,众所周知,agv的运行速度是要考虑安全扫描仪的扫描范围的,agv运行速度越高停止所需的距离(刹车距离)就越长,那么安全扫描仪的范围就应该越广,但是那条窄通道并不满足agv高速行驶条件,所以短而窄的路径就要降低agv的运行速度,但是长宽路径就允许agv高速行驶,从而行驶时间更短,所以智能工厂所需要的是时间最短而非路径最短。

在找到最快路径之后将整个路径拆分。AGVsTD讲解的一切组件都是基于Segment/Line(驱动命令是基于segment/Line的两个坐标点Coordinate)的,下面是AGVsTD的静态路径规划软件的部分截图,它展示了A到B的路径

AGVs调度管理系统开发技术框架简介_第3张图片

假设A为AGV当前位置,B为Trp参数中的目的地。TC需要将整个Trp拆分为多个“Trp part”,每一个线段都是一个TrpPart。

前面讲到过,TC负责向AI发送“驱动命令Drive Command”,驱动命令中包括两个坐标点(线段的起点和终点);TC除了发送驱动命令还负责发送“任务命令TaskCommand”,比如货叉举升/下降300mm高度;当然也包括向IH发送信号处理命令SetSignalHigh(AccessReq)和WaitSignalHigh(AccessOk)。

TC向AI发送线段“驱动命令”(从一个线段的起点坐标->终点坐标)之前,还要处理一些事务–动态路径规划的一部分–路径验证,TC需要判断agv01(假如负责处理Trp的agv编号为01)是否可以进入前方线段(如果前方线段被其他agv(假如是02)锁定,则在agv02释放前方线段锁定之前,负责处理Trp的agv01是不能进入该线段的)。如果前方线段被agv02锁定,那么agv01将向TO发送移动agv02请求(MoveReq(agv02)),如果agv02所在的位置为闲置点(Idle01),那么TO将为agv02寻找除了Idle01之外的闲置点(比如Idle02),之后将Idle01->Idle02这个Trp发送到TC以驱动agv02驶离当前位置,从而达到agv01推动agv02的效果;如果agv02无法被“推动”,则TC将停止向AI(agv01)发送前方线段的驱动命令,转而寻找从当前线段->目的地的其他TrpParts,如果寻找失败,则只能等待agv02自行离去(agv02完成自身的TrpParts之后就会离去并释放线段锁定)。

当TC发送驱动命令到达自动升降门所在的线段的前一条线段时,应该向IH发送SetSignalHigh(AccessReq)以申请访问升降门,其意图是让升降门打开,让agv通过升降门,同时TC还要向IH发送信号状态请求以获取AccessOk状态,等到升降门打开之后AccessOk将置为高电平,当TC获取到来自IH的信号状态报告(AccessOk=1)后,发送线段驱动命令,这部分完整的程序大概如下:

If(!isSignalLow(AccessReq))
{
SetSignalLow(AccessReq);
Wait(1000);
SetSignalHigh(AccessReq);
}
else
SetSignalHigh(AccessReq);
WaitSignalHignal(AccessOk);

这个程序应该附加到Segment/Line属性当中,在驱动命令执行之前先执行该命令。

之后agv通过升降门。

agv通过升降门之后,TC应该向IH发送SetSignalLow(AccessReq,AccessOk);表示取消访问升降门请求。

当agv到达B之前应该准备货叉高度,此时TC将TaskCommand(设置货叉高度,300)以准备开始作业,整个过程结束。

从上面的例子可以看到TC负责的事务非常多,包括动/静态路径规划+动/静态交通管制。其实在动态路径规划中除了上面例子提到的还有很大一部分条件需要考虑,比如agv01不可以在升降门所在的线段停止,以避免升降门故障突然下落损坏agv。这个功能的实现我们放到后面TC专项再谈。

3、AI接受到来自TC的各种Args后向AGV/AS发送TC的意图。AGV/AS完成相应指令后向AI发送完成或者错误报告,AI再将信息发送回TC,如果人为干预在AGV显示屏上关闭了该Trp,那么TC将会向TO发送DelTrpReport以通知其删除Trp。

到这里这个简单的例子就讲完了,但是在实际数据交换过程中还需要更复杂的验证和更多条件满足才能完成整个Trp。

之前我们已经介绍了TO,那么TO的Trp是从哪里来的呢?这样下来我们就要谈订单管理组件(Orde Manager)的概念了。

但是在此之前我们先停下来把整个AGVs系统框架搭建起来(详见标题系统框架总览)。之前我们介绍了AS/AI/TC/TO/IH这五大组件,但是之后的订单管理OM/外部系统接口ESI/客户端软件AGVsClient与它们有一个很大的区别,那就是面向客户开发,说到底,agv的首要功能是运输,每个个智能工厂的运输方案都不一样,这些组件都需要一对一的开发。

AGVs除了需要开发面向客户的组件之外还要开发面向开发者的软件,路径规划软件+逻辑规划软件、agv调试诊断软件、日志追溯软件、外部系统模拟软件等。

除此之外,我们还没有提到“数据存储”这个概念呢。

总之,可以说一个AGVs的开发是非常庞大的,一个中型配置的团队可能需要数年时间才能完成基础开发,到试运行发布盈利、再到系统优化都需要时间沉淀,这也是为什么国内很少有优秀的agv管理系统出现的原因。

未完待续

Ok,时光总是那么的短暂,也总有说不完的话,本章介绍了一些组件感念,当然还剩下一部分以后介绍。

接下来几周计划讲解:

1、AGVsTD开发环境
说实话,本篇文章阅读起来并不“通俗易懂”,我总结了一下原因,主要是文章覆盖范围太广,仅仅只用几千字就讲解了AGVs中近一半的组件;另外就是专业性太强,对于一般AGC系统开发工程师来说,在逻辑思想上可能有些对冲,当然AGVsTD在全球AGV管理系统开发团队中并不是最出色的,任何其他团队的开发思想都非常的有价值。

2、AGV项目方案详解
为什么要将这一节呢?似乎AGV项目方案和agv管理系统开发并没有什么直接关系啊,没错,确实是没有直接关系,但是在AGVsTD中有一个组件“外部系统接口组件“,这个组件的开发是和具体方案有关的。每一个项目需要对接的系统可能不同,比如MES\WCS\WMS\ERP\PLC等等,所以方案讲解也在计划之中

3、还没有介绍的组件

4、单个组件的开发专题
关于单个组件的开发专题中,可能涉及大量的代码实现,但是我会尽可能的将各个算法的实现使用最简洁的语言和生动的例子讲解清楚。当然在单组件开发专题之前,先要讲解几个核心算法实现。

5、主要算法实现
①时间最短路径算法的实现。
②静态交通管制算法的实现
标准锁的基础:agv轮廓占用的实现、如何根据agv轮廓找到agv的标准锁
预防死锁:如何找到死锁、如何解决死锁
③动态路径规划算法的实现
④其他算法的实现

解释与声明

文章内容全部原创,如有雷同绝对是别人copy的(我自己除外),另外本专题后续开发的所有软件概不外发,所以请不要留邮箱以免泄露您的隐私和避免您的财产损失。

关于评论回复,可能会回复,但更多的是希望后期进行评论问题答疑专项章节的发布来处理读者疑点。

关于文章中的错别字,都是故意的。

关于文章发布的时间节拍,免费期间完全随心。

如果你能读完,恭喜你,没有任何奖励!

下期再见!!!

你可能感兴趣的:(AGVs调度管理系统开发)