电赛H题自动驾驶小车：从原理图到PID调参的完整实战指南

简介：这份资源是2024年全国大学生电子设计竞赛H题自动驾驶小车系统的完整工程包，面向备战电赛的高校学生、计算机与自动化相关专业做课程设计或毕业设计的学习者，以及需要嵌入式项目实战练手的开发者。包内共144个文件，以84个h头文件与38个c源文件为核心，构成完整的嵌入式控制代码框架，另含uvprojx、uvoptx工程文件、sct分散加载脚本、map与axf编译产物，以及jpg、png、pdf原理图与说明文档，压缩包约10.26MB，结构清晰便于直接导入编译。内容覆盖主控逻辑、MPU姿态解算、CAN通信、Flash与定时器等模块，配合原理图可帮助读者理解小车感知、决策与执行链路，快速复现赛题方案并在此基础上二次开发。目前已有2190人学习下载，适合作为高分项目参考与实战练习素材。

1. 从电赛 H 题说起：一套自动驾驶小车系统到底由哪些模块拼起来

2024 年电赛 H 题把「自动驾驶小车」推到了很多队伍面前，题目要求小车在指定场地内完成循迹、避障、目标识别与定点停车，评分点集中在路径跟踪精度、任务完成时间和系统稳定性上。真正做过这套题的人都知道，难点不在某一个模块，而在于把感知、决策、控制三层串成一条能跑通的链路。我见过太多队伍摄像头调通了、电机也能转，但一上车就画龙、丢线、误判，最后时间全耗在联调上。这套「源代码 + 原理图」的价值就在于它给了一个已经跑通的基线：主控选型、电源树、电机驱动、传感器接口、图像处理流程、PID 参数都是配套的，你拿到手可以先复现再改，而不是从零搭架子。适合正在备赛电赛 H 题、做智能车课程设计，或者想入门嵌入式自动驾驶的工程师，前提是你得愿意动手接线、烧录、调参，而不是只读代码。

2. 硬件原理图怎么读：电源树、主控最小系统和电机驱动三块先啃下来

拿到一份原理图，最忌讳从头到尾一页页翻。我的习惯是先找电源入口，再找主控，最后看执行器和传感器怎么挂上去。这套 H 题小车的原理图按功能分页，核心就三块：电源管理、主控最小系统、电机驱动与传感器接口。把这三块吃透，剩下的都是外设连线，出问题也容易定位。

2.1 电源树：先确认每一路电压从哪来、给谁用

小车上的电源通常来自 2S 或 3S 锂电池，标称 7.4V 或 11.1V，但主控、摄像头、电机驱动芯片需要的电压各不相同。常见做法是用降压模块分出 5V 和 3.3V 两路：5V 给舵机、部分传感器和电机驱动逻辑侧，3.3V 给主控和摄像头。读图时重点看三个地方：电池正负极有没有防反接、每路降压芯片的输入输出电容是否齐全、电机驱动供电和逻辑供电是否隔离。

一个血泪经验：电机启动瞬间会把 VBAT 拉低，如果 5V 和 3.3V 没有足够的输入电容，主控会复位，表现就是小车一加速就重启。原理图上如果看到降压芯片输入端只有一个小电容，基本可以判定要补。

2.2 主控最小系统：晶振、复位、下载口一个都不能少

主控最小系统是原理图里最「标准」的部分，但恰恰是新手最容易忽略细节的地方。以常见的 STM32 或 GD32 方案为例，最小系统包括主控芯片、晶振电路、复位电路、BOOT 配置和下载调试口。读图时确认四件事：高速晶振和负载电容是否匹配、复位电容是否在 100nF 量级、BOOT0 有没有下拉电阻、SWD 接口是否引出了 VCC/GND/SWDIO/SWCLK 四根线。

# 用 OpenOCD 验证 SWD 连接是否正常，替换成你的调试器配置 openocd -f interface/cmsis-dap.cfg -f target/stm32f1x.cfg -c "init; reset halt; exit"

这段命令的作用是在烧录前先确认调试器能和主控握手。如果输出里出现「Info : stm32f1x.cpu: hardware has 6 breakpoints」之类的信息，说明 SWD 链路通了；如果一直报「Error: open failed」，先查接线，再查主控供电，最后查 BOOT 配置。参数上，interface/cmsis-dap.cfg对应 CMSIS-DAP 调试器，如果你用的是 ST-Link，换成interface/stlink.cfg即可。

2.3 电机驱动与传感器接口：TB6612 和编码器的典型接法

