12-4

　　软件加加入一个新的分支，昨天最后的软件版本暂时搁置。把转弯的后边几个阶段完全改成初赛的算法，只保留了转弯前精确停车部分。在此基础上只做了简单的改进：转弯即将结束时，若后排传感器可以利用则利用调整，否则转弯不再依赖后排传感器。
　　传感器的冗余实际上确实只会有益处的，但是很可能极大的增加算法的成本，在转弯这个环节上，改善的余地已经不是很大，我们最终放弃了对于复杂策略的努力，我们选择简单，我们选择实用。
　　由于改进了精确停车的策略，转弯的效果也有了保证。
　　循迹的策略做了较大调整，简单介绍一下所谓的速度全局控制：

1. 正常情况下，小车高速行驶。
2. 前排传感器判断小车循迹时候偏移量(白线位于前排传感器的位置)，在允许的范围内(这个范围比较大，估计接近15cm)只做速度梯度调整，即在中心速度上一轮减速，一轮增速，同时限制增速的幅度，避免车速在这时被高速轮带起来。
3. 若偏移量过大，则一轮FASTSTOP一轮低速转动用以调整，同时降低整个车速，即即使调整至无偏移量时仍然维持一个较低的稳定车速。
4. 通过前后排传感器判断小车的姿态，即小车与循迹的白线是否平行，若平行，则取消上边的速度梯度，即只要平行，即使白线不在小车中间，依然不做调整，直线行驶，同时再次提速。
5. 即将停车时3级减速，前边已经介绍过。转弯结束后恢复高速标志。

12-3

　　这些天进展缓慢，甚至可以说是略有倒退...也就没有精力在这里整理自己曲折的思路...
　　加了侧排传感器，为了停车定位，当然，我们从来没有考虑过前后摆动来调整的停车策略，测排的传感器只会作为辅助手段进一步改善停车的精确定位。
　　简单介绍一下现在的停车策略：
　　决赛必然提速，提速的极限是满占空比，而此时，即使FASTSTOP也无法让小车很快的停下，于是有3级减速，离目标点距离两格和距离一格时分别减速一次，在目标点处前排传感器一越线再减速至最低速（PID能稳定控制的最低速度），由侧排传感器触发FASTSTOP。
　　最后总结一下这些天的曲折经历:也就是控制的两大部分，转弯和循迹。
　　转弯策略做了很大调整，目的是利用后排传感器保证转弯后小车的姿态，换句话说白线可以不穿过小车的中心(或者是传感器的中心)，但车必须与白线平行。利用两排传感器来控制转弯，这一短短的过程程序中一度写出了5个阶段，最终仍然存在考虑不周的地方，导致转弯很不稳定，也极大的影响了tracking循迹的效果...
　　循迹部分，高速时一轮FASTSTOP另一轮前行的调整效果并不好，因为调整量较小，速度一高就容易跑飞，因此尝试两轮正反转差速调整，由于PID对有正转转为反转的控制能力很差（实际上还有bug），于是改进PID控制函数，但是发现PID调整周期仍然限制着调整的反应速度(由于速度传感器精度有限，其采样时间无法很短)，同时又存在两白线交叉处的干扰等等问题，循迹的稳定性一直没有达到我们满意的程度...
　　晚上回来的时候，极其郁闷的我考虑重回初赛策略的可能性，因为小车现在的状态可以说是连初赛都不如了，而我们已经没有时间继续耗在这条暂时看不到光明的路上，控制只是比赛的一部分，我们必须为算法留出时间。最终决定放弃这些天在转弯策略上的尝试，重回简单...对于循迹，我开始构建基于FASTSTOP调整的循迹速度全局控制策略。

后补：事实证明，这天最后的决定对我们队伍极其重要，我们及时的避免了在弯路上的继续尝试，当然，那条路子也许能够走出更加强悍的控制算法，但是，已经不值得我们继续尝试和努力。

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度的大转弯也有很大的改善。至此，对小车的控制部分大体确定。

10-27

　　前些天找空旷场地调节了小车调速PID的参数，今天拿到创新实验室的场地上实测循迹效果时又发现许多问题...
　　今天调试时发现之前我们对转速传感器的误差估计过大，因而PID调整周期设置的也较大，今天改小调整周期后再次调整PID参数，循迹性能改善了不少。
　　循迹的策略也在不断优化中...
　　识别守卫点LED的接收管传感器也开始制作，不过由于组委会为防作弊将LED灯埋的过深，给接收管接收信号带来很大困难，这个问题还在和组委会协调中...

10-22

　　这周调转速传感器出了些问题，s12的累加器设置有误，今天最终被almighty搞定，然后开始利用串口调试PID参数。
　　这周之内我也在不断完善那个算法仿真平台，功能也不断集成化，可以实现随机地图、手动选择地图及公主点、遍历所有并给出评价指标的均值和方差等功能...
　　周三去了趟6B0，惊奇发现比赛场地被搬走....以后调试不能随心所欲了...

10-15

　　算法仿真平台我基本搞定，并进一步考虑评价算法的标准：用算法对92种地图依次仿真，得出所需前行单元格数和转弯次数，并加权给出综合评价指标。
　　和红志搞定左右两轮的转速传感器，示波器测试效果很好，这个我以为最艰难的硬件部分终于落实。

