Debug记录
代码以及思路整理：
系列文章
【智能车Code review】—曲率计算、最小二乘法拟合
【智能车Code review】——坡道图像与控制处理
【智能车Code review】——拐点的寻找
【智能车Code review】——小S与中S道路判断
【智能车Code review】——环岛的判定与补线操作
智能车复工日记【1】——菜单索引回顾
智能车复工日记【2】——普通PID、变结构PID、微分先行PID、模糊PID、专家PID
智能车复工日记【3】：图像处理——基本扫线和基本特征提取和十字补线
智能车复工日记【4】：关于图像的上下位机的调整问题总结
智能车复工日记【5】：起跑线的识别与车库入库
智能车复工日记【6】：有bug的模糊PID记录
智能车复工日记【7】：关于会车的图像问题
智能车复工日记【N】：图像处理——环岛debug记录（持续更新）
4.10号更新
问题1
左环岛出现问题：
这时候应该用左上点来进行修补。检查为何没有补线。
关键是四状态和五状态的切换
修改参数为30；
效果有所改善，延时了状态5的到来。
问题2
接下来的问题：
状态7的问题：
状态7问题修复，
问题3
但是状态8进早了，原因：
左上拐点找到了，却是因为图像左上角糊了。
修改之后，bug消失。
同时对右环做对称处理：
问题4
同时发现下坡flag在判断后要清除掉。
问题5
//对2020.1.19 16.20.20进行处理，发现问题： 十字误判成右环岛：
原因：由于右线在55行以上存在环岛所以计算曲率时，曲率变大；
补救措施：限制计算曲率的点，最远处不可以超过57；
并且将拟合和计算方差的最后的点置换为curvity_point2。这样减少离群点的影响。
原本以为是上面的问题，结果发现，没用，是左下角的问题：
左下角有图像，导致l_start不等于0，然后计算曲率以及方差也就不同了，如何解决这个问题？显然这种十字部分容易误判环岛，可以考虑其他变量特征的限制！！！
先休息会儿。
加入新变量：
byte R_first_notget = 0;
byte L_first_notget = 0;
问题6
拟合且计算方差的依据(以左线为例)：起始点既和L_start（也就是为L_first_get）有关也和L_first_notget有关,还和L_sec_get有关
什么时候以L_start（第一次黑）为开始？
解决方案：
问题7
又出现了问题：
这次就是单纯地曲率计算有问题了，右线曲率太大了！！
修改曲率限制：第三点改为50以下，并将第二点的运算放到第三点确定之后。
问题解决。
问题8
发现右环岛7状态有问题，没有补线，观察问题:
由于是用r_start点拉线，此时显然不可以，考虑用r_sec_start点；
问题解决。
问题9
另外的一个小问题:
8状态出早了
将r_start!=0减去，并且将9状态条件限制一下
对左环岛进行对偶操作。
然后对扫线的时候的拟合线进行进一步限制
然后将固定扫线改为继承性扫线
问题10
发现假如将速度调高，有时候5状态和6状态的切换不流畅，必须一帧一帧地慢放才不会误操作，所以将限制条件打注释
问题11
又发现问题，卡循环了，只知道是在环岛部分卡的。检查！
卡在这儿，因为右上点为0
修改成这样就行了
对左环岛进行对偶操作。
今天就进行到这儿，下位机先不忙做调整。
5.4号更新
先交代一下之前没有上传的debug记录：
当时设定的阈值为7，现在更改为13。效果好点了。左线也做同样调整。
问题1
这一帧图像竟然判断成环岛1状态了，查找问题：
由于是继承性扫线，显然扫到了很高的行数，然后右线的曲率就大了，方差也大了。
现在增加限制条件，连续两帧的方差都大才能进入环岛状态1或2。
也就是增加新变量last_row：
左环岛对称处理，bug解决。
接下来跑st的图像：
问题2
100的左环岛，目前应该是7状态，但是却被误判为8状态。问题：
这里被判断为左上拐点，此时应该加以限制。左上拐点的列坐标不能大于175.
右环岛对偶操作：
同时要杜绝左上拐点在下面的情况：补线的时候限制左上拐点：
问题3
同时8状态补线找的点也需要改进:
右环岛同样操作:
问题4
还要解决，出环岛接十字的情况，这时候要将环岛状态清除:
改限制中拐点，不改限制上拐点。
我们重新找一下出环岛的特征。
else if (huandao_flag_R_L != 2 && huandao_memory >= 8 && (left_turn_up[0] <= 25 || ( fiv_width[35]>=80 && fiv_width[35] <=90 && fiv_width[30] >= 90 && fiv_width[30] <= 100 && fiv_width[25] >= 100 && fiv_width[25] <= 110)) && (leftfindflag[2] == 1 && leftfindflag[4] == 1 && leftfindflag[16] == 1 && leftfindflag[15] == 1 && leftfindflag[16] == 1 && leftfindflag[17] == 1 && leftfindflag[18] == 1))
{
huandao_memory = 9;
//SetText("完全脱离环岛，可以清除标志了");
clear_huandao_data();
}
这样问题解决。
对右环岛进行对偶操作。
问题5
发现3状态跳不到4状态，
将这一条件去除。右环岛对偶操作。
问题解决。
问题6
5状态没有进6状态。
发现问题：
限制条件改为25
左环岛对称处理。
Bug解决
问题7
刚到7状态就变为8状态，找BUG：
限制右上拐点的列坐标，同时修改行数>=25
左环对偶操作。
问题8
误判左环岛，可以通过右线的曲率进行限制。但是发现由于我们之前限制了曲率的最后一个点的取值在50行之前，所以此时曲率并不是很大。所以准备引入新变量。
由于我发现，正入十字的最后几帧特别容易判断成环岛的3状态。
加入限制，如果左右两个上拐点同时存在并且都小于30的话，不是环岛3状态。
问题解决，对右环做对称操作。
隐患评估：（可能在异弯接环的入环存在问题）
对判断环岛大条件中加入last直线的方差。
这一帧的左线曲率不知为何这么大：
这里对计算方差的函数进行更改。在曲率的限制条件的地方或上一个条件：
对右曲率计算进行对偶操作;
这会是右线方差大了，找原因;
问题9
原本限制的是小于36，我们修改限制为40.
结果发现还是不行，然后观察得到：
是曲率的原因现将左曲率min修改为-0.3
发现还是不对.
明明从上面计算，为何方差会这么大？
原来拟合出来的线并不符合整体趋势，这该怎么办？
我们限制一下，如果参与计算方差的点总共不超过12个我们就对其限制幅度，让他小于7000；
5.5号更新
这边由于断线的缘故导致计算方差错误，这该怎么办呢？？？
D:\上位机图像文件夹\上位机图像\上位机图像\2020.1.16 11.15.33注意！！！！
解决思路：
1、 扫线
2、 环岛状态上做文章
这是第630帧，其实在第628帧就应该开始了，
不符合的地方有：
左斜率
修改之后，成功识别为状态2；
但是没有进状态3的问题仍然存在：
找到原因了，因为之前为了防止出十字判断成环岛，我对赛道宽度进行了限制，从而导致此时没有识别出来。
修改之后发现并不是这个问题：
此时其实可以这样写，如果已经判断成12状态了，三状态的宽度限制可以稍作放松。
发现问题还是上次的那个，方差计算有问题。
结果发现是break取的点有问题，假如在60行以内没有找到就直接继承的原来的break点了，现在，将所有扫线的程序都进行观察并修改这个问题。
即包装好的扫线程序以及部分十字区域代码进行修改。
问题解决。