电机驱动部分，电赛小车里 TB6612 出现频率很高，原理图上一般能看到 VM 接电池、VCC 接 5V 逻辑、AO1/AO2 和 BO1/BO2 接电机、PWMA/PWMB 接主控定时器通道、AIN1/AIN2 和 BIN1/BIN2 接普通 GPIO 控制方向。读图时注意 STBY 引脚有没有上拉，悬空的话驱动芯片不工作，这是新手最常翻的车之一。

编码器接口通常分 AB 相，A 相接主控定时器的编码器模式通道，B 相接同一侧的另一通道。原理图上如果编码器供电是 5V，而主控是 3.3V，中间需要电平转换或者确认编码器输出是开漏。我一般会在读图阶段就把每个外设的引脚号抄到一张表里，写代码时直接对照，省得反复翻图。

提示：原理图里所有标了 NC 的引脚不要想当然认为可以随便接，有些是芯片内部功能保留，接错会锁死。

3. 源代码怎么跑起来：从工程结构到第一个能动的轮子

源代码拿到手，别急着改。先按「编译能过、烧录能跑、轮子能转」三步走，每一步都确认了再往下。这套 H 题小车的代码通常分驱动层、中间件层和应用层，驱动层管 GPIO、定时器、ADC、串口，中间件层管 PID、滤波、协议解析，应用层管任务调度和逻辑判断。跑通的关键是先把驱动层验证一遍。

3.1 工程目录和编译环境：先确认工具链版本

常见做法是用 Keil MDK 或者 STM32CubeIDE 打开工程。如果你拿到的是 Keil 工程，先看.uvprojx文件里的器件型号和实际主控是否一致；如果是 CubeIDE 工程，看.cproject里的 MCU 配置。编译报错里最常见的是头文件路径不对和启动文件选错，这两类问题占新手翻车原因的一半以上。

# 以 Makefile 工程为例，先清理再编译，观察输出 make clean make -j4 2>&1 | tee build.log # 检查生成的 elf 和 hex 文件 ls -lh build/*.elf build/*.hex

make clean清掉旧的目标文件，避免缓存导致的玄学问题；make -j4用四线程编译加快速度，tee build.log把输出同时打到屏幕和日志文件，方便回查。编译成功后重点看两个数：Flash 占用和 RAM 占用。如果 RAM 占用超过 80%，后面加功能很容易栈溢出，表现就是跑着跑着死机。

3.2 烧录与串口验证：让板子先说话

烧录之后第一件事不是让轮子转，而是让串口打印出一行字。这是验证主控活着、时钟配置正确、串口驱动正常的最小闭环。代码里通常有一个uart_init和printf重定向，确认printf用的是正确的串口实例。

// 串口重定向示例，注意 USART1 和实际接线一致 #include <stdio.h> int __io_putchar(int ch) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, HAL_MAX_DELAY); return ch; } // 主函数里先打印再进主循环 printf("boot ok, sysclk=%lu\r\n", HAL_RCC_GetSysClockFreq());

__io_putchar是 Keil 和 CubeIDE 都认的重定向函数，把printf的输出引到串口。HAL_UART_Transmit的最后一个参数是超时时间，调试阶段用HAL_MAX_DELAY阻塞发送没问题，正式跑任务时建议改成非阻塞或者 DMA，否则打印会拖慢控制周期。串口助手里看到boot ok和正确的时钟频率，说明主控和串口这条链路通了。

3.3 电机开环测试：给固定占空比看轮子转不转

开环测试是排除电机驱动问题的标准手段。写一个最简单的测试函数，给左右电机各一个固定占空比，正转两秒、停一秒、反转两秒。如果轮子不转，问题在驱动接线或 STBY；如果只有一个转，查对应通道的 PWM 和方向引脚；如果转速明显不对，查定时器预分频和自动重装值。

// 电机开环测试，TIM3 通道1/2 输出 PWM void motor_test(void) { HAL_TIM_PWM_Start(&htim3, TIM_CHANNEL_1); HAL_TIM_PWM_Start(&htim3, TIM_CHANNEL_2); // 正转 50% 占空比 __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_1, 500); // 假设 ARR=999 __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_2, 500); HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_SET); // AIN1 HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET);// AIN2 HAL_Delay(2000); // 停止 __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_1, 0); __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_2, 0); }

__HAL_TIM_SET_COMPARE直接改比较寄存器，比重新配置定时器快得多，适合在控制循环里调用。占空比的计算是compare / (ARR + 1)，如果 ARR 设成 999，compare 给 500 就是 50%。方向引脚的电平组合决定正反转，具体哪个组合对应正转，不同驱动板可能相反，以实测为准。这一步跑通，说明电源、主控、驱动、电机这条功率链路没问题，可以开始上传感器了。

