电赛从入门到国奖：单片机、传感器与系统工程的完整备赛路线

电赛这条路，我从大二跟着学长打杂，到后来自己带队拿奖，走了不少弯路。很多人问我比赛难不难，我说难也不难。难在信息差太大，不少队伍直到比赛结束都不知道自己输在哪；不难在它考的东西其实很固定，无非就是单片机、传感器、执行器和一套系统工程方法。这篇攻略想做的事很简单：把“电赛从入门到国奖”这条路线完整摊开给你看，从赛制认知、备赛节奏、技术栈积累，到真题拆解和现场避坑，全部讲清楚。不管你是大一刚摸过点灯程序，还是已经打了一年杂准备冲奖，这篇内容都能对应到你现在的位置。

1. 认识电赛：赛制、目标与投入产出

1.1 电赛到底考什么

电赛全称全国大学生电子设计竞赛，奇数年是全国赛，偶数年各省自主命题或承办分区赛，但无论是哪一年的题目，核心考查点高度一致：在规定时间内，用给定的器件完成一个具备完整功能的电子系统。注意关键词，是“完整功能”，不是跑通一个点灯程序，也不是在开发板上把某个例程调出来。你需要把传感器采集、信号处理、控制算法、驱动执行、人机交互、电源管理这几块全部打通，并且装进一个可靠、可演示的物理装置里。

从题目的方向看，大体分几类：电源类、信号源与仪器类、控制类、无人机类、测量与数据采集类。最近几年网友搜索最多的控制类题目，比如大家常提的H题、G题，核心就是“系统集成能力+实时控制能力”。这类题通常给你一个具体场景，比如让小车循迹、识别目标、完成定点动作，所有模块必须在三天四夜里协同工作。很多队伍平时分开测传感器、测电机都没问题，一到整机联调就崩，原因就是缺少系统思维。

还有一个容易被忽略的点是题目描述里的评分细则。电赛评分从来不是“做得越复杂分越高”，而是按指标打分：跑完规定赛道的距离、定位误差、响应时间、功耗。我在赛后评审现场见过不少队伍功能花哨，但核心指标差一点，最后分数并不理想。备赛阶段就要养成习惯：拿到题先画指标表，把每一档分数对应的实现难度标出来，优先保基础分，再冲加分项。

1.2 三天四夜的完整节奏

一场正式电赛持续三天四夜，绝大多数人第一次参加时对时间毫无概念。前半天用来反复读题和讨论方案，第一天晚上到第二天中午做框架搭建，第二天全天到第三天早上完成各模块联调，第三天白天到晚上是整机调试和功能打磨，最后半天写设计报告、封箱、交作品。

很多人死磕某一个模块，比如PID调不出来就不往下走，结果最后连报告都没写完。我在后面专门讲倒排工期的方法，这里先给个建议：比赛第一天的晚上应该是带队人做决策的时刻。所有队员必须在这一晚把方案定死，之后只做优化，不再允许推翻重来。备赛期间的所有训练都要围绕这个节奏来，习惯它，比赛时就不会慌。

封箱环节也值得提前演练——现场测试是在封箱之后的第二天或当天进行的，测评时不允许再碰代码和硬件。我的习惯是交作品前留出两个小时写一个自检脚本，上电后自动跑一遍核心功能，并打印关键参数，这能救回不少“上电没反应”的尴尬现场。

1.3 组队比埋头刷题更重要

电赛每组三个人，很多队伍默认是“一个写代码、一个画板子、一个写文档”。但我观察下来，最强的组合是：一个系统架构人（通常兼队长），一个嵌入式软件人，一个硬件与接口人。系统架构人负责读题、拆指标、定方案、分模块、排时间表；软件人负责单片机逻辑、传感器驱动、控制算法；硬件人负责电路设计、电源选型、接线布局、整机装配。三个人都要具备“能读懂全系统”的意识，不能各自只盯着自己那一亩三分地。

