复杂巡线设计
小车可以通过黑白循迹传感器进行循迹。
原理：循迹传感器会将当前地面的反光度转化为数值，黑线与白线反光度不同，转出的数值也不同。
循迹传感器自身存在监测上下限，我们假设循迹监测范围为0-65555。黑线反光为50%，白线反光为100%。
在光小于65555时较为准确，当光大于13万（65555*2）时，循迹传感器失灵。
原理
速度对循迹的影响
传感器每隔一段时间读取一次数值，通过设置阈值来判断当前地面为黑线还是白线。
假设我编写了一段程序：循迹到前面第二个路口停止，原理是：
路口 = 0
小车前进
如果 左循迹+右循迹同时为黑：则路口计数+1
如果路口计数为2，小车停止
如果速度过快，则容易冲出路口，这很好理解。但如果速度过慢，容易重复判定路口（因为速度太慢，车认为自己已经走了多个路口）。
结论：可以通过观察小车的表现来查看当前速度过快还是过慢。
光与颜色对循迹的影响
我们假设地面有：白 、红、黄、绿、蓝、紫、黑。这样的色彩带。
越靠近白色的（浅色），数值越接近白色 。 越靠近黑色的（深色），数值越接近黑色。
假设我们纯白色的读数是100，纯黑色读数是0。我们编写的判断阈值是50：大于50的判断为白色，小于50的判断为黑色，
如果我们的地图贴了反光的膜，那么不论地图是什么颜色，读取的数值都一样。小车会无法分辨地面的颜色，无法循迹。对应的情况就是：小车乱跑。
如果地图上存在一种不深不浅的颜色：譬如蓝色。
它的读数刚好是40-60，你的循迹程序就会出现不稳定的情况，因为这个蓝色有时被读成黑，有时被读成白。
想要程序稳定，可以把阈值写为39，这样蓝色稳定被判断为白色，也可以设为61，这样蓝色稳定被判断为黑色。
但是还没有结束，以上仅仅是白天的情况。
在晚上照明不足的情况下，你会发现这个蓝色又被读取为30-50，如果你之前设置的阈值是39（介于不稳定中间），你会发现程序又失效了。
结论：循迹程序稳定的前提，是循迹传感器的判断稳定。充分考虑光照、地图背景色、地图膜对循迹传感器的影响。
伪循迹的应用
这里我们做一个极端的假设：这个颜色是一个LED屏幕，你通过它的时候不知道循迹传感器测出来的值是多少。
此时我们可以放弃循迹，直接写:前进/左转/右转/后退 XXX 秒（看起来和循迹效果是一样的）
但这里又会出现新的问题：速度问题
运动员在塑胶跑道、柏油路、草地上的奔跑速度不同。
小车在：木地板、大理石地面等不同的路面上速度不同。
因此如果你编写了前进0.1秒后继续循迹，在大理石地面上可以越过无法循迹的路口，但是在木地板上无法成功。
结论：过于复杂的循迹地形可以通过“非循迹”的方式来处理。但“非循迹”的方式对场地要求高，并不是“万能钥匙”。
实战
我们以下面这张赛事地图为例，要求从左下角出发，可以前往任意任务点。
思考下编写 循迹程序的难点有哪些？
背景色
首先就是背景色，背景中存在太多的深色，与中间色（蓝色）。
通常小车的循迹程序往往是默认只有路是黑色，其他都是白色。因此这样的地图使用默认循迹代码的时候，如果传感器碰到了背景颜色，可能会影响原本程序的执行。（具体是否影响看代码逻辑）另外蓝色往往介于黑白之间，不易判定。
下图中被标记部分属于深色背景，通常会被识别为黑线
下图中被标记部分通常不易判定，正常光线下易被识别为白色
结论1：考虑到光照不确定，应该通过现场测光的方式来获取阈值，或者设置更靠近白色侧的阈值。
结论2：另外对转弯、掉头等需要循迹掠过背景的代码，需要手动重写逻辑。
针对结论1，我将自动设置阈值的算法变成了代码形式：
scar.SetThreshold(46000,46000,46000)
里面的三个数字分别表示：左循迹阈值、中循迹阈值、右循迹阈值
针对结论2：我编写了2个新的算法：
- 左侧调头
scar.Car_TurnAround_Left_Advanced()
继续左转 直到 左右循迹传感器 都 变黑
继续左转 直到 左右循迹传感器 都 变白
继续左转 直到 左右循迹传感器 都 一黑一白 停止 - 右侧调头
scar.Car_TurnAround_Right_Advanced()
继续右转 直到 左右循迹传感器 都 变黑
继续右转 直到 左右循迹传感器 都 变白
继续右转 直到 左右循迹传感器 都 一黑一白 停止
路口
其次就是路口，小车在转弯的时候通常比较慢，因此如果转弯之后立马就是路口的话，这个路口可能被判断为多个路口。
结论3：对于转弯后不太容易判定的路口，可以通过先倒退，再前进的方式来确认路口。
场地
我们并不确定比赛举办时的光照情况、场地地面材质。因此使用“非循迹”需要高度谨慎。
结论4：不使用转弯XX秒的方式伪循迹，仅用来调整小车位置。
只要是白天，光线有一定的亮度，循迹的部分还是很简单的。
任务点与循迹结合
下面是结合任务点的思考：A去B的路上，总是会把C点的球碰掉，怎么办？
这个问题有很多原因：
-
爪子太长，任务挂在爪子上的位置不确定，如果靠前就会碰掉小球。
-
速度太快，冲出路口一定距离后才停止
所以我们可以根据这个原因适当的调整爪子的结构，并降低一定的速度（你可以自己调整这个值来提高成绩）。
限位结构改造(建议)
此处的限位结构会对爪子的舵机线产生磨损，磨损到一定程度后，爪子不动，建议移除此处限位结构。
车轴结构改造(可选)
小车的传动轴可以更换为碳纤维的传动轴（不少于9个单位），可以减少一定的左右摇摆，提高小车的稳定性。
如果没有十字钉轴，可以通过添加更多的轴套来固定传动轴。
爪子的改造(参考)
通常爪子夹球的效果取决于球是否在正中与爪子力量是否足够，我们可以变换思维：将球兜起来，然后通过机械臂的上升，将球抬起。
考虑到A到B时容易碰掉小球，我们增加限位结构，让货物A能被挂在内爪的指定位置，同时爪子整体向后移动1格。
中间限位柱的长度没有要求，放置位置也可自行调整，保证货物A能够被挂在内爪的指定位置，小球易夹即可。
两侧限位柱需要向下延伸一些，可以在任务J点更容易升起火箭。
| 俯视图 |
|---|
 |