4. 感知与控制怎么调：循迹、避障和 PID 参数整定

小车能动了，接下来才是 H 题真正的难点：让它按赛道走。感知部分通常用灰度传感器阵列或者摄像头，控制部分用 PID 或者纯比例控制。这一章讲的是怎么把感知数据变成控制量，以及参数怎么从「能跑」调到「跑得稳」。

4.1 灰度循迹：阈值标定和加权偏差计算

灰度传感器阵列是最稳的方案，不受光照突变影响。常见做法是 5 路或 7 路灰度，每路输出模拟量或者数字量。模拟量方案需要先标定：把小车放在白底和黑线上分别读一遍，取中间值作为阈值。数字量方案省事，但阈值固定，遇到反光地面容易误判。

// 7 路灰度加权偏差计算，权重从 -3 到 +3 int weights[7] = {-3, -2, -1, 0, 1, 2, 3}; int read_gray(void) { int sum = 0, count = 0; for (int i = 0; i < 7; i++) { if (HAL_GPIO_ReadPin(GRAY_PORT, gray_pins[i]) == GPIO_PIN_SET) { sum += weights[i]; count++; } } if (count == 0) return last_error; // 丢线保持上次偏差 last_error = sum / count; return last_error; }

加权法的好处是偏差连续，PID 输入平滑。count == 0表示七路都没检测到黑线，这时候不能直接返回 0，否则小车会突然回正，正确做法是保持上一次偏差或者按丢线方向继续转。权重间隔可以根据赛道宽度调整，赛道窄就把权重拉开，赛道宽就压缩。

4.2 PID 参数整定：先 P 后 I 再 D，别一上来就三个一起调

PID 整定没有捷径，但顺序有讲究。先把 I 和 D 置零，只调 P，从小到大加，直到小车能跟着线走但有点抖；然后加 D，抑制抖动，D 太大会引入高频噪声，表现是电机啸叫；最后加 I，消除稳态误差，I 太大会积分饱和，表现是过弯后回正慢。这套 H 题小车的代码里 PID 通常是位置式，输出限幅和积分限幅都要设。

