基于STM32与51双MCU的AGV小车寻迹避障系统设计

简介面向嵌入式开发工程师、单片机爱好者及电子竞赛参赛者的AGV智能小车寻迹避障系统完整工程资料覆盖STM32C8T6与51单片机双平台设计。资源从硬件选型、双层亚克力底盘组装、L298N电机驱动接线讲起系统实现红外循迹模块检测黑色轨迹、HC-SR04超声波实时测距、遇障自动调整路径、蜂鸣器与LED声光报警以及蓝牙无线控制等功能软件层则详细拆解PID路径跟踪、超声波避障和状态监测算法给出可直接用于课程设计、毕业设计和工程项目的完整方案与代码示例。压缩包内含1个PDF文档大小4.29MB文档配有硬件连接图、模块接线说明及关键代码解析并总结了现有设计的优缺点与改进方向单文件即涵盖从原理到落地的完整链路。目前已有186人学习浏览适合具备一定嵌入式基础、希望深入实践传感器融合与运动控制的研发人员参考。 又到一年课设、毕设扎堆的日子和我聊AGV智能小车寻迹避障的同学明显多了起来。这个题目在嵌入式方向里属于“经典永流传”它把传感器采集、电机驱动、单片机通信、控制逻辑全串在一块硬件和软件都覆盖得到。我手上这套基于STM32与51单片机的AGV智能小车寻迹避障系统最值得拿出来分享的点是双MCU分工协作51单片机负责底层传感器轮询和电机执行STM32负责避障决策和路径规划。整份工程资料里原理图、PCB、源码、接线说明都齐全下面我把设计思路、关键代码和调试时踩过的坑一起整理出来对正在做嵌入式入门项目或者毕业设计的同学应该很有参考价值。1. 系统整体设计与方案选型思考1.1 双MCU架构为什么不是一块单片机搞定很多人第一反应是一块STM32跑寻迹避障绰绰有余何必再加一块51这个疑问我当初也有但实际做下来发现双MCU架构并不是为了显得复杂而是有很实际的好处。51单片机价格便宜、外设简单、中断响应直接很适合做“高频小任务”——比如不停轮询三路红外寻迹传感器、控制电机PWM输出。这些操作如果全部压在STM32上虽然性能绰绰有余但代码里会充斥着底层轮询逻辑主循环很难抽身去处理更复杂的超声波避障算法。把底层传感器采集和电机控制放在51上让STM32专注于超声波测距、策略切换、状态管理代码结构会清晰非常多。从教学的视角看双MCU方案也更容易拆解工作量51侧是“传感器执行器”的基础外设练习STM32侧是“中断定时器串口通信”的进阶练习两个部分都可以独立调试、独立验证最后联调时只需要关注两板之间的串口协议是否正常。对答辩来说这也比单芯片方案多出了“双机通信”这个能讲透的亮点。成本方面也不必担心STC89C52RC这类51芯片几块钱一片STM32F103C8T6蓝板也就十几块钱双芯片总成本比一块高配STM32还低。唯一需要注意的就是两套开发环境、两套下载器但这点麻烦在后续调试中完全值回票价。1.2 硬件清单与选型理由做这类小车硬件的坑往往比软件更隐蔽。我按实际使用顺序整理了一份清单表格里也写了选型理由方便你直接照单抓药。模块型号/规格作用选型理由车体底盘2驱或4驱TT马达底盘承载所有硬件便宜、结构成熟、轮子抓地力够主控决策板STM32F103C8T6超声波避障、路径决策性能充足、资料多、支持串口/USB调试底层控制板STC89C52RC51红外循迹、电机PWM控制外设简单、实时性好、成本极低寻迹模块TCRT5000反射式红外 × 3~5检测地面黑线灵敏度可调、抗环境光能力较好避障模块HC-SR04超声波探测前方障碍物测距精度够用、驱动简单、体积小电机驱动L298N或TB6612驱动直流电机L298N接线简单TB6612效率更高电源7.4V 18650锂电池组两节系统供电续航和电流输出能力平衡稳压LM2596降压模块 AMS1117给各模块提供稳定电压大电流部分与逻辑供电分离通信串口UART TTL双MCU数据交换最简单可靠的板间通信方式这里特别提醒一下电源方案。TT马达堵转时电流能到1A以上四个电机同时启动瞬间压降非常明显。我的做法是电池先接电机和L298N然后用LM2596降压到5V给51和超声波供电再通过AMS1117降到3.3V给STM32。等于是把“电流大户”和“逻辑单元”的供电路径分开避免电机一启动单片机立刻复位。2. 感知系统核心细节寻迹与避障的底层逻辑2.1 红外寻迹原理与传感器布局TCRT5000这类反射式红外传感器的工作原理并不复杂模块上的红外发射管持续发射红外光线光线照到不同颜色的物体表面后反射率不同——白色地面反射率高黑色线条吸收率高接收管收到的反射光强度就会产生明显差异。模块内部通过比较器把这种光强差异转成高低电平或者输出模拟电压供ADC采样。布局上我推荐三路起步五路更好。三路一字排开中间一路压线、左右两路检测边界逻辑最简单五路T型布局则能在黑线小转弯时提前感知方向变化转向更平滑。对于入门项目三路完全够用程序好写后续升级五路也只需要在代码里多判断两个引脚。实际调试时传感器离地高度建议控制在1~2cm太近了容易和地面摩擦太远了黑白电平差异变小。另外每个TCRT5000模块上都有一个可调电位器用来设定比较器阈值。调的时候不要只看一块板子最好把三块板子都放在同一段黑线上分别调节到“输出稳定的黑线状态”再放到白色地面上确认能输出白线状态。这个校准过程看起来琐碎但一步没做到位后面的寻迹逻辑全都会误判。从代码设计的角度讲传感器输出的电平定义需要先明确。我用的是黑线输出低电平、白底输出高电平模块上的LED指示灯会直观显示这样寻迹逻辑读起来非常符合直觉。主循环里只需要不断读取三个引脚的状态组合就能判断小车当前是“偏左”“偏右”还是“居中”。2.2 超声波避障测距公式与安装位置HC-SR04是市面上最常见的超声波测距模块工作时有四个引脚VCC、GND、Trig、Echo。测距流程是在Trig引脚上拉10us以上的高电平触发模块模块自动发射8个40kHz的超声波脉冲并等待回波收到回波后Echo引脚会输出一个高电平脉冲这个脉冲的宽度就是声波从发射到返回的总时间。距离计算用最经典的公式距离(cm) 高电平时间(us) / 58或者写成更直观的形式距离(cm) 高电平时间(us) × 0.034 / 2为什么除以2因为高电平时间是声波“往返”的总时间实际距离只有一半。0.34是声波在空气中约340m/s换算成us/cm的结果。实际测试下来HC-SR04在2cm到200cm范围内精度都还不错完全够小车的避障需求。超声波模块的安装位置比很多人想的更讲究。我最早安装在车头正中间结果小车和前方障碍物几乎成零度夹角时反而测不到——因为声波打到平整垂直的墙面后会原路返回但如果车头带一点角度回波就会弹向其他方向模块接收不到回波时间溢出最终被判成“无障碍”。后来我把超声波模块装在车头略微偏右的位置并且让模块表面稍微朝前下方倾斜几度这样即使小车角度稍有偏斜也能捕捉到一定反射信号。另一个细节是模块安装高度不要太低离地10cm左右比较合适太低会测到地面产生大量虚假回波。2.3 避障优先还是寻迹优先状态机切换思路小车上同时存在“寻迹”和“避障”两套逻辑最忌讳的就是把两个功能硬塞进一个主循环里来回判断。正确的做法是做一个小型状态机。我定义了几种核心状态状态含义触发条件FOLLOW_LINE寻迹模式前方无障碍物正常沿黑线行驶AVOID_OBSTACLE避障模式超声波测得前方距离小于安全阈值STOP停车持续检测到近距离障碍物或收到停止指令SEARCH_LINE搜索黑线避障结束后未找到黑线进入低速扫描状态机的重点在于优先级设计避障一定优先于寻迹。理由是简单的——如果小车已经在寻迹前方突然出现一个纸箱此时继续寻迹的结果就是直接撞上去。所以在主循环里先读超声波测距如果距离小于阈值我一般设25cm就立刻下发避障指令把控制权从“循线”切到“绕障”。避障的具体策略我用的是“先停车、再判断、后转向”检测到障碍后先停止向左或向右原地旋转90度然后前进一小段再旋转回来寻找黑线。如果转向后依然检测到障碍说明两边都堵住就继续保持原地旋转直到找到出路。这个策略不复杂但稳定性非常高也比较接近AGV常见的“停车—绕行—回轨”行为模式。3. 控制系统核心细节电机调速与双MCU通信3.1 电机驱动与PWM调速原理直流电机调速工程上最常用的手段是PWM脉冲宽度调制。简单说就是通过控制单位周期内高电平的占比——也就是占空比——来改变电机的平均输入电压。占空比越高电机拿到的平均电压越高转速越快。L298N驱动板和电机之间的接线如下IN1、IN2控制左电机正反转IN3、IN4控制右电机正反转ENA、ENB接PWM信号分别控制左右两路的速度。当ENA为高电平时电机全速接PWM时就可以通过调节占空比调速。我调试时最常遇到的情况是直行时两边电机转速不一致小车总往一边偏。这种情况光靠结构调整很难完全解决更有效的办法是在代码里给慢的那侧电机一个“速度补偿偏置”。比如左转略微跑偏就把左轮PWM加5%~10%的额外占空比反复试几轮就能跑直。转弯的策略也不要搞得太复杂。我的做法是直线行驶左右轮占空比都为70%~80%留一部分余量给补偿。左转/右转外侧轮保持70%内侧轮降到20%~30%实现差速转向。掉头/原地转向左右轮方向相反一个正转一个反转占空比分别给40%左右。占空比不是越大越好。超过90%之后电机扭矩提升有限反而发热严重电池消耗也快。过小也不行PWM占空比太低时电机处于接近堵转状态会发出尖锐的“呜呜”声这时候电池电流很大板子容易被拉垮。3.2 双MCU串口通信协议设计既然用了双MCU板间通信就是整个系统的“数据中枢”。STM32和51之间的通信最简单可靠的方式就是UART串口直接连接TX、RX交叉线共地即可。但串口通信如果只是“裸传字节”很快就会出问题。51单片机每次只发一个字节给STM32如果发的是0x01表示循迹、0x02表示避障看起来没问题可一旦STM32侧串口接收出现错位或者两边波特率有微小偏差导致丢帧后续的命令全都会错乱。所以哪怕只是一个字节的控制命令我也建议加上协议帧格式。我用的自定义帧格式很小但足够可靠帧头(0xAA 0x55) 命令字 校验和例如STM32下发避障命令实际发送的是0xAA 0x55 0x02 0x57其中0x57是前面三个字节的累加和。51收完4个字节后先校验帧头是否正确、校验和是否匹配如果匹配再执行对应动作不匹配就丢弃整帧数据。别看协议简单它彻底解决了串口粘连和错位问题。收发波特率我用的9600这个速率足以传输状态信息而且稳定性和抗干扰能力比115200强特别是在电机干扰比较大的情况下。3.3 控制逻辑状态机实战51侧核心逻辑51单片机侧的核心逻辑比较纯粹就是一个“读传感器-判断状态-控制电机”的循环。下面这段代码是当时调试时用的核心框架去掉了很多临时调试打印保留了最主干的判断流程// 引脚定义 sbit S_LEFT P1^0; // 左寻迹传感器黑线为低电平 sbit S_MID P1^1; // 中间寻迹传感器 sbit S_RIGHT P1^2; // 右寻迹传感器 // 电机方向控制 #define MOTOR_GO 0x00 #define MOTOR_LEFT 0x01 #define MOTOR_RIGHT 0x02 #define MOTOR_BACK 0x03 void motor_run(unsigned char direction, unsigned char speed_left, unsigned char speed_right) { // 根据方向设置IN1~IN4通过定时器输出PWM控制ENA/ENB // speed_left / speed_right 为0~100的占空比 } void main(void) { init_timer_pwm(); // 初始化定时器产生PWM uart_init(); // 初始化串口接收STM32指令 while (1) { if (cmd_received CMD_AVOID) // 收到避障命令 { motor_run(MOTOR_GO, 60, 60); // 低速前进配合上层避障逻辑 } else if (cmd_received CMD_STOP) { motor_run(MOTOR_GO, 0, 0); } else // 默认循迹模式 { if (S_LEFT 0 S_MID 1 S_RIGHT 0) { motor_run(MOTOR_GO, 80, 80); // 居中直行 } else if (S_LEFT 1 S_MID 0) { motor_run(MOTOR_RIGHT, 40, 80); // 偏左向右修正 } else if (S_MID 0 S_RIGHT 1) { motor_run(MOTOR_LEFT, 80, 40); // 偏右向左修正 } else if (S_LEFT 1 S_RIGHT 1) { // 两侧都丢线可能压过线或遇到断线保持低速直行搜索 motor_run(MOTOR_GO, 50, 50); } } } }这个逻辑最核心的一点是“检测到左侧传感器压黑线就往右打方向检测到右侧传感器压黑线就往左打方向”这对应着小车在赛道上的实际偏差方向。代码不复杂但状态覆盖要完整尤其是“两侧同时丢线”的情况不能漏掉否则小车在较大的弯道上一冲出去就再也回不来了。4. 实操过程与关键代码实现4.1 开发环境搭建Keil5如何同时搞定C51和STM32做这个项目需要两套编译环境51单片机用Keil C51STM32用Keil MDK-ARM。很多人以为Keil装一个MDK就够了结果打开51工程发现编译报错找不到头文件原因就是Keil MDK默认不包含C51编译器。我的处理方法是最稳妥的电脑上安装两个独立的Keil环境一个Keil C51专门写51代码一个Keil MDK-ARM专门写STM32代码。两者互不干扰下载器也分开一个用STC-ISP串口下载或ST-Link一个用ST-Link或J-Link。如果实在想在一个Keil里同时支持两种工程也可以手动给MDK增加C51支持包但配置过程比较折腾我试过几次后最终还是选择了双环境方案省心太多。STM32侧我建议直接用STM32CubeMX生成初始化代码再用HAL库开发。HAL库虽然运行时效率不如寄存器版本但逻辑清晰、外设初始化代码自动生成省下来的时间完全可以投入到策略调试上。对于F1这种大热门芯片HAL库的资料一抓一大把遇到问题也好找解决方案。整理一下我的工程目录结构供参考/AGV_Car ├── /51_Code // 51侧工程 │ ├── main.c │ ├── uart.c │ ├── motor.c │ └── reg52.h ├── /STM32_Code // STM32侧工程 │ ├── Core/ │ ├── Drivers/ │ ├── USART/ │ ├── Ultrasonic/ │ └── control_state.c └── /Hardware_Docs ├── 原理图.pdf ├── 接线表.xlsx └── 器件清单.csv好的工程目录能在联调时代替你省一半的找文件时间。尤其是一个项目跨两套开发环境时建议从一开始就建好清晰的目录结构否则过几天你自己都会忘记某个引脚定义写在哪。4.2 STM32侧关键代码超声波测距与指令下发STM32侧最重要的任务是超声波测距然后把结果变成51能执行的指令。超声波Echo引脚的脉冲时间测量我用了输入捕获方式先配置一个定时器在Echo引脚上升沿触发时开始计数下降沿触发时读取计数值再根据定时器频率换算成时间。也可以用更简单的延时方式Trig触发后用while循环不断检测Echo电平同时让一个计数变量自增最后根据计数值换算距离。这种方式代码最简单但会阻塞主循环而且在调试避障策略时主循环被阻塞会让整个系统显得“卡顿”。我更推荐基于定时器或外部中断的非阻塞方式。下面是一段基于HAL库的简化流程体现的是测量思路void start_ultrasonic_measure(void) { HAL_GPIO_WritePin(TRIG_GPIO_Port, TRIG_Pin, GPIO_PIN_SET); delay_us(15); HAL_GPIO_WritePin(TRIG_GPIO_Port, TRIG_Pin, GPIO_PIN_RESET); // 等待Echo上升沿记录起始时间 // 等待Echo下降沿记录结束时间 // 高电平时间 结束时间 - 起始时间 } int16_t read_distance_cm(uint32_t echo_time_us) { return (int16_t)(echo_time_us * 0.017); }注意0.017这个系数怎么来的340m/s换算成cm/us是0.034cm/us往返距离除以2就是0.017。之前公式里除以58实际上就是1/0.0172的近似结果两者是等价的。STM32避障决策部分最核心的就是这个主循环逻辑while (1) { uint16_t dist read_distance_cm(); if (dist OBSTACLE_THRESHOLD) // 默认25cm { send_command(CMD_AVOID); // 下发避障指令 } else { send_command(CMD_FOLLOW); // 下发循迹指令 } HAL_Delay(50); }避障阈值的设置要根据小车实际速度和刹车距离来标定。我在桌面上测试时25cm是刹车后与前障碍的“安全缓冲区”速度太快或者阈值太小都会导致突然撞上。4.3 联调与参数整定经验整台车联调的时候最忌讳的就是“全部堆在一起跑”出了问题根本无从下手。我的习惯是先分解模块再逐个验证先用USB转TTL直接把5V电源和串口接出来单独验证51侧有没有正确收到STM32的串口帧。再用多块纸板搭一个简易赛道把寻迹传感器单独接好手动推动小车看每个传感器的电平输出是否和预期一致。最后才把超声波模块加上调试避障绕行的转向角度和停车距离。联调时还有两个非常实用的小技巧。第一在STM32侧通过串口把当前状态、距离值实时打印到电脑上比如随时能看到“距离30cm状态FOLLOW_LINE”这样小车跑歪的时候能立刻定位是传感器问题、逻辑问题还是通信问题。第二在51侧预留几个状态指示LED比如当前是“循迹模式”亮绿灯、“避障模式”亮红灯通过LED就能快速确认51侧有没有收到并执行指令。赛道方面我用黑色电工胶带在地上贴了两条车道一条是带直角弯的直线道测试寻迹一条是中间放纸箱的环形道测试避障。先跑通直线道再跑环形道最后两者合在一起调优先级整个流程下来很顺畅。5. 嵌入式开发中的常见问题与排查技巧5.1 ST-Link连接失败一颗芯片救了整个调试环节用STM32时最让人崩溃的错误提示就是“Error: No STM32 target found! If your product embeds Debug Authentication, please...”这句英文接下来就是下载器连不上目标芯片程序烧不进去。我之前遇到这个问题时排查了老半天最后发现原因很简单SWD的四根线里SWDIO或SWCLK接触不良或者板子没有独立的3.3V稳压输出USB供电时电压不足导致芯片压根没进入调试模式。排查步骤我总结成这样可能原因检查方法接线松动重新插拔ST-Link与板子的SWD杜邦线尽量缩短线长供电不足给板子单独接USB供电再连ST-Link的SWD口芯片读保护在ST-Link Utility或CubeProgrammer里尝试解除读保护驱动异常检查设备管理器里ST-Link是否枚举为调试设备驱动重装还有一个隐蔽的问题某些ST-Link的VCC引脚会和板子电源短路接错线会直接把调试芯片烧掉。我现在用ST-Link一律先接SWDIO、SWCLK、GND三根线不接VCC让板子用自己的电源这样既隔离了供电干扰也规避了接反风险。5.2 Keil工程兼容性C51与STM32混装的坑很多同学第一次同时接触51和STM32时会莫名其妙遇到“同一个Keil工程里51代码编译正常STM32代码一打开就报缺芯片”的问题。原因就是前面提到的编译器与器件支持包不匹配。我的建议是装两个独立版本给它们取不同的安装路径快捷键名字也改成“Keil C51”和“Keil MDK”。每次打开工程时先确认一下用的是哪个环境习惯之后效率并不低。如果你非要在VS Code里统一开发也可以STM32侧用EIDE或PlatformIO插件51侧继续用Keil编译在VS Code里只做编辑和串口监视。不过这套流程对新手不太友好先老老实实双击Keil图标吧等熟了再折腾环境。5.3 供电不稳导致复位和传感器数据乱跳这是小车项目里出现频率最高又最难排查的故障之一。表现为电机加速或转弯瞬间单片机莫名其妙复位传感器数值乱跳串口打印乱码。查到最后通常都是供电问题。根本原因是直流电机启动电流冲击大电池内阻和导线电阻导致整个电源轨的电压瞬间跌落。STM32F103C8T6的供电范围是2.0V~3.6V如果3.3V轨在电机启动瞬间被拉低到2.5V以下芯片就会进入欠压复位状态现象就是“小车一跑就重启”。解决办法有几个层次电机电源和逻辑电源分开走线共地但不共用导线。L298N的VS电机电源和VSS逻辑电源分别供电逻辑侧用独立稳压输出。MCU电源入口加一个100uF~470uF的电解电容吸收瞬时压降。电机两脚之间并联104电容或续流二极管减小开关噪声对电路的污染。我实测下来“主电源→L298N→电机”和“主电源→LM2596→5V→AMS1117→3.3V→单片机”这种双路电源架构最稳定。虽然多了一级降压模块但系统可靠性提升非常明显。5.4 超声波回波溢出与寻迹误判的边界情况超声波模块看似简单坑也不少。最常见的现象是Echo引脚一直输出高电平导致测距超时代码误判为“无限远”小车直奔障碍物而去。这通常发生在模块对着空旷地或者斜对某个大平面时回波信号太弱或者根本没返回。我的处理方式是在测距代码里加一个“超时保护”如果高电平时间超过某段时间比如60ms对应约10m就认为本次测量无效继续沿用上一次距离值同时计一个失败次数。如果连续失败超过一定次数才把距离置为最大值。这样做可以避免单个无效测量导致小车突然丢线或撞车。寻迹模块的误判场景则集中在光线强烈的环境下。阳光直射地面时红外反射强度会整体漂移可能导致黑线上的传感器输出变成白线电平。对策一是调整模块的电位器让阈值适应环境光二是尽量在室内或阴天环境下调试三是在代码里加“连续判断N次才确认状态”的去抖动逻辑防止单次误采样触发转向。最后再分享点个人心得做这套AGV智能小车寻迹避障系统我的感受是难度不在于某一个模块有多深而在于所有模块之间的接口和配合。双MCU方案初期确实要解决两套工程、两套下载器、两套调试环境的麻烦但当你把51侧的循迹、STM32侧的避障分别跑通再通过串口把两边捏合成一台完整的小车时那种系统感是单芯片方案体会不到的。如果后续想继续升级可以从三个方向入手把三路寻迹升级到五路或灰度传感器转向会更顺滑换装TB6612驱动电机响应速度会更快再进一步把STM32换成K210或者接入ESP8266模块做远程监控就能从单纯的小车项目向更完整的智能化场景扩展。先把这套基础框架吃透后面每走一步都会轻松很多。本文还有配套的精品资源点击获取