| 正视图 |
|---|
 |
代码逻辑分享
测试下平均速度在1分25秒（较先前往J点提升5秒）
-
该代码从左下角出发，前往A点抓取任务，放置到B。
-
之后前往C点抓取任务，放置到E。
-
连续5次调头左转，回到出发点后，前往J点，升起火箭。
-
完成后小车停 止。
使用方法
这段代码使用了一部分我自己编写的循迹方法，以适应不同的调头算法。
- 第一步：下载文件 ，确认名称为
SmartCar.py
而不是
SmartCar(1).py这样带有序号的文件名。
对于熟悉代码化编程的，如果你想查看循迹逻辑，或者编写新的循迹算法，可以在此文件夹中自定义函数调用。
- 第二步：复制
SmartCar.py至指定编程软件下的lib子文件夹中，让编程软件能够加载这个文件。
路径：编程软件路径+ \resources\app\src\boards\default\micropython_esp32x\build\lib
参考路径示例：C:\Program Files\company\mixly2.0-win32-ia32\resources\app\src\boards\default\micropython_esp32x\build\lib
- 第三步：切换到代码界面，复制粘贴这篇文章最末尾的代 码，上传。
代码中有一些注释，结合下面的说明，可以帮助调试。
上传程序后，夹子会先打开到最大、再闭紧、再打开。机械臂会下降到最低，再抬起至最高。如果没有到达指定形态（如：闭紧、下降），或者到达指定形态，但发出咔咔声。需调整舵机角度到合适位置。
由于我们的舵机可以正反装，所以你的舵机开与合可能与我相反。另外主控电量较低、高频使用均会对舵机角度产生(小幅度)影响。
如果舵机（爪子或机械臂）没有运动，尝试重新上传代码，或更换舵机线。
如果错过路口、一个路口被判定为多个路口，那么可以尝试调整小车速度。
如果整体无法循迹，可以调整循迹传感器的阈值（使其处于黑线的值与白线的值之间，通常取平均值）。
如果A点、B点、E点调头时掠过深色背景，但无法正确调头：调整左右循迹传感器的阈值、降低小车速度。
如果不确定是否掠过深色背景，可以在转弯代码中加入参数1，表示当小车检测到不同的背景时停顿1秒后再继续执行。
修改前示例：scar.Car_TurnAround_Right_Advanced()
修改后示例：scar.Car_TurnAround_Right_Advanced(1)
# 检测到左右循迹均小于阈值时，等待1秒
# 检测到左右循迹均大于阈值时，等待1秒
# 检测到左右循迹一大一小时，等待1秒
# 停止
如果小车在转弯时左右轮打滑（原地空转或不转），可提高打滑轮的速度，使其稳定转向。
如果小车在大弧线弯道中容易冲出弯道，可降低左右轮胎速度,以减小偏转。
-
第四步：调整后再次上传修改后的代码
-
第五步：小车放置至指定位置，左右循迹为白线，中间循迹为黑线。
放置正确时，屏幕从上到下显示的数字应该为：
左循迹的值：约50000
中循迹的值：约25000
右循迹的值：约50000
-
第六步：按下中间的圆形确认键，启动小车。
-
第七步：根据表现情况适当修改：循迹阈值、电机速度、某个任务点前进/后退的时间，如此循环。