2024年电赛H题做完了从四天三夜的实验室连轴转里爬出来想着把我们这套基于MSPM0G3507的智能小车方案完整记录下来。题目一出来身边很多人第一反应是上STM32或者直接拿Arduino改但我们最终选择了TI的MSPM0G3507做主控传感器方案锁定了8路灰度加MPU6050的组合。这套配置在电赛控制类题目里非常典型灰度负责地面循迹MPU6050负责姿态感知两者配合基本覆盖了路径识别和坡道检测两大核心场景。这篇内容主要面向正在备赛的参赛队伍或者是想用MSPM0系列快速搭建小车平台的同学我会把硬件选型、软件架构、核心代码、PID调参和踩过的坑都摊开来讲尽量做到拿过去就能复现。MSPM0G3507这颗芯片可能还没被很多人注意到但它在电赛场景下的性价比真的非常高。Cortex-M0内核主频做到80MHzFlash和RAM的配置在同级别里也算宽裕关键是集成了两个OPA、两个比较器、12位ADC和DAC外设资源非常齐全。更讨喜的是它的电源和时钟配置比老一代MSP430简单得多开箱体验接近现代MCU的直觉。我们用它同时驱动两路直流电机PWM、一路8路灰度传感器ADC采集、一路MPU6050的I2C通信外设全部打开的情况下CPU占用率依然很健康这给调试留了充足的余量。下面我按完整的项目迭代顺序把整个方案剖析一遍。1. 整体方案设计与系统架构拆解1.1 为什么选MSPM0G3507而不是STM32或Arduino电赛H题这种场景下选主控的第一原则不是性能最强而是“够用、好调、不容易翻车”。STM32F103ZET6虽然生态最成熟教材和代码满天飞但正因为大家都在用电赛现场撞车率极高而且F103的ADC和DMA配合在这一类应用中其实有点老态。Arduino的话开发效率是快但面对需要精细控制电机PWM、同时要跑姿态解算的赛题它那个抽象层吞掉的性能实在有点心疼。MSPM0G3507夹在两者之间刚好卡在甜点位置它用的是大家熟悉的Keil环境有SDK可以直接抄寄存器操作逻辑又足够透明关键外设响应速度比Arduino那种解释型封装快得多同时又不像STM32的CubeMX那一堆初始化代码那么冗余。我之前在MSPM0G3507上跑过一个简单的外设压力测试同时开启2路PWM输出、8通道ADC扫描、I2C从机通信再加上一个定时器中断做控制周期调度CPU负载也就三成左右。这种富裕的性能余量在电赛最后两天的临场改需求阶段太重要了——你永远不知道评委临时会加什么“灾难性”测试条件留出计算余量就等于留出活路。1.2 传感器方案选型的逻辑为什么是8路灰度加MPU6050灰度传感器在循迹小车里属于“传统艺能”但多少路才算够是个经常被低估的问题。我们见过很多队伍用2路或4路结果一到急转弯就飞出赛道。8路的优势在于它能把赛道的“横向位置信息”量化成一个连续的概念而不是简单的“左偏了/右偏了”这样离散的判断。我们用的灰度模块有8个探头一排排开间隔大约1厘米总检测宽度大约8厘米配合20厘米左右的车体宽度能非常稳定地识别出小车相对赛道中心线的偏移量这个偏移量可以直接作为PID控制器的误差输入。MPU6050在这套方案里解决的是“坡道怎么办”的问题。纯灰度方案一上坡就发懵因为坡道会改变灰度传感器的反射距离导致信号跳变甚至丢失。这时候就需要姿态信息来辅助判断通过MPU6050读取加速度计数据解算出小车的俯仰角pitch一旦俯仰角超过设定阈值就判定小车正在上坡或者下坡。这个信息可以用于切换控制策略——比如上坡时增大电机PWM输出补偿重力分量下坡时降低速度避免冲过头如果题目要求坡道停车姿态数据更是唯一的判断依据。1.3 系统总体架构和控制流程整个系统的信号流是这样的8路灰度传感器通过模拟量输出接到MSPM0G3507的ADC通道MPU6050通过I2C上报三轴加速度和三轴角速度主控在固定时间周期内我们用的是5ms中断采集所有数据运行位置环PID计算转向控制量同时运行姿态环判断当前车体状态最终输出两路PWM分别控制左右后轮实现差速转向。这里我们用了一个大型状态机来组织整个控制逻辑把小车的行为拆成“基础循迹”“坡道模式”“停车模式”“异常复位”几个状态让代码结构和比赛现场的调参动作都变得非常清晰。2. 硬件细节从选型到电路连接的完整记录2.1 主控板与电机驱动板的选择MSPM0G3507市面上能买到的核心板选择不算太多我们用的是官方风格的LaunchPad改版板型把排针用排母引出来方便飞线。电机驱动方面考虑到电赛小车通常用两个直流减速电机加万向轮的结构我们选了经典的TB6612FNG模块。这个选择基于两个原因一是它的逻辑电压范围能稳定兼容3.3V的MSPM0G3507不需要额外电平转换省去一堆麻烦二是它的最大持续电流达到1.2A/通道驱动常见的N20电机或者微型RS-380电机都绰绰有余。电源系统是个最容易被忽略但也最容易翻车的地方。我们用了两节18650锂电池串联供电标称7.4V经过一个低 dropout 的5V降压模块给主控板和传感器供电电机则直接由7.4V电池供电中间不经过稳压。这样设计是因为电机的启动瞬间电流可以达到1A以上如果和主控共用稳压后的电压轨很容易把MCU的供电电压拉低导致复位。灰度传感器模块我们专门用了一个单独的3.3V LDO供电因为TCRT5000红外发射管的电流会随供电电压波动而改变供电稳了ADC读数的稳定性才有保证。2.2 灰度传感器的安装布线与阈值校准灰度传感器的安装位置很有讲究。我们吃了一个亏之后才摸到正确姿势传感器排布应该尽量贴近车体前缘距离地面高度控制在1.5厘米到2厘米之间。高度太低遇到赛道接缝或者轻微颠簸会刮到地面高度太高环境光的干扰会明显增加而且黑白线之间的电压反差会变小。安装时还要保证8路传感器的扫描线与车体中轴线严格垂直最好用尺子量着贴双面胶不然左右两端的传感器实际检测宽度不一致会导致PID控制量的对称性出问题。灰度模块一般支持模拟输出和数字输出两种模式。我们在比赛里用的是模拟输出因为模拟量保留了“灰度深浅”的信息可以通过ADC读取到相对连续的值比数字输出只返回0/1要精细得多。校准流程上我在每次比赛前会做一次“白底黑线标定法”把小车放在全白赛道上读取8路ADC的原始值记为white[i]再把传感器对准黑线用黑色胶带模拟读取原始值记为black[i]。实际使用时归一化灰度值gray[i] (adc[i] - black[i]) / (white[i] - black[i])这样每一路传感器都有了统一的比较基准即使8个探头的个体差异很大比如发射管光强不完全一致也能在算法层被抹平。2.3 MPU6050连接与供电细节MPU6050模块我们用的是常见的“GY-521”兼容板注意这类模块通常板载了10k上拉电阻和滤波电容I2C通信可以直接和MCU对接。接线方面SDA连到MSPM0G3507的I2C数据引脚SCL连到I2C时钟引脚VCC接3.3VGND务必和主控共地。这里有一个容易被忽略的地方MPU6050的中断引脚INT是可以接到主控EXINT上的但我在第一版代码里没接中断而是用主控定时器每5ms去轮询读取一次数据。实测下来完全够用还能少写一个中断服务函数少一个调试变量。MPU6050的零点偏移是另一个大坑。陀螺仪的零偏和加速度计的零偏都会导致姿态解算结果出现缓慢漂移或者角度固定偏差。所以每次上电启动后我在主控里强制小车静止2秒在这2秒内连续读取100次加速度和角速度原始数据求平均把这组平均值作为“零点基准”存到一个全局结构体里之后每次读取数据都先减去这个基准值再参与解算。这个校准逻辑代码量不大但对后续的坡道检测精度提升是决定性的。如果不做这步坡道角度判定阈值可能就会偏掉两三度比赛时上小坡就不触发或者平地误触发。3. 核心代码逻辑与关键模块实现3.1 灰度数据的读取与归一化处理灰度数据的采集是整套循迹系统的最底层基础。我们在MSPM0G3507上开了8路ADC通道采用常规的单次采样模式。对于这个应用场景采样率完全不是瓶颈8路全部采完也就几十微秒的时间在一个5ms控制周期内只占极小比例。为了保证采样稳定ADC的采样时间我们手动调到了最大档位因为灰度传感器返回的信号是未经放大的模拟量内阻相对较高采样时间太短会采到电容充放电过程中的中间电压导致数据跳变。归一化处理这一步很多人觉得可有可无但它直接决定了PID能不能调得顺。假设某一路传感器漂移比较大白色时ADC读数是3000黑色时是500另一路白色时是2500黑色时是800如果不做归一化直接算位置误差那前一路的“灵敏度”就比后一路高PID会觉得小车一会儿偏左一会儿偏右怎么调参数都救不回来。归一化之后两路的输出都映射到接近0到100的区间同一套PID参数才能生效。归一化的C代码核心逻辑如下float gray[8]; uint16_t adc_raw[8]; void readAndNormalizeGray(void) { for (int i 0; i 8; i) { adc_raw[i] ADC_readChannel(i); if (adc_raw[i] black[i]) adc_raw[i] black[i]; if (adc_raw[i] white[i]) adc_raw[i] white[i]; gray[i] (float)(adc_raw[i] - black[i]) / (float)(white[i] - black[i]); if (gray[i] 0.15f) gray[i] 0.0f; if (gray[i] 0.35f) gray[i] 1.0f; } }这里我做了两个额外的滤波动作。一是钳位防止偶发的超量程值跑进归一化公式二是加了死区判断把0.15以下的都当绝对黑线处理0.35以上的都当绝对白底处理。这看起来像“糊弄”实际上是为了抑制噪声在阈值边界处带来的连续抖动——你肯定不希望灰度值在0.2附近反复横跳导致PID误差信号在那里振荡。3.2 位置误差计算与PID控制器有了8路归一化灰度值下一步就是把这一组布尔量或者说连续量转换成一个“小车偏离赛道中心线多少”的标量。我用的方法是“加权重心法”。给每一路传感器预设一个空间位置坐标比如从左边数第一路是-7第二路是-5一路排到右边第四路是7。然后计算误差公式error sum(gray[i] * pos[i]) / sum(gray[i])如果黑线刚好在正中央黑色的那一路对应的gray1其他路接近0所以误差约等于它自己的坐标也就是0。如果黑线偏右误差会是一个正值控制器需要让小车右转来追线。如果小车完全压在线上导致多路传感器同时检测到黑色这个公式的加权平均就会自动得出一个介于两者之间的误差信息和真实偏移的重合度非常高。PID控制器的实现我们用的是位置式PID表达式是output Kp * error Ki * integral Kd * derivative参数整定顺序是先P后I再D。先只保留Kp从小到大慢慢加直到小车在线附近出现轻微的左右摆动这时的比例响应已经基本能跟上赛道曲率了。然后加一点Ki消除稳态误差但由于循迹系统的积分项很容易导致过冲我们给Ki加了积分限幅只允许积分累积在一个很小的范围内。最后加Kd抑制摆动Kd对噪声非常敏感所以在代入Kd之前我们把误差信号做了简单的低通滤波否则灰度传感器的微小抖动会被微分项放大成PWM的巨大波动小车跑起来像喝醉了一样。下面是PID实现的核心代码float pidUpdate(float error) { integral error * dt; if (integral integralLimit) integral integralLimit; if (integral -integralLimit) integral -integralLimit; derivative (error - lastError) / dt; lastError error; float out Kp * error Ki * integral Kd * derivative; return out; }这个dt就是我之前说的5ms控制周期的长度也就是0.005秒。这里有个细节dt必须和定时器中断的实际周期严格一致如果你设置了5ms那所有涉及积分的运算都应该用0.005不能图省事直接写1否则Ki的含义就不是“每秒的积分增益”了只能靠乱凑参数去掩盖数学错误。3.3 MPU6050初始化与姿态解算MPU6050的初始化流程不算复杂但需要细心。上电后先等待50ms让传感器内部完成上电自检然后通过I2C往电源管理寄存器地址0x6B写入0x00唤醒传感器。接着配置加速度计量程为±4g寄存器0x1C陀螺仪量程为±500°/s寄存器0x1B这个组合适合小车运动场景太小容易超量程太大则分辨率不足。我们没开FIFO和中断简化了驱动代码。姿态解算方面我们没用官方的DMP库因为DMP在MSPM0G3507上移植有点折腾而且我们只需要一个俯仰角用互补滤波就足够了。互补滤波的原理很直白加速度计在静态时非常准但动态时容易被线性加速度干扰陀螺仪在动态时响应快但会积分漂移。所以把两者按权重融合角度 0.98 * (上一时刻角度 角速度 * dt) 0.02 * 加速度计计算角度。这个0.98和0.02的权重是经验值它对“快速响应”和“抗漂移”做了折中。俯仰角pitch的计算公式如下#define ALPHA 0.98f float calculatePitch(float ax, float ay, float az, float gx, float dt) { float accelPitch atan2f(-ax, sqrtf(ay * ay az * az)) * 180.0f / PI; float gyroPitch pitch gx * dt; pitch ALPHA * gyroPitch (1.0f - ALPHA) * accelPitch; return pitch; }这里有一个坑必须提atan2f参数里ax的正负号和加速度计模块安装方向直接相关。如果你把MPU6050的X轴方向和车头方向保持一致那么上坡时加速度计的ax会输出一个负值atan2f的结果才是正值。我们第一次装机时没注意方向导致上坡时解算出来的pitch成了负数坡道检测逻辑怎么调都不对。排查到后面才发现是加速度计的方向跟车头方向差了180度后来直接在代码里把ax取反解决了没有再去改硬件焊接。这个问题的排查办法很简单用手慢慢抬起车头看串口打印的pitch值有没有跟着往正方向走。3.4 坡道检测与模式切换检测坡道的核心逻辑是设置一个pitch阈值。我们经过实测把阈值定在5度。也就是说一旦互补滤波解算出的俯仰角绝对值超过5度状态机就从“平路循迹模式”切换到“坡道模式”。这个5度不是随便拍的它是基于赛道实际坡度和MPU6050噪声水平反复试出来的。如果阈值太低平路上电机震动带来的微小倾角变化会误触发阈值太高遇见短坡可能还没来得及反应小车就已经冲上去了。坡道模式里我们做了两个事。第一是调整目标速度上坡时PWM基础的占空比增加15%左右补偿重力分量导致的速度下降下坡时反之把占空比降低20%防止小车越滑越快最后冲出赛道。第二是用pitch数值做闭环修正目标车速 基础车速 K_slope * pitch其中K_slope是一个需要实测的增益。这样做的好处是闭环里自动适配不同的坡度不用针对每种坡调一套参数。停车场景我们用了两段式逻辑如果检测到pitch逐渐增大并稳定在一个正向角度超过1秒同时灰度传感器全部变成全白或者全黑视赛道设计要求就判定小车到达了停车区域此时切断电机输出并打开一个100ms的刹车时间。刹车时间很关键因为直流减速电机的机械刹车不像伺服电机那么干脆直接切断PWM的话小车会因为惯性继续滑行10厘米左右这个距离在严格的停车精度测试里是完全不可接受的。4. 控制周期、状态机与整体调度4.1 5ms控制周期里到底做了什么为了保证系统的实时性我们把所有控制逻辑都塞进了一个5ms的定时器中断里。这个中断服务函数的结构非常清晰每进来一次就按顺序执行这些步骤第一步读取8路灰度ADC并做归一化。第二步读取MPU6050原始数据减去零点偏移解算pitch角。第三步计算灰度位置误差跑PID得出转向输出。第四步根据当前状态机的状态结合pitch和灰度信息判断是否需要切换状态。第五步根据状态和目标速度计算左右轮的目标PWM值更新寄存器。整个中断服务函数的执行时间实测大概在200微秒左右只占到5ms控制周期的4%剩下大量时间主循环几乎是空的。这个时间余量非常重要因为调试时你永远要往中断里临时塞一些调试代码比如把某几个变量通过串口发出来观察波形如果中断已经跑到七八成负载再塞代码很可能就出现时序错乱。空余时间多的好处在电赛现场简直救命。为什么控制周期选5ms而不是更短或者更长我解释一下这个选择背后的循环逻辑电赛小车的最高速度我们设到每秒0.8米左右赛道上的急转弯半径大约20到30厘米换算下来车头指向角速度大概每秒几百度的级别。如果控制周期50ms也就是每秒执行20次控制那么小车在转弯过程中误差的更新间隔太长了PID输出的是一段一段的阶跃控制效果非常粗糙如果周期1ms算力不是问题但灰度传感器和MPU6050的物理响应时间本身就有限过快的控制周期只会放大噪声对性能提升没有帮助。5ms是平衡了赛道物理特性、传感器带宽和MCU负载之后的一个公认甜点值。以下是我用的定时器初始化代码基于MSPM0 SDK的写法抽象成配置函数void setupTimerForControl(void) { GPIO_InitPeripheral(); DL_TimerG_setCaptureCompareValue(TIMER_0, 5000 - 1, DL_TIMER_CC_0_INDEX); DL_TimerG_initPWMMode(TIMER_0, DL_TIMER_CLOCK_DIVIDE_1, DL_TIMER_PWM_MODE_EDGE_ALIGN, DL_TIMER_CC_0_OUTPUT_ENABLE); NVIC_EnableIRQ(TIMER_0_IRQn); }这里的5000是根据80MHz主频和16位定时器预分频算出来的。因为80MHz分频1就是80MHz80MHz除以5000等于16kHz而我们要的是200Hz控制频率所以再配合一个80MHz/16kHz5000的计数上限最终中断频率就是200Hz也就是5ms周期。可以直接把这类参数在初始化时确认一遍不要想当然。4.2 状态机实现要点状态机的实现我是用了一个枚举类型的state变量加一个switch-case来处理的。核心的状态有这么几个STATE_INIT: 上电校准姿态静止2秒然后自动切到STATE_DRIVE。STATE_DRIVE: 常规循迹模式PID控制转向检测到坡道信号后切到STATE_SLOPE。STATE_SLOPE: 坡道模式沿用PID但叠加坡度速度补偿驶出坡道pitch绝对值小于2度后切回STATE_DRIVE。STATE_STOP: 停车模式关电机刹车100ms之后小车保持静止。状态机的优势在于当比赛现场突然出现“小车怎么一上坡就冲过头”这种现象时你不至于去翻一大堆逻辑代码只需要在关键切换点打印一条串口日志看小车到底卡在哪个状态、为什么没有切出去。我们那个失败版本里就出现过pitch角由于滤波深度不够在坡道入口处跳了两三次阈值导致状态在DRIVE和SLOPE之间来回弹跳的问题——这个在纯逻辑写死的代码里可能看不出来但用状态机一眼就能从日志里发现它在状态间“抽搐”。4.3 串口调试技巧让小车回答你“它到底在想什么”电赛现场调试最怕的就是小车跑起来之后你完全不知道它内部的状态变量是什么。所以在整套代码里我们在所有关键事件点都埋了串口打印。比如每次状态切换时打印“SWITCH TO SLOPE MODE”PID输出变化超过阈值时打印“PID OUT XX”灰度归一化数组中某个关键时刻也把8个值整组打印出来。串口的波特率我们设了115200每5ms中断里如果直接打印所有数据串口肯定来不及发完所以我们在主循环里做了“慢速打印”策略每100ms集中打印一次完整的状态帧。这个帧格式就是一行逗号分隔的浮点数可以直接用串口助手的波形显示功能画出来。加上后面将提到的斜坡测试我们靠这套日志手段把问题定位的时间缩短到了原来的三分之一。5. 常见问题与排查技巧实录5.1 编译链接报undefined symbol mpu6050怎么办这个报错我相信是所有学着做题目时都查过的经典错误。完整信息很长核心是.\objects\project.axf: error: l6218e: undefined symbol mpu6050出现这个符号找不到的报错几乎永远是同一个原因你在某个地方调用了mpu6050开头命名的函数但是编译器在链接阶段在它所有能看到的源文件里找不到这个函数的定义体。很多时候是因为MPU6050的驱动源文件比如mpu6050.c没有加进工程或者函数名拼写不一致。排查方法是先在工程里搜一下“mpu6050”这个字符串看看这个源文件在不在编译列表里。Keil的project窗口里把mpu6050.c加进去重新编译一般就解决了。还有一种比较隐蔽的情况是头文件保护宏冲突导致函数定义被条件编译跳过了这时候检查一下整个工程里有没有重名的宏。5.2 灰度传感器在强光环境下失效比赛场地如果灯光很强或者赛道上有窗边直射的太阳光灰度传感器的表现会骤降。这是因为TCRT5000的红外发射和接收都是开放式的环境光里包含红外分量会直接叠加到反射光信号上导致黑白反差变小。解决的办法有几个层面。硬件上可以在传感器探头上加装遮光罩我们用的是3D打印的小圆柱套筒效果立竿见影。软件上在归一化标定环节必须做到“比赛现场的灯光条件下标定”而不是在实验室里标定。因为我们用的归一化公式是基于黑、白两个参考点的线性映射只要现场标定过环境光的影响就可以被很大程度抵消掉。5.3 MPU6050数据抖动和零点漂移在Debug模式下用串口打印MPU6050的原始数据时你可能会看到在静止状态下加速度计的各个轴输出也会有小幅度的波动幅度大概在±20个LSB左右。这些抖动经过互补滤波后会衰减很多但如果滤波系数ALPHA设得太大比如0.995角度就会变得过度平滑导致坡道入口处的检测反应变慢了一拍。如果设得太小比如0.9抗抖动能力又会下降平路上频繁跳阈值。我们的经验值是0.98到0.99之间大家可以在这个范围内用实际赛道测试来选择。5.4 小车循迹时不断画龙蛇形走位画龙是PID调参里最经典的问题。现象是小车在直道上不会走直线而是左右偏摆幅度越来越大。我排查这个问题的思路是先把速度降到很慢比如PWM占空比20%然后观察小车的画龙频率和幅度。如果频率高、幅度小多半是P太大输出对误差反应过激如果频率低、幅度大还伴随胶合感多半是D太小缺少阻尼。还有一个很常见的问题是里程计轮子的差速特性不同左右电机即使给同样的PWM实际转速也可能差上10%以上这会导致直道上小车慢慢偏向一侧。这时在代码里加一个“左右电机占空比修正系数”把左右PWM值乘以不同的系数来弥补机械偏差。5.5 坡道检测失灵我们踩过最大的一个坑是上坡时pitch角的变化幅度只有预期的一半。排查了半天最后发现是MPU6050的安装位置太靠近电机电机的磁场干扰了IMU。更换安装位置用双面胶把它移到车体中央并尽量远离电机线圈之后数据立刻恢复干净。这是一个非常容易被忽视的物理层面的干扰问题如果遇到了先别怀疑代码先看数据通过串口打印再回头怀疑算法。5.6 电池电压下降导致性能不稳电赛小车如果用锂电池供电在满电到接近亏电的过程中电机上的实际电压会逐渐下降同样占空比下电机的转速也会下降这会直接导致小车循迹的稳定性变差。我们的应对方案是在主控里实时检测电池电压用ADC读取分压电阻然后根据电压折算出一个校正系数把目标PWM值乘这个系数相当于做了一个开环的电压补偿。6. 写在最后一些实在话做H题这几天最大的感受是一套牛逼的方案固然重要但真正决定比赛成绩的是备案的深度和现场排坑的速度。MSPM0G3507这颗MCU用下来整体是满意的SDK虽然有一些小瑕疵但外设的灵活性足以cover电赛控制题的所有硬需求。8路灰度加MPU6050的方案组合在继承传统循迹方案的稳定性的同时把坡道检测这种“难点升级”变得既不复杂又足够可靠。如果你明年也打算打电赛控制类强烈建议提前用这套组合多跑几种场地把每个坑都提前踩一遍这样真正上场的时候你就不是在做题而是在做验收。个人最大的体会是——调PID不要急带着数据去调小车从来不会骗你它只是不太会说话而已。