OpenTCS打造移动机器人交通管制系统(五)

本文来谈一谈OpenTCS的调度问题。

OpenTCS默认的算法是基于"前馈锁路"的方式进行交通管制的。

所谓的“前馈锁路”，意思是当某辆车需要运动时，在运动之前会将MovementCommand转换成一种交通管制资源向系统中注册。只有当该资源被系统接受时，车辆才会运动，大致的逻辑如下所示：

 

OpenTCS的这种默认交通管制策略其实比较简单，也容易理解，那么这种方式是否在实际项目中就可以使用了呢？答案是分情况，宽阔的场地可以充分规划双行线的场景一般没有什么问题，但是对于一些场地受限制的场景，比如几乎只能使用单行线的工作场地，这种算法依旧是无法解决死锁问题的。所以下面主要讲讲这种情况下的死锁问题。

举个栗子，假如存在下面这个地图：

系统中存在两辆车，初始位置分别停靠在12点和13点。这是一个很简单的地图，正常运行时也不会有多大问题，但是这个地图有个特点，那就是路段只允许一台车通过。如果使用OpenTCS默认的算法，就会存在死锁问题，比如遇到下面的情况：

当某辆车在Location-0001作业完后，需要回到停靠为12，此时系统规划了一条通往12位的路径，但是同时有一个订单要求另一辆车从13点通往Location-0001，系统又会生成一条路径从13点通往Location-0001。

此时死锁就极有可能发生，如下所示：

对于上述死锁问题的改进办法个人认为有下面两种：

1、错开订单的下发。

2、改进调度资源分配算法，将双向路径考虑到资源分配的过程当中(改进方法可关注后面的文章)。

当然还存在其他的死锁问题，在项目应用时需要特别注意。

、