1. 项目概述一场关于成长、协作与极限挑战的回忆“电子设计竞赛2020回忆录”——看到这个标题很多参加过电赛的朋友尤其是经历过2020年那特殊一届的估计心头都会涌上一股复杂的情绪。这不仅仅是一个技术项目的复盘更是一段关于青春、汗水、团队与在极限压力下完成不可能任务的集体记忆。2020年的全国大学生电子设计竞赛因为众所周知的原因赛制、备赛过程乃至比赛心态都发生了深刻的变化。作为亲历者我写下这篇回忆录不仅是为了梳理我们团队三人组从选题、设计、调试到最终提交的完整技术路径更是想分享那些在官方技术报告之外的真实故事我们如何远程协作、如何应对突发的器件短缺、如何在最后48小时不眠不休地解决一个诡异的电磁干扰问题。这篇文章适合所有对电子设计感兴趣的同学无论你是正在备赛的在校生还是已经工作的工程师或许都能从中看到自己曾经的影子并获得一些关于团队管理、技术选型以及临场应变的具体经验。2. 赛前准备在不确定性中寻找确定性2020年的备赛期最大的特点就是“不确定”。学校实验室时开时关团队成员分散各地传统的集中培训模式被打乱。这对一个高度依赖动手实操和即时讨论的竞赛来说是前所未有的挑战。2.1 团队组建与远程协作模式建立我们团队的三个人分别擅长硬件电路设计我、嵌入式软件编程队友A和算法与信号处理队友B。在无法见面的情况下我们首先确立了几条核心协作原则每日站会每晚9点准时进行视频会议每人用5分钟同步今日进度、遇到的问题和明日计划。这强制保持了项目节奏避免了有人“掉线”。工具链统一与云端化代码管理我们早早搭建了私有Git服务器用Gitea所有代码、配置文件必须提交。这避免了版本混乱也是远程协作的基石。设计文件同步硬件使用Altium Designer我们约定所有原理图和PCB的更新都必须生成PDF和版本号说明上传至团队网盘并在群里相关成员。虽然无法像本地那样实时协同编辑但通过严格的流程避免了“我改了你不知道”的灾难。文档即一切所有设计思路、器件选型理由、测试数据都必须记录在共享的在线文档我们用的语雀中。这后来被证明是救命稻草当任何人需要接替另一部分工作时文档提供了完整的上下文。模块化分工与接口先行我们根据往年赛题趋势预先划分了几个可能的方向模块电源模块、信号调理模块、主控模块STM32、电机驱动模块、传感器模块等。每个模块由负责人先行进行“预设计”并明确定义输入输出接口电压、电流、通信协议、物理接口。这样即使各自在家也能并行开发最后像搭积木一样快速集成。注意远程协作最大的敌人是沟通延迟和信息不对称。强制性的每日同步和详尽的文档记录虽然初期感觉繁琐但在后期集成调试阶段其价值远超所花费的时间。我们甚至为关键电路模块录制了简短的讲解视频方便队友理解设计意图。2.2 核心技能栈与知识库构建面对广袤的赛题范围控制、电源、仪器、信号处理等盲目学习是不可能的。我们的策略是“深度广度”结合。深度扎根核心平台我们一致选定STM32F4系列作为主控核心。理由是其性能足够应对大部分赛题生态完善HAL库、CubeMX且我们之前都有一定基础。备赛期我们不是泛泛地学而是每人啃透一个方向我深入研究其时钟树、各种定时器的精准控制模式用于PWM生成、输入捕获队友A钻研DMA直接存储器访问在ADC采样、串口通信中的应用以解放CPU资源队友B则吃透了FPU浮点运算单元和DSP库为复杂算法做准备。广度通过“最小可行产品”拓展对于其他可能用到的技术如无线通信ESP8266/蓝牙、图像处理OpenMV/吴鉴鹰、电机控制PID算法我们采取“MVP”策略。即不追求大而全而是每个方向用一个周末完成一个最简单的、可演示的小项目。例如做电机控制就用手边的小车底盘实现从零到有的位置式PID控制并记录下参数整定的过程和现象。这些“小项目”的代码和报告都归档到知识库成为赛时可快速调用的“模板”。器件储备与替代方案2020年最大的痛点是器件采购不便。我们整理了一份“核心器件清单”和“替代型号清单”。比如清单里明确主控芯片除了STM32F407还可以用F103或H750需要修改引脚和时钟配置运放除了经典的NE5532TL082、OPA2182在多数场合也能替代MOS管IRF540缺货时可以用IRF520或者IRFZ44N但要注意导通电阻和栅极电荷量的差异可能需要微调驱动电路。这份清单打印出来人手一份。3. 赛题揭晓与方案决策四天三夜的战争打响比赛题目公布的那一刻空气仿佛凝固了。我们当年选的是【本科组】一道关于“绕障飞行器”的题目此处为示例实际赛题可能不同但决策逻辑相通。题目要求设计一个能自主识别并绕过障碍物的四旋翼飞行器系统。3.1 题目关键信息提取与需求分解我们没有立刻开始讨论具体实现而是花了足足两个小时“读题”。功能指标分解核心功能自主飞行、障碍物识别、绕障路径规划。性能指标飞行稳定性、绕障成功率、响应时间、续航时间。约束条件限定飞行器尺寸、最大起飞重量、禁止使用成品飞控模块意味着要从底层写控制算法。技术路径评估感知方案选择题目未限定传感器。我们评估了三种方案① 纯视觉摄像头OpenCV信息丰富但算法复杂对处理器要求高稳定性风险大。② 超声波/红外测距阵列简单可靠但探测范围有限无法提前感知。③激光雷达Lidar成本高但测距精准可生成二维点云。结合我们的技能树队友B擅长算法和稳定性优先的原则我们冒险选择了低成本二维激光雷达如RPLidar A1作为主传感器并辅以一个向下的超声波模块定高。主控方案飞行控制本身就需要大量计算姿态解算、PID控制再加上实时处理激光雷达数据并进行路径规划STM32F4的单核显然力不从心。我们果断决定采用双MCU架构一颗STM32F4专门负责飞控接收遥控器信号、运行姿态算法、输出PWM控制电机另一颗性能更强的STM32H7或树莓派Zero W作为“任务主机”负责处理激光雷达数据、运行SLAM即时定位与地图构建简化算法和路径规划并通过串口向飞控MCU发送目标航点指令。这个决策是比赛成败的关键之一。机械平台为了节省时间我们采购了成熟的四轴机架和电机电调套装。但桨叶我们准备了多组不同尺寸、材质因为后期调试发现桨叶的平衡性和效率对飞行稳定性影响巨大。3.2 详细方案设计与任务拆分方案确定后我们立即进行了任务拆分并制定了精确到小时的时间表前紧后松。第一天D1硬件集成与基础飞控调试。我的任务将两个MCU、激光雷达、超声波、电调、遥控接收机、电源模块集成到机架上。重点设计电源树使用一块3S锂电池通过多个低压差线性稳压器LDO分别给不同模块供电飞控MCU用3.3V LDO任务MCU用3.3V LDO激光雷达用5V开关稳压模块并在关键电源入口处加磁珠和去耦电容以抑制噪声。电机供电线路必须粗而短且与信号线远离。队友A的任务在飞控MCU上移植并调试一个开源的基础四轴姿态解算和PID控制程序如基于IMU的Mahony滤波。目标能让飞行器在手动遥控下稳定悬停。队友B的任务搭建任务MCU的开发环境编写驱动读取激光雷达数据并实现一个简单的“最近点”障碍物检测算法。第二天D2感知与决策联调。集成任务。我的重点是确保双MCU间通信UART稳定并做好电气隔离如使用光耦或电平转换芯片防止地线噪声干扰。队友B优化算法将激光雷达的极坐标数据转换为二维笛卡尔坐标点云并实现一个简单的“向量场直方图”算法进行实时避障方向计算。队友A修改飞控程序使其能接收任务MCU发来的“偏航角速度”或“目标航点”指令并融入底层控制循环。第三天D3系统整合与场地适应性测试。全天进行室内试飞。测试不同材质纸箱、木板、不同形状柱状、墙状障碍物的识别与绕行效果。记录所有异常数据飞行器抖动、突然偏航、传感器数据跳变等。根据测试结果动态调整PID参数、避障算法的安全距离和决策频率。第四天D4优化、录制与报告撰写。上午进行最终优化和稳定性测试。下午按照赛题要求录制功能演示视频多角度、清晰展示绕障过程。报告撰写贯穿始终我们从第一天就开始在共享文档里填充报告内容包括方案论证、电路图、程序流程图、测试数据等。最后一天主要是整理、润色和生成最终PDF。切忌把所有工作留到最后半天。4. 核心实战那些教科书上不会写的“坑”与“亮”四天比赛真正的技术成长都发生在解决一个又一个突如其来的问题上。4.1 硬件上的“玄学”问题排查问题一电机启动时激光雷达数据疯狂跳变。现象飞行器静止时激光雷达读数稳定。一旦解锁电机哪怕电机低速旋转雷达传回的点云就出现大量噪点甚至角度信息错乱。排查过程软件排查首先怀疑是任务MCU处理不过来。我们降低了雷达数据读取频率问题依旧。在雷达数据接收中断服务程序里加时间戳发现中断响应时间在电机启动后显著变长且不均匀。电源排查用示波器观察给雷达和任务MCU供电的5V和3.3V电源线。电机启动瞬间5V电源线上出现了高达500mV的尖峰毛刺这就是罪魁祸首。电调ESC中的MOS管高速开关产生了强烈的电磁干扰通过电源网络耦合到了敏感的雷达和MCU。解决方案加强电源滤波在雷达和任务MCU的电源入口处增加了一个大容量100μF钽电容并联一个小容量0.1μF陶瓷电容的组合用于滤除不同频率的噪声。同时在电源路径上串联了一个铁氧体磁珠。物理隔离重新布线将电机供电线粗线与所有信号线、传感器线严格分开必要时成90度交叉。将雷达和任务MCU的电路板用铜箔胶带包裹并接地机架地做一个简单的屏蔽。软件容错在雷达数据解析程序中增加简单的数据校验和滤波算法例如连续两次角度增量异常大的数据点视为无效。实操心得在电机、继电器等大功率感性负载系统中电源完整性和电磁兼容性EMC必须从设计之初就重点考虑。多路独立LDO供电、星型接地、充分的去耦电容和物理隔离成本不高但能避免后期很多“玄学”问题。示波器是硬件调试的“眼睛”一定要善用。问题二飞行器总是朝一个方向缓慢自旋。现象手动悬停时飞行器会不受控制地绕Z轴缓慢旋转。排查这通常是偏航轴Yaw的PID参数没调好或者IMU的陀螺仪零偏Gyro Bias未校准。解决方案精确校准IMU将飞行器水平静止放置运行校准程序采集几分钟的陀螺仪和加速度计数据计算静态零偏。关键点校准时的环境必须静止且温度应接近实际飞行环境。我们后来发现电脑风扇的热风都会导致IMU温度变化引起零偏漂移。地面测试Yaw轴响应用手抓住飞行器务必卸掉桨叶安全第一在遥控器上打Yaw方向舵通过USB线连接飞控MCU用上位机软件如匿名科创地面站观察陀螺仪Z轴数据和控制量输出是否响应及时、线性。通过调整Yaw轴的PID参数主要是P和D让响应既快速又无超调振荡。实操心得飞控调试安全是绝对红线。调参务必遵循“先内环后外环”、“先角度后角速度”、“先卸桨测试再上桨慢速测试”的原则。一个微小的参数错误都可能导致“炸机”毁掉所有努力。4.2 软件与算法上的性能博弈挑战任务MCU算力不足路径规划延迟高。现象在复杂障碍物环境下飞行器反应“迟钝”有时甚至撞上障碍物。分析经 profiling性能分析发现80%的算力消耗在将激光雷达的极坐标数据转换为直角坐标涉及大量的sin/cos计算和遍历所有点云进行障碍物检测上。优化策略启用硬件FPU和DSP库在编译选项中确保STM32H7的硬件浮点单元FPU启用并将数学库math.h替换为ARM提供的CMSIS-DSP库其中三角函数等计算经过高度优化。数据降维与分区激光雷达一圈有360个点我们不需要全部处理。首先我们只关心飞行器前方180度范围内的点。其次将前方区域划分为若干个扇形区如5度一个区只处理每个扇形区内距离最近的点这样将处理的数据量减少了一个数量级。查表法LUT替代实时计算对于sin/cos值我们提前计算好一个0-360度或0-180度的查找表精度到0.5度。坐标转换时直接查表用一次乘法和加法替代复杂的浮点三角函数计算速度提升显著。降低决策频率路径规划不需要和姿态控制一样高的频率后者需要500Hz。我们将避障算法的运行频率从50Hz降低到20Hz但通过提高控制环的频率来弥补决策延迟整体响应依然流畅。实操心得在嵌入式资源受限的环境下做算法“差不多就行”的工程思维比追求绝对的理论最优更重要。通过降低精度、减少数据量、利用硬件特性和近似算法往往能用20%的算力获得80%的效果这对比赛这种有时间限制的场景至关重要。5. 赛后复盘比技术更重要的收获提交作品的那一刻筋疲力尽但内心充实。回顾整个过程技术上的细节会随着时间淡忘但一些更深层的收获却历久弥新。5.1 团队协作的“软技能”信任与责任明确分工后就必须充分信任队友能完成他那部分。同时要对自己的模块负全责不能成为团队的短板。当硬件出现干扰问题时队友A和B没有抱怨而是立刻一起帮忙查资料、测波形这种“共患难”的感觉是团队凝聚力的核心。冲突管理在第三天调试不顺利时我们对于是否要简化算法产生了激烈争论。我主张保稳定队友B想追求更好的性能。僵持不下时我们设定了一个“决策截止时间”再试一个小时如果性能没有显著提升就回退到稳定版本。最终我们采用了折中方案。设定规则比争论对错更有效。压力下的沟通越到后期人越累脾气越急。我们约定可以说“这个方案不行”但必须跟上“我觉得可以试试……”。用建设性提案替代单纯批评。5.2 工程思维与项目管理启蒙电赛是一个微缩版的完整产品开发流程。我们经历了需求分析读题、方案设计、任务分解、并行开发、集成测试、问题排查、版本迭代和最终交付。这让我们第一次真切体会到文档的重要性没有那些详细的笔记和测试数据我们根本无法在第四天有条不紊地写出高质量的报告。版本控制是生命线当一次激进的算法修改导致飞行器失控后我们通过Git轻松地回退到了上一个稳定版本没有损失任何有效工作。测试驱动开发对每个模块如PID控制器、避障算法我们都编写了简单的测试程序如用模拟输入看输出确保其基本功能正确再进行集成。这比集成后再大海捞针式调试高效得多。5.3 对后续学习与职业发展的影响这次比赛像一把钥匙为我们打开了专业领域的大门。我硬件对电源管理、高速信号完整性、EMC设计产生了浓厚兴趣后来深入学习并选择了硬件工程师的职业道路。比赛中被EMC折磨的经历让我在以后的产品设计中格外重视这些“隐性”要求。队友A软件深入理解了实时操作系统RTOS的必要性。赛后他学习了FreeRTOS并将其应用到飞控中更好地管理多个任务姿态解算、通信、数据记录等。队友B算法认识到嵌入式AI的潜力。他开始研究如何在STM32等边缘设备上部署轻量级神经网络如TinyML用于更复杂的场景理解。2020年的电子设计竞赛是一段在特殊时期与伙伴们共同奋斗的独特记忆。它教会我们的远不止如何画一块电路板或写一段代码而是如何在压力下系统性地思考、协作与解决问题。那些在实验室里通宵达旦的夜晚那些为一个小小成功击掌欢呼的瞬间以及那些共同攻克难题后相视一笑的默契都成为了我们技术生涯中最宝贵的起点和财富。如果你也在备赛我的建议是享受这个过程珍惜你的队友大胆地去设计、去实现、去踩坑因为这一切的经历终将让你与众不同。 电子设计竞赛实战：从STM32到激光雷达的嵌入式系统开发与团队协作
1. 项目概述一场关于成长、协作与极限挑战的回忆“电子设计竞赛2020回忆录”——看到这个标题很多参加过电赛的朋友尤其是经历过2020年那特殊一届的估计心头都会涌上一股复杂的情绪。这不仅仅是一个技术项目的复盘更是一段关于青春、汗水、团队与在极限压力下完成不可能任务的集体记忆。2020年的全国大学生电子设计竞赛因为众所周知的原因赛制、备赛过程乃至比赛心态都发生了深刻的变化。作为亲历者我写下这篇回忆录不仅是为了梳理我们团队三人组从选题、设计、调试到最终提交的完整技术路径更是想分享那些在官方技术报告之外的真实故事我们如何远程协作、如何应对突发的器件短缺、如何在最后48小时不眠不休地解决一个诡异的电磁干扰问题。这篇文章适合所有对电子设计感兴趣的同学无论你是正在备赛的在校生还是已经工作的工程师或许都能从中看到自己曾经的影子并获得一些关于团队管理、技术选型以及临场应变的具体经验。2. 赛前准备在不确定性中寻找确定性2020年的备赛期最大的特点就是“不确定”。学校实验室时开时关团队成员分散各地传统的集中培训模式被打乱。这对一个高度依赖动手实操和即时讨论的竞赛来说是前所未有的挑战。2.1 团队组建与远程协作模式建立我们团队的三个人分别擅长硬件电路设计我、嵌入式软件编程队友A和算法与信号处理队友B。在无法见面的情况下我们首先确立了几条核心协作原则每日站会每晚9点准时进行视频会议每人用5分钟同步今日进度、遇到的问题和明日计划。这强制保持了项目节奏避免了有人“掉线”。工具链统一与云端化代码管理我们早早搭建了私有Git服务器用Gitea所有代码、配置文件必须提交。这避免了版本混乱也是远程协作的基石。设计文件同步硬件使用Altium Designer我们约定所有原理图和PCB的更新都必须生成PDF和版本号说明上传至团队网盘并在群里相关成员。虽然无法像本地那样实时协同编辑但通过严格的流程避免了“我改了你不知道”的灾难。文档即一切所有设计思路、器件选型理由、测试数据都必须记录在共享的在线文档我们用的语雀中。这后来被证明是救命稻草当任何人需要接替另一部分工作时文档提供了完整的上下文。模块化分工与接口先行我们根据往年赛题趋势预先划分了几个可能的方向模块电源模块、信号调理模块、主控模块STM32、电机驱动模块、传感器模块等。每个模块由负责人先行进行“预设计”并明确定义输入输出接口电压、电流、通信协议、物理接口。这样即使各自在家也能并行开发最后像搭积木一样快速集成。注意远程协作最大的敌人是沟通延迟和信息不对称。强制性的每日同步和详尽的文档记录虽然初期感觉繁琐但在后期集成调试阶段其价值远超所花费的时间。我们甚至为关键电路模块录制了简短的讲解视频方便队友理解设计意图。2.2 核心技能栈与知识库构建面对广袤的赛题范围控制、电源、仪器、信号处理等盲目学习是不可能的。我们的策略是“深度广度”结合。深度扎根核心平台我们一致选定STM32F4系列作为主控核心。理由是其性能足够应对大部分赛题生态完善HAL库、CubeMX且我们之前都有一定基础。备赛期我们不是泛泛地学而是每人啃透一个方向我深入研究其时钟树、各种定时器的精准控制模式用于PWM生成、输入捕获队友A钻研DMA直接存储器访问在ADC采样、串口通信中的应用以解放CPU资源队友B则吃透了FPU浮点运算单元和DSP库为复杂算法做准备。广度通过“最小可行产品”拓展对于其他可能用到的技术如无线通信ESP8266/蓝牙、图像处理OpenMV/吴鉴鹰、电机控制PID算法我们采取“MVP”策略。即不追求大而全而是每个方向用一个周末完成一个最简单的、可演示的小项目。例如做电机控制就用手边的小车底盘实现从零到有的位置式PID控制并记录下参数整定的过程和现象。这些“小项目”的代码和报告都归档到知识库成为赛时可快速调用的“模板”。器件储备与替代方案2020年最大的痛点是器件采购不便。我们整理了一份“核心器件清单”和“替代型号清单”。比如清单里明确主控芯片除了STM32F407还可以用F103或H750需要修改引脚和时钟配置运放除了经典的NE5532TL082、OPA2182在多数场合也能替代MOS管IRF540缺货时可以用IRF520或者IRFZ44N但要注意导通电阻和栅极电荷量的差异可能需要微调驱动电路。这份清单打印出来人手一份。3. 赛题揭晓与方案决策四天三夜的战争打响比赛题目公布的那一刻空气仿佛凝固了。我们当年选的是【本科组】一道关于“绕障飞行器”的题目此处为示例实际赛题可能不同但决策逻辑相通。题目要求设计一个能自主识别并绕过障碍物的四旋翼飞行器系统。3.1 题目关键信息提取与需求分解我们没有立刻开始讨论具体实现而是花了足足两个小时“读题”。功能指标分解核心功能自主飞行、障碍物识别、绕障路径规划。性能指标飞行稳定性、绕障成功率、响应时间、续航时间。约束条件限定飞行器尺寸、最大起飞重量、禁止使用成品飞控模块意味着要从底层写控制算法。技术路径评估感知方案选择题目未限定传感器。我们评估了三种方案① 纯视觉摄像头OpenCV信息丰富但算法复杂对处理器要求高稳定性风险大。② 超声波/红外测距阵列简单可靠但探测范围有限无法提前感知。③激光雷达Lidar成本高但测距精准可生成二维点云。结合我们的技能树队友B擅长算法和稳定性优先的原则我们冒险选择了低成本二维激光雷达如RPLidar A1作为主传感器并辅以一个向下的超声波模块定高。主控方案飞行控制本身就需要大量计算姿态解算、PID控制再加上实时处理激光雷达数据并进行路径规划STM32F4的单核显然力不从心。我们果断决定采用双MCU架构一颗STM32F4专门负责飞控接收遥控器信号、运行姿态算法、输出PWM控制电机另一颗性能更强的STM32H7或树莓派Zero W作为“任务主机”负责处理激光雷达数据、运行SLAM即时定位与地图构建简化算法和路径规划并通过串口向飞控MCU发送目标航点指令。这个决策是比赛成败的关键之一。机械平台为了节省时间我们采购了成熟的四轴机架和电机电调套装。但桨叶我们准备了多组不同尺寸、材质因为后期调试发现桨叶的平衡性和效率对飞行稳定性影响巨大。3.2 详细方案设计与任务拆分方案确定后我们立即进行了任务拆分并制定了精确到小时的时间表前紧后松。第一天D1硬件集成与基础飞控调试。我的任务将两个MCU、激光雷达、超声波、电调、遥控接收机、电源模块集成到机架上。重点设计电源树使用一块3S锂电池通过多个低压差线性稳压器LDO分别给不同模块供电飞控MCU用3.3V LDO任务MCU用3.3V LDO激光雷达用5V开关稳压模块并在关键电源入口处加磁珠和去耦电容以抑制噪声。电机供电线路必须粗而短且与信号线远离。队友A的任务在飞控MCU上移植并调试一个开源的基础四轴姿态解算和PID控制程序如基于IMU的Mahony滤波。目标能让飞行器在手动遥控下稳定悬停。队友B的任务搭建任务MCU的开发环境编写驱动读取激光雷达数据并实现一个简单的“最近点”障碍物检测算法。第二天D2感知与决策联调。集成任务。我的重点是确保双MCU间通信UART稳定并做好电气隔离如使用光耦或电平转换芯片防止地线噪声干扰。队友B优化算法将激光雷达的极坐标数据转换为二维笛卡尔坐标点云并实现一个简单的“向量场直方图”算法进行实时避障方向计算。队友A修改飞控程序使其能接收任务MCU发来的“偏航角速度”或“目标航点”指令并融入底层控制循环。第三天D3系统整合与场地适应性测试。全天进行室内试飞。测试不同材质纸箱、木板、不同形状柱状、墙状障碍物的识别与绕行效果。记录所有异常数据飞行器抖动、突然偏航、传感器数据跳变等。根据测试结果动态调整PID参数、避障算法的安全距离和决策频率。第四天D4优化、录制与报告撰写。上午进行最终优化和稳定性测试。下午按照赛题要求录制功能演示视频多角度、清晰展示绕障过程。报告撰写贯穿始终我们从第一天就开始在共享文档里填充报告内容包括方案论证、电路图、程序流程图、测试数据等。最后一天主要是整理、润色和生成最终PDF。切忌把所有工作留到最后半天。4. 核心实战那些教科书上不会写的“坑”与“亮”四天比赛真正的技术成长都发生在解决一个又一个突如其来的问题上。4.1 硬件上的“玄学”问题排查问题一电机启动时激光雷达数据疯狂跳变。现象飞行器静止时激光雷达读数稳定。一旦解锁电机哪怕电机低速旋转雷达传回的点云就出现大量噪点甚至角度信息错乱。排查过程软件排查首先怀疑是任务MCU处理不过来。我们降低了雷达数据读取频率问题依旧。在雷达数据接收中断服务程序里加时间戳发现中断响应时间在电机启动后显著变长且不均匀。电源排查用示波器观察给雷达和任务MCU供电的5V和3.3V电源线。电机启动瞬间5V电源线上出现了高达500mV的尖峰毛刺这就是罪魁祸首。电调ESC中的MOS管高速开关产生了强烈的电磁干扰通过电源网络耦合到了敏感的雷达和MCU。解决方案加强电源滤波在雷达和任务MCU的电源入口处增加了一个大容量100μF钽电容并联一个小容量0.1μF陶瓷电容的组合用于滤除不同频率的噪声。同时在电源路径上串联了一个铁氧体磁珠。物理隔离重新布线将电机供电线粗线与所有信号线、传感器线严格分开必要时成90度交叉。将雷达和任务MCU的电路板用铜箔胶带包裹并接地机架地做一个简单的屏蔽。软件容错在雷达数据解析程序中增加简单的数据校验和滤波算法例如连续两次角度增量异常大的数据点视为无效。实操心得在电机、继电器等大功率感性负载系统中电源完整性和电磁兼容性EMC必须从设计之初就重点考虑。多路独立LDO供电、星型接地、充分的去耦电容和物理隔离成本不高但能避免后期很多“玄学”问题。示波器是硬件调试的“眼睛”一定要善用。问题二飞行器总是朝一个方向缓慢自旋。现象手动悬停时飞行器会不受控制地绕Z轴缓慢旋转。排查这通常是偏航轴Yaw的PID参数没调好或者IMU的陀螺仪零偏Gyro Bias未校准。解决方案精确校准IMU将飞行器水平静止放置运行校准程序采集几分钟的陀螺仪和加速度计数据计算静态零偏。关键点校准时的环境必须静止且温度应接近实际飞行环境。我们后来发现电脑风扇的热风都会导致IMU温度变化引起零偏漂移。地面测试Yaw轴响应用手抓住飞行器务必卸掉桨叶安全第一在遥控器上打Yaw方向舵通过USB线连接飞控MCU用上位机软件如匿名科创地面站观察陀螺仪Z轴数据和控制量输出是否响应及时、线性。通过调整Yaw轴的PID参数主要是P和D让响应既快速又无超调振荡。实操心得飞控调试安全是绝对红线。调参务必遵循“先内环后外环”、“先角度后角速度”、“先卸桨测试再上桨慢速测试”的原则。一个微小的参数错误都可能导致“炸机”毁掉所有努力。4.2 软件与算法上的性能博弈挑战任务MCU算力不足路径规划延迟高。现象在复杂障碍物环境下飞行器反应“迟钝”有时甚至撞上障碍物。分析经 profiling性能分析发现80%的算力消耗在将激光雷达的极坐标数据转换为直角坐标涉及大量的sin/cos计算和遍历所有点云进行障碍物检测上。优化策略启用硬件FPU和DSP库在编译选项中确保STM32H7的硬件浮点单元FPU启用并将数学库math.h替换为ARM提供的CMSIS-DSP库其中三角函数等计算经过高度优化。数据降维与分区激光雷达一圈有360个点我们不需要全部处理。首先我们只关心飞行器前方180度范围内的点。其次将前方区域划分为若干个扇形区如5度一个区只处理每个扇形区内距离最近的点这样将处理的数据量减少了一个数量级。查表法LUT替代实时计算对于sin/cos值我们提前计算好一个0-360度或0-180度的查找表精度到0.5度。坐标转换时直接查表用一次乘法和加法替代复杂的浮点三角函数计算速度提升显著。降低决策频率路径规划不需要和姿态控制一样高的频率后者需要500Hz。我们将避障算法的运行频率从50Hz降低到20Hz但通过提高控制环的频率来弥补决策延迟整体响应依然流畅。实操心得在嵌入式资源受限的环境下做算法“差不多就行”的工程思维比追求绝对的理论最优更重要。通过降低精度、减少数据量、利用硬件特性和近似算法往往能用20%的算力获得80%的效果这对比赛这种有时间限制的场景至关重要。5. 赛后复盘比技术更重要的收获提交作品的那一刻筋疲力尽但内心充实。回顾整个过程技术上的细节会随着时间淡忘但一些更深层的收获却历久弥新。5.1 团队协作的“软技能”信任与责任明确分工后就必须充分信任队友能完成他那部分。同时要对自己的模块负全责不能成为团队的短板。当硬件出现干扰问题时队友A和B没有抱怨而是立刻一起帮忙查资料、测波形这种“共患难”的感觉是团队凝聚力的核心。冲突管理在第三天调试不顺利时我们对于是否要简化算法产生了激烈争论。我主张保稳定队友B想追求更好的性能。僵持不下时我们设定了一个“决策截止时间”再试一个小时如果性能没有显著提升就回退到稳定版本。最终我们采用了折中方案。设定规则比争论对错更有效。压力下的沟通越到后期人越累脾气越急。我们约定可以说“这个方案不行”但必须跟上“我觉得可以试试……”。用建设性提案替代单纯批评。5.2 工程思维与项目管理启蒙电赛是一个微缩版的完整产品开发流程。我们经历了需求分析读题、方案设计、任务分解、并行开发、集成测试、问题排查、版本迭代和最终交付。这让我们第一次真切体会到文档的重要性没有那些详细的笔记和测试数据我们根本无法在第四天有条不紊地写出高质量的报告。版本控制是生命线当一次激进的算法修改导致飞行器失控后我们通过Git轻松地回退到了上一个稳定版本没有损失任何有效工作。测试驱动开发对每个模块如PID控制器、避障算法我们都编写了简单的测试程序如用模拟输入看输出确保其基本功能正确再进行集成。这比集成后再大海捞针式调试高效得多。5.3 对后续学习与职业发展的影响这次比赛像一把钥匙为我们打开了专业领域的大门。我硬件对电源管理、高速信号完整性、EMC设计产生了浓厚兴趣后来深入学习并选择了硬件工程师的职业道路。比赛中被EMC折磨的经历让我在以后的产品设计中格外重视这些“隐性”要求。队友A软件深入理解了实时操作系统RTOS的必要性。赛后他学习了FreeRTOS并将其应用到飞控中更好地管理多个任务姿态解算、通信、数据记录等。队友B算法认识到嵌入式AI的潜力。他开始研究如何在STM32等边缘设备上部署轻量级神经网络如TinyML用于更复杂的场景理解。2020年的电子设计竞赛是一段在特殊时期与伙伴们共同奋斗的独特记忆。它教会我们的远不止如何画一块电路板或写一段代码而是如何在压力下系统性地思考、协作与解决问题。那些在实验室里通宵达旦的夜晚那些为一个小小成功击掌欢呼的瞬间以及那些共同攻克难题后相视一笑的默契都成为了我们技术生涯中最宝贵的起点和财富。如果你也在备赛我的建议是享受这个过程珍惜你的队友大胆地去设计、去实现、去踩坑因为这一切的经历终将让你与众不同。