组队常见的坑有两个：一是三个人技术栈完全重叠，遇到问题时没人负责另一块，二是三个人性格都偏内向，比赛期间交流太少。电赛现场沟通效率极其重要，建议队内每周固定做一次“系统演示日”，哪怕只是把现有进度拼起来跑一遍，也能提前暴露集成问题。我见过不少平时各干各的队，最后两天才第一次联调，结果各种接口对不上，比赛直接崩盘。别让这种事发生在你身上。

2. 从零开始的备赛路线：时间怎么分配最划算

2.1 第一阶段：把单片机变成肌肉记忆

如果你是大一或大二刚起步，第一阶段的目标不是学会所有知识，而是让单片机的基本操作变成不需要动脑的肌肉记忆。具体来说，至少要做到：点亮LED、用按键中断、用定时器产生PWM、用ADC采集电压、用UART串口打印、用I2C或SPI读传感器数据。这六项是电赛的地基，几乎所有题目的底层都在围绕它们转。

很多新手一上来就啃《STM32参考手册》，从寄存器开始学，这其实效率很低。我建议的路线是：用STM32CubeMX初始化代码，配合HAL库写业务逻辑。不要把时间花在手工配置寄存器上，那是芯片原厂工程师的工作。你只需要理解外设的工作原理（比如PWM的频率和占空比怎么影响电机转速），把初始化交给工具完成，把脑力留给策略和算法。

这一阶段用什么板子并不重要，但芯片选型值得提前考虑。从我的经验看，STM32F103C8T6是入门性价比之王，资料多、例程全、价格便宜，坏了也不心疼；等你具备一定能力后，再根据题目方向考虑F407（主频高、带DSP指令）或带硬件浮点加速的芯片。不要一上来就追求高端芯片——在赛场上，真正制约你的不是处理器性能，而是你写代码的速度和调Bug的思路。

2.2 第二阶段：攒够一抽屉的模块

备赛的第二阶段，核心任务是模块化积累。你要像攒工具一样，把常用模块一个个调通、封装成能直接调用的库函数，并写成自己的“模块手册”。电赛题目看似年年不同，但底层模块高度重复：灰度传感器或摄像头循迹、编码器测速、红外或激光测距、惯性测量单元（IMU）姿态解算、OLED显示、按键交互、无源蜂鸣器提示音，以及电机驱动和舵机控制。

每调通一个模块，都要做两件事：第一，写一个干净的接口函数，把硬件细节封装起来。比如灰度传感器，对外只暴露上电初始化、读取五路值、返回归一化结果这三个函数，赛场上改方案时能省出大量时间。第二，记录模块的特性参数：传感器在什么光照条件下容易误判、电机驱动在多少PWM占空比下会进入死区、电池电压降到多少V时系统开始不稳定。这些参数就是你的“经验值”，远比临时翻手册更有用。

我特别强调统一供电和信号地的处理。很多新人喜欢把各个模块的电源全挂在一个面包板上，信号线也随便搭，结果电机一转单片机就复位。第二阶段就要养成习惯：动力电源（电机、舵机）与逻辑电源（单片机、传感器）分开走线，共地但别共用回路；信号线尽量短，绕过电机和电调区域；地线要用粗线或覆铜连接。这些习惯在备赛时不觉得，赛时能救命。

2.3 第三阶段：真题模拟与封箱演练

到了赛前两个月，别再逐个模块练了，开始完整地模拟比赛：找近三到五年的真题，严格按照三天四夜的节奏走一遍，并且把作品封箱，过一天再开箱测试。这一步叫封箱演练，很多人在正式比赛前从没做过，结果真到封箱环节才发现漏工具、缺备份、代码没固化。

真题模拟的核心目的有两个。第一是练方案决策速度：拿到题目后多久能确定主控制芯片、传感器方案、执行机构和系统框架。我的标准是“半天之内必须定方案”，哪怕不是最优，也要先定下来跑通，再考虑优化。第二是练故障定位能力：整机跑起来之后，问题一定是一堆一堆地冒出来的，你要习惯用“二分法”定位问题——先把系统拆成传感器、主控、执行器三块，逐一确认哪块异常，再深入那一块的内部细节。这种排查思维是电赛现场最值钱的能力，没有之一。

