在高校实验室里全国大学生智能车竞赛常被戏称为“一年四季都在修车、调车、看轮胎磨损”。真正离开赛道之后回头看这段智能车生涯留下的远不止一辆小车有被反复烧写过的芯片有十几版 PID 参数有凌晨三点还在跑直线的摄像头还有一群人在同一张调试桌前争论方案又握手和解的瞬间。用一支智能车 Vlog 纪念这段经历是很多队伍在比赛结束后都会做的事但真正动手时往往会发现视频素材要么没拍全要么代码版本对不上要么比赛现场最重要的细节根本没有记录。下面这套思路把智能车竞赛当成一门可以拆解的工程课先讲清楚一辆车从零开始会经历哪些技术模块再讲如何搭建环境、实现循迹与控制、处理边界情况最后讲怎样用 Vlog 和文档把一年的调试过程沉淀下来让这段智能车生涯不只停留在记忆里还能变成未来可复用的能力。无论你是在准备下一届比赛还是刚退役想为队伍留下点东西都可以按这个顺序落地。1. 智能车竞赛到底在做什么一场软硬件结合的压缩训练1.1 一套智能车系统的基本组成智能车竞赛的核心任务是让一辆基于单片机控制的小车在规定赛道上自主完成一圈或多圈运行。听起来简单但真正实现下来会发现一辆能稳定跑完赛道的车最少由四部分配合完成。第一是执行机构包括车模底盘、轮胎、转向舵机和驱动电机。车模通常由主办方指定或限定范围不同组别对车模尺寸、电机类型、轮胎材质有不同要求这些规则细节直接决定车辆极限速度。第二是传感器系统负责感知赛道信息。常见方案有摄像头识别赛道边缘、电磁传感器感知导线电流、激光雷达做更复杂的环境建模等。第三是主控板负责接收传感器数据、运行控制算法、输出 PWM 信号驱动舵机和电机。第四是电源与调试链路包括电池、稳压模块、串口、无线透传、下载器等。一辆车的运行流程可以抽象成三个环节感知、决策、执行。传感器采集赛道信息主控板对数据进行滤波和特征提取再通过算法算出目标转向角和目标速度最后把控制量交给舵机和电机。大部分队伍把精力花在感知的稳定性和决策算法的鲁棒性上这两项直接决定车辆能不能在全赛道上稳定跑完。1.2 从规则到任务不同组别共享同一套工程方法论每届竞赛都会在赛前发布详细规则包括车模选定、传感器允许范围、芯片型号限制、赛道元素类型等。以近几届比赛常见的组别为例摄像头组依赖视觉识别赛道边缘电磁组通过多个电感检测赛道下的通电导线平衡组在速度控制之外还要解决车体直立控制越野组则要面对更复杂的路面。组别之间差异很大但工程链条高度一致先读取原始数据再做信号处理然后提取特征最后输出控制量。常见组别主要传感器核心任务典型难点摄像头组摄像头识别赛道边缘并稳定循迹光线变化、图像畸变、帧率不足电磁组电磁电感检测赛道导线位置磁场干扰、高度变化、弯道预判平衡组陀螺仪、加速度计、传感器直立控制与速度环结合直立稳定、速度闭环、打滑补偿越野组摄像头、陀螺仪等复杂路面与坡道处理姿态变化、减震、传感器安装不同组别对算法难度要求不同但有一个共同规律先保证基本循迹能跑再逐步加入速度优化和复杂元素处理。很多队伍一上来就写高深的控制算法结果连直线都跑不直最后全部精力花在调参上。正确顺序是先搭好数据链确认传感器所见即所得再用最简单的逻辑让车能“跟线跑”最后才考虑弯道切弯、加速策略这类进阶问题。1.3 为什么“记录生涯”本身也是一种工程能力很多队伍在比赛结束后想剪一支智能车 Vlog却发现素材少得可怜。原因不是没拍而是没有把“记录”当成工程流程的一部分。代码提交记录、串口日志、参数调整记录、现场比赛视频这些素材如果能在一整年中有意识地保存最后不仅能剪出有故事感的 Vlog还能反向提升调试效率。调试智能车时最常见的困境是“昨天还能跑两圈今天突然冲出赛道”但没人记得昨天改了什么。如果每次修改都留下提交记录和现象描述就能快速回退版本。Vlog 的本质是把这种工程记录从文本扩展到影像调车时顺手录一段屏幕、比赛时按固定机位录制完整冲刺、每次出现严重问题后对着镜头说三个“发生了什么、为什么、怎么改”这些素材在赛后整理时价值非常大。2. 从零开始准备环境、工具链和调试链路的搭建2.1 硬件平台选型与起步清单准备一辆参赛车第一步不是买最贵的器件而是确认规则限定的硬件范围。主控芯片通常有明确型号限制常见平台包括英飞凌系列、恩智浦系列、ST 系列等不同年份规则对主频、封装、资源有不同约束。选型时建议优先选择队伍里有人用过的平台而不是盲目追求性能因为有人踩过坑的芯片调试效率会明显更高。除了车模和主控板下面这份基础清单建议在备赛初期一次备齐硬件/工具用途建议车模套装提供底盘、电机、舵机等执行机构按规则指定范围购买留备用轮和转向机构主控板与下载器烧录程序和在线调试确认仿真器驱动能正常安装电池和备用电池整车供电多备一组注意电压一致性传感器模块采集赛道信息根据组别选摄像头或电磁电感稳压模块给主控和传感器稳定供电电机启动瞬间电压跌落是常见故障源串口/无线调试模块输出调试数据、在线查看状态配合上位机使用效率远高于看灯逻辑分析仪或示波器查看 PWM 波形和通信时序调舵机和电机时非常必要这块容易忽略的是机械安装。传感器支架稍微松动、轮胎磨损不均匀、底盘高度不对称都会让算法输出完全不同的结果。很多控制问题排查到最后根因是机械环节而不是代码问题。所以硬件到位后第一件事是把车固定稳定确保传感器安装角度和位置在连续调试中不变化。2.2 软件工具链从 IDE 到串口监视智能车主控开发最常用的是 Keil、IAR 这类集成开发环境也有队伍迁移到 VS Code 配合扩展工具链。选择工具链的标准不是“哪个更好”而是“整个队伍能不能一致使用”。同一套代码在不同 IDE 下可能因为编译选项、优化等级不同产生不同行为赛前突然换工具链是大忌。串口调试是智能车调试里最基础也最重要的手段。主控通过串口把传感器原始值、滤波后值、目标速度、实际速度周期性发送到上位机调试者才能看到车辆内部状态。下面是一段串口发送调试信息的示例具体寄存器配置以实际芯片手册为准// 串口调试输出示例周期性发送传感器数值和控制量 // 假设 UART_SendString 已由底层驱动提供 void debug_report(void) { char buf[128]; snprintf(buf, sizeof(buf), L:%d C:%d R:%d Angle:%d Speed:%d\n, sensor_left, sensor_center, sensor_right, target_angle, current_speed); UART_SendString(buf); } // 在主循环或定时中断中调用 void main_loop(void) { while (1) { sensor_update(); control_calculate(); debug_report(); delay_ms(20); } }串口输出需要控制频率。20ms 左右刷新一帧足够观察运行趋势频率过高会占用主控时间影响控制周期频率太低则看不出动态变化。实际项目里可以设置一个调试开关比赛发布版本关闭调试输出练习版本打开避免因为日志输出拖慢控制循环。2.3 用版本管理保存代码也保存调试记录很多队伍调试智能车时代码从不用 Git而是靠“新建文件夹 v12 final 最终版”。这种习惯在比赛周期长、人员流动大的项目里非常危险。建议从第一天就用 Git 管理代码并配合一份调参记录表。下面是一个适合小型队伍的 Git 分支方案# 仓库初始化 git init # 主分支保持可运行版本 git checkout -b stable # 开发分支自由实验 git checkout -b develop # 每次可跑通一个赛段后合入 stable 并打标签 git tag experiment_20240315_lap1调参记录表建议记录日期、提交版本、赛道元素、现象描述、参数改动、测试结果六列。用表格或 Markdown 文件都可以重点是每次下赛道前先写“准备测什么”跑完立刻补“实际结果”。这样出现“昨天能跑今天不能跑”时翻一下记录和 Git log能很快定位是代码变化、参数变化还是环境变化。3. 核心技术模块实现让车先能跑再跑得稳3.1 传感器数据采集与预处理传感器是智能车的眼睛。无论摄像头还是电磁传感器原始数据都不能直接用于控制必须先做预处理。以电磁传感器为例电感读出的原始 ADC 值受温度、电池电压、离地高度影响同一位置同一角度不同时间读数可能差异明显。常规做法是采集多个通道数据后做归一化把绝对数值转成相对比例减少环境干扰。下面是一个滑动平均滤波示例用于平滑 ADC 采样值// 滑动平均滤波适合对传感器原始值做轻度平滑 #define FILTER_N 8 static int filter_buf[FILTER_N]; static int filter_index 0; int smooth_filter(int new_value) { int sum 0; filter_buf[filter_index] new_value; filter_index (filter_index 1) % FILTER_N; for (int i 0; i FILTER_N; i) { sum filter_buf[i]; } return sum / FILTER_N; }滤波窗口越大数据越平滑但延迟也越大。平衡组对延迟敏感适合小组数滤波电磁组和摄像头组可以根据运行速度调整窗口。调参时不要只盯着滤波后的曲线还要看原始值的波动范围。如果原始值本身严重跳变应该先检查接线、电源和传感器安装而不是把滤波窗口调大掩盖问题。摄像头组的预处理更复杂核心是把图像转换成赛道信息常见流程包括灰度图转换、二值化、边缘提取和偏差计算。二值化阈值是让无数队伍头疼的参数固定阈值在室内灯光下可能没问题但室外或赛场灯光变化后很容易失效。推荐做法是使用动态阈值或根据图像灰度分布自动计算至少保留一个调试界面能看到二值化后的图像否则很容易“在盲调”。3.2 控制算法从 PID 到转向与速度的解耦智能车控制里最经典的算法是 PID。绝大多数队伍用 PID 就能取得不错成绩问题通常不在算法本身而在被控对象建模不清。转向控制里输入是传感器计算出的赛道偏差输出是舵机 PWM速度控制里输入是目标速度与实际速度差输出是电机 PWM。两者必须先解耦转向环根据赛道偏差输出舵机角度速度环根据当前直道弯道状态输出目标速度不能混在一起。下面是增量式 PID 的一个基础实现适合输出到舵机或电机// 增量式 PID 示例返回本次新增控制量 float pid_incremental(float error, float kp, float ki, float kd) { static float last_error 0; static float last_last_error 0; float delta kp * (error - last_error) ki * error kd * (error - 2 * last_error last_last_error); last_last_error last_error; last_error error; return delta; }P 项负责“根据当前偏差快速反应”I 项负责消除静态误差D 项负责抑制超调。智能车控制里 D 项用多了很容易引入噪声因为传感器波动会被放大。实际调参时先只保留 P让车能大致跟线再加 D 抑制摆动最后才按需加 I。很多队伍上来就三参数一起调效果反而混乱。速度控制需要额外的思考。摄像头或电磁传感器识别的是偏差这个偏差在直道上很小在弯道上突然变大。如果只按偏差控制速度车进弯时已经来不及减速。实际做法是根据赛道特征或历史偏差提前判断弯道在入弯前完成减速。这个提前量来自对赛道连续帧的分析而不是只处理当前这一帧。3.3 边界情况处理起跑线、十字、环岛和坡道完整的比赛赛道不止直线和普通弯道还包括起跑线、十字路口、环岛、坡道等元素。处理这些元素时最忌讳的是在控制主流程里堆大量 if-else。推荐使用状态机正常循迹是一个状态检测到起跑线进入停车状态检测到环岛进入环岛处理状态处理完成后回到正常循迹状态。下面是一个极简状态机示例typedef enum { TRACK_NORMAL, TRACK_ENTER_ROUNDABOUT, TRACK_EXIT_ROUNDABOUT, TRACK_STOP } track_state_t; track_state_t state TRACK_NORMAL; void state_machine_update(void) { switch (state) { case TRACK_NORMAL: if (is_roundabout_detected()) { state TRACK_ENTER_ROUNDABOUT; } else if (is_start_line_detected()) { state TRACK_STOP; } break; case TRACK_ENTER_ROUNDABOUT: // 执行固定转向策略 if (is_exit_detected()) { state TRACK_EXIT_ROUNDABOUT; } break; case TRACK_EXIT_ROUNDABOUT: // 恢复正常循迹 state TRACK_NORMAL; break; case TRACK_STOP: // 停车逻辑只执行一次 break; } }边界元素的检测必须放在可靠数据之上。很多队伍的环岛误判来自单一条件触发比如只看某一列像素突然改变结果十字路口也触发了。稳妥做法是连续多帧确认或者结合多个特征条件判断。调试时每个状态都要单独做测试场景反复验证进入条件和退出条件不能只在完整赛道上肉眼观察。4. 用 Vlog 复盘竞赛生涯素材采集与叙事设计4.1 素材采集清单代码、画面、日志、口述智能车 Vlog 最容易犯的错是把素材集中到比赛当天拍摄最终只剩下赛道冲刺和颁奖画面完全看不到一年里的过程。真正有记录价值的素材恰恰是日常调试中最枯燥、最挫败、最无聊的片段。素材类型采集方式可提取内容常见遗漏赛道调试画面手机稳定放在赛道边车辆过弯姿态、冲出赛道瞬间只拍成功圈不拍失败过程屏幕录制录电脑上位机界面二值图、赛道曲线、参数调整过程上位机没有录屏习惯代码提交Git log 和提交备注版本演进、重大修改节点提交备注写“改了”串口日志保存文本文件异常时刻的传感器数据日志覆盖旧文件口述复盘手机录音或录视频现象、原因、下一步计划调试太晚懒得说建议每组固定安排一个人同时负责“调试记录员”不用专业拍摄只要在每次调试出现重大变化时花三分钟拍一段先说当前在调什么再说出了问题是什么最后说下一步怎么改。这种素材比后期补旁白真实得多也更容易剪出困难到解决的故事线。4.2 用时间线和版本号组织 Vlog 素材素材采集会持续几个月如果不加组织最后整理时会面对一堆“录像 001”“视频 12”的文件。建议从第一天就用统一命名规则把日期、内容、版本号写进文件名。20240315_直道参数调整_v12.mp4 20240320_环岛误判问题_log.txt 20240401_分区赛第一轮_成功圈.mp4 20240401_分区赛第二轮_冲出赛道.mp4 20240402_赛后复盘_口述.m4a同时维护一份简单的素材清单可以用 Python 脚本扫描目录生成 CSV方便后期剪辑时按关键词检索import os import csv folder race_materials rows [] for fname in os.listdir(folder): if fname.endswith(.mp4) or fname.endswith(.txt) or fname.endswith(.m4a): rows.append([fname, os.path.getsize(os.path.join(folder, fname)), fname[:8]]) with open(material_list.csv, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([文件名, 大小, 日期]) writer.writerows(rows)文件名里的日期最好和 Git 提交、串口日志的日期保持一致这样剪辑时如果发现视频里车突然失控可以立刻反查当天代码版本和日志解释清楚失控原因。素材不是视频素材的堆砌而是整套工程记录的影像化部分。4.3 复盘与剪辑把“踩坑”变成脚本Vlog 的叙事线可以按照真实经历来组织队伍组建与目标设定、赛前准备与车能跑到第一圈、进入瓶颈期反复调参、分区赛遇到突发状况、国赛冲刺与最终结果、比赛结束后对这段智能车生涯的总结。这条线不刻意煽情只要把真实节点放进去故事自然成立。剪辑时不要只剪流畅的部分。智能车 Vlog 真正打动人的是冲出赛道后的沉默、修车修到深夜的疲惫、发现问题瞬间的兴奋。建议在剪辑脚本里提前写好“困难、动作、结果、反思”四行结构场景画面配文/旁白目的困难车连续冲出环岛记录环岛误判现象建立冲突动作队员看上位机图像、改阈值解释排查过程展示方法结果车稳定通过环岛发布对应代码版本号给出交代反思赛后采访队员总结教训收束情绪技术上要注意原始赛道的错误信息和报错弹窗是很好的素材不要因为“不好看”就删掉。观众想看的不是一个完美的智能车而是一支队伍如何从不会到会、从失败到稳定。这些片段保留得越多Vlog 越有信息量。5. 常见问题排查从烧录失败到赛前失控5.1 代码烧不进去的排查链路智能车项目最基础也最气人的问题是代码烧不进去。现象可能是下载器报错、进度条卡住、主控完全没反应。排查顺序建议固定为供电、接线、Boot 模式、驱动、芯片选择。先确认主控板供电正常电池电压在范围内下载器提供的工作电压足够稳定。再检查下载器到主控的接线SWD 或 JTAG 线序是否接对杜邦线是否虚接这是最常见的烧录失败原因。接着确认芯片是否处于可下载状态部分芯片需要拉高或拉低特定引脚进入 Boot 模式。最后检查 IDE 里的芯片型号选得对不对仿真器型号和固件版本是否匹配。问题现象可能原因检查方式处理建议一直显示连接超时下载器线序接错或虚接用万用表量通断重插线换一根杜邦线芯片识别不了型号IDE 中型号选错核对主控芯片丝印重新选择对应芯片烧录后程序不运行启动模式引脚状态错误查看手册确认 Boot 引脚设置正确电平后重新上电烧录成功但现象不变下载了错版本固件检查工作区路径确认编译输出文件是否更新烧录问题里容易被忽略的是电池电压。电机起转瞬间会把电池电压拉低如果主控供电直接取电池且没有稳压可能在启动瞬间掉电复位。这也是为什么稳压模块不能省测试环境里必须用稳定电源或带保护板的电池。5.2 传感器数据漂移与赛道丢失传感器数据漂移是调车时最头疼的问题。电磁组常见现象是同一位置每次读到的电感值都不一样摄像头组则是同一赛道在不同时间看到的二值图偏差很大。排查时不能直接改算法要先判断是物理层、信号层还是算法层的问题。物理层检查传感器是否牢固、线缆是否屏蔽良好、供电是否干净。电磁传感器对金属物质、附近大电流导线敏感车模周围走线要尽量避开传感器。摄像头还要检查镜头是否沾灰、光线是否从侧面直射、曝光时间是否固定。信号层看滤波输出是否平滑如果原始值本身就是噪声滤波只能延后控制不能解决根因。算法层最后看阈值、偏差计算公式是否在目标环境中失效。建议在代码里保留一个“数据观察模式”用按键切换到串口输出或上位机显示实时查看原始值、滤波值、最终偏差。这样每到一个新场地先看三分钟数据分布再决定参数是否调整。比赛现场变化最快的是灯光和电磁环境有数据观察意识能避免很多无谓调参。5.3 比赛现场的稳定性保障训练时能跑两圈赛场上一圈就冲出赛道是很多队伍的真实经历。现场最典型的问题是环境变化赛场灯光与训练场地不同摄像头白平衡和曝光失效地板反光或材质不同电磁传感器离地高度等效变化现场存在其他队伍的车和大功率设备电磁干扰加剧。针对这些变化赛前必须有“最小改动原则”。不要因为现场不稳定就大改 PID 参数、裁剪赛道代码、替换传感器型号。正确做法是准备一套稳定的基础参数现场只做微调。同时带上完整的备份工具链电池多备、传感器多备、下载器多备、串口线多备每一样都有可能现场损坏。最后一练要留下完整日志。跑完整圈后保存串口日志、屏幕录像、车辆状态照片一旦正式比赛出现异常可以回放对比。车辆运行期间注意观察电池电压跌落情况电压不足时速度会自动下降这是冲刺后期突然慢下来的常见原因。保证现场稳定不是靠运气而是靠提前把每一条可能导致失控的链路都检查一遍。6. 最佳实践与后续扩展一条可复用的成长路径6.1 比赛后的文档沉淀清单比赛结束不是项目结束真正体现工程素养的是文档沉淀。很多队伍打完比赛就把代码丢进网盘下一届新队员进来又从零开始之前踩过的坑全部重踩一遍。建议赛后立刻整理四类材料把这段智能车 Vlog 从“视频纪念”升级为“技术资产”。第一类是技术报告包括系统架构、传感器方案、控制算法、调参过程重点写清楚“为什么选这个方案”和“遇到了什么坑”。第二类是调参记录把一年里积累的每一组参数、现象、结果整理成表格新队员可以直接在历史参数基础上继续调。第三类是 BUG 记录每个问题都按“现象、原因、解决方式、预防方式”四段写。第四类是代码归档在代码仓库里写一个 README说明目录结构、编译环境、下载方式、注意事项。沉淀内容形式复用对象技术报告Markdown 文档新队员、答辩、作品集调参记录表格/CSV参数恢复、速度提升BUG 记录文档排查同类问题代码归档Git 仓库二次开发、跨组复用这个整理过程本身也是很好的 Vlog 素材把技术报告里的关键页拍下来剪辑进去会让视频看起来更有厚度不再只是热闹的画面。6.2 团队协作与知识传递智能车竞赛通常是小组作战常见分工是硬件、软件、机械、调度各一人。团队最容易出现的问题是“代码只有一个人看得懂”。核心队员离队后整个项目就可能停摆。所以从备赛初期就要约定代码规范、命名规范和提交规则。建议使用 Git 管理代码时固定 commit 格式例如feat: 增加环岛进入判断、fix: 修复串口打印崩溃、test: 测试三次全赛道。这样后续查看历史时每个版本解决的问题一目了然。调参记录表共享到团队可访问的地方任何成员改了参数都必须登记。Vlog 素材同理统一命名后放到共享空间避免“素材在某人手机里”的尴尬。对下一届队员最好的交接不是口头讲一遍而是带着他们走一遍“环境搭建、烧录、跑赛道、看日志”全流程。让他们亲手复现一个曾经的问题再独立修复它比看十份文档都有效。这个过程也是智能车生涯最具传承价值的时刻。6.3 从竞赛小车到更广阔的嵌入式世界智能车竞赛最大的收获不是一块奖牌而是建立了一套完整的嵌入式开发方法论。感知、决策、执行这个结构可以迁移到机器人、无人机、自动驾驶、工业控制等多个方向。竞赛里练过的数据滤波、状态机、PID 调参、现场排障都是嵌入式工程师日常工作的基本功。比赛结束后想继续深入可以从几个方向选择往算法方向走学习卡尔曼滤波、PID 调优理论、视觉 SLAM往系统方向走学习 RTOS、Linux 驱动、ROS 机器人开发往工程方向走学习 PCB 设计、电路调试、可靠性设计。每一块都可以依托智能车项目继续扩展。最后说回 Vlog。这支智能车 Vlog 无论有没有剪辑完成、有没有漂亮转场只要它真实记录了这一年里调过的每一组参数、摔过的每一台车、吵过的每一个方案它就是这段生涯最值得留下的作品。如果现在你正在备赛建议从今天开始按下录音键拿起手机把当前调车的问题说清楚。几个月后回头看你会感谢这些素材。