企业官网建设流程全解析

1. 从“回忆录”到“实战指南”：为什么今天还要聊2020年的电赛？

“电子设计竞赛2020回忆录”——这个标题听起来像是一篇怀旧文章，记录着三年前某个团队或个人的参赛经历。你可能会想，技术迭代这么快，2020年的经验放到今天还有价值吗？是不是早就过时了？这正是我想在开头和你探讨的核心：恰恰相反，对于准备参加电子设计竞赛（无论是国赛、省赛还是校内选拔）的同学来说，一篇详尽的、来自“过去”的回忆录，其价值远超一篇泛泛而谈的“备赛攻略”。

原因很简单：电赛的题目形式、考察重点、技术趋势确实在变，但备赛的底层逻辑、团队协作的痛点、临场调试的“坑”、以及从零到一完成一个综合电子系统的完整心路历程，是高度相通的。2020年电赛，作为一个在特殊时期举办、题目风格又有一定代表性的赛事，其经历浓缩了电赛几乎所有典型的挑战。通过深度复盘一个具体年份的完整参赛过程，我们不是在“考古”，而是在解剖一个麻雀，从中提炼出可迁移的方法论、可复现的技术路径、以及必须警惕的“历史教训”。这比任何空洞的“要好好准备”、“注意团队合作”都来得实在。

所以，这篇“回忆录”不会停留在“那年我们做了什么题，拿了什么奖”的流水账。我会以2020年我亲身参与并指导的某个典型赛题（例如“坡道行驶电动小车”）为贯穿主线，但重点在于拆解其背后的通用技术栈选择逻辑、软硬件协同开发中的“暗礁”、时间管理上的致命失误，以及那些让作品从“能跑”到“跑得稳”的关键细节。无论你是初次接触电赛的小白，还是希望优化策略的老手，都能从中找到直接映射到自己项目上的“干货”。

2. 赛题选择与破题：在“看起来简单”和“做起来要命”之间权衡

2020年电赛公布赛题后，留给团队选择的时间通常只有几个小时。这个阶段的一个常见误区是：盲目追求“技术新颖性”或“复杂度”，而忽略了团队的真实能力和时间边界。我记得当时有“坡道行驶电动小车”、“信号失真度测量装置”、“无线运动传感器节点设计”等题目。我们最终选择了小车题目，并不是因为它最简单，而是基于一套快速评估体系。

2.1 五分钟快速评估法：四个维度的打分

面对多个赛题，我们当时用了一个土办法，但非常有效：给每个题目在四个维度上快速打分（1-5分，5分最高）。

1. 技术熟悉度：团队现有知识储备与题目核心技术的匹配程度。例如，小车题涉及电机控制、PID、传感器融合，这些都是我们之前项目反复锤炼过的，可以打4分。而一个涉及高频信号处理的题目，如果团队没人搞过，可能只有1分。
2. 模块化程度：题目是否允许将系统分解为相对独立的模块并行开发。小车可以清晰地分为机械结构、主控与驱动、传感器与算法、电源管理四大块，并行开发效率高，打5分。有些装置类题目，硬件是一个高度集成的整体，软件和硬件耦合极深，难以分拆，可能只有2分。
3. 关键风险点可见性：题目中那个“最可能卡住我们、且一旦卡住就万劫不复”的环节是否明确，以及我们是否有应对预案。对于小车，最大的风险是“在坡道上跑偏甚至翻车”，这指向了姿态传感器（如MPU6050）的校准与滤波算法、以及电机差速控制的稳定性。我们知道风险在哪，并且有基本的算法储备和调试手段，打3分。有些题目风险点很隐蔽（比如一个特定环境下的电磁干扰），打1分。
4. 发挥空间与区分度：在满足基础要求后，是否有让我们“秀肌肉”的加分项空间。小车题的基础要求是循迹和爬坡，但我们可以通过优化控制算法让运行更平滑、增加路径记忆功能、或者设计更优雅的机械结构来提升整体分，有发挥空间，打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和传感器，导致系统复位或数据异常。这是无数人踩过的坑。
• 电源方案：这是硬件稳定的基石。我们采用了两级供电方案：
  1. 动力电源：一节大容量（如2000mAh）的7.4V锂电池，直接给电机驱动供电。
  2. 控制电源：通过一个高效的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 i=0; i<TASK_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（积分）项。因为爬坡时负载变化大，纯比例控制会产生静差（即实际速度永远达不到目标速度），积分项可以消除这种静差。
