去年备赛时，我见过太多队伍在控制题上栽跟头。他们不是不懂PID，也不是不会写代码，而是把精力用错了地方。有的队伍花了一周时间把小车循迹的响应调得飞快，结果比赛当天因为一个电机驱动模块过热保护，整个系统直接宕机；有的队伍算法写得天花乱坠，报告里却连一张清晰的系统框图都没有，评委看得一头雾水。控制题，表面上是算法和代码的比拼，内核其实是工程化思维和风险预判能力的较量。它考验的不是你能把某个参数调到多极致，而是你能否在有限的时间里，搭建一个从传感器、执行器到控制器都稳定、可靠、可调试的完整系统。
TI杯电赛的控制类题目，无论是经典的循迹小车、平衡倒立摆，还是更复杂的视觉伺服、多机协同，其核心逻辑都是一致的：感知-决策-执行。很多新手一上来就扎进“决策”（也就是算法）的深水区，却忽略了“感知”的准确性和“执行”的可靠性才是地基。地基不稳，再精巧的算法大厦也会顷刻倒塌。这篇文章，我们不空谈理论，而是从一个经历过完整备赛周期的视角，拆解控制题备战的底层逻辑和实操路径。目标很明确：帮你避开那些“事后才明白”的坑，把有限的备赛时间，投入到真正能“稳拿奖”的关键环节上。
1. 控制题的胜负，在动手写代码之前就已决定
很多人认为电赛是四天三夜的极限编程，但真正有经验的队伍都知道，决定性的工作早在比赛开始前几个月就已经完成了。控制题的备赛，本质上是一场针对不确定性的预演和封装。你需要做的，不是期待一道完全符合你准备的题目，而是准备好一套能快速适配各种变化的“乐高积木”和“组装说明书”。
1.1 建立你的“核心武器库”：模块化与可复用性
你的武器库不是一堆散乱的芯片和代码，而是一系列经过充分测试、接口清晰、文档齐全的功能模块。在控制系统中，这些模块通常包括：
- 感知层模块：各类传感器（如编码器、陀螺仪、摄像头、超声波、红外对管）的驱动与数据滤波算法。关键不是你会用，而是你能把它封装成一个稳定的“数据源”。例如，一个封装好的编码器模块应该能直接返回经过滤波的速度和位移，而不是原始的脉冲数。
- 执行层模块：电机驱动（如TB6612、DRV8833）、舵机控制、继电器控制等。这里的重点是保护与诊断。你的电机驱动函数里，是否包含了过流保护、死区补偿、软启动？能否在驱动异常时通过LED或串口给出明确的错误码？
- 通信层模块：UART、I2C、SPI、CAN等总线的可靠收发框架。特别是要处理好数据帧的拼接、校验和超时重发。很多队伍在调试多传感器融合时，问题都出在通信丢包或数据错乱上。
- 控制算法模块：将PID、模糊控制、状态观测器等算法封装成独立的、参数可在线调整的库。例如，一个PID模块应该提供清晰的接口：
PID_Init(),PID_Calculate(),PID_SetParam()，并且内部最好集成抗积分饱和和输出限幅。
如何验证你的武器库？不要只做单元测试。进行集成压力测试：让电机长时间全速正反转，同时读取所有传感器数据并打印日志，观察系统是否会出现温度过高、数据跳变、通信中断等问题。这个过程暴露的问题，就是比赛时最可能爆发的雷。
1.2 吃透官方清单：从器件清单里读出“出题逻辑”
全国大学生电子设计竞赛官网发布的《元器件清单》是最高效的“考纲”。不要只把它当作采购列表，要学会反向解读。
- 关联性分析：清单里同时出现了“摄像头模块”和“小型直流电机”，那么视觉伺服类控制题的概率就大大增加。出现了“陀螺仪”和“加速度计”，平衡类题目（如平衡车、倒立摆）就是重点。2024年清单中的“舵机”和“超声波模块”，很可能指向需要精确角度控制和避障的题目（如2024年H题）。
- 限制性解读：清单规定了处理器型号（如STM32F103、MSP430），你就必须在其资源限制内设计系统。例如，STM32F103的RAM和Flash有限，如果你的视觉算法需要大缓冲区，就要提前优化或考虑外扩内存；如果只能用MSP430，那么算法复杂度就必须大幅降低，转向更精巧的逻辑控制。
- 拓展性准备：清单里没有直接给出，但与之强相关的器件也要准备。例如，清单有电机，你就必须备好多种规格的电机驱动模块和足够的散热片；有摄像头，就要准备好OpenMV或K210等常用视觉处理核心的备用方案和SD卡。
行动建议：根据近三年清单，制作一个“器件-可能题型”的映射表。针对每一种可能题型，用你的“武器库”快速搭建一个最小验证系统（MVP）。比如，针对“视觉+电机”，你的MVP就应该能在一天内，实现用摄像头识别一个色块，并控制电机带动云台跟随。
2. 系统设计：用一张图说清所有事，是最高效的沟通
在紧张的比赛时间里，清晰的系统设计文档是团队协作的基石，也是报告获得高分的关键。很多队伍的报告被批评“逻辑混乱”，根源在于设计阶段就没有想清楚。
2.1 从顶层框图开始：明确信息流与责任边界
不要一上来就画原理图。先画一张系统顶层框图，它应该包含以下要素：
- 物理层：标出所有传感器、执行器、主控、电源的物理连接和型号。
- 数据流：用箭头清晰标明信息流向。例如：“摄像头 -> (图像数据) -> OpenMV -> (目标坐标) -> STM32 -> (PWM占空比) -> 电机驱动 -> 电机”。
- 控制流：标出核心控制回路。例如：“编码器反馈 -> PID控制器 -> 电机”。用不同的线型或颜色区分开环和闭环。
- 关键信号与变量：在数据流旁边标注关键数据的名称和格式，如“坐标 (x,y, uint16)”、“速度 (float, m/s)”。
这张图的作用是让团队每个成员（硬件、软件、算法、报告撰写）对系统全貌达成共识，明确自己的模块处于整个链条的哪个环节，输入输出是什么。
2.2 细化到模块设计：接口定义高于一切
顶层框图确定后，每个成员负责细化自己的模块。此处的核心是定义严格的软件接口。
以电机速度控制为例，一个糟糕的接口可能是：
void Motor_Run(int speed); // 速度是多少？单位是什么？正负代表什么？一个良好的接口应该是：
// motor_driver.h typedef enum { MOTOR_DIR_FORWARD = 0, MOTOR_DIR_BACKWARD } Motor_Direction_t; typedef struct { float target_speed_rps; // 目标速度，单位：转/秒 Motor_Direction_t direction; } Motor_CtrlCmd_t; /** * @brief 设置电机控制命令 * @param cmd: 电机控制命令结构体 * @retval 0: 成功， -1: 参数错误， -2: 硬件错误 */ int32_t Motor_SetCommand(Motor_CtrlCmd_t cmd); /** * @brief 获取电机当前状态（速度、温度、错误码） */ Motor_Status_t Motor_GetStatus(void);接口定义的价值：它强制了模块间的解耦。算法同学只需要调用Motor_SetCommand()，而不需要关心PWM是如何产生的；硬件调试同学可以单独测试Motor_GetStatus()，而不需要算法参与。当出现问题时，清晰的接口和返回值能快速定位是命令问题、驱动问题还是硬件问题。
2.3 报告中的“设计部分”：框图就是你的语言
在最终的设计报告里，系统框图不是点缀，而是核心论述工具。评委通常没有时间逐行阅读你的代码，但他们一定会仔细看你的框图。
- 前后呼应：报告中“系统总体设计”部分的框图，应该与你实际实现的软件架构图、硬件原理图核心部分一致。
- 图文结合：在描述每个子模块（如“路径规划算法”）时，在旁边附上该模块的输入输出流程图或状态机图。
- 标注创新点：如果你的算法或结构有改进，直接在框图中用醒目的方式（如高亮框、虚线框加说明）标出来，让评委一眼看到你的工作亮点。
3. 算法实现：PID是起点，远非终点
PID是控制题的基石，但只会调三个参数是远远不够的。高手和普通选手的差距，在于对PID的“工程化”理解和应对复杂场景的能力。
3.1 PID调参：建立科学流程，告别“玄学调参”
很多队伍调PID靠“手感”，这是极不可靠的。你需要一个可重复、可分析的调参流程：
- 先P后I再D，分步整定：这是经典法则。先设I和D为0，增大P直到系统出现等幅振荡，记录此时的临界增益Ku和振荡周期Tu。然后根据齐格勒-尼克尔斯法则或其他经验公式计算出一组初始参数。
- 利用上位机可视化：务必使用串口绘图工具（如SerialPlot、Vofa+）或自己写的简单上位机，实时绘制设定值、反馈值、输出值、误差值曲线。眼睛比感觉可靠一万倍。通过曲线，你能清晰看到是超调大、稳态误差大还是响应慢。
- 区分响应阶段：将系统的响应分为“上升阶段”、“稳定阶段”和“抗扰阶段”。调整P主要影响上升速度和超调；调整I主要消除稳态误差，但可能引入超调或振荡；调整D主要预测变化、抑制超调，但对噪声敏感。
- 参数冻结与记录：每调好一个场景（如小车空载匀速），就把参数记录下来，并备注测试条件。换一个场景（如小车负重）后，重新微调，并对比参数变化。这能帮你理解负载、摩擦等因素对系统的影响。
3.2 应对复杂场景：给PID穿上“智能外衣”
纯PID在非线性、大滞后、多耦合的系统中会力不从心。你需要一些策略来增强它：
- 变参数PID：根据误差大小切换参数。例如，误差大时用一套强P、弱I的参数快速接近目标；误差小时换一套弱P、强I的参数精细调节。这能兼顾快速性和稳定性。
- 积分抗饱和：这是必须实现的！当执行器（如电机）已输出最大力但仍无法消除误差时，积分项会不断累积（windup），一旦误差反向，系统需要很长时间才能“消化”掉这些累积积分，导致大幅超调或振荡。解决方法是在输出限幅时，同步冻结或清除积分项。
- 微分先行与滤波：微分项对噪声极其敏感。可以对反馈值进行低通滤波后再做微分（微分先行），或者直接对误差的微分进行滤波。但要注意滤波会引入相位滞后，需要权衡。
- 串级控制：对于复杂对象（如无人机），往往采用内外环串级。内环（如角速度环）响应快，负责“抗干扰”；外环（如角度环）响应慢，负责“定目标”。内环的设定值由外环的输出给出。设计时，内环带宽应至少是外环的5-10倍。
3.3 超越PID：了解其他控制器的适用场景
虽然PID能解决80%的问题，但了解其他方法能让你在剩下的20%里找到更优解。
- 模糊控制：适用于难以建立精确数学模型、但专家经验丰富的系统。比如，对于“水温控制”，规则可以是“如果温度偏低很多，就大力加热；如果温度略低，就轻微加热”。在电赛中，可以用于决策层（如小车在弯道和直道采用不同的策略权重）。
- 状态反馈控制：适用于多变量、强耦合的系统（如倒立摆、平衡车）。通过构建系统状态空间模型，设计状态反馈矩阵，能将多个状态量（角度、角速度、位置、速度）同时控制到稳定点。这对数学建模能力要求较高，但控制效果往往更优。
- 模型预测控制：更前沿，在电赛中较少实现。但其思想——基于模型预测未来一段时间内的系统行为，并优化当前控制量——值得借鉴。你可以用简单的线性模型做一个预测步，来改善大滞后系统的控制效果。
核心建议：不要贪多。在备赛期，深挖PID，并熟练掌握一种进阶策略（如变参数PID或串级控制），远比泛泛了解多种算法更有实战价值。
4. 调试、测试与报告：把“偶然成功”变成“必然得分”
比赛最后一天，当系统基本能运行时，真正的竞争才刚刚开始。如何证明你的系统可靠？如何让你的作品在评测中稳定发挥？如何让报告为你赢得高分？
4.1 构建防御性调试体系
调试不是乱试，而是有计划的“攻击”自己的系统，寻找薄弱环节。
分层调试法：
- 硬件层：单独测试每个传感器、执行器是否工作正常。用示波器看关键信号波形，用万用表量供电电压。
- 驱动层：编写简单的测试程序，让电机正反转、舵机打角，确认驱动逻辑和硬件连接无误。
- 算法层：在静态环境下测试算法。例如，用手拿着小车移动，看编码器反馈和PID计算出的输出是否合理；手动给一个目标值，看系统响应曲线是否符合预期。
- 系统集成：最后进行动态联调。此时大部分基础问题应已解决，主要处理模块间耦合产生的新问题。
日志系统是生命线：不要只会用
printf。建立一个分等级的日志系统（如DEBUG, INFO, WARN, ERROR），通过宏定义控制编译时输出级别。将关键变量（设定值、反馈值、输出值、错误码）以固定格式定时输出到串口，方便上位机抓取分析。当系统出现偶发性异常时，这些日志是唯一的破案线索。设计“诊断模式”：为你的系统增加一个通过按键或串口命令触发的诊断模式。在该模式下，系统可以依次执行一系列自检操作（如所有舵机回中、电机慢速旋转、传感器读数打印），并输出综合健康状态。这在赛前检查阶段能节省大量时间。
4.2 模拟评测环境进行压力测试
比赛评测通常是在特定场地、连续运行多次。你需要模拟这种压力。
- 极限边界测试：让系统在参数边界运行。例如，让小车以最高速冲撞障碍物（软质），看能否恢复；让云台执行机构快速往复运动到机械限位，看是否卡死或丢步。
- 长时间疲劳测试：让系统连续运行30分钟到1小时，监测主控芯片温度、电机驱动器温度、电源电压是否稳定。很多硬件问题（如电容过热、接触不良）都是在长时间运行后出现的。
- 抗干扰测试：故意在系统附近开关大功率设备（如电钻）、使用手机通信，观察传感器数据是否受到严重干扰。思考并实施一些抗干扰措施，如软件滤波、电源隔离、信号屏蔽等。
4.3 报告撰写：用工程师的语言讲好故事
报告是向评委展示你工作的唯一窗口。它应该是一份严谨的工程文档，而不是散文。
- 结构清晰，紧扣评分点：报告目录应严格对应题目要求。通常包括：摘要、系统方案论证、理论分析与计算、电路与程序设计、测试方案与数据、结论。每个部分都直接回答题目中的某个要求或评分项。
- 数据说话，图表为王：
- 测试数据不要只写结果，要附上测试环境照片和屏幕截图。
- 性能曲线图（如阶跃响应曲线、跟踪误差曲线）必须清晰，坐标轴、单位、图例齐全。
- 将关键性能指标（如调节时间、超调量、稳态误差）整理成表格，与题目要求进行对比，一目了然。
- 突出创新，诚实说明不足：在“总结”或“创新点”部分，明确写出你设计的亮点（如某种改进的算法、独特的机械结构、高效的调试方法）。同时，也可以客观说明系统的局限性或未达标的指标，并分析原因。这体现了严谨的科学态度，有时比一味鼓吹更能赢得好感。
- 格式规范，细节制胜：统一图表编号、公式编号、参考文献引用格式。检查错别字和语法。一份排版精美、细节无可挑剔的报告，本身就传递着一种专业和认真的态度。
控制题的备战，是一个将理论知识不断工程化、产品化的过程。它要求你从“实现功能”的思维，升级到“交付一个可靠产品”的思维。这个产品要在未知的赛场环境下，在有限的资源和时间内，稳定地完成指定任务。因此，你备战的焦点，不应仅仅是某个算法的数学推导，而应是一个包含可靠硬件、稳健软件、清晰调试、完整文档的完整生命周期。当你带着这样一套经过千锤百炼的“作战体系”走进赛场时，无论题目如何变化，你都能从容地拆解、适配、实现。这种基于深厚准备的从容，才是“稳拿奖”的真正底气。