typedef struct { float kp, ki, kd; float integral, last_error; float out_max, integral_max; } PID; float pid_calc(PID *pid, float error) { pid->integral += error; // 积分限幅，防止饱和 if (pid->integral > pid->integral_max) pid->integral = pid->integral_max; if (pid->integral < -pid->integral_max) pid->integral = -pid->integral_max; float derivative = error - pid->last_error; pid->last_error = error; float out = pid->kp * error + pid->ki * pid->integral + pid->kd * derivative; // 输出限幅 if (out > pid->out_max) out = pid->out_max; if (out < -pid->out_max) out = -pid->out_max; return out; }

integral_max一般取out_max / ki的量级，保证积分项单独作用时不会超过输出上限。derivative用差分代替微分，控制周期固定时没问题，周期不固定要除以实际时间。调参时把kp、ki、kd打到串口或者 OLED 上实时看，比盲调快得多。

4.3 避障与目标识别：超声波和摄像头的分工

H 题里避障通常用超声波或者红外，目标识别用摄像头。超声波负责近距障碍，摄像头负责颜色或形状识别。两者数据融合的常见做法是：超声波检测到障碍就降速或停车，摄像头识别到目标就切换任务状态。代码里一般用一个状态机管任务切换，状态包括循迹、避障、识别、停车。

typedef enum { STATE_TRACK, STATE_AVOID, STATE_DETECT, STATE_STOP } CarState; CarState state = STATE_TRACK; void task_loop(void) { float dist = ultrasonic_get_distance(); switch (state) { case STATE_TRACK: if (dist < 20.0f) state = STATE_AVOID; else track_control(); break; case STATE_AVOID: avoid_control(); if (dist > 30.0f) state = STATE_TRACK; break; case STATE_DETECT: if (camera_detect_target()) state = STATE_STOP; break; case STATE_STOP: motor_stop(); break; } }

状态机的关键是状态切换条件要加迟滞，比如避障进入阈值 20cm、退出阈值 30cm，否则会在边界反复切换，表现就是小车一抖一抖。ultrasonic_get_distance返回单位统一用厘米，避免和摄像头测距混用。

5. 避坑与排查：电赛小车联调阶段最常见的 5 个翻车现场

这一章是我自己踩过和看别人踩过的坑，按「现象 → 原因 → 解决」写，每一条都对应一个具体的排查动作。

5.1 现象：小车一加速就复位，串口打印乱码

原因：电机启动瞬间电流大，VBAT 被拉低，降压芯片输入电压跌破最低工作电压，3.3V 输出跌落导致主控复位。串口乱码是复位瞬间波特率失锁。

解决：在电机驱动 VM 和 GND 之间并一个大电解电容，常见 470uF 到 1000uF；降压芯片输入端补 100uF 以上电容；如果还不行，把电机供电和主控供电彻底分开，用两路降压。

5.2 现象：循迹时小车画龙，左右摆个不停

原因：P 太大或者 D 太小，系统在偏差零点附近过冲。也可能是灰度传感器安装高度不一致，导致各路灵敏度不同。

解决：先把 D 加上去，从 P 的十分之一开始加；然后检查传感器离地高度，一般 5 到 10mm，太高灵敏度下降，太低容易刮地。如果还摆，把控制周期缩短，比如从 20ms 改成 10ms。

5.3 现象：摄像头图像正常但识别率低，换个场地就废

原因：阈值写死在代码里，光照一变就失效。或者摄像头曝光时间固定，运动时拖影严重。

解决：把颜色阈值做成运行时可调，通过串口或者按键现场标定；曝光时间改成自动或者根据帧率动态调。常见做法是加一个「标定模式」，按一下按键采集当前背景色作为阈值。

5.4 现象：烧录后程序不跑，调试器也连不上

原因：BOOT0 被拉高进了 bootloader，或者复位电路电容太大导致上电复位时间过长，或者 SWD 引脚被复用成了普通 GPIO。

解决：查 BOOT0 有没有下拉；复位电容换成 100nF；查代码里有没有把 PA13/PA14 配置成输出，有的话在初始化里先关掉复用。如果调试器连不上，用 BOOT0 拉高上电再连，连上后擦除 Flash。

5.5 现象：PID 调好了但换块电池就变差

原因：电池电压下降后电机转速变慢，同样的占空比对应转速不同，控制效果自然变。这是开环控制的通病。

解决：加编码器做闭环，用速度环套位置环；或者至少在代码里读电池电压做占空比补偿。常见做法是actual_duty = target_duty * nominal_voltage / current_voltage，简单有效。

注意：排查顺序永远是先电源后信号、先硬件后软件、先单模块后联调，跳步排查只会浪费更多时间。

6. 从能跑到跑得快：用日志和参数在线整定把调试效率提上去

小车能跑之后，下一步是让它跑得快、跑得稳。这一步靠的不是反复烧录试参数，而是把关键数据实时传出来看。我一般会在代码里加一个轻量级的日志模块，把偏差、PID 输出、电机占空比、电池电压按固定周期打到串口，用上位机画曲线。这样调参的时候能直接看到超调、振荡、积分饱和，比盯着小车猜快十倍。

具体做法是定义一个结构体存调试变量，主循环里每 10ms 更新一次，串口每 50ms 发一帧。帧格式用简单的文本，方便上位机解析。

// 调试帧发送，每 50ms 一次 void debug_send(void) { static uint32_t last_tick = 0; if (HAL_GetTick() - last_tick < 50) return; last_tick = HAL_GetTick(); printf("D,%d,%d,%d,%d\r\n", (int)(gray_error * 100), (int)(pid_out * 100), (int)(motor_left_duty), (int)(battery_voltage * 100)); }

D是帧头，后面四个整数分别是偏差、PID 输出、左电机占空比、电池电压，都乘了 100 转成整数，避免浮点打印的格式问题。上位机用串口助手或者自己写个 Python 脚本解析，画成四条曲线。调 P 的时候看偏差和 PID 输出的相位关系，调 D 的时候看偏差的过零次数，调 I 的时候看 PID 输出有没有长时间贴限幅。

参数在线整定还有一个技巧：把 PID 参数存在 Flash 里，通过串口命令修改，改完不用重新烧录。命令格式可以很简单，比如P 1.5改 kp，D 0.2改 kd，SAVE写 Flash。这样在赛道边调参，几分钟就能试一组，效率比反复编译高得多。

最后说一个我自己的习惯：每次调出一组好参数，立刻记在本子上，写清楚场地、电池电压、赛道材质。因为电赛现场的光照和地面和实验室不一样，实验室调好的参数到现场可能要微调，有记录就能快速找到调整方向。这套 H 题小车的代码和原理图给的是一个起点，真正拿高分靠的是你在现场快速定位问题和调整参数的能力。希望帮到你。

本文还有配套的精品资源，点击获取