简介：这是一份面向嵌入式初学者与智能小车爱好者的STM32红外循迹避障小车完整程序，基于ARM Cortex-M内核微控制器，结合红外传感器实现路径跟踪与障碍物规避，适合用于课程设计、电子竞赛或自学STM32外设驱动与实时控制。压缩包共92个文件，约318KB，以C源码与头文件为主体（33个.c、35个.h），并包含汇编启动文件、Keil工程文件（uvprojx、uvoptx）、编译生成的hex固件及readme说明，覆盖初始化配置、中断服务、传感器数据处理与电机PWM控制等模块。目前已有10787人学习下载，热度较高。读者可从中获得可直接编译的工程框架、红外信号采集与滤波思路、循迹与避障的电机控制逻辑，以及基于Keil的调试排错参考，便于在实物平台上验证响应速度与稳定性。
1. 从一堆“能跑但不敢改”的源码说起：这套 STM32 红外循迹避障小车程序到底值不值得拆
如果你搜到过“基于 STM32 的红外循迹避障小车程序”，大概率会看到两种极端：一种是只有主函数、引脚定义全靠猜的“半成品”；另一种是工程文件齐全、但注释稀薄、改一个阈值就翻车的“黑匣子”。我这次拆的这套 C 程序资源，属于后者里相对规整的那类——它把循迹、避障、电机驱动、红外采样几条线拆得比较清楚，不是那种把所有逻辑塞进while(1)的写法。
它解决的核心问题很具体：让一辆基于 STM32 的小车，在红外对管阵列的灰度反馈下完成循迹，同时用红外避障模块做前方障碍检测，并在两者冲突时给出一个可调的优先级策略。适合谁？适合已经点过 LED、调过串口，但第一次把“传感器采样—决策—PWM 输出”串成闭环的嵌入式新手；也适合手上有车、但程序逻辑乱成一团、想找一份能读得下去的参考实现的熟手。值不值得下？如果你正卡在“循迹能走但一遇到障碍就发呆”或者“避障触发后回不到线上”这类问题上，这份程序里的状态切换写法比很多教程都实在。
2. 循迹与避障的代码骨架：从红外采样到 PWM 输出的完整链路
2.1 为什么这套程序把采样和决策分开写
很多小车程序翻车，不是因为算法多复杂，而是因为把红外采样、循迹判断、避障判断、电机输出全揉在一个定时器中断里。这套程序的做法是：用 SysTick 或一个基本定时器做 5ms 节拍，在节拍里只做三件事——采样红外对管、更新避障标志、调用决策函数。决策函数本身不碰 GPIO，只输出一个“目标动作”枚举，最后由电机执行层去换算 PWM 占空比。
这样拆的好处是，当你发现小车在黑色胶带边缘抖动时，可以单独把采样结果通过串口打出来看，而不用在电机转动的情况下去猜是传感器问题还是逻辑问题。常见做法是给循迹红外阵列留 3 到 5 路，避障红外留 1 到 2 路，程序里用位掩码表示状态，比用一堆if判断更省事。
// 红外状态位定义：bit0~bit2 循迹左中右，bit3 避障前 #define TRACE_L (1 << 0) #define TRACE_M (1 << 1) #define TRACE_R (1 << 2) #define AVOID_F (1 << 3) // 5ms 节拍里调用的采样函数，只更新全局状态，不做决策 void IR_Sample(void) { static uint8_t filter[4] = {0}; uint8_t raw = 0; // 假设低电平有效，具体极性按你的模块改 if (!HAL_GPIO_ReadPin(TRACE_L_GPIO_Port, TRACE_L_Pin)) raw |= TRACE_L; if (!HAL_GPIO_ReadPin(TRACE_M_GPIO_Port, TRACE_M_Pin)) raw |= TRACE_M; if (!HAL_GPIO_ReadPin(TRACE_R_GPIO_Port, TRACE_R_Pin)) raw |= TRACE_R; if (!HAL_GPIO_ReadPin(AVOID_F_GPIO_Port, AVOID_F_Pin)) raw |= AVOID_F; // 简单滑动滤波：连续两次相同才认，抑制反光毛刺 for (int i = 0; i < 4; i++) { if ((raw & (1 << i)) == (filter[i] & (1 << i))) { // 保持 } else { filter[i] = raw & (1 << i); } } g_ir_state = filter[0] | filter[1] | filter[2] | filter[3]; }这段代码里filter数组的用法是典型的“连续两次一致才更新”，比单纯延时去抖更省 CPU。参数上，5ms 节拍对应 200Hz 采样，对小车速度在 0.3 到 0.8 米每秒的场景足够。如果你把节拍改成 1ms，滤波窗口会变短，反光干扰会重新冒出来；改成 20ms，循迹响应会明显滞后，过弯容易冲出去。
2.2 决策层怎么写才不会“避障完找不到线”
避障和循迹冲突是这类小车的经典坑。这套程序里有一个g_avoid_flag，当避障红外持续触发超过 3 个节拍（15ms）时置位，决策层进入避障模式：先停车，再后退一小段，然后原地转向。关键在于转向后不是立刻回到循迹，而是先清空避障标志，再等循迹状态稳定 2 个节拍才恢复。
typedef enum { MODE_TRACE, MODE_AVOID, MODE_STOP } car_mode_t; car_mode_t g_mode = MODE_TRACE; uint8_t g_avoid_cnt = 0; void Car_Decide(void) { if (g_ir_state & AVOID_F) { g_avoid_cnt++; if (g_avoid_cnt >= 3) g_mode = MODE_AVOID; } else { g_avoid_cnt = 0; if (g_mode == MODE_AVOID) { // 避障结束后不立刻回循迹，先停一拍 g_mode = MODE_STOP; } else if (g_mode == MODE_STOP) { g_mode = MODE_TRACE; } } switch (g_mode) { case MODE_TRACE: // 根据 g_ir_state 的 bit0~bit2 做差速 Trace_Action(g_ir_state & 0x07); break; case MODE_AVOID: Avoid_Action(); // 后退 + 转向 break; case MODE_STOP: Motor_Set(0, 0); break; } }这里g_avoid_cnt >= 3是避障确认次数，防止地面反光或深色接缝误触发。MODE_STOP那一拍是很多程序漏掉的“后悔药”——没有它，避障转向后如果立刻按循迹走，车会朝着刚避开的障碍方向猛打，看起来像“抽风”。参数上，后退时长和转向占空比需要按你的电机减速比调，常见做法是后退 150ms、转向 200ms，占空比给 60% 到 70%。
2.3 电机执行层：PWM 频率和死区怎么定
执行层一般用 TIM 的四个通道输出两路互补 PWM，或者用两个通道分别控制左右电机的方向和使能。这套程序里用的是后者：每个电机一个 PWM 通道调速，两个普通 GPIO 控制方向。PWM 频率建议 10kHz 到 20kHz，低于 5kHz 电机会有可闻啸叫，高于 20kHz 部分驱动芯片发热会明显。
// 电机执行层：入参为 -100 到 100 的百分比 void Motor_Set(int16_t left, int16_t right) { // 方向控制 if (left >= 0) { HAL_GPIO_WritePin(MOTOR_L_DIR_GPIO_Port, MOTOR_L_DIR_Pin, GPIO_PIN_SET); } else { HAL_GPIO_WritePin(MOTOR_L_DIR_GPIO_Port, MOTOR_L_DIR_Pin, GPIO_PIN_RESET); left = -left; } // 右电机同理，略 // 限幅，防止占空比超过 100 if (left > 100) left = 100; if (right > 100) right = 100; // 假设 TIM 自动重装值为 999，则比较值 = 百分比 * 10 __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_1, left * 10); __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_2, right * 10); }left * 10这个系数来自 ARR=999 的设定，如果你改成 ARR=1999，系数要变成 20。很多新手改完定时器配置忘了改这里，结果小车要么不动要么全速，查半天以为是传感器坏了。另外，电机启动瞬间电流大，建议在Motor_Set里加一个斜率限制，比如每次调用最多变化 20%，否则电池电压会被拉低导致 MCU 复位。
3. 把程序烧进车之前：工程配置、引脚核对与串口调参
3.1 时钟树和 GPIO 模式别照抄
这套程序基于 HAL 库，工程里默认用的是外部晶振加 PLL 到 72MHz。如果你手上的板子是 8MHz 晶振，直接烧进去可能跑不起来，因为SystemClock_Config里的 PLL 倍频参数对不上。常见做法是先用 CubeMX 按你的实际晶振重新生成时钟配置，再把程序里的外设初始化替换掉。
GPIO 模式上，红外输入建议配成上拉输入或浮空输入，具体看模块输出类型。很多红外对管模块输出是开漏的，必须上拉；如果配成浮空，读数会乱跳。避障红外如果是数字输出，同样处理。电机方向引脚配推挽输出，PWM 引脚配复用推挽。
# 用 ST-Link 烧录的典型命令，OpenOCD 环境 openocd -f interface/stlink.cfg -f target/stm32f1x.cfg \ -c "program build/car.elf verify reset exit"这条命令里target/stm32f1x.cfg要按你的芯片系列换，F4 系列换成stm32f4x.cfg。verify会回读校验，reset exit让芯片复位后运行。如果你用 Keil 或 IAR，直接点下载就行，但建议勾选“Reset and Run”，否则烧完还要手动按复位。
3.2 串口调参：把红外状态打出来看
程序里留了一个串口输出，每 100ms 打印一次g_ir_state和当前模式。调车之前先别装车，把车架空，用手遮挡红外对管，看串口助手里状态位变化是否跟预期一致。这一步能省掉后面大量“到底是线没贴好还是程序没写对”的扯皮。
| 打印字段 | 含义 | 正常表现 |
|---|---|---|
| IR_STATE | 红外状态位 | 遮挡对应管时对应 bit 翻转 |
| MODE | 当前模式 | 遮挡避障管时从 TRACE 变 AVOID |
| L_PWM/R_PWM | 左右占空比 | 循迹偏差越大，差值越大 |
如果遮挡后状态位不变，先查模块供电和输出极性；如果状态位变了但模式不变，查g_avoid_cnt的阈值是不是设太高。串口波特率一般 115200，如果你用 9600 会看到乱码，别以为是程序跑飞了。
3.3 电池和电机驱动的匹配
这套程序默认电机驱动是常见的双 H 桥模块，逻辑电平 3.3V 兼容。如果你用的驱动模块需要 5V 逻辑，而 STM32 输出只有 3.3V，可能会出现“信号认不到、电机不转”的情况。解决方法是加电平转换，或者选 3.3V 兼容的驱动。电池方面，7.4V 锂电配 5V 降压给 MCU 是常见方案，但电机启动瞬间压降可能让 5V 跌到 4V 以下，导致 MCU 复位。在电源入口并一个 470uF 到 1000uF 的电解电容，能明显改善。
4. 避坑与排查：红外小车最容易翻车的五个地方
4.1 现象：小车原地打转，串口显示循迹状态一直在跳
原因：红外对管离地高度不对，或者地面反光太强。常见的高度是 1cm 到 2cm，太高灵敏度不够，太低容易蹭地。反光地面（比如瓷砖）会让接收管一直收到反射，状态位全亮或全灭。
解决：先调高度，用串口看状态是否稳定。如果地面反光，给对管加遮光套管，或者换用调制式红外模块。程序里也可以把滤波窗口从 2 次加到 4 次，代价是响应变慢。
4.2 现象：避障触发后车后退，但退完就停住不动了
原因：MODE_STOP那一拍没有正确退出，或者退出条件写成了“避障标志消失”，而车后退后避障标志确实消失了，但程序卡在 STOP 里等一个永远不会来的条件。
解决：检查Car_Decide里 STOP 到 TRACE 的切换是不是只依赖g_avoid_cnt == 0。如果是，后退结束后避障管不再触发，g_avoid_cnt归零，但模式切换需要额外一个节拍。可以在 STOP 里加一个计数器，停满 2 个节拍强制回 TRACE。
4.3 现象：PWM 输出正常但电机不转，摸驱动芯片发烫
原因：方向引脚和 PWM 引脚接反，或者驱动模块的使能脚没拉高。发烫通常是 H 桥上下管直通，多半是方向控制逻辑写错，比如左电机正转时右电机也在正转但被机械卡住。
解决：先断开电机，用万用表测驱动输出；再单独给方向引脚高低电平，看输出是否翻转。程序里Motor_Set的方向判断要跟实际接线一致，别迷信“左正右负”的默认。
4.4 现象：烧录后程序不跑，或者跑几秒就复位
原因：时钟配置不对导致主频异常，或者电源压降触发欠压复位。前者表现为串口无输出或波特率错乱，后者表现为电机一动就复位。
解决：先用调试器看SystemCoreClock的值是不是预期频率。电源问题就在电池入口加大电容，或者给电机和 MCU 分开供电。另外，看门狗如果开了没喂，也会复位，检查IWDG初始化。
4.5 现象：循迹能走直线，但过弯道时冲出去
原因：差速响应太慢，或者循迹状态判断只用了“左中右”三路，弯道时中间管还没压线，左右管已经悬空，程序却还在按直走处理。
解决：把决策层里的差速比例调大，或者增加“预判”——当左管或右管单独触发时，提前给反向差速。参数上，直走时左右占空比 50%，单侧触发时降到 20% 到 30%，另一侧升到 70% 到 80%。具体值要在架空状态下用串口看 PWM 变化，再落地试。
5. 进阶调法：用状态机表替代 if-else，以及一个验证循迹稳定性的土办法
这套程序读到最后，你会发现决策层虽然能用，但if-else嵌套多了以后，改一个模式容易碰坏另一个。我一般会把它重写成状态转移表：行是当前模式，列是红外状态，格子里是下一个模式和动作。这样加一个“死区直行”或者“急弯减速”只需要改表，不用动逻辑。
typedef struct { car_mode_t next_mode; int16_t left_pwm; int16_t right_pwm; } trans_t; // 行：当前模式，列：红外状态（简化成 4 种） static const trans_t trans_table[3][4] = { // TRACE 模式：直、左偏、右偏、避障 {{MODE_TRACE, 50, 50}, {MODE_TRACE, 25, 70}, {MODE_TRACE, 70, 25}, {MODE_AVOID, 0, 0}}, // AVOID 模式：统一后退转向 {{MODE_AVOID, -40, 60}, {MODE_AVOID, -40, 60}, {MODE_AVOID, -40, 60}, {MODE_AVOID, -40, 60}}, // STOP 模式：停一拍 {{MODE_TRACE, 0, 0}, {MODE_TRACE, 0, 0}, {MODE_TRACE, 0, 0}, {MODE_TRACE, 0, 0}}, };用表驱动之后，Car_Decide里只剩查表和赋值，逻辑一目了然。参数上，-40表示后退时左轮反转 40% 占空比，右轮正转 60%，形成原地转向。注意负值在Motor_Set里会被转成方向引脚反转，所以表里可以直接写负数。
验证循迹稳定性有个土办法：把车放在一条 2 米长的黑胶带跑道上，跑道中间故意贴一小段透明胶带模拟反光，看车经过时会不会抖。如果抖，先调滤波窗口，再调差速比例。另一个办法是用手机慢动作拍车轮，看左右轮在过弯时是不是有“一顿一顿”的停顿——有停顿说明 PWM 更新频率太低，把节拍从 5ms 降到 2ms 试试。
从那以后我每次拿到一份小车程序，都强制先架空、开串口、手动遮挡传感器走一遍状态，再落地跑。这个习惯帮我省掉了至少一半的“玄学”调试时间。希望帮到你。
本文还有配套的精品资源，点击获取