10-14

　　进一步拆开小车，考虑如何安装转速传感器...
　　我开始用labview试着编写算法仿真平台，希望可以和软件中的函数无缝连接...只是试着而已...当labview练手...

10-12

　　连续两天晚上调试小车，修改循迹时跑偏过大两轮正反转的策略为一侧车轮抱死、另一侧快转，避免了调整过程中由于地面摩擦阻力原因而使小车倒退的现象
　　小车转弯正常，给定任意目标点自动寻找路径正常。不过测试30*30最小方格行驶失败，距离太短速度过慢，导致导致停下转弯时车的中心并不在白线交叉处。准备暂时搁置调试先进一步考虑加装转速传感器。
　　晚上因为一个很傻X的问题浪费了很多时间，不过也顺便发现并解决了程序中其他的一些问题。
　　

10-10

上午去6B0测试昨天的程序，顺利完成小车坐标更新(越线后判断自身状态并更新坐标)并通过LCD实时显示坐标的试验，接着测试停车，转弯几个动作，结果良好。

10-9

和Almightly讨论系统方案的设计，由Almightly整理软件的整体框架，我接着编写判断坐标位置、转弯策略等算法。
不断的讨论、修改，最终定下第一个版本的系统方案:
每隔一个时间间隔（比如10ms）定时器中断执行控制程序段，主要包括：

1. 获取传感器参数
2. 更新小车坐标
3. 小车行驶控制(朝着目标点前行)
4. 策略算法(确定目标点)

此时，寻找公主点的策略与小车行走的控制两部分已经分离开来，由目标点坐标这一参数连接起来。软件思路逐渐清晰。

10-7

　　洪志和Almighty去中发采购，结果今天没开门....
　　下午我和Almighty去6B0调试小车。循迹的程序没有问题，只是循迹的效果太差，传感器虽然已经告诉单片机现在车跑偏了，但是通过基准速度(正常前进速度)下的差速(一侧速度增加，另一侧减少)仍然无法将小车调正。左右两侧车轮速度可在0-255间调整，我们测试一侧轮速为0另一侧为200时的转弯特性，发现转弯并不明显。我突然想到了两轮正反转时的原地转弯，于是策略改进为：当小车循迹跑偏并不严重时通过两轮线性差速纠正，当跑偏严重时改为正反转原地转弯以纠正。迅速修改程序，测试很成功，现在试验的效果是：当小车快跑出白线时，停下，原地转弯调回方向，继续前行...小车始终能够保证白线处于左右两轮之间，完全能够满足循迹的需要。
　　期间我们顺便测试一下小车原地转弯的特性，转弯过多时小车会偏离初始位置，但是转过90度基本处在"原地"，效果非常的好。
　　无奈充满电的电池电量迅速耗尽，下午共调试约1个半小时，小车第一次成功循迹。

10-6

　　硬件大体完工，上午先对母板的线路和其他排线进行了检测。侧边一排传感器异常，估计采样电路设计有误，后来想想其实纵向电阻只需要一排即可，没必要左右两排，遂暂时无视之。
　　下午我们带小车去6B0的实际场地上进行第一次试验，结果循迹失败...试验中发现不少问题，一是单片机IO的门限电压估计错误，二是几路用到AD/IO复用端口的传感器失灵。回实验室继续调试，那几个AD/IO复用的端口用作IO时始终不正常，原因未知，于是改用AD，再用软件将AD当作IO来用。单片机读取传感器信号正常。随即又发现软件上的问题...中秋之夜，最终实现小车循迹跑偏时的两轮差速，只是仍未成功循迹，实在实验室场地有限，而且电池又如此垃圾（至今仍未有一块充满电的电池，系统功耗又如此之大...）。
　　找空闲时间我整理了现有的技术文档，在自己的笔记本上安装了编译调试环境，下一步的重点在于循迹、定点停车和原地转弯的软件控制了...

10-5

　　我和红志继续制作识别地面白线的循迹传感器电路，并完成了与小车的连接。我先拟定了小车在场地中的位置和方向的参数，然后讨论了循迹的算法，Almighty开始编写处理循迹传感器信号的程序段。

10-4

　　我们先确定了单片机的端口定义，红志兄将电机驱动部分的外围接口部分搞定，并完成了母板和小车的连接，Almighty开始写简单的小车控制程序，我开始调试转速传感器。
　　晚上的时候，驱动小车的软硬件完成，小车第一次跑了起来！
　　回来后，Almighty的QQ nick改成了"First step. Unexpected"，我的也随后改成了"First step. Expected"。其实我先前预想的进度比这更快的，不过现在回想起来这进度还是快的有点令人恐怖...

10-3

　　开始动手制作。先检测了小车电机的基本特性，确定驱动电路的基本参数。
　　我开始设计制作母版的电机驱动部分，红志兄寻找合适的传感器，Almighty负责制作数码显示器，用以显示小车的位置及控制状态以方便调试。

9-29

　　领车，对小车进行初步测试。拆开小车分析其内部结构。讨论了一下宏观的进度和总体的控制思路及算法。初步计算了所需的端口资源及传感器种类。初步决定使用freescale的s12单片机。

9-24

我们小组进行了第一次正式的讨论，基本确定的我们的目标和参赛策略。