资源在这
http://download.csdn.net/download/hello_world12138/9910603
2016/7/3
1． 今天发现一个比较尴尬的问题，之前摄像头采集到的图像和现实中我显示的图像的旋转方向根本就是反的，而且是各种颠倒。这也是为什么之前战舰例程使用的LCD刷新是从上往下，再从左往右刷新的原因，所以，我在存储像素点的时候，需要按照LCD上使用的方法存储，才能够正确的存储图像。
2． 现在实现了图像的正向显示，也就是，将摄像头采集到的320（宽）*240（高），进行隔行扫描，隔4列扫描。
3． 但是，摄像头的图像是从上往下再从左往右，所以，就要将原来的宽变为高，原来的高变为宽，也就是成为120（240/2列） * 80（320/4行） 也就是数组定义为cutImg[80][120]。
4． 现在使用的LCD扫描方式为默认的方式，也就是从左往右，从上往下，这种方式是我们常识中的扫描方式，那么现在我将数组反转后，直接将数组按照正常的顺序依次输入到LCD中，如果LCD中能够正确的显示，那么就说明我转换成功，接下来的数字图像辨析都可以用这个数组来做了。
第一个图像算法方案：边沿检测，最小二乘法
5． 二值图像处理问题：对每行图像中的黑线的相对位置的处理叫做行数据处理。对每行中黑线位置综合分析再现黑线的形状。
6． 对一行中的数据，进行提取黑线的算法使用：边沿提取法。该算法对黑线反应灵敏、准确度高、抗干扰能力强。
7． 边沿提取算法步骤：对于每一行的像素，从左往右，检测高电平到低电平的负跳变，那么这时就检测到了左边的黑线边界，接着继续开始往右检测，出现低电平到高电平的跳变时，就出现了正跳变的时候，就检测到了右边黑线的边界。（这里的高电平和低电平分别指代白色和黑色像素值）。 这时候就可以通过黑线的位置比较与摄像头轴线的偏离，那么就可以将相对的偏离计算出来。
8． 图像帧的处理：虽然边沿提取算法可以粗略的控制小车，但是当出现其他干扰信号时，可能会影响控制信号。那么解决办法就是将上面获取的每一行像素中黑色点位置进行干扰滤波，也就是帧处理。
9． 在帧数据的处理中，采用的算法是：提取连续段的方法，去掉图像中无用的错误数据。
10． 连续段提取算法的大致流程：1）提取以行为标准，如果隔着某些行，各个黑点之间的垂直距离是某种固定或者接近固定的阀值，那么这些连续的点，就构成了一段连续段。最好提取三个连续段。2）提取三个端中，再在其中最为可靠的端，例如上图中的连续段3，也就是这个段中，所包含的连续点越多越可靠。3）然后将可用端连起来，成为一个大段。可以将不可靠段使用插补的方法归算到大段中。
2016/7/4
1． 今天继续二值图像分析算法的研究。
2． 基于昨天的算法，接下来可以使用三个变量对飞行器进行命令数据包的发送。
3． 数据包包含三个信息：part_1：检测到的图像斜率，作为主要的控制依据 part_2：检测到的飞行器相对于黑线的位置偏移，作为辅助的控制依据part_3：图像的前端图像斜率，用于预测下一阶段的动作。
4． 实际中是否能够使用这三个变量还不确定，现在只是理论上的建立，找到一个可行的方案。
5． 
6． 
7． 经过二值化和动态的阀值调整，可以获得噪声较小的图像，而且因为赛道也是黑线白底，所以滤波算法并不必要。
8． 如果出现无用的轮廓，那么这个轮廓就用上面总结的斜率段的获取方法，可以滤除。获得最可靠的那一段，其他不可靠段需不需要插补进去可以考量。
第二个图像算法方案：采用边缘检测算子
1． 感觉运算量增加很多，还是第一个算法比较好理解可靠。
遗留问题：如何自动根据光照强度设置二值化的阀值？
1． 先把自动计算阀值的算法放一放，因为已经做了按键控制阀值，虽然不是很智能，但是最起码一种解决方案已经完成，现在主要任务是完成摄像头对黑线的辨析和斜率判断。
2． 第一步：检测图像的正负跳变，确定边界。但是现在做的不是无用功，那么就要预先能够理解最小二乘法的是什么算数原理和如何使用，特别是它需要什么样的数据，就可以计算出斜率，这个问题是首先要解决的。
3． 那么在我大体了解了程序化的最小二乘法以后，我知道只要能够存储到边界黑点在每一行中的相对位置就可以。
4． 中间测试了sobel算子的效果，这个算子其实也需要一个从左往右检测以及梯度阀值的设置，而且效果并不是那么好，所以放弃这种方法，还是使用之前的思路。
5． 第一步完成，以及能够比较准确稳定的获取各个左右黑点的位置。
6． 
![]()
7． 
8． 上面的图片被右转90度了，串口打出来的数据分别是左右边边界的黑点相对位置，要是粗糙的用这个数据，也可以计算出斜率，但是不可靠。
9． 第二步：对采集到的位置进行一定量的数据采集，经过分析，获得较为理想的边界位置数组。
10． 第三步：在获得的边界位置数组中，将有效的连续段提取出来，供后面的斜率以及其他位置判断使用。
2016/7/5
1. 今天做边界的有效段的截取，先做线的边沿检测，如果没检测到某一边也需要明确的指示出来。
2. 
3. 上图是测试过程，将左右边界同时检测到，同时消失，和某一边存在的情况都测试了，说明段截取函数的开始阶段的功能是正常的。
4. 接下来做昨天的步骤。
5. 第三步：现在获得的两个边界的位置数组的偏差之间的误差不超过2，那么这样根据前三个点的阀值，就可以确定基本的点与点之间的增量关系，有波动也不超过2，为提取段提供了依据。
6. 现在采用的误差为3，因为飞行器有震动。
7. 现在实现了单独采集左侧边界的最长有效边界。
8. 
9. 接着将右边界也加入进去，取出最有效的段，先把斜率给算出来。黑线距离中线的偏离应该也不复杂，可以在后期做。
10. 第四步：将右边界的有效段和左边界都融合提取，取出最为有效的段，然后用最小二乘法算出斜率。
11. 现在做出了左右边界两个边界比较选取最长有效段。
12. 对于最小二乘法的理解：
13. 还是不怎么理解，但是根据上面的式子，编程其实很方便。
14. 问题：要是有效段没有检测到，或者是只检测到一个点，都认为是失败，还么做处理。
15. 处理完毕了以上的问题。
2016/7/6
1． 继续上面的第四步，现在做到的是，我使用上面最小二乘法的求到的斜率的倒数，也就是tan（B） = （位置偏移） / （竖直方向单位，这里为1），那么用反正切函数，就可以算出角度，但是这个角度不是斜线与X轴的夹角，而是斜线与Y轴，或者说是中线的夹角。只是反向需要矫正。
| 左偏 | 右偏 |
| 角度为负数 | 角度为正数 |
| 注意：角度是相对于竖着方向的图像中线而言！！！ | |
3． 上面这个问题可以用正切的函数解释。Tan值越是大，角度越接近90°，角度变化范围越是小。
4． 现在考虑一个问题，真的需要计算出角度吗？因为计算出的角度并不是以一个线性的方式变化，那么这就给我的解析带来难度，我难道还要分析到底多少度，我才发送转向指令？所以我认为还是废弃角度的运算，直接用斜率，对斜率稍作处理，这样在辨析方向时，方便准确。
5．
6． 现在获取到的斜率如图所示，那么斜率也可以看做是直线偏离竖直中线的距离
| 左偏 | 右偏 |
| 斜率为负数 最小 -30左右 | 斜率为正数 最大 +30左右 |
| 注意：斜率是相对于竖着方向的图像中线而言！！！ | |
8． 第五步：采集大量斜率，获得范围和规律，进行斜率的筛选和分割。
9． 在准备使用while中定时采集的时候碰到问题，这个问题想不到还真让人头疼。我采集完最大有效段，然后给了最小二乘法函数去算出斜率，但是算完了我竟然没有清空最长有效段和最长有效长度，这样，要是一次就采集到了最长的有效段，那么下一次一比较，之前旧的最长段就不能被代替，我就说怎么只能采集一次，最多就三次。
10． 还有值得一说的，这次比赛过程中我才向别人学会了keil的debug，简直了，以前都是在暴殄天物，这么好的工具不用，竟然用串口打，唉。这次错误也是用这个调试，就很快找到问题了。
11． 接着继续分析斜率，并且做分割。
| 左侧倾斜 | 右侧倾斜 |
| -30° -2.2- -2.5 | +30° 2.2-2.5 |
| -45° -4.0 | +45° 3.3-3.4 |
| -60° -7.0 | +60° 7.0-7.2 |
13．
14．
15．
16．
17．
18．
19． 那么其实数据斜率的范围在正负20左右。其他在Debug时出现的不规律的数据，都是乱码，随机数，我现在需要先把斜率K的值做好充分的出错处理，让它的输出变得稳定，有规律。
20． 筛选分割终于做完了，但是现在的命令格式还没有定下来，那么我只能做到，使用函数接口，获得一定的返回值（宏），便于后面确定命令格式。
21． 这样，直线的循迹基本就做完了，做硬件的也把要画的板子做出来了，现在需要我测试所有的引脚，并且更改摄像头引脚，让打出来的板子调试完成。
22． 第六步：调试最小系统版。
2016/7/7
1． 今天开始上面的第六步，调试最小系统版，由于最小系统版和战舰的板子，对摄像头的引脚定义不一样，所以需要进行更改。
2． 测试过程中，因为将TX RX也作为普通的IO口，所以使用普通的推挽输出。
3． 出现一个问题，没有很好的考虑外部中断的出发引脚，现在板子上把原来的PA8接成了PC8，这个不知道能不能映射过来的，不然就尴尬了。
4． 今天把最小系统版全部测试完毕，硬件方面没有问题，那么为了开发效率，我还是转战战舰的开发板，毕竟有LCD显示出来，便于调试，最后再全部移植到最小系统板中，因为引脚都修改完了，所以最小系统板的工程中只需要添加相应的算法即可。
2016/7/8
1． 今天开始继续从战舰上开发。
2． 第七步：完善直线检测，增加直线（不论有没有偏移）的中线，与像素高度一半的交点，相对于屏幕中线与高度一半的交点。
3．
4． 那么现在如何检测，是个问题，需要分几种情况和位置。
5． 我的思路是：首先滤除左右边界一开始的0点；
6． 然后，使用获取最长有效段的函数接口，获得两个边界的最长有效段；
7． 在获得两个边界分别的最长有效段以后，比较两者斜率，要是不相近，返回；
8． 要是相近，再根据两者的斜率，开始认为增加边界长度，直至两边界与高度1/2相交为止；
9． 左右两个相交点的中点，距离图像中线的水平为止即为偏移量！
10． 这个思路还是大体的，里面的具体情况我还没有全部测试完毕，需要写出接口的原型才能具体修改。
11． 现在做出的检测是，最理想的情况，两边都检测到了，而且两边的线都切到水平中线了，这时候可以算出偏移量。还做了一种情况是，当左边或者右边没有检测到边界的时候，将偏移量置为一个限定的最大值，然后返回相应的宏。
12． 在实现斜线延长计算出不存在交点的时候，我发现可以用一种方法求出这个直线的几乎所有情况，也就是统一使用延长的方法，反正可以计算出斜率和常数，直接代入公式不就能够求出了？
13． 那么要用到这个，必须知道这个斜率是出现在边界检测时的哪个位置，这样才能判断与真正的中线的相对坐标。
14． 如上图，向下为X轴，向右为Y轴，那么第一个与网友的Y轴相交的就是常数b，那么我认为最长有效段的第一个有效节点对应的高度为有效高度，水平中线相对于这个第一个有效节点的位置，就可以算出与水平中线交点的位置。
15． 那么以向下为X轴，向右为Y轴，再求出来的是反斜率，正好就可以满足，y = kx + b，其中y就是一行像素中的水平位置。直接将x经过测算就可以实现随意坐标的水平位置的计算。
16． 注意！一定要根据相同的X值，计算出Y值才可以，不是左右边界有效段的第一个就能相互计算了的，这样根本不对，他们很有可能不在一个水平面上，完全没有意义！！！
2016/7/9
1． 昨天晚上做的使用斜率和常数计算出不存在的点的操作，还存在一些问题，好像数据不是很对劲，今天继续测试这个算法，应该是可行的，就是还没做完善。
2． 现在发现，使用斜率计算出交点坐标很不合理，因为采样的间隔比较大，所以我采出来的斜率在比较倾斜的时候，整个斜率会变得很大，这样误差会很大，根本不能稳定的计算出交点和偏移量，一旦斜率大了以后，根本就是错误的动作！
3． 所以现在使用一种新的思路。
4． 我的思路是：首先滤除左右边界一开始的0点；
5． 然后，使用获取最长有效段的函数接口，获得两个边界的最长有效段；
6． 接着，依据短一点的最长有点段的某个点，和长一点的最长有效段，在水平位置的偏差即为线宽！注意需要获得左右在同一水平面上才能有效，不然继续取其他点，直到两边最长有效边均可以取到为止。
7． 获得线宽以后，使用整个图像的中点位置相对较长最长有效段的距离，然后考虑一下线宽，就可以计算出斜线的中点距离图像中点的位置了。
8． 注意：最长有效线段的高度位置和最长有效线段到底要不要做清空？
9． 现在获得了线宽，接着做下面的。
10． 已经完成了检测斜线相对于屏幕中线的偏移，而且斜率之前做完了，那么现在的直线循迹基本实现了，我可以向上位机发送斜线的斜率和斜线的相对位置偏移，这样可以精确的描述当前直线的位置。
11． 第八步：我要做出错处理，将直线循迹的各种情况全部模拟一下，做好出错处理，然后就把最上层接口一下的接口写完，等到与上位机通信方式确定以后，就可以做最上层的接口。
12． 基本处理完了第八步。
检测直角 从左上直角开始！
1． 开始新的检测了，就是左右直角的检测，如何检测我在网上没有看到类似的代码，但是经过不断的比划，我感觉算法可以使用之前检测最长又掉段的算法，因为终究还是要在检测到的基础上，才能进行判断。
2． 第一种情况，整个直角，基本保持理想的水平垂直位置，那么从直线慢慢往上，开始检测不到某一边了，而另一边的有效长度就比这边长，要是这个有效长度的斜率或者说是增长的方式几乎为垂直的方向，那么就可以大体断定检测到了直角。
3． 也可以先看数据再说话，我先把采样到的左右边界位置看一下，是不是有什么特别的地方，然后再做判断。
4． 几乎理想的直角
5． Left: 0 0 0 0 0 30 29 29 28 2828 27 27 27 26 26 26 25 25 25
6． ******************
7． Right:0 0 0 0 0 0 0 0 0 0 71 7171 70 70 70 69 69 68 68
2016/7/10
1. 今天基本没写记录，其实检测直角很简单，我之前的接口，比如检测直线最长有效段这样的接口，复用一下，直接通过最长有点短的长短和相对的位置就可以判断出直角的位置，但是弊端是，这个直角不能偏差过一定的角度，大概在45°以内，就可以捕获到，这个范围应该还是能够被飞行器接受的，因为之前的直线循迹的时候，我会发直线的偏移量和直线的斜率，经过这样的调整，应该还是能够满足+-45°以内倾斜的直角的检测。
2. 由于飞行器可以做转向，那对于摄像头来说就没有左下和右下直角这一说，所以只要可以检测左上和右上直角就可以了，现在还可以通过命令来制定是单纯检测左上还是右上的直角。
3. 现在又出现问题，因为飞行器飞的越高，分数就越高，但是我之前使用的线宽都是很宽的，根本就没有代表性，所以在实际测试的时候，直线倒是可以，但是用来检测直角的规律就不适用了。原因在于我把竖直方向压缩的很厉害，我首先隔了4行从摄像头中采样出来，再隔4行采出来的图像二次采样，进行处理，这样的话，直接就缩小了16倍，很多细节部分，在飞行器较高的时候，会被无情的忽略，那么这样直角的检测也就废了。
4. 解决办法：将数值方向扩大一倍，也就是一次采样的时候，是隔2行采样的，后面依旧是隔4行采样，幸好之前的宏定义做的比较周全，我基本就就改了宏定义，就直接扩展成了120*160的屏幕，二次采样出来，用来数字图像处理的图像大小为120*40。
5. 现在测试才发现，之前的直线水平偏移做的不是很好，一定要两边都要被水平中线检测到才能做出很好的检测判断。
6. 注意：是不是需要确保一行中只检测一次做跳变和一次右跳变，其他第二次遇到则作废？现在使用的就是一行就检测一次左跳变，一次右跳变，而且是以第一次为准。
2016/7/11
1. 今天再次测试直角检测，确保检测比较及时灵敏，这样就可以进行下一种图形的检测了。
2. 直角又发现问题，例如当为左上直角的时候，倾斜一定角度以后，立马变为检测到右上直角了，这个原因在于，我使用了最长有效段的比较长短的方法，而出现直角的时候，有时候正巧会出现变成检测另一种直角的状态，出现错误的检测。
3. 左直角需要取第一次边缘为准，其长有效段的最后几个，特别是左边界不能碰到左屏幕，就是最好左最长有效段不能靠到左边边界，这样会影响检测结果。
4. 右直角需要取第二次边缘为准，其最长段的最后几个，特别是右边界不能碰到右边屏幕，也会影响检测。
5. 其实这个问题是我要求太苛刻了，我想直角在转过不到45度的时候，还是能够检测到它是原来的直角，但是，如果飞机飞的稳定，循迹动作好的话，这个问题根本就不是问题，我现在还是先用简单的过滤方法，将两边最长有效段的最后一个位置限制，不能靠近边界！！！即使这样会丢失一定的动作检测，但是可以确保左直角就是左直角，右直角就是右直角，可以当这个状态是正在转弯。
6. 注意：直角检测时，对于检测的错误，有两种解决方案。1）增加检测的限制条件，确保直角的竖直边不会碰到边界，这样可以保证动作的正确性。（准确性增加，检测范围减小，足够智能便捷，可以不设置固定赛道，准确检测）2）不增加限制条件，但是在循迹的时候，使用定死的循迹轨道进行循迹，也就是，知道跑道的下一个检测的是右直角还是左直角，然后直接检测，检测到类似直角就返回检测到状态。（准确性减小，检测范围增大，不够智能便捷，需要比赛时设置）。
7. 权衡利弊，还是先使用第一种解决方案，确保准确度。要是实在飞行器不稳地，需要增加检测范围就使用第二种解决方案。
8. 左直角和右直角不同，检测时，左直角使用不覆盖的边缘检测方法，而右直角使用覆盖的边缘检测方法。原因在于：左直角的竖直边在左边，要主要保存图像左侧的边缘，而右直角就相反。
十字路口检测
9. 以下是标准的十字采集到的图像边界
10. Left:50 50 50 50 50 51 51 51 5151 52 52 52 52 52 52 52 53 0 0 0 5353 53 54 54 54 54 54 54 54 54 54 55 55 55 55 55 55 55
11. ******************
12. Right:63 63 63 63 64 64 64 6465 65 65 65 66 66 66 66 66 66 0 0 0 67 67 68 68 68 68 68 68 68 69 69 69 69 69 6969 69 69 69
13. 左偏十字
14. Left:30 32 34 36 38 40 42 44 4648 50 52 54 56 58 60 62 58 49 4030 21 12 3 7778 80 82 84 86 88 89 91 93 95 97 98 100 102 104
15. ******************
16. Right:45 47 49 52 54 56 58 6062 64 66 68 70 72 74 108 100 91 83 83 6657 48 39 31 22 13 4 100 102 103 105107 109 111 112 114 116 117 0 LCD ID:5310
17. 右偏十字
18. Left:72 70 68 66 64 62 60 58 5 13 21 28 36 44 44 42 40 38 36 34 32 30 28 26 24 22 20 1816 14 12 10 8 6 4 2 0 0 0 3
19. ******************
20. Right:87 85 84 82 5 13 20 28 35 43 68 6668 77 85 59 57 55 53 51 49 47 45 43 41 39 37 35 33 31 29 27 25 24 22 20 18 1614 12
21. 检测十字路口的思路，检测十字路口的关键在于，如何在一个检测到的边界中，将无用的斜率数据进行过滤，进而将这段无用数据的前后两个有效段进行比较斜率，如果斜率相似或者近乎相同，那么认为是一条直线，只是中间被某些东西遮盖掉了，那么这个遮盖掉的东西就是十字路口的横向的黑线。
22. 十字路口检测完毕。
2016/7/12
1. 今天做了十字检测，已经可以稳定检测了，但是算法的稳定性和健壮性堪忧，所以只能到时候固定的检测一种状态，直到检测到为止。
2. 现在完成的有竖线的检测，斜率的输出和水平偏移量的输出 左上和右上直角的检测 十字路口的检测
3. 还差一个起点位置的检测，因为这个起点位置的图像比较复杂，整个图像是圆形和直线的混合图形，外围还有黑色细圆包围，形成一种树轮状。
4. 问题：现在还有没有做完的就是，将YUV分量检测更换为RGB565检测，因为我今天测试发现，跑道的反光很厉害，也许是我们是在晚上，日光灯的影响比较严重，但是这也间接说明这个YUV是不完善的，存在比较严重的干扰问题。而如果更换为RGB检测，他不是单纯靠着Y（亮度分量）作为基准的，而是依靠颜色，但是我担心的是，RGB有可能还是没有什么用，因为反光时，完全可能被认为是白点。
5. 明天的两个重要的任务：1）修改YUV方式，变为RGB方式，实现采集的稳定性。 2）完成起点位置的检测，需要检测的方面有，起点中心的偏移位置，和斜率。
2016/7/13
1. 今天趁着太阳不错，自然光不错，开始在模拟跑道上测试摄像头，昨天晚上在灯光下，效果非常差，日光灯的反光太严重了，但是今天白天太阳不错的情况下，或者说自然光可以的情况下，测试采集的图像和动作还是差强人意的，同时需要增加一点二值化的阀值，大概在130，就可以比较完整的采集到图像的信息，检测动作也基本正确。
2. 今天开始做最后一个关键的图像检测，就是起点圆的检测，这个检测至关重要，因为这关系到了起点时的悬停参照和终点时的准确落地，所以要做好这个比较有难度，不仅要做好圆的位置检测，而且要做好位置偏移的检测和斜率的检测，因为起飞时不能出现偏离很大的情况，最好就没有什么偏差。
3. 检测方案：1）依旧是检测边界的方法，通过增加边缘检测时，后续连续点的个数，来滤除起点圆外缘的黑色细圆（问题：当检测时，接近竖直的细圆的边倒是好滤过，但是当细圆的边接近水平状态时，这种过滤方法就不见得有效了。） 2）采用矩阵检测的方法，将还没有进行边缘检测的原始图像拿出来做处理，这个处理是，采用接近起点图像的矩阵来检测，这个矩阵应该是取整个起点圆的中心位置，然后通过计算，判断飞行器偏离起点圆的位置，或者是斜率。（问题：这个检测的难度在于，如何选取一个比较有代表性，灵敏性的矩阵，来检测，并且对矩阵叠加的结果进行判断，这都是难点。） 3)采用图像边界采样检测的方法，利用原始采集图像，对图像中交于边界的位置来判断相对的偏移和斜率，这个方法适用于三边存在，一边不存在的情况，这样还可以方便的辨析现在的图像方向，进而判断自身需要运动的轨迹。（难点，如何使用边界的交点位置，灵活的表示图像的位置。）
4.
5.
6. 这是采集到的效果图，可以看到周边的边缘相对于黑线和圆显得很小很小，基本可以忽略，但是我在检测边缘的时候，采用的方法是，检测到跳变，再检测后一个像素是不是和前一个像素相同，相同就是边沿，但是现在显然不行，我需要手动的滤除这些杂点，问题是如何滤除细圆杂点，比赛的时候，不知道这些细圆的具体粗细，滤除的时候条件也可能会被动态的改变。（事实证明这样做并不能达到很好的效果，右边界完全被扰乱，毫无规律可言。）
2016/7/14
1. 今天继续做起点圆的检测，我准备采用昨天提出的方案三，最为简便和灵活，准确度应该也能够保证。
2.
3. 如上图的方框，这就是摄像头采集到的图像经过间隔采样以后，生成的160高*120宽的图像大小，这个图像的四个边界一定会检测到起点圆的三边，对边界进行区分，左边或者下面都是-1 ，右边或者上面都是1，经过这样的加权，就可以通过累计知道大概的偏移。
4. 经过检测采样，120/40 = 30宽 160/40 = 40高的图像。
5. 其实就是建立了直角坐标系，然后通过两条直线的交点，大体定位圆心的位置。
6. 现在基本测出了三边的中点位置，这个位置是相对于整个图像的原点而言的，宽度可以通过记录最后一个有效位置，然后减去一半的长度，再计算出相对于中线的偏移即可。
7. 但是这个算法非常弱，三个边界要是有边界上的位置被外圈的圆给影响了，那么这次采集就算作废了，而且出错处理和筛选还没有很好的做完。
8. 我想做的就是直接用一个接口，针对四个方位的起点圆做出统一的调用。
9. 首先发送命令我准备使用判断哪个方向上的偏移比较严重来以哪一边为基准，X轴上偏移严重就发送X轴上的偏移命令。
10. 因为现在检测时，要求比较苛刻，必须中心圆不在边界上才能正常检测，这个是出错处理没做好。出错处理：当出现边界不能正常检测的时候，用可用的边界来预测现在的位置，不能就等死了，可以大体预测，等待回归正常检测。
11. 注：现在所做的接口都是返回了检测到的直线或者直角的位置，而不是发送给飞行器的命令，命令这接口返回值应该是相反的！
2016/7/15
1. 今天准备完善上面的内容，将起点圆的各个方向检测做完，但是首先要把正方向的检测完善，做到良好的出错处理和预测。
2. 对于起点圆的斜率，我使用的是向上圆的竖线的斜率为标准，而这个斜率的绝对值越是大，那么越是垂直，经过测试，在0-3 和 -3-0的斜率时，倾斜角过于偏大，需要调整，其他情况可以忽略角度的调整。
3. 注：对于检测一遍出错以后，也就是出现杂点较多时，出错处理不是很好，这个对于左右都一样，不能因为一边没有正常采集，就认为它偏向那边，需要更加具体的根据两个有效边的位置进行预测！
4. 针对以上问题，解决方法是，默认斜率在可接受的状态，因为即使不可接受的状态也没办法计算出斜率。可以根据有效的两边的坐标来大体判断。
5. 注：全局变量要慎用，需要不断更新的全局变量需要不断的清空，不然会出现奇怪的现象。
2016/7/16
1. 今天准备做的是，将摄像头和飞行器接在一起，初步想要实现的是定点悬停，我不断的发送的是，让飞行器往哪个方向运动的命令。
2. 还有一个就是，OLED要做的比较灵活了，因为初始时，摄像头根本采集不到比较完整的图像，也就是说，在飞行器起飞时，命令时无用的，这个很致命，但是可以通过测试，得知飞行器的固定偏移路径，然后通过设置出错时的上一个命令，将无法采集时的默认动作更新到程序中。
3. 现在做的OLED显示菜单，会出现一些逻辑问题，显示老是不准确，菜单暂时只做阀值和默认方向设置。
4. 把菜单简单的做完了，现在就是如何准确的为飞行器从起飞之前到起飞定点时，大体的判断现在的位置。
5. 发现一个有趣的问题，一直以来我面对着摄像头调试，LCD上显示的位置就是返回值，原理上是像LCD上图形位置相反的方向才能做出修正，但是我本来就应该背对着摄像头，倒着看LCD，那么就是说，我可以直接用现在的图像位置作为返回值，让飞行器移动，而不用飞行做相反的命令处理。
6. 接下来的任务：1）将起点圆的正向起点圆命令发送矫正，基本可以为上位机提供位置指令。2）完成直线横向的检测，加强对横向的横线的检测，用于保证飞行器在横向飞行时的循迹。（思路：根据之前检测竖直的直线斜率,可以大体判断出横向飞行时，直线的斜率，但是好像没有那个必要了，因为现在飞行器基本不会自旋，我就默认它是直的。那么横向检测的时候，只能使用边界检测方法，检测左右屏幕上的黑点，用来大体的判断直线的位置，横向飞行时短暂的，所以这样处理也可以行得通。 3）完成左下右下直角的检测功能函数，现在不想让飞行器旋转了，那么四个方向的直角也必须做完。 4）起点圆的各个方向的检测，正向的已经可以了，也剩下三个方向的检测，重点还是如何检测圆心的位置，给出偏移量。
2016/7/17
1. 任务1已经完善。
2. 任务3：左上直角和右上直角，会出现比较极端的情况，需要使用最下边界的比较，例如左上直角：(leftMaxUBlackHeight[leftMaxULen - 1] <= rightMaxUBlackHeight[rightMaxULen- 1]) 就是为了让左边边界抵到左边的边界时，确保可以检测。基本完成四个直角的检测，最后命令发送动作还没统一做。
3. 任务2：横向直线的检测，使用比较简单的方法，因为现在直线的斜率直接可以忽略了，那么之前做的斜率就没有什么用了，现在也不需要，直接可以通过检测边界判断大体的位置。
4. 打算考虑多种情况来对横向直线的检测做出判断，比较极端的情况：1）就是两个很像都靠近到了边界上，所以这个数值是比较错误的，但是至少还是能够给出大体的位置的。2）只检测到了一边，那么按照这一边作为参考。3）检测到了两边，然而两边的偏差很大，也就是有可能是经过直角的时候，我决定使用短的边作为参考，因为长边很可能就是直角的竖直边。
5. 现在基本完成了任务2。
6. 任务4：起点圆的检测的话，我其实不需要检测那么多，就检测正向和反向就可以了，因为现在飞行器不转向，在横向的时候经过左起点圆或者右起点圆就没必要辨析了，直接可以路过，只是一开始的正向起点圆起飞和反向圆停止需要明了的检测。
7. 现在基本的任务已经完成，但是最上层的接口还没有做完，因为我还不知道我应该发送多大的偏移或者什么指令给上位机。
8. 下一步：使用安卓客户端的体感，不断的发送命令给接在飞行器上的蓝牙模块或者wifi模块，模拟摄像头发送给飞行器命令，用体感也周期性发送命令给TI，这样如果用手机遥感能够使得飞行器比较稳定的飞行，最起码能够绕着场地一圈，那么在上摄像头的时候，就有了飞行器姿态正确性的保证，加快了调试速度
2016/7/18
1. 今天上午尝试了使用手机遥感控制飞行器飞行，目的是模拟摄像头的控制，因为要想上摄像头，必须要把飞行器的运动姿态调整好，这样它才能很好的对摄像头的动作做出反应。
2. 现在测试发现效果还是不错的，单纯的给平衡角的期望就实现了基本的控制，效果比单纯的按键命令发射好多了，接下来准备将位置式的PID调整完，就可以实现比较稳定的控制了。
3. 摄像头命令格式：我准备使用的是两个命令，因为在X和Y方向，都要发送命令，所以要根据当前检测的内容，进行命令的发送，一次发送两个命令，分为五个档次，也就是速度分为五个档次，最快的速度用于往一个方向快速的移动。
2016/7/19
1. 因为现在突然修改了题目，没有四轴了，那么现在做的数字图像处理就只是一个没有实际运用的模块，根本没有被加上，独立的一块，而且很难加到其他的项目上了，因为是为了飞行器做的，然而现在要做小车，小车循迹可能复杂很多，所以我之前做的基本白费！
2. 改做小车。
1246
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