第三个阶段还要做一件容易被忽略的事：准备一份“赛时急救包”。里面包括常用器件的替代料（比如备用主控芯片、备用电调）、烧录器、下载线、杜邦线、各种电阻电容、热缩管、扎带、焊台耗材，甚至备用电池。比赛现场没有电子市场可以逛，所有东西都必须提前备齐。我见过太多队伍因为一根转接线坏了就趴窝半天的，这种低级失误完全可以靠准备来避免。

3. 核心武器库：单片机、传感器与电源的底层逻辑

3.1 STM32选型：F103还是F407

很多新手会纠结比赛到底用哪颗芯片，我的观点很直接：除非题目明确要求特定主控（比如需要用FPGA或DSP），否则优先选择你最熟悉、资料最多、例程最丰富的芯片。指挥能力再好的将军，也得用顺手的那把枪。

简单对比一下：STM32F103C8T6主频72MHz，性价比极高，做一般测控系统绰绰有余，适合入门、练手和大部分控制类题目；STM32F407主频168MHz，带浮点运算单元和DSP指令，适合需要做实时姿态解算、快速FFT分析的场景，比如信号处理类、需要视觉处理的题目。但如果你的F103已经玩得很熟，千万不要为了追求参数临时换F407——三天四夜的时间经不起你重新学习一套外设库。

选型还有一个维度是引脚数和封装。控制类题目通常需要同时接多个传感器、多个电机、几个串口外设，引脚不够是很容易出现的瓶颈。我备赛时会选引脚多的封装，并且在CubeMX里提前规划好外设的引脚分配：哪些引脚复用、哪些引脚不能有冲突，全部提前钉死。真到赛场上再改引脚映射，改错一根线就要排查半天，时间成本太高。

3.2 传感器不是插上就能用

传感器是电赛系统里最容易出问题的环节，但也是最容易被新手低估的环节。很多人以为传感器就是上位机串口打印几个数字、看着对就行，实际上传感器的数据质量直接决定闭环控制能不能稳住。拿大家搜索最多的灰度传感器举例：它本质是反射式红外传感器，利用不同颜色表面对红外光的反射率差异来区分黑白。听起来简单，但真正用起来有几个非常要命的细节。

第一是环境光干扰。阳光、灯光、赛场顶部的强光照射都会改变传感器输出，导致阈值漂移。解决办法有两个层面：硬件上给传感器加遮光罩，让探头紧贴地面以缩短光路；软件上做动态阈值——每次上电后先读取当前环境下黑白两种表面的ADC值，取中值作为判定阈值，不要让阈值写死在代码里。第二是地表材质一致性。赛场跑道和你的实验桌面不可能完全一样，灰度值会整体偏移，所以需要写一个“标定函数”，用一个按键触发，自动走一遍黑白两个区域完成阈值学习。这个功能看着小，赛场上能帮你省掉大量崩溃时间。

再比如IMU（惯性测量单元），很多队用它做姿态或者小车走直线。它的坑是零漂：静止状态下读数也会缓慢漂移，直接积分必然发散。解决思路是不能只看原始数据，要用互补滤波或者更复杂的姿态解算算法，把加速度计和陀螺仪的数据融合起来。并且每次系统启动时要采集静止偏置，在代码里减去偏置后再计算。这些细节在模块单独测试时不一定暴露，但一放进整车、电机一震动，问题全都会冒出来。

3.3 电源和电机驱动的隐藏杀手

电源是整个系统的“血压”，偏偏很多新手对它的重视度排在最末尾。常见的悲剧是：传感器数据乱跳、单片机偶尔重启、电机转速不稳——排查半天发现是电源问题。电赛用电池供电，常见选择是锂电池组或者干电池。这里有几个关键点值得注意。

第一，DCDC降压模块的压差问题。很多人用的降压模块是线性稳压器（比如常用的LM1117、AMS1117），它只适合压差小的场景。锂电池供电时电压可能是7.4V甚至更高，直接用线性稳压降到5V或者3.3V，多余的能量全部变成热量消耗在芯片上，电流一大就过热保护，系统就会周期性断电。正确做法是使用开关电源模块（DCDC），比如常见的降压模块，效率高、发热小。选模块时注意输入电压范围和你电池的满电/亏电电压都要覆盖到。第二，电机驱动瞬间电流非常汹涌，一个堵转的直流电机可以抽出几安培电流，如果电机驱动模块和单片机共用一条细电源线，电压会被瞬间拉垮。我会用“动力电源”和“逻辑电源”两个网络分开走线，在接入点处共地但绝不共用回路。电源线至少使用AWG20以上的粗线，并且尽量缩短长度。

