最近在智能车竞赛的备赛圈子里最常听到的一句话就是“我们的进度要完蛋了”。尤其是第21届全国大学生智能车竞赛的节奏逐步推进之后不少队伍发现自己还停在“车能走直线”或者“图像还没调稳”的阶段而别人已经在跑元素、刷圈速了。这种对比确实容易让人焦虑。但作为经历过完整备赛周期的人我想说一句大多数所谓“进度完了”其实并不是真的完了而是任务拆分不清楚、调试效率太低、没有抓住优先级。这篇文章不是来给谁灌鸡汤的而是围绕智能车竞赛中最常见的“进度失控”场景整理一套从系统拆解、模块开发、联调排错到冲刺管理的完整思路。里面会给出可以直接参考的代码结构、调试方法、常见问题排查表以及最后阶段如何合理排优先级。无论是正在准备21届智能车比赛还是后面几届想提前规划的同学都可以把这篇文章当作一份“备赛避坑手册”来用。1. 为什么你的进度会失控1.1 进度焦虑的根源每当比赛临近进度焦虑几乎是所有参赛队的共同状态。但冷静下来分析你会发现进度失控通常不是某一个模块做不完而是下面几类问题叠加在一起任务没有按系统拆解想到哪做到哪。硬件和软件并行开发互相等待。调试工具不完善出现问题只能靠猜。一开始追求完美算法忽视了“先跑起来再优化”的原则。没有为机械、电池、线材等“非代码因素”预留时间。智能车竞赛有一个特点你永远不可能把所有参数调到最优但你可以通过合理的工程管理让车在一个可接受的稳定状态下进入下一轮调试。进度焦虑的本质是把“不知道怎么做”和“还没做”混在了一起。前者需要通过学习和实验解决后者只需要排列优先级并执行。1.2 一辆智能车到底包含哪些部分很多队伍进度乱是因为一上来就写图像处理、写PID却忽略了系统整体结构。先把系统拆开你才知道自己的进度到底卡在哪里。一辆典型的摄像头/光电组智能车按功能可以拆成五个层面层面核心内容主要风险点机械层车模组装、重心、轮胎、悬挂、舵机安装装好不改否则后面全部白调硬件层主控、摄像头/传感器、电机驱动、电源、编码器供电不稳接错线烧板子控制层电机速度环、舵机转向环、PID参数参数不收敛车发飘感知层图像采集、灰度/二值化、赛道元素识别图像延迟大、误判严重策略层状态机、速度规划、元素处理逻辑混乱越改越差如果当前进度落后第一步不是写新代码而是对照这张表逐项确认“哪一层还没有跑通”。大多数队伍卡在感知层和控制层的衔接上图像已经能看到了但车不知道怎么根据图像转向或者PID只写了速度环转向还在开环。2. 环境准备与版本说明2.1 开发环境怎么选智能车主控目前以 STM32 系列为主流也有部分队伍使用恩智浦、灵动微或者其他国产芯片。这里以 STM32 为例环境选择思路是通用的如果是 STM32推荐用 STM32CubeMX 生成初始化代码再配合 Keil MDK 或者 IAR 进行编译下载。如果熟悉寄存器操作也可以直接用标准外设库或 HAL 库但建议新手优先使用 CubeMX因为它能减少底层配置出错概率。上位机推荐串口助手或者自定义的 Python 脚本用于实时查看图像和参数曲线。版本需要根据你的实际芯片和开发环境调整本文示例以常见环境为例重点演示思路。不要照搬具体版本号因为芯片型号、库版本不同代码细节会有差异。2.2 调试工具清单进度慢的队伍普遍有一个特征调试工具只有一根下载线。车跑歪了屏幕没有数据只能靠肉眼猜测。下面的工具至少应该配齐串口模块或USB转TTL用于输出日志。OLED 屏幕或蓝牙模块用于显示关键参数。逻辑分析仪或示波器用于排查编码器信号、PWM 波形问题。独立电源开关和电流表用于检测堵转和短路。摄像头图像回传工具很多视觉处理板卡或配套上位机支持实时查看二值化图像。不需要所有工具一步到位但串口输出和图像回传是强烈建议优先准备的。调试效率直接决定你剩下的时间够不够。2.3 项目目录结构建议无论你用哪个 IDE都可以按照模块化思路组织源码避免所有代码堆在一个 main.c 里。推荐结构如下project/ ├── Core/ │ ├── Inc/ │ └── Src/ ├── Drivers/ ├── App/ │ ├── control/ │ │ ├── pid.c │ │ └── motor.c │ ├── sensor/ │ │ ├── camera.c │ │ └── image_process.c │ ├── strategy/ │ │ └── state_machine.c │ └── debug/ │ └── debug_uart.c这样做的目的是让每个模块可以单独测试。比如 PID 写好了可以先不给舵机输出只在串口打印计算值确认逻辑正确后再接硬件。这个习惯能避免“不知道是代码问题还是硬件问题”的尴尬局面。3. 核心模块开发顺序先求能跑再求快如果进度已经很紧张我的建议是不要按书本目录从底层开始学而是按“控制闭环→感知→策略→提速”的顺序推进。先把车变成一个“能根据输入信号稳定行动的基础平台”再往上加识别和策略。3.1 第一步让电机形成闭环很多队伍第一版代码是开环给PWM车能跑但速度不受控坡道、电池电压下降都会导致速度变化后面所有算法都会受影响。所以第一步应该把电机的速度闭环做起来。基础硬件配置包含电机驱动常见如BTN7971、DRV8701、直流减速电机、编码器。编码器一般接在定时器的编码器模式引脚上。下面以 STM32 HAL 库为例给出编码器配置思路// 文件路径App/control/motor.c核心片段 // 假设编码器A相接TIM3_CH1编码器B相接TIM3_CH2 void Encoder_Init(void) { TIM_Encoder_InitTypeDef encoder_cfg {0}; TIM_MasterConfigTypeDef master_cfg {0}; __HAL_RCC_TIM3_CLK_ENABLE(); htim3.Instance TIM3; htim3.Init.Prescaler 0; htim3.Init.CounterMode TIM_COUNTERMODE_UP; htim3.Init.Period 65535; htim3.Init.ClockDivision TIM_CLOCKDIVISION_DIV1; htim3.Init.AutoReloadPreload TIM_AUTORELOAD_PRELOAD_DISABLE; encoder_cfg.EncoderMode TIM_ENCODERMODE_TI12; encoder_cfg.IC1Polarity TIM_ICPOLARITY_RISING; encoder_cfg.IC1Selection TIM_ICSELECTION_DIRECTTI; encoder_cfg.IC1Prescaler TIM_ICPSC_DIV1; encoder_cfg.IC1Filter 0; encoder_cfg.IC2Polarity TIM_ICPOLARITY_RISING; encoder_cfg.IC2Selection TIM_ICSELECTION_DIRECTTI; encoder_cfg.IC2Prescaler TIM_ICPSC_DIV1; encoder_cfg.IC2Filter 0; HAL_TIM_Encoder_Init(htim3, encoder_cfg); HAL_TIM_Encoder_Start(htim3, TIM_CHANNEL_ALL); }读取速度时只需要读取定时器计数器的值并做差频计算int16_t speed_count (int16_t)__HAL_TIM_GET_COUNTER(htim3); __HAL_TIM_SET_COUNTER(htim3, 0);然后写一个速度环 PID。这里给出一个通用位置式 PID 控制器公式和实现都比较直观// 文件路径App/control/pid.c typedef struct { float kp; float ki; float kd; float integral; float last_error; float output_max; float integral_max; } PidObject; float PID_Update(PidObject *pid, float target, float current) { float error target - current; pid-integral error; // 积分限幅防止长时间误差积累导致积分饱和 if (pid-integral pid-integral_max) pid-integral pid-integral_max; else if (pid-integral -pid-integral_max) pid-integral -pid-integral_max; float diff error - pid-last_error; pid-last_error error; float output pid-kp * error pid-ki * pid-integral pid-kd * diff; // 输出限幅 if (output pid-output_max) output pid-output_max; else if (output -pid-output_max) output -pid-output_max; return output; }这里需要注意的是电机输出的 PWM 占空比与电压相关PID 输出需要映射到 PWM 的 CCR 范围。通常还要根据方向引脚决定正反转。示例代码如下void Motor_SetOutput(uint8_t dir_pin, uint8_t pwm_pin, int16_t output) { if (output 0) { HAL_GPIO_WritePin(GPIOA, dir_pin, GPIO_PIN_SET); __HAL_TIM_SET_COMPARE(htim1, pwm_pin, output); } else { HAL_GPIO_WritePin(GPIOA, dir_pin, GPIO_PIN_RESET); __HAL_TIM_SET_COMPARE(htim1, pwm_pin, -output); } }速度闭环做好的标志是给定固定目标速度代码输出稳定转速不随电池电压下降而明显漂移。达到这个标准才进入下一阶段。3.2 第二步转向环与基本循迹电机速度闭环之后接下来是转向。常见方案有两种基于摄像头/灰度传感器的偏差信号得到赛道偏差。根据偏差映射到舵机PWM占空比。对于摄像头组默认你已经获得了图像中赛道中线的偏差。这里先不纠结图像处理重点看如何根据偏差控制舵机// 文件路径App/control/steer.c核心片段 // 输入偏差范围假设为 -100 ~ 100输出为舵机PWM比较值 uint16_t Steer_Control(int16_t error) { int16_t center 7500; // 中位PWM需要根据实际舵机标定 int16_t range 3000; // 最大转向范围 int16_t output center error * range / 100; if (output center range) output center range; if (output center - range) output center - range; return (uint16_t)output; }实际调试中舵机中位非常重要。如果中位不准车会一直往一边偏。建议在代码里加上舵机中位和左右限位的显示方便机械调整。3.3 第三步图像处理与赛道中线提取图像处理是很多队伍进度崩掉的重灾区。如果你当前卡在这里先不要急着写复杂的透视变换和寻找赛道边界而是按以下顺序实现一个“能用”的版本读取摄像头图像转为灰度数组。对灰度图像做二值化区分赛道和赛道外。从图像底部向上扫描提取每一行的赛道中心位置。得到中线数组后计算近处平均偏差作为转向控制输入。二值化最简单高效的方法是固定阈值但光线变化时容易失效。可以改用大津法Otsu自动计算阈值。核心思路是最大化类间方差下面是简化版实现// 文件路径App/sensor/image_process.c核心片段 // 假设灰度图像为 img宽度为 W高度为 H灰度范围 0~255 uint8_t Otsu_Threshold(uint8_t *img, int W, int H) { int histogram[256] {0}; int total W * H; for (int i 0; i total; i) { histogram[img[i]]; } float sum 0; for (int i 0; i 256; i) { sum (float)i * histogram[i]; } float sum_bg 0; int weight_bg 0; float max_var 0; uint8_t threshold 0; for (int t 0; t 256; t) { weight_bg histogram[t]; if (weight_bg 0) continue; int weight_fg total - weight_bg; if (weight_fg 0) break; sum_bg (float)t * histogram[t]; float mean_bg sum_bg / weight_bg; float mean_fg (sum - sum_bg) / weight_fg; float var_between (float)weight_bg * (float)weight_fg * (mean_bg - mean_fg) * (mean_bg - mean_fg); if (var_between max_var) { max_var var_between; threshold (uint8_t)t; } } return threshold; }得到阈值后做二值化然后提取赛道边界。这部分通常需要针对你的赛道颜色和光线做多次试验不必追求完美只要在比赛场地能稳定识别中线即可。3.4 第四步状态机与元素处理当车已经能稳定循迹再加入元素识别和状态机。元素包括十字路口、环岛、坡道、路障、断路等不同组别元素不同。这里不建议把所有判断逻辑堆在中断或者主循环的 if-else 里。建议建立一个简单的状态机// 文件路径App/strategy/state_machine.c typedef enum { STRAIGHT, CURVE, CROSS, RAMP, FINISH } TrackState; TrackState g_state STRAIGHT; void StateMachine_Update(void) { switch (g_state) { case STRAIGHT: if (Check_Curve_Enter()) { g_state CURVE; } break; case CURVE: if (Check_Curve_Exit()) { g_state STRAIGHT; Set_Target_Speed(BASE_SPEED); } break; case CROSS: // 十字处理逻辑 break; case RAMP: // 坡道处理逻辑 break; default: break; } }状态机的核心价值在于每个状态只关注“进入条件”和“退出条件”不会因为某个元素处理失败导致整车逻辑混乱。这也是调试效率提升的关键。4. 调试效率才是救命稻草4.1 串口输出与 printf 重定向进度落后的队伍往往在调试时没有数据支撑。第一步是打通串口输出。以 STM32 HAL 库为例可以重定向 printf 到串口// 文件路径App/debug/debug_uart.c #include stdio.h UART_HandleTypeDef huart5; int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart5, (uint8_t *)ch, 1, 100); return ch; }之后你就能在代码里用 printf 输出中间变量printf(err%d, speed%d, steer%d\r\n, error, current_speed, steer_output);有了串口日志很多“玄学问题”会变成可分析的问题。注意串口波特率要和上位机一致常用 115200 或 460800。4.2 图像回传调车不靠猜摄像头组的调试强烈建议做图像回传。最简单的方案是通过串口发送二值化后的图像数组上位机用 Python 或配套软件还原图像。下面是一个极简的 Python 可视化思路import serial import cv2 import numpy as np ser serial.Serial(COM3, 460800, timeout1) while True: # 根据协议读取一帧图像数据这里演示单行数据 line ser.readline().decode(utf-8, errorsignore).strip() # 示例格式row, col0 col1 col2 ... if line.startswith(ROW): parts line.split() row int(parts[0][3:]) values list(map(int, parts[1:])) img[row, :, 0] np.array(values, dtypenp.uint8) img[row, :, 1] np.array(values, dtypenp.uint8) img[row, :, 2] np.array(values, dtypenp.uint8) cv2.imshow(binary_image, img) if cv2.waitKey(1) 0xFF ord(q): break这个示例只是思路具体协议需要根据你的发送代码调整。关键是看到现场图像比任何猜测都有效。4.3 用数据曲线观察 PID 响应调整 PID 参数时尽量输出“目标值、实际值、PID输出”三组数据。用串口绘图工具或写一个小的 Python 脚本绘制曲线判断超调、震荡、稳态误差。一个实用的调参经验先调 P让系统能接近目标值但允许震荡。再调 D抑制超调和震荡。最后加 I消除稳态误差。每次只变一个参数记下变化前后的现象。不要同时改三个参数否则出问题了你根本不知道是哪个参数导致的。5. 常见问题与排查思路进度紧张的时候最怕的就是被一个 bug 卡住大半天。这里整理一份智能车调试排错表供大家快速定位问题。问题现象常见原因解决思路电机不受控制PWM输出异常定时器通道配置错误或占空比比较值方向反了检查CubeMX定时器配置用示波器看PWM波形编码器读数一直为0编码器接线错误、定时器未启用编码器模式用逻辑分析仪检查A/B相波形确认引脚配置速度环震荡电机嗡嗡响PID参数过大或控制周期不合理降低P值增加D值确保控制周期稳定图像一片黑或一片白二值化阈值不对或摄像头曝光参数不合适先查看原始灰度图再调整自动阈值范围图像中心线与实际赛道偏差大摄像头安装角度、透视关系没标定固定安装后在直道重新采样标定舵机转向滞后明显中位不对或PID输出被限幅先标定舵机中位再检查转向控制输出范围电池电量掉得快电机堵转、驱动电路效率低检查机械阻力避免过度抱死车轮跑几圈后参数漂移电池电压变化导致输出能力变化速度闭环必须做好必要时加入电压补偿程序下载失败调试器连接不稳或芯片锁定检查接线尝试按住复位再下载必要时用ISP擦除排查思路永远是先确认硬件输入电源、信号再确认软件逻辑变量、分支最后再调数值参数。不要一上来就怀疑 PID 参数不对很多问题根源其实是机械卡顿或者供电不足。6. 冲刺阶段的工程建议6.1 版本控制与风险控制备赛到了后期代码改动频率会非常高。强烈建议建立代码版本控制哪怕是简单的本地备份也要保证每天结束时的代码是能编译、能跑的。比较好的做法是每次大改动前保存一个可用版本。改动后记录改动内容和测试结果。比赛前确定一个“保底版本”这个版本只修 bug不再加新功能。这不仅是代码管理更是风险控制。很多队伍在比赛前一天还在大改参数结果现场环境一变回归到场地的反而是最好的老版本。6.2 每日联调流程冲刺阶段不要每天埋头写新功能建议固定一套调试流程早上先跑一遍昨天的基线版本确认没有回退。选择当天要解决的一个最核心问题。修改参数或代码每步都要有数据反馈。下午集中做完整赛道测试记录圈速和失败点。晚上备份代码整理失败原因。这个流程的优点是每天都有一个“跑得动的版本”即使当天新功能没做完也不会影响基础稳定性。6.3 不要忽视机械与硬件稳定性到了后期决定比赛成绩的往往不是算法有多先进而是硬件稳不稳定。以下几项必须提前检查电池固定是否牢靠会不会在高速过弯时位移。轮胎磨损情况落场后是否打滑。排线是否有松动用扎带和热熔胶做好应力释放。主控板、驱动板、摄像头是否固定结实是否有共振。舵机拉杆是否顺滑有没有虚位。如果时间不够优先保证硬件不松动、不断线。这比多写一个元素识别重要得多。因为比赛现场的震动和室内测试差异很大很多队伍就是死在了看似不起眼的排线松动上。6.4 参数管理与现场调整预案比赛现场光线、赛道摩擦力、电池状态都会变化所以赛前需要准备一套“现场调参预案”。例如记录当前赛道最适应的二值化阈值范围。准备两套速度参数一套保守一套激进。比赛前先试跑一圈观察图像和舵机响应再决定是否调整参数表。把常用参数集中放在代码开头方便现场修改// 文件路径App/config/config.h #define BASE_SPEED 2000 #define RAMP_SPEED 1800 #define STEER_P 60 #define STEER_D 12 #define IMAGE_THRESHOLD 128 #define CAMERA_EXPOSURE 50集中管理参数避免在代码深层到处找魔数。7. 回到“进度要完蛋”这个问题如果用一句话回答“我们的进度要完蛋了吗”我的答案是只要车还能动、代码还能编译、串口还能输出数据进度就没有完蛋。真正完蛋的是盲目加班、无计划改动、不记录结果、发现问题不排查而是反复换参数乱试。第21届智能车竞赛的备赛周期已经到了需要做减法的时候。现在最该做的不是去网上收藏更多源码也不是下载一堆从没跑通的参考程序而是打开自己的工程对照本文的模块表格找出当前最薄弱、最影响整车奔跑的环节用半天时间把它打通然后跑起来看数据。如果你现在还处在“车能跑但说不清为什么跑不好”的阶段先从串口调试和图像回传入手把调试通道建立起来。能看见数据就不怕时间紧张数据能说话你就知道自己下一步该改什么。祝大家备赛顺利场上发挥稳定。留下来的代码和调试经验比最终的名次更值得带走。