2025电赛E题比赛过程的记录

第一天

拿到题目几乎全面预测正确。小车部分已经准备完毕，第一小问直接可以开跑。这说明，其实7月23号器件清单出来之后的这段时间的准备，是非常关键的，几乎是比赛的一个延伸。另外我们的器件一开始就选型非常合适：首先考虑各种限制，比如大小限制、芯片限制等等；其次就是买最好的产品。比如电机能用步进电机就别用普通电机，在比赛中没有DIY，只有谁能完成任务。越贵的器件往往在多方面都有非常巨大的优势：精准性、操控性、耐烧性（最重要的），等等。平时感觉差别不大，但在比赛环境中，这些优势可能就决定了你是否要花一整天去解决一个因硬件限制而无法避免的问题。比如，舵机能买360度的，就别买270度、180度的；能买总线控制舵机、磁编码器的，就别买普通的。就像今年的题目，舵机的角度精度几乎完全决定了比赛成败。

随后我们进行了一些基础的题目分析、分工和底层的结构搭建。队员之间一开始就熟悉题目，明确目标是极度重要的，能够极大提高效率和开发速度。先确定好底层结构，因为这些东西在之后很难改动，比如说车的机械结构，比如底层通信协议。我们就此完成了分工：我负责视觉部分，着手搭建视觉和云台的协议控制以及图像识别；硬件队友开始搭建小车结构，确保能够放得下云台和拓展板，确保小车的长宽高不会超出规定幅度。

随后我们开始更精细化的配置。这一步建立在每一个人都深度熟悉题目的每一个要求、每一个要点之上。我们需要确定进一步的方向，以及可能在这个步骤下取巧的关键点。比如说，电控部分是否应该把每一段拐弯和直线的速度进行分别设置，以适应距离远近导致的云台调整角度变化，让响应更加流畅。再比如，硬件部分如何安装视觉模块和激光笔的相对位置，如何稳定云台结构，防止抖动。

第二天

第二天我们遇到了一个巨大的瓶颈：我们的黑框识别始终无法达到期望的水平。识别的精准度、准确率都差强人意。这个时候的解决办法是，去哔哩哔哩上找找灵感。很多大神在第一天其实就把方案做出来了，拍视频或者干脆分享源码。这些都是非常好的参考来源，但不能想着直接拿过来用。因为如果不了解这些代码，在之后调整时，可能会忙活一整天却找不到bug在哪。参考了一个博主的解决方案后，我们设计了一个新方案：优先检测外部黑框的色块，检测到色块之后，用merge方法把它们合起来，然后再去检测里面的白色部分面积，假定白色部分是黑色部分面积的85%左右，最后确认里面的部分是不是白色。这样的设计逻辑就非常有效，并且在多种环境下抗干扰能力比较强。

紧接着就是把图像识别、PID控制、舵机协议输出这三个部分整合在一块儿。我在这个地方为自己挖了一个非常大的坑。我想着只要通过控制KP、KI、KD参数，就可以让输出量直接对应到舵机角度值，省去中间的换算。这个地方埋下的隐患，让我花了整个第三天来解决。

第三天 & 第四天

第二天晚上就出现了问题：如果靶子出现在摄像头边缘，云台会突然失控（“飞出”）。起初我们以为是PID调整的问题。但有一个线索：如果在失控后将摄像头手动对准靶子，就无论如何都不会再跟丢了，即使在摄像头边缘也不会。尝试调整PID参数后无效，我们便开始尝试各种方法：比如多级PID、分段积分、动态PID、平滑输出滤波等等。尝试了几乎一整天，也没有解决问题。

直到第三天晚上9点，我实在受不了了，发呆了半个小时。突然，我意识到了问题所在：我们在输出PID结果的时候，将结果与舵机角度进行了1:1直接映射！我原本在设计这套方案时认为，只要调整PID的比例项（KP），就可以抵消掉这个1:1映射带来的问题。但我当时犯了一个极其愚蠢的错误，这套逻辑根本不成立。因为积分项（I）是一直在累积的，假如我把输出与角度进行1:1映射，只有最开始那一帧的输出结果能被调整后的KP比例抵消掉。在此之后，积分项和比例项的关系，就完全无法被PID参数调整所抵消。所以，当我们找到一套“合适”的PID参数时，如果P太小，响应速度就慢到离谱；而P一大，就会在第一帧的时候飞出去。因为PID输出的是像素级误差计算的结果，这个像素值直接对应角度就非常巨大。摄像头中心到靶子中心的误差像素可能在很大范围内变化，KP无论如何都无法适应这么巨大的范围，在响应速度可接受的情况下，通常是P项主导。