第三，滤波电容不是越大越好，但绝对不能没有。在电机驱动电源输入端并联一个470uF左右的电解电容，加上一个0.1uF陶瓷电容，能大幅吸收电机换向时产生的尖峰噪声。很多“莫名奇妙的干扰”问题，加几个电容就消失了一半。

4. 控制类核心玩法：循线、视觉与闭环调参

4.1 灰度循线系统的完整方案

控制类题目里，小车循线是出现频率最高的场景之一，从2024年很多队伍使用“STM32+灰度传感器”的组合就能看出，这是一套被验证过的稳定方案。下面给出一套可以直接抄作业的设计思路。

排布方式建议用五路灰度传感器并排，中间一路对准跑道中心线，左右两路用来判断偏离方向和程度。采集方式用ADC读取每一路传感器的模拟值，经过归一化处理后，把每一路判定为“黑/白”逻辑值；更进一步，还可以根据中间几路的模拟值大小估算车体相对于线的偏移量，而不仅仅是简单的“偏左还是偏右”。

控制策略从简单到进阶分几档。第一档是开关式控制：检测到偏左就往右打方向，检测到偏右就往左打方向。这种策略直道能跑，但弯道一定会扭来扭去。第二档是P（比例）控制：用偏移量乘以一个比例系数生成转向角或差速值，转弯平滑很多。第三档加上微分（D）和积分（I），组成完整PID，适合高速、多弯道的场地。我建议先跑通P控制，再逐步加D和I，不要一上来就上全套，参数没调好反而比纯P更乱。

还有两个容易被忽略的细节。一是传感器采样频率，小车速度越快，传感器读取间隔越短，一般在1到5毫秒之间比较合适，用定时器中断触发采集，不要在主循环里“顺便”读；二是转向执行机构，如果是差速驱动，转向就是调整左右轮PWM的差值，如果是有舵机的三轮车，则需要把PID输出映射到舵机脉宽范围内，并留出一定的死区（比如舵机中值附近不动作），避免在直线上高频抖动。

4.2 视觉识别：OpenMV到底够不够

很多测控类和控制类题目会涉及视觉识别，比如识别色块、二维码、特定形状或数字。这时候第一个问题就是：用OpenMV这类带视觉功能的微控制器，还是用K210，或者干脆用树莓派？我的建议：能简单就简单，不要为了“显得高级”引入太重的东西。

如果任务只是识别几个固定颜色、形状、或者 AprilTag 标签，OpenMV完全可以胜任，而且它的Python环境让现场改策略非常快。把它通过UART和STM32通信，它的核心流程是：摄像头采集图像、算法识别目标物体、把目标的类型和坐标发出去。STM32这边只负责接坐标并控制执行器。这样分工的好处是视觉栈和运动控制栈解耦，哪边出了问题都不至于全盘崩溃。

用OpenMV时有一个高性价比的经验：尽量在OpenMV端解决识别，不要往STM32传图像流。传图像不仅占用大量串口带宽，而且STM32处理不过来。你只需要把结果以固定格式发送，比如type,x,y,w,h\n这样的ASCII字符串，STM32用串口DMA接收并解析。另外，OpenMV的镜头视野、分辨率都会影响识别距离和帧率，分辨率不是越高越好，帧率优先，很多动态场景把分辨率降到合适值就能稳定识别。别忘了给摄像头固定一个可靠的支架，比赛场地车辆一跑起来，镜头晃动带来的模糊比算法问题更致命。

4.3 PID调参：从抖动到丝滑