• 调参血泪教训：
  1. 先P后I再D：这是黄金法则。先把I和D设为0，增大P直到系统开始振荡，然后取此时P值的一半到六成作为基础。然后加入I，从小值开始增加，直到静差被消除。最后加D来抑制超调。
  2. 在线调参工具：我们写了一个简单的上位机，通过串口实时绘制小车速度、位置偏差、PID输出等曲线，并可以动态修改PID参数发送给下位机。这比改代码、编译、下载、观察现象的效率高出十倍不止。没有这个工具，四天三夜根本调不好。
  3. 不同工况，不同参数：我们发现小车在平地、上坡、下坡时，同一套PID参数效果差异很大。理想情况是能根据坡度自适应调整参数，但时间有限，我们最终妥协为两套参数：一套用于平地/缓坡，一套用于陡坡，通过检测姿态角进行切换。这虽然不够“智能”，但很“实用”。

5. 系统联调与赛场实战：最后24小时的“地狱”与“曙光”

硬件、软件模块分别调试通过后，真正的挑战才刚刚开始。系统联调是问题集中爆发的阶段。

5.1 联调阶段遇到的典型“坑”及排查

1. 坑一：电机一启动，单片机就复位。

   • 现象：小车静止时一切正常，一旦给电机PWM信号，单片机就重启。
   • 排查：
     • 首先怀疑电源。用示波器探头测量单片机供电引脚（5V），在电机启动瞬间，观察到电压有一个明显的跌落（可能跌到4V以下），触发了单片机的欠压复位。
     • 解决：检查动力电源到电机驱动的导线是否过细（导致内阻大，压降大）；检查电机驱动电源输入端的大电容是否焊好（容量是否足够）；最根本的，再次确认动力电（电池）和控制电（降压模块输出）是否在物理上隔离良好，共地点选择是否合理（一点接地原则）。我们最终是更换了更粗的电源线，并在控制电源入口处增加了一个大功率二极管防止反灌，解决了问题。

2. 坑二：小车在坡道上走直线时莫名其妙地左右摇摆。

   • 现象：在平地上循迹很直，一上坡就开始有节奏的S形摆动。
   • 排查：
     • 首先排除机械问题（检查轮子是否安装同心，底盘是否刚性不足）。
     • 查看传感器数据，发现MPU6050的俯仰角数据在坡道上噪声明显变大，且存在周期性波动。
     • 意识到问题：小车在坡道上，电机负载不均，导致车身轻微振动。这种振动被MPU6050的加速度计感知，并影响了融合后的角度值。而角度值又参与了控制循环，形成了正反馈振荡。
   • 解决：加大互补滤波中加速度计的滤波权重（即减小α值），让系统更“信任”平滑但滞后的加速度计角度，而不是对振动敏感的陀螺仪积分。同时，在机械上尽量加固MPU6050的安装，并增加减震海绵。调整后，摆动幅度大大减小。

3. 坑三：到达坡顶平台后，停车位置不准。

   • 现象：有时冲过头，有时没停到中心区域。
   • 排查：我们最初只用编码器累计路程判断是否到顶。但由于坡道打滑、电池电压变化导致电机速度微调等因素，路程计算存在累积误差。
   • 解决：采用多传感器融合判决。结合三个条件：1) 编码器路程达到设定值的90%；2) MPU6050检测到俯仰角从正角度突然变为接近0度（说明已上完坡）；3) 灰度传感器检测到前方没有黑线（平台区域）。当这三个条件中有两个满足时，才触发“到达坡顶”状态，并立即切换为低速精细定位模式，直到满足精确停车条件。这种“投票机制”极大地提高了鲁棒性。

5.2 最后关头的策略：功能优先级与“保底”方案

比赛最后一天，可能还有一堆小问题没解决。这时必须做出残酷的取舍。

• 核心功能优先：确保“上坡-循迹-到顶”这个主干流程100%能走通，且成功率高。这是拿分的基础。所有花里胡哨的附加功能（比如声光提示、无线遥测），如果会影响主干稳定性，果断砍掉或简化。
• 准备“保底”参数：调出一套非常保守但极其稳定的PID参数和速度设置。也许跑得慢，也许转弯不优美，但一定能完成基本要求。在最终上场比赛前，如果心里没底，就切换到这个“保底模式”。先拿到基础分，再冲击发挥分。
• 完整流程演练：在最终场地布置（胶带贴的轨迹和坡道）上，进行不低于20次的完整流程全自动测试。记录每次的成功率、耗时、异常情况。这个过程不仅能发现隐藏问题，更是给团队建立信心的过程。

