2019年华为软件精英挑战赛，成渝赛区初赛第3，复赛第4，决赛亚军 队伍名：成电恶霸
- 主要思想是限制地图上最大行驶车辆数量，发车时规划好预期路径，当车辆的预期路径上有道路发生拥堵时再重新规划一次路径
- 单秒回溯解决死锁问题。每个时间单位都会更新一次回溯点，当发生死锁时，回到回溯点状态，对死锁环中的车辆除去预期路径的下个道路重新规划路线。
- 路径规划采用Dijkstra算法，动态更新道路损失
- 普通车辆、优先车辆、预置车辆的预期路径有不同的额外道路损失增加
- 当道路发生拥塞时，会额外增加该道路和导致本道路拥塞的下条道路的损失。道路拥塞的定义是：道路上的车数>道路容量*系数 && 道路上有车辆因为拥塞没有进入下条道路
- 路权函数非常玄学，结合了道路当前车辆数，道路道路宽度（道路宽度越小越容易出现拥塞），优先车辆、预置车辆、普通车辆预期路径的额外损失，道路长度，道路限速，车辆速度。大致形式为 cost = road.length / Math.min(road.speed, car.speed) * (1 + a * (carNum + carCost) / road.capacity) * (1 - b * road.channel)
- 速度排序优先发慢车再发快车（快车能够绕过因慢车引起的拥塞）
- 优先车辆优先发车
- 均匀发车策略，路口发车遍历顺序按照路口剩余待发车车辆数量从大到小排列
- 均匀路口发车可能会导致车辆在终点附近造成拥塞，所以在每个时刻会粗略预测每条道路的未来200时间的车辆数。当普通车辆要发车时，会确认在到达预期路径的每条道路时，不能超过该道路的容量
- 10% 预置车辆修改中，6% 用于解决因为预置车辆造成的死锁（看成解死锁的资源），3% 用于预置车辆预期路径下发生拥塞时重新规划路径， 1% 用于修改预期路径比较绕的优先预置车辆路径，考虑到了稳定性和防止写入新bug，就没有修改预置车辆的发车时间。
- 图像预处理：观察图像有旋转和剪切失真，所以首先对车牌图像进行旋转和剪切失真矫正。方法是先二值化车牌图像，找出每个字符的连通区域，所有字符连通区域的顶点拟合成一条直线，这条直线与水平线的角度代表旋转失真角度；-20°～20°剪切（shear）图像，所有字符连通区域的宽度最小时，就是图像的剪切失真角度
- 数据增强：旋转、剪切、缩小横移等
- 模型：简单的三层卷积+GRU组成的CRNN网络，采用CTC loss训练（参考：https://github.com/DeepSystems/supervisely-tutorials ），模型的输出没有字符长度的约束，所以解码的时候需要保证输出字符长度为9
- 正确率在97%左右
- 整体方案思路都是以稳定为主，包括需求的更改与策略的制定都是为了降低出现解不开的死锁的概率和减少对参数的依赖
- 个人感觉这个调度方案，本身就很玄学。对道路出现拥塞情况很敏感，因为拥塞道路上的车辆是不能改变路径的，很容易出现死锁解不开的情况。所以我们在调度策略中一直以避免出现道路拥塞为目的，但可视化了调度过程，感觉在火灾现场，有很多车在绕圈，很没有秩序，也很难预测未来道路的状况
- 从初赛到决赛都一直是这个方案，只是不断尝试和增加新策略。其实复赛之后是想换方案的，换成求解器思路（车辆发车时会用判题器完整的调度一遍，确保不会发生死锁），这样是能确保没有调参的情况下一定有成绩的，而且预测未来路况会更精准。奈何因为菜写的判题器判一次需要20s左右，就直接断了这个念头
- 针对决赛地图的有连通性高、车道数多、分布对称的特点，我们方案还是比较适应的。因为在车道宽和连通性高情况下不容易造成拥塞，还有依据车辆目的地和终点的分布特性，均匀发车策略也比较适合对称的地图。
- 针对github上的可视化开源 https://github.com/AkatsukiCC/huawei2019-with-visualization，做了一些魔改，主要是降低了绘制时间，修改了显示内容，改变了坐标计算方式，可视化添加了车辆身份显示(红色：优先预置车辆、粉色：优先车辆、蓝色：预置车辆、绿色：普通车辆)，因为修改了原先开源项目的可视化协议，使用了我们自己的json格式协议，就没有尝试把我们的版本commit上去。
- 为了考验方案的稳定性和防止参数过拟合，也生成了几份供调试的数据分布比较极端的地图。