PID是控制类绕不开的主题，但很多人对它的理解还停留在背公式层面。我的建议是：别从公式入手，从“你要解决什么问题”入手。你的目标是让被控量（速度、角度、位置）快速且稳定地到达目标值。P是力度，它决定系统对误差的反应有多强；I是纠偏能力，专门解决稳态误差（比如因为摩擦力不同，左右轮转速总有差异）；D是阻尼，防止系统冲过头、来回震荡。

调参是有顺序的，我调过大量系统后总结的步骤是：先把I和D设为0，只保留P，从小往大加，观察系统是否响应变快但不震荡。如果震荡，说明P偏大或者结构刚度不够，先减小P，再加上一点D来抑制超调。在D能稳定系统后，再慢慢加I，消除剩余的稳态偏差。在整个过程中，每一次修改参数后都记录下现象，不要凭感觉“左右乱拧”。

一个特别重要的经验：PID调不好，往往不是参数问题，而是你的测量精度问题。传感器噪声大、采样频率低、执行机构有死区，都会让系统“感觉震”，这时候再怎么调参数都没用。先回去改善传感器滤波、提高采样率、消除电机驱动死区，再回来调PID，你会发现参数一下子变得好调了。另外，静止时的抖动和运动时的抖动通常原因不同，要分开排查：静止抖动多是传感器噪声或死区问题，运动抖动往往是机械共振或P过大。

5. 真题拆解：一道测控题从审题到落地的全流程

5.1 审题阶段：把题面拆成功能清单

拿到题目之后，前几个小时大家都在反复读题，但多数人只是在“看”，没有真正“拆”。我的方法是拿一张白纸，把题目里每一个功能需求都列成一个条目，再把每一个评分点也列出来。比如一道典型的小车题，功能清单可能包括：规定路径循迹、避障、定点停车、自动返回、数据显示、声音提示，评分点可能包括：循迹准确性、用时最短、定位误差、是否满分完成加分任务。

拆完之后，打两遍标签。第一遍标优先级：哪些是基础分必须做，哪些是加分项选做。第二遍标难度：估算每个功能点的实现时间。然后把加在一起的时间和你手里剩余的三天四夜对一下。如果明显超时，就要果断砍掉一些非核心功能。大多数拿不到好成绩的队伍不是能力不够，而是什么都想做，结果什么都没做完。我在每次比赛前一天都会跟队员重复一句话：完整地做完基础项，比半吊子地尝试加分项划算得多。

5.2 方案树：在主控、传感器、执行器之间做取舍

拆完需求后，进入方案设计。这个阶段我习惯画一棵“方案树”：根节点是主控芯片选型，下面分出传感器选型和执行机构选型，再往下是通信方式和电源方案。画这棵树不是为了好看，而是为了逼自己把每个环节都明确下来，避免临场“到时候再说”。

比如传感器选型，就要回答：用五路灰度传感器还是OpenMV摄像头？灰度传感器简单、可靠、成本低，适合低成本和高速循线；摄像头灵活，能识别复杂目标，但开发量更大、调试时间更长。执行机构方面，用步进电机还是直流减速电机？步进电机定位准、控制简单，但速度上不去；直流电机速度快、加速猛，但闭环控制需要编码器反馈。电源方面，用多大容量的电池能撑完全部比赛时长？要做功耗估算：电机平均电流、单片机和传感器电流、起飞或高负载时的峰值电流，乘上运行时间再留出30%的余量。

方案树确定后，还有一个关键动作：让三个人同时指出他们各自负责模块的最大风险点。比如软件人担心OpenMV识别不稳，硬件人担心电机驱动发热，队长担心电池续航。把风险点写下来，立刻找对策：硬件人准备加强散热，软件人写一个备用识别方案，队长多备一块电池。这样风险才不会在评测前最后一刻爆雷。

5.3 倒排工期：用第n天晚上定义整个比赛

方案定了之后，很多人就开始“埋头苦干”，走到哪算哪。我觉得这是赛场上最大的时间浪费。正确做法是倒排工期：先把最后交作品的时间标出来，然后往前推出每个阶段必须完成的时间节点。

一天半的时候必须完成整机框架，所有模块至少能采集到数据、输出能动作。第二天白天到第三天上午，核心功能必须全部跑通，进入整机联调阶段。第三天的下午和晚上，集中解决稳定性问题：反复跑十次测试，看成功率；每次都记录失败现象，做针对性修复。最后三个小时，停止一切“大改”，只做备份、封装、写报告、自检。

