简介这份蓝牙智能遥控小车毕业设计论文文档面向电子信息、自动化及计算机相关专业的毕业生与单片机爱好者提供一套以无线遥控与自主感知为核心的完整设计参考。文档围绕 STC12C5A60S2 主控、L293D 电机驱动、蓝牙无线遥控、红外光电传感器与超声波收发模块展开涵盖硬件电路原理图、PCB 绘制、控制程序编写以及蓝牙遥控、自动避障、自动循迹、自动测速和自动测距等功能的实现思路。压缩包共 1 个 doc 文件约 2.49MB内容包含摘要、方案比较与论证、智能车机械结构分析、模块设计与调试等章节适合直接借鉴论文框架、电路方案与程序逻辑。目前已有 121 人学习下载可作为毕业设计选题、答辩准备或单片机课程设计的实操参考帮助读者理清 PWM 调速、传感器数据处理和电机控制之间的配合关系。1. 蓝牙智能遥控小车毕业设计先把通信链路和答辩点定下来答辩现场最难看的一幕是评委让你把车开过一条二十厘米宽的过道小车一进拐角就失联遥控按到冒火轮子还在原地打转。多数人做蓝牙智能遥控小车前两天全砸在电机驱动和底盘结构上真正让演示翻车的却是通信层HC-05 波特率配错、手机发一帧收两帧、距离一拉远就整帧丢失。从零把一辆蓝牙智能遥控小车做到能跑、能测、能写进毕业设计论文真正要提前定死的只有三件事。通信选型是走经典蓝牙串口透传还是走 BLE数据帧格式怎么用几个字节描述方向、速度、急停和灯光失控保护蓝牙断开后车必须自己停下,这一条几乎每个评委都会问。适合正在做这个题目的本科生也适合想拿它当 STM32 或 ESP32 入门练手项目的工程师。下面的接线表、AT 指令、帧结构、PWM 标定参数都能直接抄改几个数字就能跑通。2. 蓝牙模块选型与接线HC-05、HC-06 和 ESP32 内置蓝牙怎么选主控是 STM32 最小系统时最常见的做法是外挂一个 HC-05 或 HC-06 透传模块主控直接用 ESP32 时蓝牙已经集成在芯片里额外加模块反而浪费一个串口。这个选择会一路影响下位机代码的结构经典蓝牙走 SPP 透传你拿到的就是一个字节流和读串口没区别BLE 走 GATT 特征值得先处理连接、服务发现和 notify 订阅。2.1 经典蓝牙串口透传和 BLE 的差别决定了固件怎么写HC-05 默认工作在从机模式的 SPP 透传下配对成功后手机侧就多出一个串口概念App 发什么字节模块的 TX 引脚就吐什么字节反过来也一样。ESP32 按 BLE 做则要从 GATT 服务开始搭定义一个写特征用于接收指令一个通知特征用于回传状态。对毕业设计来说透传方案代码量最少BLE 方案在手机上更通用不用配对串口代价是协议栈细节更多。对比项经典蓝牙 SPPHC-05/HC-06BLEESP32 内置 / HM-10下位机拿到什么裸字节流直接当串口读GATT 特征值写入需处理事件回调手机端开发需要串口权限部分机型受限主流平台原生支持通用性好连接建立时间首次配对慢之后重连较快广播-扫描-连接通常更快功耗水平相对高低调试难度低串口助手就能测中要看连接和订阅日志常见坑波特率不匹配、供电不足特征值 UUID 写错、没开 notify题目关键词如果落在低功耗蓝牙上方案基本就锁定 BLE如果只是要一块能遥控的板子HC-05 透传是性价比最高的路径。2.2 HC-05 接 STM32 的接线表和 AT 配置接线本身不复杂出错最多的两处是供电和 TX/RX 交叉。HC-05 峰值电流能到 40mA 左右某些开发板的 3.3V 引脚带不动就会出现能配对、一连就断的现象这时单独给它一路稳压供电更稳。HC-05 引脚接到 STM32说明VCC3.3V 或 5V看模块板载稳压确认板子上有没有 LDOGNDGND必须共地TXDUSART2_RX (PA3)模块发主控收RXDUSART2_TX (PA2)主控发模块收串 1k 电阻更安全EN/KEY悬空或接高电平拉高进 AT 模式STATE可接 LED连接状态指示进入 AT 模式后用串口助手逐条发送下面的指令。注意 AT 模式下波特率通常固定为 38400部分固件是 9600连不上时两个都试。发送时不要勾选发送新行以外的附加字符很多无响应其实是工具在行尾塞了多余字节。# HC-05 AT 配置串口助手按行发送模块回复 OK / ADDR 等 AT # 测试通信正常回复 OK ATNAMESmartCar # 修改蓝牙名称手机搜索到的就是它 ATPSWD1234 # 设置配对密码出厂常见 1234 或 0000 ATUART9600,0,0 # 通信波特率 96001 停止位无校验 ATROLE0 # 0 为从机手机作为主机连接 ATCMODE1 # 任意地址均可连接 ATRESET # 复位使参数生效逐条说明ATNAME改的是广播名别和论文里写的设备名混淆ATPSWD改完手机必须重新配对否则旧密码还缓存在系统里ATUART是重灾区改完之后串口助手本身也得切到对应波特率否则后面全是乱码ATROLE0保证模块等手机来连设反了就会出现手机搜不到的假象。改完统一执行ATRESET不重启的话部分参数不生效。提示AT 模式下模块不转发数据调试完记得把 EN/KEY 恢复悬空否则正常通信时它一直停在配置模式。2.3 ESP32 方案的引脚分配与接收骨架ESP32 的蓝牙和 Wi-Fi 共用同一套射频资源一起用时内存和时序都会紧张但短指令控制小车这类轻负载场景没问题。常见做法是把蓝牙接收回调做得足够短不在回调里做耗时操作。引脚分配上避开 GPIO 6~11接内部 flash和输入专用引脚四路 PWM 驱动电机时留出两路给编码器或传感器。// ESP32 端 BLE 接收骨架收到一帧即交给解析函数 #include BLEDevice.h #include BLEServer.h #include BLEUtils.h #define SERVICE_UUID 0000ffe0-0000-1000-8000-00805f9b34fb #define CHARACTERISTIC_UUID 0000ffe1-0000-1000-8000-00805f9b34fb class CmdCallback : public BLECharacteristicCallbacks { void onWrite(BLECharacteristic *c) override { std::string v c-getValue(); // 手机写入的原始字节 if (v.length() 0) { parseFrame((const uint8_t*)v.data(), v.length()); // 只做入队别在这里跑电机 } } }; void setup() { BLEDevice::init(SmartCar); // 广播名 BLEServer *server BLEDevice::createServer(); BLEService *svc server-createService(SERVICE_UUID); BLECharacteristic *ch svc-createCharacteristic( CHARACTERISTIC_UUID, BLECharacteristic::PROPERTY_WRITE | BLECharacteristic::PROPERTY_NOTIFY); ch-setCallbacks(new CmdCallback()); svc-start(); BLEAdvertising *adv BLEDevice::getAdvertising(); adv-addServiceUUID(SERVICE_UUID); adv-start(); }SERVICE_UUID和CHARACTERISTIC_UUID必须和手机端写死的一致错一个字符手机就会显示服务不存在。onWrite回调运行在蓝牙协议栈的任务上下文里耗时过长会拖慢连接事件所以这里只做拷贝入队真正的解析和 PWM 输出放到主循环。PROPERTY_NOTIFY是给回传预留的比如把当前速度、电压发回手机显示论文里加上这一条会好看很多。3. 蓝牙数据传输的帧协议设计抗丢包、可扩展、好答辩不少同学直接让手机发一个字符F表示前进、B表示后退能跑起来但一加s调速和转向量就崩了单字符表达不了参数。所以帧结构要一开始就定死。3.1 定长二进制帧的字段定义与校验推荐固定长度的二进制帧而不是 JSON 文本。原因很直接BLE 单包默认 20 字节有效载荷写个{cmd:forward,speed:80}就超了还得做分包拼接。定长帧在嵌入式端解析也简单一个状态机就够。字节偏移字段长度取值示例说明0帧头10xAA固定用于对齐1指令10x01见指令表2参数110~100速度百分比3参数210~100转向量中值 504校验1-前 4 字节异或5帧尾10x55固定校验用异或就够了STM32 上一个循环搞定不必引入 CRC16。如果题目要求更严可以升级成 CRC-8代价是十几行代码。热词里常说的蓝牙数据传输稳定性落到工程上其实就是三件事对齐帧头、校验通过、超时丢弃。3.2 指令表运动、灯光、急停、查询指令表是论文里能直接画成图的部分正文里建议列全答辩时老师很爱问你一共支持几种操作。指令码名称参数1参数2说明0x01运动控制速度 0~100转向 0~10050 直行差速转向的核心0x02灯光0 关 1 开保留前照灯或氛围灯0x03急停忽略忽略立即把 PWM 归零0x04查询状态忽略忽略触发一次 notify 回传0x05参数设置参数编号新值调速上限、转向灵敏度急停建议做成独立一帧不要复用运动控制里的速度 0。遥控丢包时速度 0 那一帧可能正好丢了而急停走单独指令可以配合连发三次的保险策略。3.3 粘包半包的边界处理与打包代码串口和 BLE 都是流式接口收到的可能是半帧也可能是两帧粘在一起。处理思路是维护一个缓冲区先找帧头再判长度。# 手机端打包与拆包示例配合上面的定长帧结构 def build_frame(cmd: int, p1: int 0, p2: int 0) - bytes: body bytes([0xAA, cmd, p1 0xFF, p2 0xFF]) # 帧头 指令 两个参数 checksum 0 for b in body: checksum ^ b # 逐字节异或与固件端算法一致 return body bytes([checksum, 0x55]) # 补上校验和帧尾 def split_frames(buf: bytearray): frames [] while True: start buf.find(0xAA) # 先对齐帧头丢掉前面的噪声 if start 0: buf.clear() break if len(buf) - start 6: # 不足一帧等待下次数据 del buf[:start] break frame buf[start:start 6] if frame[5] ! 0x55 or (frame[0] ^ frame[1] ^ frame[2] ^ frame[3] ^ frame[4]) ! 0: del buf[:start 1] # 校验失败只前移一字节重新找头 continue frames.append(bytes(frame)) del buf[:start 6] return framesbuild_frame里p1 0xFF是为了防止传入超过 255 的值让bytes()抛异常split_frames最先做的是丢弃帧头之前的垃圾数据这是抗噪声的第一道门槛校验失败时只删一个字节而不是整帧是因为假帧头出现概率不低删一字节能让后面的真帧头重新被找到。这套逻辑在固件端用 C 写一遍、手机端用脚本写一遍功能对齐联调时能省掉大量互相怀疑。4. 下位机固件STM32 端指令解析、PWM 差速与失控保护4.1 串口中断加环形缓冲的接收结构不要在串口中断里解析帧。中断只负责把字节塞进环形缓冲区主循环再取出来解析中断里做memcpy级别的操作超过几微秒就可能影响其它外设。数据流是USART2_IRQHandler 调 ring_push 入队主循环调 ring_pop 出队喂给解析器。环形缓冲有三个关键点。head 和 tail 都用uint16_t缓冲区大小取 2 的幂比如 128取模可以用位与代替单生产者单消费者的模型不需要加锁但 head 和 tail 要声明成volatile判满的条件是(head 1) % SIZE tail不要把缓冲区填满否则无法区分空和满。4.2 解析状态机的 C 实现解析器按找帧头、收满 6 字节、验帧尾、验校验、分发五步走任何一步失败都要能干净复位。// STM32 端帧解析状态机放在主循环里调用 #define FRAME_LEN 6 static uint8_t rx_frame[FRAME_LEN]; static uint8_t idx 0; void frame_parse(uint8_t byte) { if (idx 0) { if (byte 0xAA) rx_frame[idx] byte; // 只在帧头处开始收 return; } rx_frame[idx] byte; if (idx FRAME_LEN) return; // 还没收满 idx 0; // 无论成败都要复位避免卡死 if (rx_frame[5] ! 0x55) return; // 帧尾不对丢弃 uint8_t sum rx_frame[0] ^ rx_frame[1] ^ rx_frame[2] ^ rx_frame[3] ^ rx_frame[4]; if (sum ! 0) return; // 异或校验和应为 0 last_rx_tick HAL_GetTick(); // 刷新失控保护计时 switch (rx_frame[1]) { case 0x01: motor_set(rx_frame[2], rx_frame[3]); break; // 速度、转向 case 0x02: led_set(rx_frame[2]); break; case 0x03: motor_stop(); break; // 急停 case 0x04: status_notify(); break; default: break; } }motor_set里 speed 是 0~100 的百分比要映射到定时器 CCR 的值。注意电机有启动死区低于某个占空比根本转不起来标定时要用实测阈值而不是理论值。每次成功解析一帧都刷新last_rx_tick这是失控保护的判断依据。4.3 差速转向的 PWM 参数怎么标定两轮差速模型下转弯半径由左右轮速差决定。工程上不必去算精确公式直接线性映射更快。参数含义推荐取值或标定方法PWM 频率电机驱动频率10~20kHz避开人耳可听范围死区占空比电机启动最小占空比逐个轮子实测常见 15%~30%速度映射0~100 映射到 CCRccr dead (100-dead) * p1 / 100转向系数 k转向量放大倍数取 0.6~1.0急弯可加大左轮输出直行基准left base (p2 - 50) * k右轮输出直行基准right base - (p2 - 50) * k限幅时切记要连下界死区一起钳超出范围就钳到死区值否则会出现给了指令但轮子不转的假故障。4.4 失控保护蓝牙断连后小车要自己停这一条是答辩必问的问题也是很多小车的隐藏缺陷。手机没电了会怎么样答不上来分数就往下掉。常见做法是主循环里比较当前 tick 和last_rx_tick超过 500ms 没收到合法帧就执行减速停车超过 1s 就彻底关 PWM 输出。同时打开片内独立看门狗喂狗放在主循环而不是定时器中断里这样主循环卡死也能复位。// 失控保护放在主循环里1ms 调用一次 void safety_check(void) { if (HAL_GetTick() - last_rx_tick 500) { motor_ramp_down(); // 先按斜率减速避免急停打滑 } if (HAL_GetTick() - last_rx_tick 1000) { motor_stop(); // 彻底切断 PWM防止堵转发热 } }motor_ramp_down按固定步长逐步降低 CCR比直接归零更稳车不会因为换向电流而抖一下。500ms 和 1s 这两个阈值可以按场地调窄道竞速收到 300ms室内演示留 500ms 更从容。5. 联调排错与进阶HC-05 连不上、延迟抖动、测距数据5.1 HC-05 蓝牙模块连接不上按顺序排查hc05 蓝牙模块连接不上是搜索量最大的问题按下表顺序排比乱试快得多每一步都能独立验证。现象常见原因处理方式手机搜不到设备模块未上电、EN 被拉低、名称被改乱看 STATE 灯闪不闪先量供电能配对一发数据就断供电电流不够电源跌落单独 3.3V 稳压并一颗大电容发送 AT 无响应不在 AT 模式、波特率不对拉高 EN 后重启38400 与 9600 都试收到乱码两端波特率或停止位不一致固件、模块、串口助手三处对齐数据能收但控不了车帧结构或校验不一致串口助手发已知帧看解析日志5.2 用抓包和逻辑分析仪定位延迟抖动BLE 方案可以抓 HCI 包确认指令是不是在空口重传、MTU 协商成了多少。经典蓝牙的透传不好抓退而求其次用逻辑分析仪接在模块 TX 和主控 RX 之间看波形能直接看出波特率对不对、有没有丢字节。串口监视器看的是结果逻辑分析仪看的是过程两者配合能快速分清是通信丢了还是固件卡了。延迟抖动常见原因有三个回调里做了耗时操作、主循环被HAL_Delay阻塞、发帧频率太高导致空口排队。把发送频率限在 20~50Hz人眼已经足够流畅再高只是浪费带宽、抬高丢帧率。转向的平滑度靠插值做不靠提高帧率。5.3 加蓝牙测距与避障把实测数据写进论文想让题目有新意可以在基础遥控上加一层用超声波或红外模块做前向避障主控在移动过程中按距离自动减速手机的蓝牙信号强度可以作为粗略的距离参考但它受遮挡和人体影响极大定性使用没问题别直接把 RSSI 换算值当测距结果写进结论答辩时被追问会很被动。论文里最加分的实测数据一般是三组。不同距离下的丢帧率每条指令发 200 次统计实际收到的合法帧数算出百分比做成距离-丢帧率曲线。响应延迟用逻辑分析仪两路探头一路抓发送帧头对应的引脚一路抓 PWM 输出引脚跳变取多次平均。失控保护触发时间断开手机后打点记录从断连到 PWM 归零的毫秒数重复 10 次取均值和最大值。这三组表格往正文里一放比大段文字描述有说服力得多也正好对应评委最关心的通信可靠性和安全性两个问题。本文还有配套的精品资源点击获取