6. 超越技术：团队、心态与项目管理

电赛从来不是纯技术的比拼。它是一次浓缩的产品开发演练，对团队协作和项目管理能力的要求极高。

6.1 角色分工与协作模式

我们三人团队，角色大致如下，但不是绝对割裂：

• 硬件负责人：负责原理图、PCB（如有）、焊接、所有硬件模块调试、电源管理。他必须对电路稳定性负全责，并准备好所有备用元器件。
• 软件/算法负责人：负责主程序架构、核心控制算法（PID、滤波）、传感器驱动、调试工具开发。他是系统的“大脑”。
• 机械/综合调试负责人：负责小车机械结构搭建、传感器安装固定、整机走线布局，并协助进行大量的实地测试、数据记录和现象反馈。他是硬件和软件之间的“桥梁”。

关键协作经验：

1. 每日站会：每天早上和晚上，简短同步进度、遇到的问题、下一步计划。使用一块白板或在线文档记录“待办”、“进行中”、“已完成”和“阻塞问题”。
2. 接口定义先行：硬件和软件之间，必须提前定义好清晰的接口。例如，电机驱动模块的输入PWM频率和范围、灰度传感器模块返回的数据格式、MPU6050的数据更新频率和通信协议。一旦定义，除非万不得已，不要中途更改。
3. 版本管理：即使只有三个人，也强烈建议使用Git。每天结束时，把稳定的代码提交上去。这能在你改代码改崩了的时候，快速回退到上一个可用的版本，而不是熬夜重写。

6.2 时间管理：四天三夜的节奏把控

• 第一天：上午确定选题、完成需求拆解和方案设计。下午完成核心器件选型和采购（如果学校不统一提供）。晚上，硬件同学开始焊接核心模块；软件同学搭建开发环境，编写基础驱动和框架代码；机械同学开始搭建小车底盘。
• 第二天：全天模块化调试。硬件完成各模块功能验证；软件完成各传感器数据读取、电机基础驱动；机械完成整车初步装配。目标是晚上能让小车“动起来”（哪怕只是简单的遥控前进后退）。
• 第三天：系统集成与算法调试。这是最痛苦也是最重要的一天。联调、发现问题、调试、再测试。务必在当天结束前，实现基本功能的首次贯通（即小车能完成一次不完美的全流程）。
• 第四天：优化、稳定化、演练。上午解决遗留问题，优化参数和性能。下午进行大量重复测试，记录数据，微调。傍晚之前，确定最终参数和方案，封存代码，不再做大的改动。晚上，整理报告、准备答辩材料（如果有），并最后进行几次心理安慰式的测试。

6.3 心态调整：拥抱不确定性

电赛过程中，一定会遇到计划外的问题。芯片烧了、代码跑飞了、前一天还好好的功能突然不行了……这些都是常态。心态崩了，就真的输了。

• 建立预期：从一开始就告诉自己，一定会出问题。把解决问题视为比赛的一部分，而不是对计划的偏离。
• 科学排错：遇到问题，遵循“现象->假设->验证->解决”的路径。用示波器、逻辑分析仪、串口打印等工具获取数据，不要盲目猜测。从最可能的原因开始排查。
• 懂得休息：连续熬夜会导致效率急剧下降，并增加低级错误。保证每天有至少4-5小时的睡眠，尤其是最后一天前夜，必须睡一会儿。清醒的头脑比多熬两小时更有价值。

回过头看，2020年电赛的每一个技术细节，在今天可能都有了更新的芯片、更优的算法（如神经网络PID）、更方便的开发工具。但那些关于如何拆解复杂问题、如何在有限资源和时间内做出稳健的工程决策、如何管理团队和调试一个耦合性极强的系统、如何在压力下保持思考和行动的能力——这些“元技能”，从未过时。这篇回忆录，如果能让你在备赛时少走一点我们走过的弯路，多一份从容和底气，那么它的目的就达到了。电赛是一场马拉松式的冲刺，享受这个过程，无论结果如何，那份从无到有创造出一样东西的成就感，以及和队友并肩作战的情谊，才是最宝贵的收获。