我特别想强调“最后三个小时不要大改”这条铁律。很多队伍在最后阶段发现一个Bug，就临时换方案、重写代码，结果越改越乱，最后连原本能跑的版本都丢了。所以从第二天晚上开始，每一次代码改动前都保留上一个可用版本的备份，并写好版本说明。赛场上心态崩掉的本质，往往是手里没有一个“确定能跑”的版本。保住底线，才有资格冲上限。

6. 现场避坑手册：文件袋里该装的检查单

6.1 赛前准备清单

我根据多年参赛和带队的经验，整理了一份赛前检查清单，每一条都是踩过的坑换来的。硬件方面：备用主控板、备用传感器模块、备用电机和驱动、各种杜邦线和面包板、焊台和吸锡带、万用表、稳压电源，以及最重要的——备用电池和对应充电器。软件方面：三份以上不用的烧录器（包括备用下载线）、完整工程的多个备份U盘、写代码的电脑的电源适配器。

很多人会忽略“桌面和装配”这一类：扎带、双面胶、热熔胶枪、螺丝刀套装、十字和一字各规格、尖嘴钳、剥线钳、热缩管、电工胶带。这些在比赛现场都是硬通货。我见过一个队拿到题目后临时想加装一个传感器支架，却没有热熔胶枪，最后只能用橡皮筋绑，绑完一震动就歪，识别自然也不稳定。别让这种问题拖垮你的整场发挥。

还有一件非常重要但容易被忽略的事：把核心代码“固化”到Flash里，并设置为主机上电启动。比赛现场只允许上电操作，不允许现场烧录程序。你可以把烧录口留出来方便调试，但交作品前绝对要确保板子上电后直接进入正常流程，不需要额外按键进入下载模式。

6.2 高频故障速查：常见问题与定位思路

比赛三天里，最磨人的就是各种“灵异现象”。这里整理一份高频故障速查表，每一条都是我或者身边的队伍真实踩过的坑。

排查问题有一条我个人非常受用的原则：先怀疑最蠢的原因，再怀疑复杂原因。很多时候程序跑不通，最先不是逻辑Bug，而是某个引脚没配置、某个头文件忘包含、某根线插错了。按这个顺序排查能省下大量时间。

6.3 设计报告：拿分性价比最高的一环

电赛的最终成绩通常由现场功能测试和设计报告两部分组成，设计报告在很多赛区占比能到三成以上。这可能是整场比赛中“性价比”最高的一环——你不需要解决更复杂的技术难题，只需要把已经做出来的工作讲清楚、讲规范。

报告结构通常包括：系统方案设计、理论分析与计算、电路与程序设计、测试方案与测试结果、总结与改进。重点放在“为什么这样做”和“怎么证明它有效”上。比如你采用差速转向，就要画一下差速原理的计算和转弯半径公式；你采用PID控制，就要简要说明整定过程和最终参数；你的系统达到的指标要用表格列出来，附上实测数据。

写报告最关键的一条经验是：不要把报告留到最后一晚才写。从比赛开始第一天，每天顺手记录方案思路、关键测试数据、遇到和解决的问题，最后一天用下班时间整理成文。很多队最后一天通宵赶报告，质量可想而知。还有一点，报告的排版和图表规范程度会影响阅读者观感，但不建议在花哨的图表上花太多时间，清晰、完整、数据充分就是最高标准。

我个人在赛后复盘时最深刻的体会是：电赛拼的不是谁平时刷的题多，而是谁能在高压下把“系统工程”四个字执行得最彻底。从读题拆需求、定方案、排工期，到模块联调、风险控制、文档输出，每一个环节都是一个单独的技能项，都能在备赛时提前打磨。如果你现在还在犹豫要不要报名，我想说的是：准备好上面这些底层能力，把它当成一次真实的系统工程练兵，即使最后没拿到国奖，你收获的东西也远超过奖项本身。下一届的题目也许又是全新的场景，但只要你手里握着这套方法论，就没什么好慌的。