六天五夜做完一套电赛题目,听起来时间很充裕,但实际经历过的人都知道,前两天基本都在迷茫和反复推倒重来中度过。我参加过三届电赛,带过队伍也当过评委视角的旁观者,每次结束后复盘都会发现:真正决定奖项的往往不是最后48小时的通宵,而是前48小时做对的几个关键决策。这篇攻略想把你可能要走弯路的地方直接标出来,从选题策略、系统框架设计,到焊接调试节奏、论文突击技巧,再到综合测评的应对思路,按时间线一步步拆开讲。
1. 比赛前夜:先别急着焊板子,把这三件事做完再说
很多队伍在发题前就已经摩拳擦掌准备大干一场,这是好事,但方向错了。赛前夜的准备重点应该放在“工具链验证”和“库存盘点”上,而不是提前猜测题目。
1.1 开发环境与下载器驱动验证
这是最不起眼但最容易翻车的环节。我见过不止一支队伍在比赛第二天发现某款单片机开发板的调试器在比赛用的电脑上死活装不上驱动,然后花掉大半天时间换环境、装软件、找兼容版本。赛前夜一定要做一次完整的最小系统验证:新建工程、编译空程序、下载到板子、点个LED。这个过程能暴露绝大部分环境问题。
如果队伍里有三种不同品牌的开发板,比如STM32系列、Arduino系列、还有一些国产MCU开发板,每块板子都要单独验证一遍。别嫌麻烦,第二天发题后你们会庆幸这个决定。另外,准备好备用下载器,哪怕是个十来块的盗版ST-Link,关键时刻能救命。
1.2 常用模块与传感器的健康检查
把平时常用的模块都翻出来通电试一遍:OLED屏幕能不能点亮,编码器能不能正常计数,陀螺仪数据能不能读到,电机驱动板输出是否正常,蓝牙/无线模块能不能配对。有些模块放久了会接触不良,有些传感器可能在运输过程中损坏,这些问题在赛前发现都是小事,比赛期间遇到就是灾难。
我习惯用一个专门的测试程序把常用外设全部轮询一遍,并打印结果。这样一插上就知道哪个模块坏了,不用临时写测试代码。这个测试程序平时积累下来,比赛期间反复用,非常值得。
1.3 资料离线化与代码备份
记住,比赛现场的网络状况没人能保证稳定,写明文档是最低成本的保险。
- 把所有芯片的数据手册(尤其是寄存器说明和时序图页)离线保存
- 把常用库文件、例程代码提前下载好
- 把元件封装库、PCB设计软件的基础库备份齐全
- 建立代码版本管理,哪怕只是本地多复制几份,防止手滑覆盖
还有一点:提前养成分模块写注释的习惯。六天五夜的疲劳状态下,你根本记不清三天前自己写的那段中断服务程序为什么要加那个奇怪的延时,注释能帮你省下至少半天的回忆时间。
2. 赛程前两天:方案设计的关键期,宁可慢一点也别急着动手
发题后的第一个24小时,是整个比赛最重要的决策窗口。很多队伍的通病是看到题目就急着写代码、搭电路,结果做到第三天发现整体思路有问题,被迫返工。
2.1 选题决策:别只看工作量,要看团队能力的“匹配度”
电赛题目通常有信号类、控制类、电源类、仪器仪表类等几大方向。选题的第一原则不是“哪个看起来简单”,而是“哪个匹配我们队伍现有积累”。如果你们对PID控制很熟,对运放电路把握不大,就算控制类题目工作量明显更大,也建议选控制类。比赛的六天时间根本不够从零学一个新领域,能发挥出已有的积累才是关键。
有一个比较实用的判断方法:拿到题目后,先让每个队员独立评估自己负责方向的工作量,给出一个从1到10的“熟悉度”分数。三项都超过6分的题目,基本可以放心选;如果某项低于4分,除非另一项能弥补,否则建议谨慎。
2.2 整体方案评审会:花一个晚上把系统架构定下来
选定题目后,第二天上午开一次方案评审会。这个会必须有明确的议程:
- 明确系统输入(传感器有哪些)、输出(执行器有哪些)、人机交互(屏幕按键怎么安排)
- 画出系统框图,标注各模块之间的通信方式(I2C、SPI、UART、PWM,还是直接用GPIO电平)
- 确定电源方案:用几节电池、什么电压、要不要做DC-DC转换、电源纹波会不会影响传感器精度
- 分配任务,明确每个人负责的模块和截止时间
这个会开完,你们队伍的思路会清晰很多。哪怕后面框架调整,也比一开始就闷头各干各的强。记住,这个阶段的输出不是代码,是文档和框图。一个清晰的框架能避免后续大量无效沟通。
2.3 主控选型与系统冗余设计的底层逻辑
主控选型要结合题目需求和队员熟练度,但有几个通用原则值得注意:
- 优先选择有硬件浮点单元的单片机(如STM32F4系列),会极大降低控制类算法(PID、卡尔曼滤波)的运算负担
- 如果系统里有多个传感器需要同时采集,考虑用DMA而非中断逐个读取,避免CPU过载
- 每个关键模块预留备用接口:比如摄像头数据接口预留一个串口用于调试,电机驱动预留一个PWM通道防止原通道损坏
关于冗余,我的经验是:凡是能做成双备份的尽量双备份。传感器可以买两个,电机驱动板可以备一块,电源模块可以带两路。电赛现场最崩溃的事情不是代码bug,而是硬件损伤后找不到替换件。赛前准备期间,多买几个关键器件放在公共器材箱里,队员之间提前约定好的统一使用规则。
3. 赛程中段(第3~4天):模块开发与系统联调的核心节奏
方案定下来之后,进入最紧张但也最能出成果的48小时。这个阶段的核心是“并行开发、分阶段联调”,不是把所有模块写完再统一拼接。
3.1 明确接口约定:并行开发的前提
第三天早上,所有人开一次短会,明确每个模块的接口细节:
- 通信协议的命令帧格式:起始字节、命令字、数据长度、校验方式,全部白纸黑字写清楚
- 每个模块的初始化时序和超时时间
- 各模块之间的数据流向和控制关系
这套约定要写到电子文档或黑板上,不要口头约定。因为接口不一致导致的联调返工,是电赛中最常见的浪费时间的坑。说句实在话,相当一部分队伍第三天晚上都在干这种事:控制模块说“我明明发了0x01命令”,传感器模块说“我没收到,只收到一堆0x00”——查了半天发现波特率不匹配,或者起始位设置不同。
3.2 先打通链路,再优化性能
这里想特别强调一个开发顺序的问题。很多队伍喜欢把一个模块做到极致再做下一个,比如先把PID调得很完美再开始搞视觉识别。这种做法在六天赛程里非常危险,因为到第五天你会发现还有好几个功能没接上,系统根本跑不起来。
正确的做法是:先用一个最简单能跑的版本把整个系统链路打通。比如控制题,先用开环让电机转起来,传感器数据能读到显示在屏幕上,然后再一个环节一个环节地把闭环加上去。做一个prototype版本,哪怕功能简陋、精度不高,但至少全流程能跑通。这是整个系统联调的基石。
这个逻辑和写软件时的“先跑通Main Path,再添加异常处理和边界情况”是一致的。在电赛中,这个习惯能极大降低最后阶段的焦虑感。
3.3 中段必踩的坑:电源噪声、通信不稳定、机械结构松动
这几个坑几乎每届比赛都会遇到几次,提前知道能省很多时间。
电源噪声是个隐蔽的杀手。电机启动瞬间的电流冲击会导致电压跌落,进而让单片机复位或者传感器读数跳变。解决方案大概有几条路:
- 给电机驱动用独立的电源(电池直接供电),传感器和主控用另一路经过稳压的电源
- 电源线用粗一点的,降低线路电阻
- 在主控板电源入口加一个大电容(比如470uF以上),吸收瞬态跌落
- 如果数字地和模拟地必须分开,用磁珠或0欧电阻单点连接
通信不稳定也很常见。I2C线长了会有波形变形,SPI速率高了会误码,串口的共地问题会导致数据乱码。解决办法是所有的外设通信都用短杜邦线或排线,能焊接就不要用插接,信号线尽量避开电机电源线和PWM控制线。如果必须长距离传输,用差分信号(如RS485)或者把速率降低。
机械结构松动则是控制类题目的大敌。电赛赛题里很多都有机械臂、小车、云台这类结构,螺丝没拧紧,跑起来结构就会变形;皮带松紧度不对,电机空转甚至丢步;重心不稳,转向时会侧翻。第三天到第四天,一定要做一次整机结构紧固检查,在每个关键螺丝上做标记,画的线错位了就知道哪里松了。还有,所有运动部件的结构件,尽量多打印一套备用件,尼龙或者PLA打印件在比赛期间断裂真的不稀奇。
4. 赛程末段(第5~6天):系统整合、论文和演示的冲刺策略
最后两天是整个比赛的决胜期,这个阶段的重点是加性能、写文档和反复演练测评流程。
4.1 性能优化的优先级:先保证“展示稳定性”,再追求“上限性能”
到第五天,真正拉开差距的已经不是谁能做更复杂的算法,而是谁能在评委面前稳定地把功能演示出来。这个时候要冷静下来,把精力放在提高系统的鲁棒性上:
- 代码中加入超时检测和异常恢复。比如某个传感器偶尔读不到数据,程序不能因此卡死,要有重试机制和默认值兜底
- 机械方面,检查所有接线是否牢固,把插接件用胶固定住,防止演示时抖动脱落
- 把系统运行时的功耗调低,让电池续航覆盖至少20分钟的连续演示
- 如果系统有需要校准的环节,把校准流程简化到一键启动,避免演示时分步操作容易出错
性能指标的优化要选择那些评委能直观感受到的指标:响应速度是否灵敏、显示是否流畅、动作是否连贯。而这些指标往往可以通过代码层面的合理简化和硬件方面的巧妙妥协来实现,不一定非要追求极致。
4.2 论文(设计报告)的突击策略
电赛的设计报告占有不小的分值,而且很多时候评委对报告的第一印象会直接影响他们对现场的观察角度。我的建议是安排一个文档能力强的队员从第四天晚上就开始写,不要拖到最后一天晚上。框架可以这样铺:
- 系统方案设计:放系统框图、各模块选型理由(这里可以提前从芯片数据手册里摘录关键参数)
- 理论分析与计算:比如控制算法的公式推导、滤波器的截止频率计算、电源效率估算,这部分占的分值较高
- 电路与程序设计:放电路原理图、PCB截图、软件流程图和关键代码片段
- 测试方案与测试结果:这里要用表格列测试条件和数据,最好配上实物照片
- 总结与展望:写一两段为什么现有的精度不够,哪些环节还能怎么改进
论文的写作原则是“图文并茂,有理有据”。尽管理论计算可能并不完美,但只要公式推导步骤合理,哪怕最后结果和实测有偏差,评阅专家也会认可价值。
到第六天上午,论文应该已经完成80%以上,剩下的是补测试数据、改格式细节。完整的数据记录非常重要,所以从第三天起就要安排专人记测试日志:日期、模块、测试条件、结果数据、异常现象。最后整理进论文时,这些一手记录比任何现写的内容都有说服力。
4.3 演示测评模拟:把评委可能问的问题都提前练一遍
第六天下午到晚上,可以安排一场完整的模拟测评。按照正式流程走一遍:
- 设备状态检查:电池电量、模块是否上电、传感器是否预热
- 按测评要求顺序执行各项功能,记录每项消耗的时间
- 安排队员充当评委,随机提问:为什么要选这个传感器?精度是多少?有什么缺点?如果环境干扰大怎么办?
- 让负责答辩的队员熟记系统设计中的每个环节,尤其是关键的参数和计算过程
这里想特别说一点:测评现场最影响成绩的不是功能,而是沟通。评委问“这个数据是哪里来的”,如果队员张口结舌,功能做得再好也会打折扣。反过来,如果队员能清晰流畅地讲解设计思路和选型理由,即使某项指标没有达到满分会,评委也愿意给过程分。所以,答辩话术要提前准备,甚至可以把关键问题的回答要点写在小卡片上,测评前再翻一遍。
5. 综合测评:潜伏在赛程里的“附加赛”,别等到了才慌
很多队伍在比赛公告发布前都不知道综合测评的存在,等到正赛结束被通知“明天还要来测一轮”时才开始慌张。综合测评是电赛体系里一项很重要的补充测试,主要考察队员在限定时间和器件条件下的临场工程能力,需要在很短的时间内根据指定任务自己设计并实现一个小电路或小系统。
5.1 综合测评的特点与准备策略
综合测评和正赛最大的区别是“器件受限,任务具体,时间极短”。一般是限定你只能用现场提供的元器件清单(常见的无非是若干运放、电阻电容、电位器、逻辑门、比较器、MOS管、三极管、以及一块指定型号的单片机),在三四小时内完成一个指定的信号生成、采集或处理任务,比如生成特定波形、实现特定频率的方波/正弦波、完成幅频特性测试等。
这就意味着你没法依赖自己积累的大部分模块,必须在纯硬件层面快速做出东西。准备策略上也和正赛很不一样,需要提前练就一些基础的搭电路能力:
- 熟悉常见运放电路结构:反相放大、同相放大、比较器、积分电路、微分电路,以及它们在不同输入下的输出波形。综合素质测评里,运放和比较器屡见不鲜,如果现场你还要翻手册现学,大概率做不完
- 练熟单片机的裸机编程,不依赖开发板库函数,直接操作寄存器配置定时器、ADC、DAC、PWM。现场提供的单片机型号不会太冷门,但如果你只熟悉某一种开发板,见到不熟悉的型号就会手足无措
- 学会快速搭焊小型电路:洞洞板焊接、元器件引脚的弯折成型、用万用表和示波器排查信号链问题,这些基本功在综测时比任何复杂算法都实用
5.2 综合测评现场的心法和操作节奏
综测现场的操作节奏和正赛完全不同。正赛有六天可以慢慢打磨,综测只有几个小时。我总结了几条现场实战经验:
- 拿到题目后先花10~15分钟“纸上谈兵”,画出完整信号链,标出每一级的功能和预计波形,再动手搭电路。跳过了这一步直接上手,大概率会出错
- 搭建顺序从输入端往输出端逐级搭,每一级搭完立刻测波形确认正确,再搭下一级。这能让你最快发现问题出在哪一级,否则不确定性会快速堆积
- 万一中间发现某个方案搭不出来,果断换方案。综测的容错窗口很短,没有时间在一种思路上死磕
- 随时观测电源电压和电流,防止电源短路或者过载烧坏器件。每焊好一级,先测静态工作点再通电
- 留出至少30分钟做整体调试和测量记录。因为综测最后是要提交测量结果的,测试数据记录不完整等于白做
关于综测,还需要说明一点:并不是所有年份所有赛区都有综测环节,但提前按照有综测的情况去准备训练,对自己工程能力的提升无疑是实打实的。就算没遇到综测,掌握裸机编程和基本电路搭建能力,对队友之间的分工协作也是很好的补强。
6. 六天五夜的生存指南:精力管理、团队协作与突发事件应对
最后这部分不太常出现在攻略里,但我觉得它值得单独拿出来好好说一说。六天五夜表面上拼的是技术,实际上拼的是体力和心态。我见过太多技术明明很扎实的队伍,因为最后两天状态崩了,该做出来的功能没做出来。
6.1 排班与休息策略:不是谁更能熬夜,而是谁能在关键时刻保持清醒
比赛的惯性思维是“能者多劳,累了就扛着”。我建议换一种思路:每个队员在自己负责模块的关键调试时间,必须是精力最充沛的状态。
比较好的排班模式是“三班倒+关键节点全员在线”。比如:
- 上午8点到下午2点是硬件调试主力时段,全员基本都在,但有一名队员可以在下午补觉
- 下午2点到晚上10点,换另一批精力高峰的人主导,前一批可以休息
- 晚上10点到凌晨2点,基本保留1~2人处理代码修改、数据记录等不需要大量脑力的工作
- 凌晨2点到早上8点,除非碰到关键调试点,不然强制大家都去睡觉
有些队伍喜欢比拼谁睡得少,这种风气在电赛圈里还挺有害的。事实是,熬夜带来的判断力下降在排错时代价极大。一个清醒时十分钟能找到的bug,凌晨三点可能需要两个小时。
有人可能会问,任务做不完怎么办?确实存在这种情况。但注意,越是任务紧张,越需要保证核心决策者的清醒。队长和每个技术方向的主力队员,必须保证每天至少四到五小时的有效睡眠。将这项纪律执行好,比任何“拼命”更能提高队伍的整体生产力。
6.2 队内沟通:意见分歧怎么处理?发现队友的进度落后怎么办?
六天高强度协作下,队内气氛一定会出现摩擦。最常见的矛盾就是“我觉得方案应该这么做,他觉得应该那么做”。处理分歧的基本原则是:以数据说话,不要以嗓门说话。
比如两个方案争执不下,可以约定一个小实验的验证时限——给双方各30分钟快速做一个最小验证,测出关键数据,然后投票决定。这样既没有浪费太多时间,又让双方都觉得自己被尊重了。
如果发现某个队友的进度明显落后,不要一开始就批判,先了解一下是不是遇到了技术瓶颈。电赛期间大家压力都很大,直接指责很容易引发情绪冲突。比较好的做法是队长主动过去协助一起排查问题,同时适当调整任务分配,把这位队友的部分工作临时分担掉一部分。
6.3 现场兵荒马乱时的“定海神针”清单
比赛现场很乱,多支队伍挤在一个大教室里,连走路都要侧身。在这种情况下,如果有一个清晰的“现场秩序清单”可以大大减少慌乱感。列举几个重要的:
- 公共工具(万用表、示波器、焊台)的使用顺序提前排好,谁先谁后,借出归还都记录在案
- 贵重物品(开发板、核心传感器)用不同颜色的标签区分,防止拿混
- 每日收工前花10分钟整理桌面:工具归位、器件入盒、垃圾清掉。别小看这10分钟,第二天开工效率会完全不一样
- 确定一个“物资总管”角色,所有消耗性物料(杜邦线、电阻、芯片)统一领取,避免东西不知道去哪了
- 建立一个简单的共享文档,记录每天的工作内容和剩余问题,避免沟通盲区
6.4 突发情况处理预案:主控烧了、程序库损坏、整机崩溃
比赛中最怕的不是技术难题,而是突发状况。有几个常见情况的处理思路,希望能帮你们形成自己的预案:
- 主控芯片烧了:第一时间确认备用板是否存在、能不能用。如果没有备用板,看看是不是芯片本身可以更换(如果是直插封装,可以尝试现场更换,这要求焊接工具齐全和一定的拆焊速度)
- 程序库文件损坏:如果代码没有备份,这是最致命的情况。所以要反复强调:每天至少备份一次整个工程目录,可以压缩后传到网盘或者U盘。一旦出现库文件损坏,用备份恢复,损失最小可以控制到半天以内
- 整机在测评前两小时崩溃:这种情况很考验心态。首先要判断是硬件问题还是软件问题。如果硬件问题,优先更换故障模块而不是排查故障原因;如果是软件问题,回退到上一个稳定版本,并在代码里临时屏蔽导致崩溃的功能模块。测评现场的功能完整度,永远优先于代码的优雅程度
7. 赛后复盘:不管成绩如何,这三件事一定要做
比赛结束并不意味着时间的浪费,整个参赛过程本身就是一笔不小收获。不管最终成绩如何,赛后复盘都能帮队伍和每个人沉淀下最宝贵的经验。
7.1 整理技术文档和代码仓库
赛后第一时间把整个参赛过程中的代码、电路设计、论文、测试记录整理归档,命名规范,放在团队的共享空间里。这些材料对后续比赛(比如下一届电赛或者其他的竞赛)是直接可复用的财富。我见过不少队伍在赛后资料整理上草草了事,等下一届比赛时又重新踩一遍自己当年踩过的坑,真的非常可惜。
7.2 个人和团队的双复盘
复盘的形式可以参考这样的结构:每人写一段自己的参赛体验,把做得好的地方、失误的地方、下次要改进的地方各写几点。然后队长汇总成一个团队复盘文档,重点分析方案变更的原因、进度滞后发生在哪个环节、团队协作是否顺畅。
这里面最有价值的往往是“失误”部分。电子设计竞赛的技术能力固然重要,但更高层面的收获在于:如何在高压下做决策、如何在不确定的环境里推进项目、如何与不同性格的人协作完成一个共同目标。这些能力在未来的学习和工作中极其受用。
7.3 给下一届队友的建议清单
如果你们队伍有传承计划,把这些复盘文档和参赛过程中整理的资料(尤其是赛前准备清单、模块接口约定模板、性能调试顺序、综测准备经验)做成一份完整的交接文档,给下一届的学弟学妹。这份经验的价值,有时甚至超过网上下载的往届优秀作品集。
以我个人经验来说,电赛的成绩重要,但更珍贵的是这个过程中练出来的系统工程能力、时间管理能力和抗压能力。把六天五夜当成一次完整的产品研发过程来对待,你会收获比奖项更多的东西。
最后分享一个我自己实践过多次的小技巧:赛前准备期,把每个队员可能会用到的关键芯片数据手册打印成纸质版,装订成一本“队员手册”放在桌边。查手册不用频繁切屏幕、抢电脑,现场效率会高很多。比赛本来就是一场极限拉扯的战役,谁准备得更细致,谁就能撑得更久,也就离获奖更近一步。