简介：面向百科融创杯嵌入式技术与应用开发赛项的主车及从车端完整项目源码，专为竞赛选手、嵌入式课程设计及毕业设计开发者打造。作者在这份高分项目中给出了完整的赛题实现方案，代码注释详尽，逻辑清晰，新手也能顺畅理解；整个工程经严格调试，下载后简单部署即可运行，省去从零搭建与排错的精力。压缩包共167个文件，以C源码（74个.c）与头文件（75个.h）为核心，辅以STM32系列芯片驱动库文件、Keil工程配置（.uvprojx/.uvoptx）、烧录脚本及Arduino固件（.ino），整体仅820KB，文件归类清楚，可按功能模块快速检索。目前已有192人学习使用，适合需要快速获取可运行嵌入式赛题方案、作为期末大作业或毕业设计蓝本的读者。项目功能完善、界面美观、操作简单，具备较高的实际应用价值与参考意义。
1. 百科融创杯主车与从车：这源码到底值不值得下
每年百科融创杯嵌入式赛项报名之后，群里最常刷屏的就是“有没有现成的主车源码”“从车怎么跟着主车走”。说实话，这类竞赛项目源码的水很深：有的只是把例程拼在一起，跑起来全靠运气；有的又过度封装，离开原开发板根本挪不动。这次拆解的这套主车及从车端项目源码，属于“拿来能烧、烧了能跑、跑完能改”的类型，主车基于 STM32 系列芯片做运动控制与传感器融合，从车独立完成跟随与物料交互，两车之间通过无线串口模块保持同步。源码里没有花架子，都是竞赛现场的实用逻辑。适合正在备赛百科融创杯、准备嵌入式毕设，或者想快速搞一套双车协作演示系统的开发者。下面我按自己的拆解习惯，先把整车架构和源码结构交代清楚，再一步步落到烧录、调参和避坑，你能带着问题来找答案。
2. 赛项规则与整车架构：先搞清楚主车从车各干什么
2.1 主车任务拆解与硬件选型
百科融创杯的嵌入式赛项通常模拟智慧物流场景，主车需要沿规定路径完成运送、停靠、避障和状态上报。从源码里能看出，主车端采用的是“底盘驱动 + 传感器感知 + 无线通信”三件套结构。底盘驱动层封装了四个直流减速电机的 PWM 控制逻辑，源码里直接给出了正反转、差速转向和急停接口。传感器感知层同时接了灰度循迹模块和超声波避障模块，前者负责贴线行驶，后者负责检测动态障碍物。无线通信层则用了常见的 2.4G 无线串口模块，把主车的运行状态实时广播给从车。
硬件选型上，主控是 STM32F103 系列，主频 72MHz，跑一个双车协作逻辑完全够用。电机驱动用的 TB6612，比 L298N 功耗低，PWM 频率拉到 10kHz 左右也不会发热严重。灰度传感器是四路数字输出型，不是模拟型，好处是阈值在硬件上已经调好，代码里只读 GPIO 高低电平就行。超声波模块是 HC-SR04，触发距离设在了 20cm 到 40cm 之间可调，这个区间在竞赛场地里比较安全。这些选型都是竞赛场景里的常见配置，源码并没有绑定特定型号，换同类型模块时只需要改引脚宏定义。
2.2 从车任务拆解与通信方式
从车端的任务比主车要灵活，核心是“跟着主车走，同时完成取放物料”。源码里从车使用了独立的主控和电机驱动，没有和主车共用一块板子，这是比较合理的做法，因为两车任务不同，耦合在一起后期改起来非常痛苦。从车的传感器配了红外接近开关和光电对射传感器，用来识别货物装载位置和车斗状态。它还保留了一路串口接收通道，专门解析主车发来的状态帧。
通信协议在源码里定义得非常直白：主车每 50ms 发送一次状态帧，帧头是0xAA 0x55，中间是整车状态字节、速度档位字节和转向方向字节，帧尾是校验和。从车收到后先校验，再根据状态字节切换自己的运行模式。这样设计的好处是，即使主车突然断电或失控，从车也能在 200ms 内检测到超时并原地停车，不会追尾或跑飞。源码里还用了一个滑动窗口过滤无线模块的偶发乱码，这是现场调车时很重要的细节，很多队伍栽在莫名其妙的跳变上。
2.3 源码目录结构与模块划分
拿到源码包后，第一件事不是打开工程文件，而是先看目录结构。这套源码把主车和从车分开放在main_car和slave_car两个目录下，每个目录里又按硬件驱动、逻辑控制、通信协议分了三个层级。driver文件夹放的是 GPIO、PWM、UART、定时器的底层配置；app文件夹放的是任务相关逻辑，比如主车的循迹状态机和从车的跟随状态机；protocol文件夹里是双方通信的编解码函数。分工清楚，找问题的时候不用到处翻。
我一般建议拿到源码后先做三件事：第一，打开main_car/app/task_scheduler.c看任务调度方式，确认是裸机前后台还是用了定时器切片；第二，打开protocol/protocol.c看通信帧格式，确认校验逻辑是否能应对无线干扰；第三，打开driver/uart_config.c看串口中断和 DMA 的配合。这个顺序能让你在半小时内基本判断出这份源码的工程水平。下面贴一段主车端初始化函数的代码，说明它如何把传感器输入和电机输出串起来。
void main_car_init(void) { // 初始化系统时钟，使能外设时钟 SystemClock_Config(); // 配置四路电机PWM输出引脚，频率设置10kHz Motor_Init(TIM2, 10000); // 初始化四路灰度传感器GPIO输入，带上拉电阻 GraySensor_Init(GPIOA, GPIO_PIN_0 | GPIO_PIN_1); // 初始化超声波触发引脚和回声捕获引脚 Ultrasonic_Init(GPIOB, GPIO_PIN_10, GPIO_PIN_11); // 初始化无线串口，波特率115200，8N1 Uart_Init(USART1, 115200); // 注册通信回调函数，收到从车上行帧后自动处理 Protocol_RegisterCallback(USART1_RX_Callback); }这段代码是典型的竞赛工程初始化风格，没有使用复杂操作系统，而是直接操作寄存器和外设库。你想换引脚时，直接改Motor_Init和GraySensor_Init里的引脚参数就行。要特别注意：PWM 频率一旦低于 5kHz，电机在低速时会明显抖动；高于 20kHz 时 TB6612 的开关损耗会增加，芯片会烫手。10kHz 是一个实测比较靠谱的折中值。
3. 从源码到跑通：环境搭建与部署要点
3.1 开发环境与工具链选择
源码工程基于 STM32 标准外设库，编译环境用 Keil MDK 5 打开.uvprojx文件即可。这里有一个非常容易踩的入口坑：Keil 的版本差异会导致编译报错。建议直接使用 5.31 以上版本，同时把编译器选项切到AC5，因为源码里有一些__CC_ARM关键字的旧写法，用 AC6 会遇到一堆兼容性报错。如果你习惯用 GCC 工具链，也可以把源码导入 STM32CubeMX 生成的 Makefile 工程，但需要自己补启动文件，建议新手不要走这条路。
下载调试器方面，源码默认适配 ST-Link V2 的 SWD 接口。接线时只需要四根线：SWDIO、SWCLK、GND、3.3V。有些板子上的复位引脚没有引出，这没关系，SWD 不强制接复位线。但要注意，如果目标板供电不足，烧录时会出现Target not found的错误。这不是源码问题，是调试器供电和板子电源打架，解决办法是给板子单独接 USB 供电，调试器只保留 SWD 三根信号线和共地。
3.2 主车烧录与启动流程
烧录步骤本身不复杂，但启动流程里的顺序容易让人懵。源码里主车默认上电后先进入待机模式，等待无线遥控器发送启动指令。这样设计是有原因的：竞赛场次之间有间隔，你不可能每场比赛都去按复位键。启动指令解析成功后，绿色 LED 常亮，系统进入循迹模式。如果收到的是停止指令，两车同时刹停，LED 改为慢闪。
烧录时建议先把主车和从车的电源都断开，然后单个烧录。有人图省事用同一根 USB 线连着两个板子烧，结果无线模块互相干扰，调试器频繁断连。正确做法是先烧主车，断电，再烧从车。下面这段是主车端启动流程的核心逻辑，我把关键注释补上了。
void main_car_loop(void) { // 判断是否完成一次完整路径，路径完成标志由循迹状态机维护 if (task_complete_flag == 1) { // 执行匀减速停车，不是一脚急刹 Motor_SetSpeed(0); Protocol_SendStopFrame(); task_complete_flag = 0; } else { // 执行循迹状态机，状态机内部根据传感器输入调整电机PWM Track_StateMachine_Update(); } }这段代码里的Protocol_SendStopFrame()是从车主车通信的关键。调试时你会发现，如果不发停止帧，从车可能会一直执行跟随动作，直到撞上前面的主车才停下来。所以建议你把停止帧的发送逻辑单独拉出来，无论什么异常路径，只要进入停车态就必须触发一次。
3.3 从车跟随逻辑参数配置
从车的跟随逻辑源码里没有用视觉方案，而是纯粹依赖无线状态帧里的主车速度档位和方向信息。从车本地维护一个速度映射表，把主车的挡位映射到自己的电机 PWM 上。比如主车挡位 1 对应从车基线速度 180，挡位 3 对应 320。映射表在slave_car/app/follow_config.h里，我建议你拿到源码后先用串口抓一遍实际 PWM 值，再微调映射关系。
还有一个参数要专门提：从车的启动延迟。主车发送状态帧是每 50ms 一次，从车收到后立即执行还是稍微延迟，对整体节奏影响很大。源码里默认加了 20ms 滞后，用来吸收无线传输抖动。如果竞赛场地比较空旷，无线干扰小，可以把这个值改成 10ms 提升响应速度；如果场地里有大量金属围栏，信号反射严重，就保持默认值甚至加到 30ms。这个参数没有标准答案，必须现场试。
给你一个调试建议列表，先看驱动再看逻辑：
- 用串口助手监听两车的通信帧，确认收发频率稳定在 20Hz 左右。
- 用示波器或者逻辑分析仪看 PWM 波形，确认电机控制频率是 10kHz。
- 空载跑一遍主车路径，记录每个转向点的传感器响应时间。
- 从车单独通电，用手掰动主车状态模拟无线帧，观察从车是否按挡位切换速度。
4. 关键代码模块拆解：循迹、避障与跟随
4.1 循迹模块：灰度传感器与 PID
循迹是主车最核心的运行能力。源码里使用四路灰度传感器，布局为左外、左内、右内、右外。当车头完全压在中心黑线上时，中间两路输出低电平，外侧两路输出高电平。逻辑很简单，但竞赛现场的问题在于灰度传感器的阈值受环境光影响很大，尤其是灯光从侧面照过来的时候，传感器可能把白色地面误判成黑线。
源码在驱动层提供了一个校准函数GraySensor_Calibrate()，它在车辆上电后自动采样 100 次，缓存每路的基准值。运行状态里GraySensor_Read() == 0表示检测到黑线，== 1表示白底。这个校准逻辑很实用，但有个前提：校准过程中车辆不能移动，而且地面必须干净。实际比赛中，裁判经常用湿拖把拖地，水渍残留会让灰度值漂移，导致赛前校准的数据失效。我跑现场的经验是，每次比赛前把车抬起来，用一张 A4 白纸放在传感器下方手动触发校准，然后拿黑胶带模拟赛道线再测一次，这样能避免大部分环境光干扰。
int Track_GetLinePosition(void) { // 读取四路灰度原始值，0表示黑线，1表示白底 int s1 = GraySensor_Read(LEFT_OUTER); int s2 = GraySensor_Read(LEFT_INNER); int s3 = GraySensor_Read(RIGHT_INNER); int s4 = GraySensor_Read(RIGHT_OUTER); // 转换为小车相对于黑线的偏差，范围 -2 到 +2 int position = 0; position += (s1 == 0) ? -2 : 0; position += (s2 == 0) ? -1 : 0; position += (s3 == 0) ? 1 : 0; position += (s4 == 0) ? 2 : 0; return position; }这个偏差值是 PID 控制器的输入。源码里 P 系数默认是 25，I 系数是 0.2，D 系数是 8。别问为什么是这个组合，这是调了很久才稳定的结果。如果你换了大轮子或者更重的车体，这三个系数几乎肯定要重新调。调 PID 时先只留 P，让车在直线段上小幅震荡；再逐步增加 D 抑制过冲；最后加一点 I 消除直道上的静态偏差。每调一次就用胶带在地上贴一条 5 米长的直线测试，别上来就跑完整赛道，那样没法定位问题。
4.2 避障模块：超声波与状态机
主车避障模块是基于超声波距离触发状态切换的。源码里避障逻辑是一个独立的状态机，有TRACKING、OBSTACLE_DETECTED、BYPASS_LEFT、BYPASS_RIGHT、RETURN_TRACK五个状态。默认避障方向是左侧绕行，这样设计是为了让主车始终保持在赛道内侧行驶，减少冲出边界的风险。
超声波的触发距离参数在源码里叫做ULTRASONIC_THRESHOLD，默认 35cm。竞赛用车的速度通常在 0.5m/s 到 1.0m/s 之间，35cm 对应 0.35 秒到 0.7 秒反应时间，这个余量是够用的。但如果把车速调到 1.2m/s 以上，建议把阈值加大到 45cm，否则急刹时车体前倾，传感器读数会瞬间跳变，导致状态机错误切换。
超声波还有一个特性要注意：HC-SR04 的测量波束角大概 15 度，正前方遇到圆滑的立柱时，声波会被反射到其他方向，产生一个很长的假读数。源码里用一个中值滤波函数处理连续 5 次采样，取中间值作为最终判断依据。我实测下来，这个滤波在 70% 的场景有效，剩余 30% 是极端角度下连续 5 次都读到假值，此时滤波无能为力。如果你遇到这种翻车现场，最简单的办法是在超声波探头两侧加装黑色海绵挡板，限制波束扩散，比调参数管用得多。
4.3 主从跟随：蓝牙通信与速度映射
主从跟随的通信源码里选用了 2.4G 无线串口模块，它在协议上模拟串口，所以代码层面你在Uart_Init里配置的波特率就是无线模块的空中速率。常见模块支持 9600 到 115200，源码默认 115200。有一点容易被忽略：两个无线模块必须处于同一个信道和同一个地址，否则从车收不到任何数据。很多队伍出现“从车完全不动”的问题，检查下来不是代码 bug，而是主车模块用了默认地址、从车模块在配对时被改过地址，导致收发错位。
速度映射逻辑在从车端实现，源码里把主车速度分成 5 个挡位，挡位 0 代表停车，挡位 4 代表最高速。从车收到挡位后查映射表得到目标转速值，再经过一个简单的梯形加速曲线输出给 PWM。这个加速曲线非常关键，直接硬给高速挡位会让从车起步蹿出去，碰到前车。源码里把加速斜率限定在每 20ms 增加 3% 的占空比，等于说从车从静止到满速需要约 700ms，这个手感比较柔和，搬运物料时不容易洒出来。
void Slave_Follow_Update(uint8_t gear) { // 查表获得目标占空比 static const uint16_t gear_speed[5] = {0, 180, 250, 320, 400}; uint16_t target_speed = gear_speed[gear]; // 梯形加速限制，防止速度突变 if (current_speed < target_speed) { current_speed += (current_speed + 50) / 100; } else { current_speed -= (current_speed + 50) / 100; } // 输出到电机PWM Motor_SetSpeed(current_speed); }current_speed是一个全局变量，在初始化里赋值为 0。从车每次收到挡位帧都会调用一次Slave_Follow_Update，没有收到帧就不更新，保持上一挡速度。这样即使无线丢包一两帧，速度也不会突变，运行会比较平稳。但要注意：如果主车停了但停止帧丢了，从车会维持上一挡速度继续前进。所以源码里加了一个看门狗定时器，超过 200ms 没有收到任何有效帧就强制停车。我试过把主车断电测试，从车在 240ms 左右稳稳刹停，没有发生追尾。
5. 避坑与排查：调试现场最常见的五个问题
5.1 主车循迹冲线
现象是主车在高速入弯时车头直接冲出赛道，灰度传感器全部变成白底，车辆不停画弧。原因有两个层面：一是入弯前速度没有降下来，PID 输出饱和；二是灰度传感器的安装位置偏高，车体稍微倾斜就脱离检测面。解决方法是先看编码器反馈，确认入弯速度是否超过阈值。源码里提供了一个Curve_Check()函数，检测到左右内两路同时压线时，强制把目标速度降为原来的 60%。这比单纯调 PID 更有效，因为它在速度环之前截断了执行指令。
5.2 从车跟随抖动
现象是从车跟随时车身左右摆动，看似在走蛇形。原因是无线状态帧的到达时间不均匀，有时 20ms 内来了三帧，有时 100ms 一帧都不来，导致从车速度忽快忽慢。这不是电机问题，是无线调度产生的抖动。解决方法是给从车加一个输入平滑队列，源码里叫FollowBuffer，它缓存最近 5 个挡位值，取中位数作为实际执行值。把队列长度从 5 改成 9，可以进一步缓解抖动。
5.3 超声波误触发急停
现象是主车在距离障碍物还有 50cm 时突然急停，但障碍物不在正前方。原因是超声波波束打到倾斜表面，反射回程被另一只耳朵误判成近距离目标。解决方法是把触发条件从“距离小于阈值”改成“连续 3 次采样都小于阈值”，同时加入最小有效距离判断，小于 3cm 的读数直接丢弃。很多静态物体反射会造成 0cm 的假读数，不丢弃会直接原地锁死。
5.4 无线通信间歇性断连
现象是从车时而跟随时而原地不动，用串口助手监听时发现主车发的帧连续，从车收到的帧是断的。原因多半是无线模块供电不足，尤其当从车电机全速运转时，电源电压被拉低到模块最低工作电压以下。解决方法是给无线模块单独用一个 LDO 稳压，或者在模块电源脚并联一个 470uF 电解电容。不要指望共用一个电源轨没有任何波纹，电机的反电动势会直接干扰模块内部射频电路。
5.5 上电后程序跑飞
现象是烧录成功后第一次上电正常，复位后或者按了按键就进入死循环。原因是源码里某个初始化函数依赖外部硬件就绪信号，如果硬件没有及时响应，软件会一直等。具体在这个源码里，是超声波模块的Echo_Init()等待一个脉冲输入，如果模块没供电或者接线松动，函数就会卡死。解决方法是给初始化函数加超时退出机制，超过 10ms 没等到脉冲就跳过该模块初始化，主车也能正常上电，超声波功能之后在主循环里重新检测即可。
6. 进阶调参：把分数从及格拉到拿奖
6.1 速度环与转向环的配合
单纯跑通循环赛很简单，但要拿高分，比拼的是速度和稳定性之间的平衡。源码里的 PID 控制其实分了两层：外层转向环根据灰度偏差计算期望转向角，内层速度环根据转向角调整左右轮差速。很多人只调外层转向环，发现车在直道上走得还行，进弯就甩尾，这是因为内层速度环没有配合。我建议你先固定转向环参数不动，单独把内层速度环的 P 值加大，验证入弯时车体是否更稳。实测下来，高速入弯时速度环的 D 系数要大于转向环的 D 系数，否则轮速跟随太慢，转向就会出现滞后感。这个配合关系只能一组一组参数地试，没有捷径。我一般会把每组参数用 printf 打上时间戳，跑完一圈后和录的视频对时间点，定位到具体是哪个弯道的哪个参数出了问题。
6.2 从车跟随距离与防碰撞策略
从车防碰撞不能只指望看门狗超时，无线帧在强干扰下可能出现连续有效但内容错误的情况。进阶做法是在从车端额外加一个超声波防撞传感器，和通信超时形成双保险。源码里预留了Slave_Ultrasonic_Check()接口，默认没有启用。你可以把从车前向的距离阈值设为 25cm，当距离小于 25cm 时，无论主车发来什么高速挡位，从车都强制进入 5% 占空比的蠕行状态。这样可以保证在无线干扰导致主车停止帧丢失时，从车也不会直接怼上去。竞赛中裁判会重点观察双车交互的流畅度和安全性，这个设置往往是拉开分差的关键。
6.3 用日志和上位机验证整车的真实状态
很多队伍调试时只看车跑得怎么样，没有量化数据，出了问题全靠猜。我给这套源码加了一个调试习惯：把主车的挡位、灰度偏差、超声波距离、PID 输出值以 10Hz 频率通过串口发到上位机，用简单的串口绘图工具描出曲线。比如灰度偏差曲线如果呈现振荡形态，说明 PID 的 D 系数不够；超声波距离曲线如果出现尖刺，说明滤波效果不好；挡位曲线如果频繁跳变，说明无线链路有丢包。这套方法能帮你把玄学问题变成可视化数据。调试完一轮后，把曲线和赛道录像时间轴对齐，基本能在十分钟内锁定问题模块。
从那以后，我每次调竞赛车都会强制走一遍这个流程：先看数据曲线，再改参数，最后才上车测试。没有数据支撑的改动一律不做，调试效率提升非常明显。这套主车及从车端项目源码的底子很正，你照着第 2 章的结构吃透、第 4 章的模块逻辑跑通、第 5 章的坑一个个避掉，再把第 6 章的方法用起来，拿奖不敢保证，但至少能让你在赛场上少慌几次。希望帮到你。
本文还有配套的精品资源，点击获取
