调度，又名迪斯派车(Dispatch);我估计最早的起源可能是两个人同时过独木桥场景，有那么几种情况：
a. 两人相向而行，你让开，我过去，或者我怂了，您先走;
b. 两人一前一后走，前面走得慢，后面要么傻傻的等，要么U看U超车;
c. 很宽的桥，你看到我，然后侧身闪开了，成功避免了一起剐蹭事件
面对以上种种，调度一词渐渐浮出桥面，并被广泛应用到工业，快递业，服务业等各个需要解决冲突、化解矛盾的领域。
再比如，上图中的两台车，左边车要去到右边车的位置，大家可以数一数一共有多少条路(数对了有奖)，在这么多条路中哪一条最近，哪一条要拐的弯最少，哪一条最不堵车，哪一条最刺激，哪一条最有可能遇到那个她......根据不同的评价标准，调度可以根据您的要求，进行路线的私人订制。
我们想要辨明一个问题是不是调度问题，假设工厂中只有一台机器人在工作，此时调度问题就退化成简单的路径规划问题了，因为不需要考虑该将任务分配给哪个机器人，也不需要考虑在一个路口谁先走谁后走的问题。所以调度问题的前提是多台机器人共享路径网络，换句话说机器人之间存在资源争夺，就像马路上的车辆一样，谁都想怎么快怎么开，如果每个司机都只考虑自己而不考虑别人，那么后果很可能是谁都别想走(堵成一坨)。讽刺的是，个人追求自己局部的最优解却变成了全局的最差解，所以调度是很有存在的必要的，而且有时很重要(红绿灯、交警、人行道都可以看成“广义”的调度)。
多数情况下，调度系统需要站在上帝视角统筹所有机器人的行为，它追求的不是某几个机器人的最优解(当然它有能力这么做)，而是整体的最优解。
我们可以天马行空的想一下，能不能做一款调度软件来调度一个城市里所有的车辆，让整体解是最优的(例如所有人的油耗加起来最少)。这个最优解一定存在，我对此毫不怀疑，理论上没有任何问题，但是实际上却几乎不可能解出来，因为有两个难点：
a. 调度系统要掌握海量的信息，比如张三八点从家里开车到单位，赵四九点开车送孩子，王五的车油箱的油不够，需要中途加油等等，更麻烦的是这些信息是变动的，例如张三的车开着开着轮子飞了......
b. 调度问题的复杂度随着参与者的数量增多呈指数增加。如果只有几十辆车，现在的算法和计算机硬件还能勉强解决，如果要处理成千上万辆车，那恐怕只有上帝才能做到了，信息缺乏和维度阻碍是调度问题面临的主要困难。
正因为调度问题是极其复杂的，所以大多数时候我们只能退而求其次找一个最接近合理的最优解，这也正是实际生活中每个路口的交通信号灯闪烁背后的逻辑。
说起调度系统，不得不提及仙知强大的技术团队背景，2017年，仙知机器人曾靠“独门绝技”——多台机器人协作调度系统RoboRoute，一举获得RoboCup足球机器人世界杯小型组冠军，该调度系统自动安排机器人的运行路线、规划最优路径，并合理避开机器人之间的路线冲突。它成功解决了多台机器人之间合作问题，以及在高度动态环境中的控制问题。
用户使用仙知的多机调度系统 RoboRoute，能快速引导多台移动机器人协同工作，不论是无人叉车、搬运机器人，还是复合机器人等，免去独立控制各台机器人的繁琐，使机器人的工作效率达到最高，并且提供简洁的Web API网络协议，与MES、WMS等系统无缝对接。
仙知多机调度系统 RoboRoute的研发，旨在帮助用户轻松实施，实现对所有移动机器人的控制，快速部署，使移动机器人工作效率达到最高;实现高效调度多类型、多数量的移动机器人协同作业，提升工厂整体的生产效能。
（转载）