最终的解决方式就是，给PID输出的东西乘以一个0.1的系数（大大降低比例项的影响），让积分项占据主导地位。同时增大KI（积分系数），KP保持原来的数值。就这么简单的改动，完全解决了问题！更好的是，之前为了解决这个问题添加的多级PID、分段积分和平滑滤波，反而让最后的效果远超预期。基础题的第二问完成时间稳定在1秒以内，第三问也只需要1.6秒左右（一般在1.7、1.6左右），都在2秒内完成。

正当我喜出望外，准备开始编写发挥题（第一问、第二问）的代码时，突然发现我们烧录到K230上的代码和运行的代码似乎不一致。我们决定上机运行测试。结果发现运行时，上位机根本无法控制K230程序的执行——它会自己启动程序跑起来。过了大约2分钟，更糟的情况发生了：只要点击重启，K230就会不受控制地让云台疯狂向右转动。又过两分钟，我的电脑彻底检测不到K230了！10分钟后，我们终于确认：K230烧坏了，连带着烧坏了我电脑的一个USB接口。

我们赶紧去拿备用板子。结果发现，备用的K230因为在固定镜头时使用了热熔胶，芯片测试时的高温导致热熔胶融化，把摄像头接口给堵死了，无法正常接入。硬件组队员尝试清理热熔胶。过了10分钟，热熔胶清理完毕。连接电脑——芯片立刻飞速发烫，果然，这个芯片也烧坏了！与它一同牺牲的还有我的另一个USB接口。此时已是最后一天的凌晨4点。晚上8点就要封箱。我们用的K230是正点原子的，从广州发货根本来不及。于是我们只能在学校的各个群里到处求借K230，高价悬赏，终于借到一块儿亚博智能的K230。接着就是疯狂地测试程序，疯狂地移植代码。

然而，新的问题又来了：云台和这块儿亚博智能K230无法通信！起初我们怀疑是转接板的问题。转接板上连着两个电源线、一个USB接口、4个串口引脚和两个云台接口。我们先测试用USB口能不能控制云台——发现上位机通过USB口能控制。然后尝试用USB转串口，让电脑接上那4个串口引脚来控制云台——也可以用上位机控制。这说明转接板本身是没问题的。接着让K230通过串口直接往电脑发送数据（串口助手接收）——也能正常输出，数值也正确。这就非常让人抓狂了。

想不出原因的我，又尝试用电脑的串口助手软件，直接往云台发送控制信息。结果发现，用标准的串口助手根本无法控制云台，发送数据后没有任何反应！我只好联系云台的客服。他发给了我一个他们专用的串口调试助手。结果最离谱的事儿出现了：只有他们调试助手里附带的那一条示例控制信息能控制云台！把我程序里生成的控制信息输入进去，就无法控制。这难道是我程序生成的协议信息不对？我把云台官网上提供的示例数据，用他们的专用串口调试助手发送——也毫无结果！我又尝试输入我自己生成的数据，试验了5条，其中有一条居然成功了！我仍然怀疑是串口协议格式问题。但当我再次把那条“成功”的数据输出给舵机时——又没反应了！此时已是早晨6点，天都亮了。大脑已经油尽灯枯的我，实在受不了这种折磨了。

现在这种状况，我也想不出什么办法了，猜不到为什么。只能无力地坐在那儿，想到一个可能的原因就去试一下，失败了就继续枯坐。尝试使用之前买的OpenMV——它不知为何开不了机，烧录程序也无效。这种状况一直持续到早晨10点。我依旧不死心，叫了闪送去中关村看看能不能买到K230，也是于事无补。只能继续坐着，干等，想办法。在那种绝望的处境下，哪怕只有一丝可能的办法，也是支撑的希望。我们只能逼自己不停地想，尽可能地去尝试做点什么。

就这样挣扎到了下午5点。我的队员们也扛不住了，只能开始整理东西，收拾场地。下午6点，东西基本收拾完毕。各种平台上、各个实验室里，都没有任何K230的消息了。晚上8点封箱时间到，我们只能打道回府。我唯一能做的，就是把我们这次比赛的过程记录下来。