1. 从“回忆录”到“实战指南”为什么今天还要聊2020年的电赛“电子设计竞赛2020回忆录”——这个标题听起来像是一篇怀旧文章记录着三年前某个团队或个人的参赛经历。你可能会想技术迭代这么快2020年的经验放到今天还有价值吗是不是早就过时了这正是我想在开头和你探讨的核心恰恰相反对于准备参加电子设计竞赛无论是国赛、省赛还是校内选拔的同学来说一篇详尽的、来自“过去”的回忆录其价值远超一篇泛泛而谈的“备赛攻略”。原因很简单电赛的题目形式、考察重点、技术趋势确实在变但备赛的底层逻辑、团队协作的痛点、临场调试的“坑”、以及从零到一完成一个综合电子系统的完整心路历程是高度相通的。2020年电赛作为一个在特殊时期举办、题目风格又有一定代表性的赛事其经历浓缩了电赛几乎所有典型的挑战。通过深度复盘一个具体年份的完整参赛过程我们不是在“考古”而是在解剖一个麻雀从中提炼出可迁移的方法论、可复现的技术路径、以及必须警惕的“历史教训”。这比任何空洞的“要好好准备”、“注意团队合作”都来得实在。所以这篇“回忆录”不会停留在“那年我们做了什么题拿了什么奖”的流水账。我会以2020年我亲身参与并指导的某个典型赛题例如“坡道行驶电动小车”为贯穿主线但重点在于拆解其背后的通用技术栈选择逻辑、软硬件协同开发中的“暗礁”、时间管理上的致命失误以及那些让作品从“能跑”到“跑得稳”的关键细节。无论你是初次接触电赛的小白还是希望优化策略的老手都能从中找到直接映射到自己项目上的“干货”。2. 赛题选择与破题在“看起来简单”和“做起来要命”之间权衡2020年电赛公布赛题后留给团队选择的时间通常只有几个小时。这个阶段的一个常见误区是盲目追求“技术新颖性”或“复杂度”而忽略了团队的真实能力和时间边界。我记得当时有“坡道行驶电动小车”、“信号失真度测量装置”、“无线运动传感器节点设计”等题目。我们最终选择了小车题目并不是因为它最简单而是基于一套快速评估体系。2.1 五分钟快速评估法四个维度的打分面对多个赛题我们当时用了一个土办法但非常有效给每个题目在四个维度上快速打分1-5分5分最高。技术熟悉度团队现有知识储备与题目核心技术的匹配程度。例如小车题涉及电机控制、PID、传感器融合这些都是我们之前项目反复锤炼过的可以打4分。而一个涉及高频信号处理的题目如果团队没人搞过可能只有1分。模块化程度题目是否允许将系统分解为相对独立的模块并行开发。小车可以清晰地分为机械结构、主控与驱动、传感器与算法、电源管理四大块并行开发效率高打5分。有些装置类题目硬件是一个高度集成的整体软件和硬件耦合极深难以分拆可能只有2分。关键风险点可见性题目中那个“最可能卡住我们、且一旦卡住就万劫不复”的环节是否明确以及我们是否有应对预案。对于小车最大的风险是“在坡道上跑偏甚至翻车”这指向了姿态传感器如MPU6050的校准与滤波算法、以及电机差速控制的稳定性。我们知道风险在哪并且有基本的算法储备和调试手段打3分。有些题目风险点很隐蔽比如一个特定环境下的电磁干扰打1分。发挥空间与区分度在满足基础要求后是否有让我们“秀肌肉”的加分项空间。小车题的基础要求是循迹和爬坡但我们可以通过优化控制算法让运行更平滑、增加路径记忆功能、或者设计更优雅的机械结构来提升整体分有发挥空间打4分。将每个题目的四个分数相加选择总分最高的。这个方法帮我们快速过滤了那些“看起来很美但做起来会死”的选项。关键心得不要高估自己在四天三夜里的学习能力和抗压能力。选择一个技术栈有70%把握但存在明确风险点和提升空间的题目远比选择一个完全陌生、看似平坦实则暗藏深渊的题目要明智。2.2 坡道小车赛题的核心需求拆解确定选题后下一步不是马上画电路图而是把赛题要求一字一句地“翻译”成技术指标和功能模块。以当年小车题为例基础要求通常包括在指定坡道如角度可调上稳定行驶。沿坡道中线的黑色引导线循迹。在坡道顶端平台完成指定动作如停留、转向。全程无人工干预自动运行。仅仅这样看是笼统的。我们必须将其拆解为可量化、可设计的子系统需求动力与驱动需求需要多大的扭矩来克服坡道阻力电机的转速、扭矩参数如何选型驱动电路如H桥的电流承载能力需要多少这决定了电源方案电池电压、容量。感知与定位需求循迹用什么传感器灰度传感器阵列成本低但受光照影响大摄像头信息量大但处理耗时需要几个检测点安装高度多少姿态与坡度感知用什么测量小车自身的俯仰角坡度和平衡状态MPU6050惯性测量单元是首选但它的数据有噪声和漂移。位置判断如何知道小车已经到达坡顶平台可以用路程估算编码器、平台特征识别传感器阵列变化或结合姿态角突变来判断。控制决策需求核心控制器用STM32、ESP32还是K210考虑IO数量、计算能力是否需要跑图像算法、开发熟练度。控制算法循迹用简单的比例P控制还是PID坡道行驶时是否需要根据实时坡度动态调整电机功率这涉及到两个PID环的耦合速度环和方向环。机械结构需求小车重心要低以防翻车轮子需要足够的抓地力硅胶轮传感器支架要稳固且高度可调。这个拆解过程就是建立项目“工作分解结构”WBS的过程。它让模糊的任务变得清晰是后续一切分工和计划的基础。3. 硬件设计与选型在“性能冗余”和“成本时间”间走钢丝四天三夜的比赛硬件设计没有重来的机会。我们的策略是在关键路径上追求稳定和冗余在非关键路径上力求简洁和快速。3.1 主控与核心传感器稳定压倒一切主控MCU选择我们放弃了当时热门的带摄像头的K210方案选择了更熟悉的STM32F4系列。为什么虽然K210做图像循迹有优势但其开发环境、库函数对我们来说有学习成本。而STM32我们玩得熟硬件资源定时器、PWM、ADC、串口完全够用稳定性经过验证。在电赛中“用熟不用生”是铁律。时间成本是最大的成本。姿态传感器MPU6050这是坡道题的核心。我们直接采购了成熟的模块而不是自己画板子。重点在于冗余设计我们准备了至少3个不同批次的MPU6050模块。因为这种传感器个体差异和温漂特性不同多备几个可以在初期筛选出性能最稳的一个也防止某个模块意外损坏。关键操作上电后必须进行严格的静态校准计算零偏和动态校准补偿比例因子并将校准参数保存在MCU的Flash中。我们为此单独写了一个上位机校准工具通过串口发送指令自动完成数据采集和参数计算这比手动计算高效准确得多。循迹传感器我们选择了经典的八路灰度传感器TCRT5000阵列。没有用摄像头。考量点灰度传感器电路简单响应速度快微秒级处理逻辑简单二值化后判断位置偏差虽然受环境光影响但我们可以通过软件动态阈值调整例如根据传感器读取的平均值动态计算阈值来缓解。在光照相对可控的室内比赛场地其稳定性足以满足要求且极大减轻了主控的计算负担。3.2 电机、驱动与电源算清“能量账”电机选型我们用了常见的N20减速电机。选型时不是看空载转速而是看额定负载下的转速和扭矩。我们根据小车重量、坡道最大角度、轮径粗略计算了所需扭矩并留了1.5倍的余量。同时注意电机的供电电压范围这决定了驱动电路和电池的电压。驱动电路使用了TB6612FNG双H桥驱动芯片。它比古老的L298N效率高、发热小。关键细节一定要在电机电源输入端并联一个大容量如470μF的电解电容和一个104的瓷片电容用于滤除电机启停和PWM调速时产生的瞬间大电流和高频噪声防止干扰MCU和传感器导致系统复位或数据异常。这是无数人踩过的坑。电源方案这是硬件稳定的基石。我们采用了两级供电方案动力电源一节大容量如2000mAh的7.4V锂电池直接给电机驱动供电。控制电源通过一个高效的DC-DC降压模块如LM2596将7.4V降压到稳定的5V为MCU、传感器、舵机等供电。为什么不用一块电池直接分压电机工作时电流波动极大会在电源线上产生严重的电压跌落和毛刺。如果MCU和电机共用一路电源这些干扰极易导致MCU死机或传感器数据跳变。物理上隔离动力电和控制电是保证系统稳定的黄金法则。我们甚至为控制电源额外增加了一个LC滤波电路。3.3 PCB设计与焊接时间有限下的“敏捷硬件”我们没有时间画复杂的四层板。核心策略是“核心板洞洞板/万能板”。核心板使用现成的STM32最小系统板。功能模块将电机驱动、传感器阵列、电源模块等分别在小的洞洞板上焊接调试好形成一个个“功能子板”。系统集成用排针、排母和杜邦线将这些子板和核心板连接起来。这样做的好处模块独立调试方便哪个模块出问题就查哪个布线灵活易于修改节省了画PCB和等待打板的时间。缺点线多且乱可靠性稍差。因此我们用了热熔胶和扎带对所有连接处和线束进行固定防止运输和震动导致接触不良。4. 软件架构与算法实现让代码“跑起来”和“跑得稳”是两回事硬件是躯体软件是灵魂。电赛的软件不仅要实现功能更要在资源受限、环境多变的条件下极致稳定。4.1 基于时间片的裸机调度框架我们没有用实时操作系统RTOS因为项目复杂度还没到那一步且RTOS会引入额外的学习成本和不确定性。我们采用了一个经典的时间片轮询架构。这听起来老套但极其有效。// 伪代码示例 typedef struct { void (*task)(void); // 任务函数指针 uint16_t interval; // 执行间隔ms uint16_t counter; // 计数器 } Task_t; Task_t taskList[] { {Sensor_Data_Update, 10, 0}, // 10ms更新一次传感器数据 {Control_Algorithm, 20, 0}, // 20ms执行一次控制算法 {Motor_Output, 20, 0}, // 20ms更新电机输出 {System_Monitor, 500, 0}, // 500ms监测系统状态电压、温度等 // ... 其他任务 }; void SysTick_Handler(void) { // 1ms中断 for(int i0; iTASK_NUM; i) { if(taskList[i].counter taskList[i].interval) { taskList[i].counter 0; taskList[i].task(); // 执行任务 } } }这个框架的好处是结构清晰每个任务函数独立功能明确。时序可控可以精确控制关键任务如传感器读取、控制计算的执行周期这对PID控制器的稳定性至关重要。易于调试可以通过在任务函数里翻转一个IO口用示波器测量任务的实际执行时间和周期排查性能瓶颈。4.2 传感器数据处理滤波是玄学也是科学原始传感器数据是不能直接用的尤其是MPU6050的陀螺仪和加速度计数据。灰度传感器除了动态阈值我们还对八路传感器的状态进行了中值滤波。例如连续读取5次取中间值作为最终状态防止单次误触发。MPU6050数据融合这是小车在坡道上保持姿态稳定的核心。我们使用了互补滤波而不是更复杂的卡尔曼滤波。为什么卡尔曼滤波固然优秀但参数调校复杂在比赛紧张的时间里容易调崩。互补滤波原理简单参数直观一个滤波系数α效果足够好。原理简述陀螺仪积分得到角度但会随时间漂移加速度计测量重力分量可得到瞬时角度但动态响应慢、噪声大。互补滤波就是用一个系数α0α1来融合两者角度 α * (上一角度 陀螺仪角速度 * dt) (1-α) * 加速度计角度。α越接近1越信任陀螺仪动态好但会漂越接近0越信任加速度计静态稳但动态差。我们通过实际测试将α设定在0.98左右取得了很好的效果。实操技巧在系统初始化后小车静止放置在水平面上时采集一段时间的加速度计数据计算其平均值作为“水平基准”用于后续角度计算中的零点校准。4.3 控制算法PID的“灵魂”在于调参循迹和速度控制都用了PID。但很多人把PID用死了。循迹PID输入是灰度传感器阵列计算出的位置偏差例如-4到4输出是左右电机的速度差或舵机转角。这里我们只用了P比例和D微分去掉了I积分。为什么因为循迹是一个快速响应的过程积分项容易在直道段累积导致过冲振荡。微分项能预测偏差变化趋势让小车在接近中线时提前减速过弯更平滑。坡道速度PID输入是编码器测得的速度输出是PWM占空比。这里加入了I积分项。因为爬坡时负载变化大纯比例控制会产生静差即实际速度永远达不到目标速度积分项可以消除这种静差。调参血泪教训先P后I再D这是黄金法则。先把I和D设为0增大P直到系统开始振荡然后取此时P值的一半到六成作为基础。然后加入I从小值开始增加直到静差被消除。最后加D来抑制超调。在线调参工具我们写了一个简单的上位机通过串口实时绘制小车速度、位置偏差、PID输出等曲线并可以动态修改PID参数发送给下位机。这比改代码、编译、下载、观察现象的效率高出十倍不止。没有这个工具四天三夜根本调不好。不同工况不同参数我们发现小车在平地、上坡、下坡时同一套PID参数效果差异很大。理想情况是能根据坡度自适应调整参数但时间有限我们最终妥协为两套参数一套用于平地/缓坡一套用于陡坡通过检测姿态角进行切换。这虽然不够“智能”但很“实用”。5. 系统联调与赛场实战最后24小时的“地狱”与“曙光”硬件、软件模块分别调试通过后真正的挑战才刚刚开始。系统联调是问题集中爆发的阶段。5.1 联调阶段遇到的典型“坑”及排查坑一电机一启动单片机就复位。现象小车静止时一切正常一旦给电机PWM信号单片机就重启。排查首先怀疑电源。用示波器探头测量单片机供电引脚5V在电机启动瞬间观察到电压有一个明显的跌落可能跌到4V以下触发了单片机的欠压复位。解决检查动力电源到电机驱动的导线是否过细导致内阻大压降大检查电机驱动电源输入端的大电容是否焊好容量是否足够最根本的再次确认动力电电池和控制电降压模块输出是否在物理上隔离良好共地点选择是否合理一点接地原则。我们最终是更换了更粗的电源线并在控制电源入口处增加了一个大功率二极管防止反灌解决了问题。坑二小车在坡道上走直线时莫名其妙地左右摇摆。现象在平地上循迹很直一上坡就开始有节奏的S形摆动。排查首先排除机械问题检查轮子是否安装同心底盘是否刚性不足。查看传感器数据发现MPU6050的俯仰角数据在坡道上噪声明显变大且存在周期性波动。意识到问题小车在坡道上电机负载不均导致车身轻微振动。这种振动被MPU6050的加速度计感知并影响了融合后的角度值。而角度值又参与了控制循环形成了正反馈振荡。解决加大互补滤波中加速度计的滤波权重即减小α值让系统更“信任”平滑但滞后的加速度计角度而不是对振动敏感的陀螺仪积分。同时在机械上尽量加固MPU6050的安装并增加减震海绵。调整后摆动幅度大大减小。坑三到达坡顶平台后停车位置不准。现象有时冲过头有时没停到中心区域。排查我们最初只用编码器累计路程判断是否到顶。但由于坡道打滑、电池电压变化导致电机速度微调等因素路程计算存在累积误差。解决采用多传感器融合判决。结合三个条件1) 编码器路程达到设定值的90%2) MPU6050检测到俯仰角从正角度突然变为接近0度说明已上完坡3) 灰度传感器检测到前方没有黑线平台区域。当这三个条件中有两个满足时才触发“到达坡顶”状态并立即切换为低速精细定位模式直到满足精确停车条件。这种“投票机制”极大地提高了鲁棒性。5.2 最后关头的策略功能优先级与“保底”方案比赛最后一天可能还有一堆小问题没解决。这时必须做出残酷的取舍。核心功能优先确保“上坡-循迹-到顶”这个主干流程100%能走通且成功率高。这是拿分的基础。所有花里胡哨的附加功能比如声光提示、无线遥测如果会影响主干稳定性果断砍掉或简化。准备“保底”参数调出一套非常保守但极其稳定的PID参数和速度设置。也许跑得慢也许转弯不优美但一定能完成基本要求。在最终上场比赛前如果心里没底就切换到这个“保底模式”。先拿到基础分再冲击发挥分。完整流程演练在最终场地布置胶带贴的轨迹和坡道上进行不低于20次的完整流程全自动测试。记录每次的成功率、耗时、异常情况。这个过程不仅能发现隐藏问题更是给团队建立信心的过程。6. 超越技术团队、心态与项目管理电赛从来不是纯技术的比拼。它是一次浓缩的产品开发演练对团队协作和项目管理能力的要求极高。6.1 角色分工与协作模式我们三人团队角色大致如下但不是绝对割裂硬件负责人负责原理图、PCB如有、焊接、所有硬件模块调试、电源管理。他必须对电路稳定性负全责并准备好所有备用元器件。软件/算法负责人负责主程序架构、核心控制算法PID、滤波、传感器驱动、调试工具开发。他是系统的“大脑”。机械/综合调试负责人负责小车机械结构搭建、传感器安装固定、整机走线布局并协助进行大量的实地测试、数据记录和现象反馈。他是硬件和软件之间的“桥梁”。关键协作经验每日站会每天早上和晚上简短同步进度、遇到的问题、下一步计划。使用一块白板或在线文档记录“待办”、“进行中”、“已完成”和“阻塞问题”。接口定义先行硬件和软件之间必须提前定义好清晰的接口。例如电机驱动模块的输入PWM频率和范围、灰度传感器模块返回的数据格式、MPU6050的数据更新频率和通信协议。一旦定义除非万不得已不要中途更改。版本管理即使只有三个人也强烈建议使用Git。每天结束时把稳定的代码提交上去。这能在你改代码改崩了的时候快速回退到上一个可用的版本而不是熬夜重写。6.2 时间管理四天三夜的节奏把控第一天上午确定选题、完成需求拆解和方案设计。下午完成核心器件选型和采购如果学校不统一提供。晚上硬件同学开始焊接核心模块软件同学搭建开发环境编写基础驱动和框架代码机械同学开始搭建小车底盘。第二天全天模块化调试。硬件完成各模块功能验证软件完成各传感器数据读取、电机基础驱动机械完成整车初步装配。目标是晚上能让小车“动起来”哪怕只是简单的遥控前进后退。第三天系统集成与算法调试。这是最痛苦也是最重要的一天。联调、发现问题、调试、再测试。务必在当天结束前实现基本功能的首次贯通即小车能完成一次不完美的全流程。第四天优化、稳定化、演练。上午解决遗留问题优化参数和性能。下午进行大量重复测试记录数据微调。傍晚之前确定最终参数和方案封存代码不再做大的改动。晚上整理报告、准备答辩材料如果有并最后进行几次心理安慰式的测试。6.3 心态调整拥抱不确定性电赛过程中一定会遇到计划外的问题。芯片烧了、代码跑飞了、前一天还好好的功能突然不行了……这些都是常态。心态崩了就真的输了。建立预期从一开始就告诉自己一定会出问题。把解决问题视为比赛的一部分而不是对计划的偏离。科学排错遇到问题遵循“现象-假设-验证-解决”的路径。用示波器、逻辑分析仪、串口打印等工具获取数据不要盲目猜测。从最可能的原因开始排查。懂得休息连续熬夜会导致效率急剧下降并增加低级错误。保证每天有至少4-5小时的睡眠尤其是最后一天前夜必须睡一会儿。清醒的头脑比多熬两小时更有价值。回过头看2020年电赛的每一个技术细节在今天可能都有了更新的芯片、更优的算法如神经网络PID、更方便的开发工具。但那些关于如何拆解复杂问题、如何在有限资源和时间内做出稳健的工程决策、如何管理团队和调试一个耦合性极强的系统、如何在压力下保持思考和行动的能力——这些“元技能”从未过时。这篇回忆录如果能让你在备赛时少走一点我们走过的弯路多一份从容和底气那么它的目的就达到了。电赛是一场马拉松式的冲刺享受这个过程无论结果如何那份从无到有创造出一样东西的成就感以及和队友并肩作战的情谊才是最宝贵的收获。 
长河君 · 2026/8/29 19:02:46 · 阅读 1.2k 电子设计竞赛备赛实战：从硬件选型到PID调参的完整技术复盘
1. 从“回忆录”到“实战指南”为什么今天还要聊2020年的电赛“电子设计竞赛2020回忆录”——这个标题听起来像是一篇怀旧文章记录着三年前某个团队或个人的参赛经历。你可能会想技术迭代这么快2020年的经验放到今天还有价值吗是不是早就过时了这正是我想在开头和你探讨的核心恰恰相反对于准备参加电子设计竞赛无论是国赛、省赛还是校内选拔的同学来说一篇详尽的、来自“过去”的回忆录其价值远超一篇泛泛而谈的“备赛攻略”。原因很简单电赛的题目形式、考察重点、技术趋势确实在变但备赛的底层逻辑、团队协作的痛点、临场调试的“坑”、以及从零到一完成一个综合电子系统的完整心路历程是高度相通的。2020年电赛作为一个在特殊时期举办、题目风格又有一定代表性的赛事其经历浓缩了电赛几乎所有典型的挑战。通过深度复盘一个具体年份的完整参赛过程我们不是在“考古”而是在解剖一个麻雀从中提炼出可迁移的方法论、可复现的技术路径、以及必须警惕的“历史教训”。这比任何空洞的“要好好准备”、“注意团队合作”都来得实在。所以这篇“回忆录”不会停留在“那年我们做了什么题拿了什么奖”的流水账。我会以2020年我亲身参与并指导的某个典型赛题例如“坡道行驶电动小车”为贯穿主线但重点在于拆解其背后的通用技术栈选择逻辑、软硬件协同开发中的“暗礁”、时间管理上的致命失误以及那些让作品从“能跑”到“跑得稳”的关键细节。无论你是初次接触电赛的小白还是希望优化策略的老手都能从中找到直接映射到自己项目上的“干货”。2. 赛题选择与破题在“看起来简单”和“做起来要命”之间权衡2020年电赛公布赛题后留给团队选择的时间通常只有几个小时。这个阶段的一个常见误区是盲目追求“技术新颖性”或“复杂度”而忽略了团队的真实能力和时间边界。我记得当时有“坡道行驶电动小车”、“信号失真度测量装置”、“无线运动传感器节点设计”等题目。我们最终选择了小车题目并不是因为它最简单而是基于一套快速评估体系。2.1 五分钟快速评估法四个维度的打分面对多个赛题我们当时用了一个土办法但非常有效给每个题目在四个维度上快速打分1-5分5分最高。技术熟悉度团队现有知识储备与题目核心技术的匹配程度。例如小车题涉及电机控制、PID、传感器融合这些都是我们之前项目反复锤炼过的可以打4分。而一个涉及高频信号处理的题目如果团队没人搞过可能只有1分。模块化程度题目是否允许将系统分解为相对独立的模块并行开发。小车可以清晰地分为机械结构、主控与驱动、传感器与算法、电源管理四大块并行开发效率高打5分。有些装置类题目硬件是一个高度集成的整体软件和硬件耦合极深难以分拆可能只有2分。关键风险点可见性题目中那个“最可能卡住我们、且一旦卡住就万劫不复”的环节是否明确以及我们是否有应对预案。对于小车最大的风险是“在坡道上跑偏甚至翻车”这指向了姿态传感器如MPU6050的校准与滤波算法、以及电机差速控制的稳定性。我们知道风险在哪并且有基本的算法储备和调试手段打3分。有些题目风险点很隐蔽比如一个特定环境下的电磁干扰打1分。发挥空间与区分度在满足基础要求后是否有让我们“秀肌肉”的加分项空间。小车题的基础要求是循迹和爬坡但我们可以通过优化控制算法让运行更平滑、增加路径记忆功能、或者设计更优雅的机械结构来提升整体分有发挥空间打4分。将每个题目的四个分数相加选择总分最高的。这个方法帮我们快速过滤了那些“看起来很美但做起来会死”的选项。关键心得不要高估自己在四天三夜里的学习能力和抗压能力。选择一个技术栈有70%把握但存在明确风险点和提升空间的题目远比选择一个完全陌生、看似平坦实则暗藏深渊的题目要明智。2.2 坡道小车赛题的核心需求拆解确定选题后下一步不是马上画电路图而是把赛题要求一字一句地“翻译”成技术指标和功能模块。以当年小车题为例基础要求通常包括在指定坡道如角度可调上稳定行驶。沿坡道中线的黑色引导线循迹。在坡道顶端平台完成指定动作如停留、转向。全程无人工干预自动运行。仅仅这样看是笼统的。我们必须将其拆解为可量化、可设计的子系统需求动力与驱动需求需要多大的扭矩来克服坡道阻力电机的转速、扭矩参数如何选型驱动电路如H桥的电流承载能力需要多少这决定了电源方案电池电压、容量。感知与定位需求循迹用什么传感器灰度传感器阵列成本低但受光照影响大摄像头信息量大但处理耗时需要几个检测点安装高度多少姿态与坡度感知用什么测量小车自身的俯仰角坡度和平衡状态MPU6050惯性测量单元是首选但它的数据有噪声和漂移。位置判断如何知道小车已经到达坡顶平台可以用路程估算编码器、平台特征识别传感器阵列变化或结合姿态角突变来判断。控制决策需求核心控制器用STM32、ESP32还是K210考虑IO数量、计算能力是否需要跑图像算法、开发熟练度。控制算法循迹用简单的比例P控制还是PID坡道行驶时是否需要根据实时坡度动态调整电机功率这涉及到两个PID环的耦合速度环和方向环。机械结构需求小车重心要低以防翻车轮子需要足够的抓地力硅胶轮传感器支架要稳固且高度可调。这个拆解过程就是建立项目“工作分解结构”WBS的过程。它让模糊的任务变得清晰是后续一切分工和计划的基础。3. 硬件设计与选型在“性能冗余”和“成本时间”间走钢丝四天三夜的比赛硬件设计没有重来的机会。我们的策略是在关键路径上追求稳定和冗余在非关键路径上力求简洁和快速。3.1 主控与核心传感器稳定压倒一切主控MCU选择我们放弃了当时热门的带摄像头的K210方案选择了更熟悉的STM32F4系列。为什么虽然K210做图像循迹有优势但其开发环境、库函数对我们来说有学习成本。而STM32我们玩得熟硬件资源定时器、PWM、ADC、串口完全够用稳定性经过验证。在电赛中“用熟不用生”是铁律。时间成本是最大的成本。姿态传感器MPU6050这是坡道题的核心。我们直接采购了成熟的模块而不是自己画板子。重点在于冗余设计我们准备了至少3个不同批次的MPU6050模块。因为这种传感器个体差异和温漂特性不同多备几个可以在初期筛选出性能最稳的一个也防止某个模块意外损坏。关键操作上电后必须进行严格的静态校准计算零偏和动态校准补偿比例因子并将校准参数保存在MCU的Flash中。我们为此单独写了一个上位机校准工具通过串口发送指令自动完成数据采集和参数计算这比手动计算高效准确得多。循迹传感器我们选择了经典的八路灰度传感器TCRT5000阵列。没有用摄像头。考量点灰度传感器电路简单响应速度快微秒级处理逻辑简单二值化后判断位置偏差虽然受环境光影响但我们可以通过软件动态阈值调整例如根据传感器读取的平均值动态计算阈值来缓解。在光照相对可控的室内比赛场地其稳定性足以满足要求且极大减轻了主控的计算负担。3.2 电机、驱动与电源算清“能量账”电机选型我们用了常见的N20减速电机。选型时不是看空载转速而是看额定负载下的转速和扭矩。我们根据小车重量、坡道最大角度、轮径粗略计算了所需扭矩并留了1.5倍的余量。同时注意电机的供电电压范围这决定了驱动电路和电池的电压。驱动电路使用了TB6612FNG双H桥驱动芯片。它比古老的L298N效率高、发热小。关键细节一定要在电机电源输入端并联一个大容量如470μF的电解电容和一个104的瓷片电容用于滤除电机启停和PWM调速时产生的瞬间大电流和高频噪声防止干扰MCU和传感器导致系统复位或数据异常。这是无数人踩过的坑。电源方案这是硬件稳定的基石。我们采用了两级供电方案动力电源一节大容量如2000mAh的7.4V锂电池直接给电机驱动供电。控制电源通过一个高效的DC-DC降压模块如LM2596将7.4V降压到稳定的5V为MCU、传感器、舵机等供电。为什么不用一块电池直接分压电机工作时电流波动极大会在电源线上产生严重的电压跌落和毛刺。如果MCU和电机共用一路电源这些干扰极易导致MCU死机或传感器数据跳变。物理上隔离动力电和控制电是保证系统稳定的黄金法则。我们甚至为控制电源额外增加了一个LC滤波电路。3.3 PCB设计与焊接时间有限下的“敏捷硬件”我们没有时间画复杂的四层板。核心策略是“核心板洞洞板/万能板”。核心板使用现成的STM32最小系统板。功能模块将电机驱动、传感器阵列、电源模块等分别在小的洞洞板上焊接调试好形成一个个“功能子板”。系统集成用排针、排母和杜邦线将这些子板和核心板连接起来。这样做的好处模块独立调试方便哪个模块出问题就查哪个布线灵活易于修改节省了画PCB和等待打板的时间。缺点线多且乱可靠性稍差。因此我们用了热熔胶和扎带对所有连接处和线束进行固定防止运输和震动导致接触不良。4. 软件架构与算法实现让代码“跑起来”和“跑得稳”是两回事硬件是躯体软件是灵魂。电赛的软件不仅要实现功能更要在资源受限、环境多变的条件下极致稳定。4.1 基于时间片的裸机调度框架我们没有用实时操作系统RTOS因为项目复杂度还没到那一步且RTOS会引入额外的学习成本和不确定性。我们采用了一个经典的时间片轮询架构。这听起来老套但极其有效。// 伪代码示例 typedef struct { void (*task)(void); // 任务函数指针 uint16_t interval; // 执行间隔ms uint16_t counter; // 计数器 } Task_t; Task_t taskList[] { {Sensor_Data_Update, 10, 0}, // 10ms更新一次传感器数据 {Control_Algorithm, 20, 0}, // 20ms执行一次控制算法 {Motor_Output, 20, 0}, // 20ms更新电机输出 {System_Monitor, 500, 0}, // 500ms监测系统状态电压、温度等 // ... 其他任务 }; void SysTick_Handler(void) { // 1ms中断 for(int i0; iTASK_NUM; i) { if(taskList[i].counter taskList[i].interval) { taskList[i].counter 0; taskList[i].task(); // 执行任务 } } }这个框架的好处是结构清晰每个任务函数独立功能明确。时序可控可以精确控制关键任务如传感器读取、控制计算的执行周期这对PID控制器的稳定性至关重要。易于调试可以通过在任务函数里翻转一个IO口用示波器测量任务的实际执行时间和周期排查性能瓶颈。4.2 传感器数据处理滤波是玄学也是科学原始传感器数据是不能直接用的尤其是MPU6050的陀螺仪和加速度计数据。灰度传感器除了动态阈值我们还对八路传感器的状态进行了中值滤波。例如连续读取5次取中间值作为最终状态防止单次误触发。MPU6050数据融合这是小车在坡道上保持姿态稳定的核心。我们使用了互补滤波而不是更复杂的卡尔曼滤波。为什么卡尔曼滤波固然优秀但参数调校复杂在比赛紧张的时间里容易调崩。互补滤波原理简单参数直观一个滤波系数α效果足够好。原理简述陀螺仪积分得到角度但会随时间漂移加速度计测量重力分量可得到瞬时角度但动态响应慢、噪声大。互补滤波就是用一个系数α0α1来融合两者角度 α * (上一角度 陀螺仪角速度 * dt) (1-α) * 加速度计角度。α越接近1越信任陀螺仪动态好但会漂越接近0越信任加速度计静态稳但动态差。我们通过实际测试将α设定在0.98左右取得了很好的效果。实操技巧在系统初始化后小车静止放置在水平面上时采集一段时间的加速度计数据计算其平均值作为“水平基准”用于后续角度计算中的零点校准。4.3 控制算法PID的“灵魂”在于调参循迹和速度控制都用了PID。但很多人把PID用死了。循迹PID输入是灰度传感器阵列计算出的位置偏差例如-4到4输出是左右电机的速度差或舵机转角。这里我们只用了P比例和D微分去掉了I积分。为什么因为循迹是一个快速响应的过程积分项容易在直道段累积导致过冲振荡。微分项能预测偏差变化趋势让小车在接近中线时提前减速过弯更平滑。坡道速度PID输入是编码器测得的速度输出是PWM占空比。这里加入了I积分项。因为爬坡时负载变化大纯比例控制会产生静差即实际速度永远达不到目标速度积分项可以消除这种静差。调参血泪教训先P后I再D这是黄金法则。先把I和D设为0增大P直到系统开始振荡然后取此时P值的一半到六成作为基础。然后加入I从小值开始增加直到静差被消除。最后加D来抑制超调。在线调参工具我们写了一个简单的上位机通过串口实时绘制小车速度、位置偏差、PID输出等曲线并可以动态修改PID参数发送给下位机。这比改代码、编译、下载、观察现象的效率高出十倍不止。没有这个工具四天三夜根本调不好。不同工况不同参数我们发现小车在平地、上坡、下坡时同一套PID参数效果差异很大。理想情况是能根据坡度自适应调整参数但时间有限我们最终妥协为两套参数一套用于平地/缓坡一套用于陡坡通过检测姿态角进行切换。这虽然不够“智能”但很“实用”。5. 系统联调与赛场实战最后24小时的“地狱”与“曙光”硬件、软件模块分别调试通过后真正的挑战才刚刚开始。系统联调是问题集中爆发的阶段。5.1 联调阶段遇到的典型“坑”及排查坑一电机一启动单片机就复位。现象小车静止时一切正常一旦给电机PWM信号单片机就重启。排查首先怀疑电源。用示波器探头测量单片机供电引脚5V在电机启动瞬间观察到电压有一个明显的跌落可能跌到4V以下触发了单片机的欠压复位。解决检查动力电源到电机驱动的导线是否过细导致内阻大压降大检查电机驱动电源输入端的大电容是否焊好容量是否足够最根本的再次确认动力电电池和控制电降压模块输出是否在物理上隔离良好共地点选择是否合理一点接地原则。我们最终是更换了更粗的电源线并在控制电源入口处增加了一个大功率二极管防止反灌解决了问题。坑二小车在坡道上走直线时莫名其妙地左右摇摆。现象在平地上循迹很直一上坡就开始有节奏的S形摆动。排查首先排除机械问题检查轮子是否安装同心底盘是否刚性不足。查看传感器数据发现MPU6050的俯仰角数据在坡道上噪声明显变大且存在周期性波动。意识到问题小车在坡道上电机负载不均导致车身轻微振动。这种振动被MPU6050的加速度计感知并影响了融合后的角度值。而角度值又参与了控制循环形成了正反馈振荡。解决加大互补滤波中加速度计的滤波权重即减小α值让系统更“信任”平滑但滞后的加速度计角度而不是对振动敏感的陀螺仪积分。同时在机械上尽量加固MPU6050的安装并增加减震海绵。调整后摆动幅度大大减小。坑三到达坡顶平台后停车位置不准。现象有时冲过头有时没停到中心区域。排查我们最初只用编码器累计路程判断是否到顶。但由于坡道打滑、电池电压变化导致电机速度微调等因素路程计算存在累积误差。解决采用多传感器融合判决。结合三个条件1) 编码器路程达到设定值的90%2) MPU6050检测到俯仰角从正角度突然变为接近0度说明已上完坡3) 灰度传感器检测到前方没有黑线平台区域。当这三个条件中有两个满足时才触发“到达坡顶”状态并立即切换为低速精细定位模式直到满足精确停车条件。这种“投票机制”极大地提高了鲁棒性。5.2 最后关头的策略功能优先级与“保底”方案比赛最后一天可能还有一堆小问题没解决。这时必须做出残酷的取舍。核心功能优先确保“上坡-循迹-到顶”这个主干流程100%能走通且成功率高。这是拿分的基础。所有花里胡哨的附加功能比如声光提示、无线遥测如果会影响主干稳定性果断砍掉或简化。准备“保底”参数调出一套非常保守但极其稳定的PID参数和速度设置。也许跑得慢也许转弯不优美但一定能完成基本要求。在最终上场比赛前如果心里没底就切换到这个“保底模式”。先拿到基础分再冲击发挥分。完整流程演练在最终场地布置胶带贴的轨迹和坡道上进行不低于20次的完整流程全自动测试。记录每次的成功率、耗时、异常情况。这个过程不仅能发现隐藏问题更是给团队建立信心的过程。6. 超越技术团队、心态与项目管理电赛从来不是纯技术的比拼。它是一次浓缩的产品开发演练对团队协作和项目管理能力的要求极高。6.1 角色分工与协作模式我们三人团队角色大致如下但不是绝对割裂硬件负责人负责原理图、PCB如有、焊接、所有硬件模块调试、电源管理。他必须对电路稳定性负全责并准备好所有备用元器件。软件/算法负责人负责主程序架构、核心控制算法PID、滤波、传感器驱动、调试工具开发。他是系统的“大脑”。机械/综合调试负责人负责小车机械结构搭建、传感器安装固定、整机走线布局并协助进行大量的实地测试、数据记录和现象反馈。他是硬件和软件之间的“桥梁”。关键协作经验每日站会每天早上和晚上简短同步进度、遇到的问题、下一步计划。使用一块白板或在线文档记录“待办”、“进行中”、“已完成”和“阻塞问题”。接口定义先行硬件和软件之间必须提前定义好清晰的接口。例如电机驱动模块的输入PWM频率和范围、灰度传感器模块返回的数据格式、MPU6050的数据更新频率和通信协议。一旦定义除非万不得已不要中途更改。版本管理即使只有三个人也强烈建议使用Git。每天结束时把稳定的代码提交上去。这能在你改代码改崩了的时候快速回退到上一个可用的版本而不是熬夜重写。6.2 时间管理四天三夜的节奏把控第一天上午确定选题、完成需求拆解和方案设计。下午完成核心器件选型和采购如果学校不统一提供。晚上硬件同学开始焊接核心模块软件同学搭建开发环境编写基础驱动和框架代码机械同学开始搭建小车底盘。第二天全天模块化调试。硬件完成各模块功能验证软件完成各传感器数据读取、电机基础驱动机械完成整车初步装配。目标是晚上能让小车“动起来”哪怕只是简单的遥控前进后退。第三天系统集成与算法调试。这是最痛苦也是最重要的一天。联调、发现问题、调试、再测试。务必在当天结束前实现基本功能的首次贯通即小车能完成一次不完美的全流程。第四天优化、稳定化、演练。上午解决遗留问题优化参数和性能。下午进行大量重复测试记录数据微调。傍晚之前确定最终参数和方案封存代码不再做大的改动。晚上整理报告、准备答辩材料如果有并最后进行几次心理安慰式的测试。6.3 心态调整拥抱不确定性电赛过程中一定会遇到计划外的问题。芯片烧了、代码跑飞了、前一天还好好的功能突然不行了……这些都是常态。心态崩了就真的输了。建立预期从一开始就告诉自己一定会出问题。把解决问题视为比赛的一部分而不是对计划的偏离。科学排错遇到问题遵循“现象-假设-验证-解决”的路径。用示波器、逻辑分析仪、串口打印等工具获取数据不要盲目猜测。从最可能的原因开始排查。懂得休息连续熬夜会导致效率急剧下降并增加低级错误。保证每天有至少4-5小时的睡眠尤其是最后一天前夜必须睡一会儿。清醒的头脑比多熬两小时更有价值。回过头看2020年电赛的每一个技术细节在今天可能都有了更新的芯片、更优的算法如神经网络PID、更方便的开发工具。但那些关于如何拆解复杂问题、如何在有限资源和时间内做出稳健的工程决策、如何管理团队和调试一个耦合性极强的系统、如何在压力下保持思考和行动的能力——这些“元技能”从未过时。这篇回忆录如果能让你在备赛时少走一点我们走过的弯路多一份从容和底气那么它的目的就达到了。电赛是一场马拉松式的冲刺享受这个过程无论结果如何那份从无到有创造出一样东西的成就感以及和队友并肩作战的情谊才是最宝贵的收获。