6.1 开发调试工具
系统开发调试使用了Metroworks公司的Code Warrior 3.1开发软件，另外为了调试方便，开发了LCD路面状况显示模块，电源电压检测模块，手动设置装置和外部状态指示单元。
此次智能车大赛选用的软件开发平台为Metoworks公司的Code Warrior 3.1开发软件。其使用界面如图6.1所示
CodeWarrior3.1 CodeWarrior3.1 的功能非常强大，可用于绝大部分单片机、嵌入式系统的开发。支持多种高级语言如C，C++，JAVA等，还支持大多数微控制器的汇编语 言。开发环境界面统一，运行许多通用的桌面或嵌入式微控制器。另外还可以通过加入插件来扩展其功能。具体使用时，用户可在新建工程时将芯片的类库添加到集成环境开发环境中，工程文件一旦生成就是一个最小系统，用户无需再进行繁琐的初始化操作，就能直接在工程中添加所需的程序代码。
本次设计中我们选用的编程语言是纯汇编语言。利用软件本身自带的一些功能，可以很方便地进行诸如监视寄存器状态，查看内存内容，修改PC指针，修改RAM内存，设置断点等一系列的调试工作，从面快速地找到程序的问题所在，以便更改。下图6.2即本设计中所用的程序Debug界面。
在源程序员编译、连接通过之后就可以程序下载了。下载之前，先将单片机上已经存在的程序擦除，即在监控程序界面里先后键入E，Q，F；然后点击“传送T”选择程序文件中的bin目录下的Simulator.abs.s19文件，即可将其烧入单片机，完成程序的下载。
6.2 LCD调试模块
为了现场调试方便，开发了LCD液晶调试模块。选用的LCD型号为RT12864-M。实物如图6.4所示
调试时可以能过这个LCD显示器来实时地显示出路面的黑白状况，这样就可以很直观地看到图像采集的合理与否，一目了然，很直观。
6.3 状态指示
在程序中使用开发板自带的PB灯作为速度指示装置。在赛车的整个运行过程中可以看到PB灯一直在闪烁。有时候程序或是CS3020出现了问题，PB灯也是个很好的报警系统，因为这个时候PB灯的指示不正常，通常是全亮或是全灭。正常时，PB灯会随着赛车的加减速灯亮的个数会有规律的变化。另外在程序中把PB灯用作了识别十字交叉的指示灯，即在过十字交叉的时候，PB灯会全亮。
6.4 键盘调试
键盘调试模块是和拨码开关配合使用的。具体应用时主要是用键盘来控制速度和舵机控制量。使用一个开关作为速度和舵机控制量的选择项。0键是确认键，只有当0键按下时，键盘控制量才开始起作用，如果在0键按下之前不止按下一个键时，以最后一个键值为准。当开关拨向高电平时键盘输入用来控制速度，在程序里，设置一个基准速度值，不妨设为30（/64），当1键按下时，再按0键时，这时的速度值控制量就变为31（/64）……以此类推。键盘对舵机控制量的改变和对速度的控制基本一样，只不过幅度相对较小。这样做的一个好处，就是一个控制算法成熟之后，可以实现现场脱机调参，不必每次都要把程序重新烧一次,而且还可以一次记录多组数据以备以后查看比较，改进算法。
6.5 AD参考电压的调试
本次设计中使用LM336稳压器的输出来作为AD的基准参考电压。考虑到不同的光线环境阈值的不同以及更改阈值的便捷性，在这一模块电路中使用一个5K的滑动变阻器来扩大可选的AD基准电压的范围。实验证明，5K电位器在本模块电路中的可调电压范围为0—5V,完全可以满足要求。
经过大量实验，AD基准电压定为2.7V。因为在这个参考电压下，AD模块能最大限度地区分出黑白点，而且在试行的过程中不会发生意外的抖动而冲出赛道。在实验中还发现，如果这个参考电压偏离选定的AD基准电压超过0.2V时，就会影响到采集图像的准确度。调试时发现，近处几行的图像受到的影响相对较小，基本上可以如实反映出黑白点的变化，但是中远几行就会出现比较明显的错误，特别是最远处的几行，有些地方甚至黑白不分。从理论上讲，如果AD参考电压不适当，会出现两种情况：一是AD参考电压过大，导致黑白点的阈值相差不多，即黑白点没有明显的差别，这样此块区域就可能被识别成全白或是全黑。还有一种情况是AD参考电压过小(不能低于视频信号的电压峰值，否则会造成转换失败而得出错误的结果)，这样黑白点的阈值相差太大。这对于已经调试好的程序来说，会把某些白点当成黑点，或是把某些黑点当成白点，而且这样很易受光线的影响。
6.6 十字交叉的处理
对于十字交叉的处理，设计过程中随着调试的进行总共走过三步：
第一步：单行十字交叉法
即在一行中发现有十字交叉现象就认为本场图象有十字交叉，从而转为十字交叉子程序。编程时，每行扫描中中如果有两个黑点的间隔超过了2个点，就认为本行中有十字交叉现象。这种算法的缺点是，单行定十字交叉有很大的局限性，调试时经常发现出现在直线十字交叉灯亮的现象，虽然对赛车的正常行使不会造成太大的影响，但是一圈下来识别错误太多，也即指示灯亮的太频繁，累积下来会对车速造成很大的限制。
第二步：多行十字交叉法
这是对第一步的直接改进。不同之处在于，本场图像中有四行或是四行之上的有十字交叉现象才认为本场是十字交叉。这样做虽然相对于第一种算法比较复杂，增加了处理时间，但是识别十字交叉出错的概率却大减小。但是这样也会带来一定的问题，我们在计算某行黑点的中心位置是用黑点的右边界减去该行黑点个数的一半。下面分三种情况来分析一下这种算法在处理十字交叉时会有什么局限性。以下的三种情况都是假设小车视野由下向上。
1．如果进入摄像头视野的是一个正十字，如图6.5所示。这种算法在很大程度上可以正确识别出十字交叉，并做出正确的判断。
在这种情况下，摄像头扫描到黑点是连续的，那么按照上面所提到的那种算法，这样计算出来的黑点中心是在直线上，那么此时小车就可以顺利地通过十字交叉。
2．如果进入摄像头视野的是一个左斜十字，如图6.6所示。在这种情况下，小车也可以通过十字交叉，但是按照本设计中所用到的黑点中心计算方法，远处的黑点右边界在直线上，而远处行中的黑点个数较少，这时由黑点的右边界减去黑点个数的一半计算出来的黑点中心明显偏左，所以小车会先向左抖动一下，然后返回到直线上来。
3．如果进入摄像头视野的是一个右斜十字，如图6.7所示。在这种情况下，小车就不能通过十字交叉，因为按照本设计中所用到的黑点中心计算方法，远处的黑点右边界在水平直线上，而远处行中的黑点个数较少，这时由黑点的右边界减去黑点个数的一半计算出来的黑点中心明显偏右，小车会把这种情况识别为急转弯，所以小车会很快减速，并转向水平线上，偏离正确的轨道。
第三步：鉴于前期两步的十字交叉识别都有一定的局限性，我们在第二步的基础上提出了第三种思路。即如果某行四行或四行之上识别出了十字交叉（此行中黑点不连续），就先确认此场是十字交叉。然后继续往近处行进行搜索，直到找到某行不是十字交叉（即黑点是连续的一行），以此行以下的几行作为十字交叉处理的图像依据。这样就可以很好地解决前面两步算法的局限性，而且实验证明小车在通过十字交叉时再也不发生意外的抖动，也会出现急转的现象，达到了预想的效果。
