11-29

　　昨天讨论转弯循迹若要优化，则必须知道小车的姿态，所以必须增加一处传感器，后排或者侧边。于是，红志昨晚搞定后排传感器。
　　今天测试，明显看到姿态调整的优势，不过转弯策略变得愈加复杂，优化余地仍然很大。而且考虑后排传感器可以作为循迹tracking的优化。

11-26

　　决赛赛题出炉...
　　昨晚组委会召集各个进入决赛的队伍讨论的时候就已经确定了改变赛题的想法，这意味着我们对于算法的研究几乎全部浪费...我和Almightly极力阻止赛题的改动，并提供了一些解决方案，却一一被否决，原因很简单，一是不希望碰撞，二是为了保证观赏性。讽刺的是碰撞的问题正是我们在赛题出来之后就一直担心的问题...
　　从论坛上组委会的回复可以看出，显然他们对我们的算法不屑一顾：

我想在您领奖时，如果听到观众议论说"这种东西，我也能做"时，心里一定不好受吧？

　　不想解释。他们不知道我们的算法是针对92*8种情况做的统计最优解，他们也许只认为我们所谓的算法只是在8*8的地图上对公主点做横竖斜线的排查，他们看不到我们对路径的优化，只是在这个初赛的地图上并不能看出其全部策略而已。无所了。
　　还好我灵感突发，想到对称这种方式...也最终在决赛赛题中采纳，使得决赛赛题不至于和八皇后毫无关系，也使得我们的仿真平台不至于一无所用，尽管赛题改到这一地步，仿真的意义已经不大...

11-25 毫无悬念

　　预赛，毫无悬念。
　　比赛前我看了看地图，很中庸的一张地图，虽然用不上优化的算法，但也不会对控制提出很高要求，估计所花“时间”是处于平均水平，小车的轨迹已经在我心中...
　　小车刚发出不久就跑飞，重置。惊奇的发现前排循迹传感器一侧已经掉下，处于悬臂状态，让红志找透明胶，同时觉得问题不大，遂小冒风险直接开始。很快完成任务。
　　毫无悬念，初赛而已。

11-23

　　测试了一些特殊算法应用的地图以及预测时间最长的地图，同时也发现了一个小bug，再次优化了转弯的控制算法，收车，准备预赛。

11-22

　　上午出现诡异问题，总是出现随机性错误，到了晚上再调又一切正常，错误无法重现...
　　（补：1天后找到原因确实是受外边自然光的影响）
　　调试中发现小车的循迹和转弯并不想原来一样稳定，估计是传感器安装位置影响到小车重心，于是再次优化循迹转弯程序。

11-21

制作出第五代守卫点探测传感器，下午检测并匹配电阻后仍然发现对光过于敏感，于是加了不少遮光措施...

11-20

制作出第四代探测守卫点接收管传感器，采取10管并联再接采样电阻，由于间距过大，并不十分可靠，估计有5%的可能性经过守卫点时却检测不到。
调整时序后测试算法通过，形成修改传感器之后的稳定版本。

11-19

　　利用LED显示变量状态和单步调试终于找到问题所在：对结构体中定义的数组进行操作的时候超出了数组的范围，于是改变了结构体中其他成员的值！
　　于是，电设软件的第一个稳定版本诞生！
　　开始移植改进算法，遇到很多问题，根源仍然在于传感器信息不同步且循迹传感器超前于探测守卫点的接收管传感器，使得对地图的处理不得不滞后一个动作（比如走动一格或者转弯，因为延时并不可靠），这就导致软件上对地图的处理(map_process)和目标点获取(get_target)的时序出现很大问题。晚上试图从软件上来调整时序，并没有太大的改善，即使改动成功，软件的逻辑也比较混乱...
　　回来后便决定将探测守卫点的接收管移动到循迹传感器之前，使得硬件上的时序和软件相吻合。

11-18

　　昨晚得到通知场地LED灯已经可以手动配置，今晚便去调试策略。策略的算法本身在labview中经过验证，应该问题不大，但策略和控制的接口需要做不少调整...而且还有很多无法预见的问题...
　　首先遇到的一个大问题是传感器信息之间以及他们与算法之间的同步问题，如果算法每1ms或者10ms执行一次算法，此时传感器的信息未必准确，比如在经过守卫点时，守卫点灯的接收管接收到灯光的时间很短，即传感器得到“正确信息”的时间很短，而在其他时间内再次执行地图处理程序段就会发生错误。这个问题是通过用车上LED显示器监视地图状态数组(spot)发现的，发现后即改动地图处理程序段的执行触发时刻，将其改为下一次越过白线时处理上一位置的地图信息（后想到转弯完成也可以执行），同时传感器的信息一旦改变就保护起来，直到经过处理（程序上的处理有点像PLC中的自锁，呵呵）。
　　到这里，小车终于第一次在比赛地图上成功完成任务。
　　然后又发现一个诡异的问题：某种地图（空行空列处理）下小车能成功完成任务，但却与仿真的结果不相同（步数增加很多）。简单调试发现空行空列的处理有问题，但这种地图下在仿真中若去除空行空列的处理则无法完成任务。诡异把？无奈时间已到，欲知原因如何，且听明天分解。

11-14

　　今天顺便去测测场地公主点灯改造后对小车的影响，可惜场地仍然不能正常显示完整地图-___-
　　 有趣的是，在最后的时候“labview之父” Jeff Kodosky居然来创新实验室参观，好像对我们的小车很感兴趣的样子，特意让我多跑几趟...然后我告诉他我用labview做算法仿真，显然他对此更感兴趣，"激动"的给我和小车照了几张像...真是一个意外:)

11-10

　　测试车底探测守卫点的接收管，发现收到循迹发射管的影响，遂在中间加了一个挡板，搞定！
本想再跑一次比赛地图综合测试一下，无奈比赛场地又歇菜...LED灯无法正确配置亮灭...


后补：电设论坛上组委会又传出消息，场地公主点灯光更换：

根据近几日参加调试的选手反馈，公主点的灯并不能够被稳定的识别。为此本周末将对公主点灯光进行更新。

　　为什么之前无视我们的反馈-____-，虽然我们预见到这个公主点灯还会调整，但为了不影响进度，还是提前制作了接收管传感器，并与改动前的公主点等做了匹配。虽然这样的改动对我们应该影响不大，不过也耗费了红志兄不少脑细胞啊...

11-3

　　对转弯策略进行了较大的修改，弱化了转弯对于停车位置的依赖性。
转弯分为3个阶段：

1. 转弯第0阶段。停车，每次转弯前FASTSTOP停车。
2. 转弯第1阶段。摆脱原来的白线，进入与之垂直的另一条白线。
3. 转弯第2阶段。对目标白线找正。

　　 其中第1阶段的策略进行的重写，第1阶段结束的标志定为：前排传感器信号无效(not valid)或者全黑(lost)，无效包括前排传感器横跨垂直的两条白线的情况以及前排传感器获取白线位置从一端突然跳到另一端的情况（忽略了传感器出现异常的情况，因为这么久的试验中似乎传感器一直很强悍）。
　　这种改动对于旋转180度的大转弯也有很大的改善。至此，对小车的控制部分大体确定。