第一次看到卡丁快跑组的规则文档时，我第一反应是：智能车竞赛终于把“人”放回自动驾驶系统里了。这个组别的名字里既有“卡丁车”的速度感，又有“快跑”的竞技味，但真正让它区别于往年组别的核心，其实是“人车交互”这四个字。简单来说，卡丁快跑组不再只是让一辆小车自己跑完赛道，而是要求它在自动驾驶模式下完成大部分路段的自主行驶，同时在特定环节接收人的指令——可能是手势、语音，也可能是遥控——进行模式切换或动作配合。这个设定对参赛队伍的技术栈提出了更综合的要求：你既要把感知、规划、控制这套自动驾驶链路做扎实，又要把人和车之间的通信、识别、反馈做得足够可靠。这篇文章我就以带队备赛的视角，把卡丁快跑组从赛题理解、整车方案、感知控制，到人车交互实现、现场调参配合的整个流程拆开揉碎，给准备参赛或者对自动驾驶工程落地感兴趣的朋友一份可以直接参考的实战手册。
1. 卡丁快跑组：赛题背后的技术逻辑
1.1 从“寻迹”到“理解赛道”，卡丁组到底考什么
智能车竞赛这些年一直在往“真车自动驾驶”的方向靠。早几年的组别更多是比谁的车能更快地贴着黑线跑，核心算法是二值化、边缘提取、中线拟合这些经典图像处理手段，本质上是在解决“怎么走”的问题。而卡丁快跑组的设计思路明显不一样：它把赛场限定在一个更像真实道路的场景里，赛道上有十字路口、环岛、斑马线这类交通元素，车辆不能只看“哪边是白、哪边是黑”，还得理解当前处在什么路况中，做出对应的行为决策。
卡丁组的比赛任务一般可以拆成两大段：自动驾驶段和交互响应段。自动驾驶段要求车辆自主完成一圈或几圈赛道行驶，这部分拼的是感知和控制的基本功；交互响应段则是在赛道中设置若干交互点，车辆到达后需要通过某种人机接口接收到特定指令，再执行相应的动作，比如停车等待、鸣笛示意、加速通过或者重新起步。这类设计让比赛从一个“算法竞技场”变成了一个“系统工程竞技场”：电子、嵌入式、控制、通信、上位机，每一块都是拿分点，任何一环掉链子成绩都会很难看。
所以如果你问我卡丁快跑组的核心考什么，我的答案不是“图像处理”，也不是“PID”，而是“在有限算力下，把一套完整的自动驾驶任务闭环跑起来的工程能力”。车辆要能感知环境、理解语义、做出决策、执行控制，还要能在人的介入下改变行为，这本质上已经是一个微缩版的自动驾驶系统了。
1.2 为什么选择卡丁车型：阿克曼转向带来的控制挑战
卡丁快跑组在车型上的一个显著特征是采用了阿克曼转向结构，也就是前轮负责转向、后轮负责驱动的“准真车”布局，而不是传统智能车那种双后轮差速转向。这个细节直接决定了控制算法完全不能照搬以往经验。
阿克曼转向的原理是：车辆转弯时，内外侧前轮的转角不同，外侧轮转角小于内侧轮转角，从而让所有车轮的轴线都交汇于同一个瞬时转向中心，避免轮胎侧滑。这个结构在真车上很常见，但在竞赛小车的尺度下，它首先带来的是转向执行器（舵机）的响应延迟和角度控制精度问题。差速小车可以用左右轮速度差直接产生转向力矩，响应快、模型简单；阿克曼车则必须精确控制前轮转角，而舵机的机械响应天然存在一个一阶惯性环节，转角给太快会甩尾，给太慢会推头。
对算法设计的影响也很直接：在路径跟踪时，不能把期望转向量当作“速度差”直接下发，而要把它当作“前轮转角”来做闭环控制。常用的是纯跟踪（Pure Pursuit）或者基于预瞄距离的横向偏差控制，都需要把车辆运动学模型（自行车模型）纳入计算，预瞄距离的选取还跟车速强相关。很多队伍第一次把阿克曼车调跑时最明显的感受是：弯道里车子一条一条地画龙，其实就是因为预瞄距离没随速度动态调整，或者前轮转角的PID响应跟不上赛道曲率变化。
这也是为什么我一直觉得卡丁快跑组是最适合用来理解“自动驾驶控制”的入门车型：它把整车横向控制、纵向控制、执行器延迟这些概念全部压缩到一台手掌大小的车模里，调明白之后，再去看真车的横纵向控制报告，你会发现底层逻辑其实是同一个。
2. 自动驾驶核心链路：感知、决策、控制的完整闭环
2.1 传感器方案选型与布置思路
卡丁快跑组的传感器方案，绝大多数队伍会选择“摄像头为主、雷达/测距为辅”，原因很简单：竞赛场景是二维平面赛道，视觉信息足够丰富，而且摄像头能同时解决道路线识别、元素检测、标志识别多个任务。但摄像头选型并不是越贵越好，关键看接口、帧率、全局快门和灰度/彩色。
我见过不少队伍在传感器上花了太多精力去纠结，其实主流方案就那么几种：
| 传感器 | 分辨率 | 输出 | 主要优势 | 常见场景 |
|---|---|---|---|---|
| 灰度全局快门摄像头 | 640x480 或更低 | 灰度/YUV | 抗运动模糊、曝光可调、处理简单 | 赛道线跟线、元素识别 |
| RGB彩色摄像头 | 640x480 | RGB565 / JPEG | 适合做语义分割、标志颜色识别 | 交通标志、灯色、交互手势 |
| 单点测距模块 | 单点 | 距离值 | 补盲、近距防撞 | 交互区测距、停车定位 |
| TOF/激光雷达 | 面阵/点云 | 深度 | 能直接测距，融合视觉 | 避障、地图构建（较少用） |
我的建议是：主摄用全局快门的灰度摄像头做赛道线和元素检测，因为全局快门在快速运动下不会产生果冻效应，二值化也更稳；交互识别如果要判断手势、颜色，可以再加一个RGB摄像头，或者用同一颗RGB摄像头，在图像上同时做赛道线处理和交互目标识别。不要一上来就上激光雷达，除非你明确知道打算用它解决什么问题，否则只会白白增加系统复杂度和调试时间。
安装高度和俯仰角是最容易被忽略的“隐形参数”。摄像头装得太低，近景视野占满整个画面，远处的弯道信息看不到，车速一快就来不及转向；装得太高、俯仰角朝下太狠，又会丢失远处的赛道信息。我们当时的经验是：镜头离地高度保持在15到20厘米之间，俯仰角调到让画面中“近端消失线”大约出现在图像下三分之一位置，这样既能看清近处的赛道边缘，又能提前看到一到两米外的弯道趋势。光线变化的场景下，曝光时间不要设死，要根据整体灰度动态调整，不然室外强光和室内灯光下会出现大面积丢线。
2.2 从像素到语义：赛道元素识别的关键方法
赛道线提取是自动驾驶段最基础的一环。常规流程是：灰度化、二值化、透视变换（可选）、行扫描找边线、计算中线。二值化的阈值不能固定，因为不同光照条件下白底和赛道边缘的灰度差会变化。实用做法是做一个大津法（OTSU）自适应阈值，或者按图像中心区域灰度分布动态算阈值。找到左右边线后，逐行取中点，就得到一条包含赛道路径的点序列，后续的转向控制直接盯住这条中线的末端位置就行。
但卡丁快跑组要拿高分，光会找中线远远不够。比赛场景中会出现环岛、十字路口、斑马线、停止线这类元素，它们都会干扰“找边线”这个朴素逻辑。环岛区域左右边线会突然消失，十字路口会出现多个方向的边线交叉，斑马线会引入大量高频黑白跳变。处理这些元素，不同队伍用的方法差异很大，但一条很通用的原则是：先识别元素的“特征”，再决定要不要“屏蔽”对应的图像区域处理。
以环岛为例，在进入环岛前，图像里远端会出现一段连续的白色“岛状”区域，可以通过统计远端区域白像素的数量或分布来判断是否接近环岛。判断到后，可以调整边框搜索策略，把内圈边线作为主边线，同时记录进入角度。又如停止线，通常表现为一条横向贯穿赛道的粗白线。在检测到停止线后，车辆需要执行定点停车，这时可以通过白线在图像中的纵向位置估算距离，从而控制停车时机，而不是等到撞上再去刹车——这也是后面要用到单目测距的原因。
再往后走一步，就是热词里反复出现的“语义分割”。传统二值化只能区分“是赛道/不是赛道”，语义分割则能把图像中每个像素归类为“赛道”、“路肩”、“斑马线”、“标志牌”等不同的语义类别。在竞赛场景下，可以在上位机或者带有NPU的主控上跑轻量级分割网络，比如基于MobileNet结构的编码解码网络，对图像做逐像素分类，再把分割结果作为后续逻辑的输入。这个方案的稳定性和鲁棒性都优于传统二值化，尤其适合元素干扰多的场地，代价是算力需求和开发成本明显上升。
2.3 控制策略：让车“想清楚再打方向”却又不失速度
感知做好之后，真正决定圈速的是控制策略。卡丁快跑组的控制可以拆成横向和纵向两部分：横向是前轮转角的控制，纵向是驱动电机的速度控制。
横向控制里最经典的方案是PID，但单纯的位置式PID对车模的转向控制很容易产生振荡。我建议至少用增量式PID，并且把微分项放到被控量（前轮转角反馈）上，而不是放在偏差上，这样可以避免设定值突变带来的微分冲击。此外，竞争稍微强一点的队伍都会用“预瞄控制”，也就是控制器看的不是当前车辆位置与中心线的偏差，而是前方一定距离处（预瞄点）与中心线的偏差。预瞄距离随车速增大而增大，这条“预瞄距离-车速”曲线需要实测标定，一般先给定一个基础值，再根据车速做线性增益。弯道里如果转向不足，就缩短预瞄距离、增大P项；如果来回振荡，就增大D项或适当降低弯道速度。
纵向控制的目标是“能快则快，该慢则慢”。弯道前要提前减速，出弯后要尽快加速。实现上可以做一个简单的速度规划表：根据当前点处的赛道曲率（可以从中线点序列拟合算出），映射一个期望车速。曲率半径小的地方把目标速度降下来，直道则拉满。速度闭环推荐用增量式PID加积分限幅，不然电机响应和编码器反馈延迟叠加之后，车子很容易出现“一冲一顿”的笨拙感。
最后提醒一句：转向和速度这两套控制回路不要完全独立调。阿克曼车高速过弯时，如果先急减速再急打方向，载荷转移会让后轮抓地力变化，车尾会变得不稳定。所以调参时一定是从低速到高速、从缓弯到急弯逐层进阶，先确保“慢速下稳定转向”，再逐渐提高速度阈值。这个顺序反了，后面所有数据都不可信。
3. 人车交互：把“驾驶员”放回系统里
3.1 交互场景设计与系统架构
卡丁快跑组和传统组别最大的差别，就是赛场上多了一个“人”。人车交互不是单纯加个遥控器让车听人指挥，而是在自动驾驶运行的过程中，车辆需要感知人的存在、理解人的意图，并且正确执行对应的动作。典型场景可以包括：选手站在交互区向车挥手，车识别到“停止”手势后减速停车；选手发出一个语音指令，车进入“低速巡航”模式；或者选手通过遥控器发送一个“超车”信号，车在安全前提下完成一次加速。
人车交互的系统架构可以从两条维度来拆。一条是“感知链路”：车怎么感知人的指令，可能是视觉手势识别、语音命令词识别，也可能是2.4G无线遥控信号解析。另一条是“行为链路”：车接收到指令后，当前状态机如何迁移，哪些动作不允许切换，异常情况下如何恢复。两条链路缺一不可，交互“识别到了”不等于“交互成功”，只有把识别结果转化成正确的车辆行为序列，才算是真正完成的交互。
从工程复杂度来看，识别链路往往占掉80%的调试时间。因为视觉和语音在真实场景里受到环境干扰太大：室内灯光频闪、选手衣服颜色和背景接近、语音指令被赛场广播噪声淹没，各种意外情况都会让识别率跳水。所以设计阶段就一定要想好降级方案：视觉识别不可靠时，可以用超声波或红外接近传感器作为兜底；语音识别不可靠时，可以让选手通过按键或遥控器作为备用触发；遥控通信有延迟时，要设计超时重发和状态确认机制。指望单一交互通道从头到尾稳定，几乎是不可能完成的任务。
3.2 交互识别的工程实现
在嵌入式平台上做手势识别，我的建议是“不要追求花哨，追求稳”。最实用的是一个纯图像处理方案：先按颜色阈值把戴有特定颜色手套的手从背景中分离出来，然后计算这个色块轮廓的几何特征，比如面积、宽高比、质心位置、凸包缺陷数量。把“手掌张开”和“握拳”区别出来，通常只需要看轮廓面积和宽高比就够了。
如果想让交互更有层次，可以用一个轻量级分类网络来识别几个固定手势。现在很多主控芯片已经有了简单神经网络加速能力，即使没有，也可以把图像压到很小的尺寸，比如32x32灰度图，用一个两层卷积网络在单片机上跑推理，帧率也能达到十几帧每秒。比赛场景下，手势数量控制在三到五个就够了，比如“停止”“直行”“左转”“右转”“确认”，太多容易让选手现场手忙脚乱，也会让识别模型变得难调。
语音指令的实现思路类似，比赛现场一般不会允许联网调用云端语音识别，所以我们用的是本地命令词识别方案，类似离线语音模块或者嵌入式端的轻量级关键词唤醒。先录制每组指令的语音特征模板，匹配时计算距离或相似度。这里有个容易被坑的点：现场的环境噪声会让特征匹配阈值严重失灵，要么用降噪麦克风阵列，要么在代码里加一个信噪比判断——环境太吵时直接放弃语音识别，切换到视觉或遥控通道。
遥控交互是另一种思路：用2.4G无线模块把遥控器或上位机的指令编码发送到车端。这里的难点不是发送，而是协议设计和状态同步。遥控端和车端必须定义清晰的帧格式、指令编号和校验位。车端收到指令后要先校验、再做状态迁移，不能收到什么就立刻执行什么。比如车在高速过弯时收到“停车”指令，如果立刻满刹车，很可能直接翻车。正确的做法是给每条指令附加一个“可执行条件”，不满足条件时就挂起指令，等安全时机再执行。
3.3 交互时延与可靠性的平衡
人车交互里最难调的是“时延与可靠性的平衡”。时延太大，选手会感觉车“不听使唤”；可靠性补得太多，比如长时间等待确认状态，又会让交互过程拖沓，影响比赛用时。
以遥控指令为例，如果每50毫秒发送一次指令帧，车端收到后立即执行，这个时延人基本无感；但如果无线信道拥挤，或者接收端在忙图像处理导致轮询不及时，实际响应可能超过200毫秒，就会出现“指令延迟”的糟糕手感。解决思路是：交互相关的处理要放到最高优先级的中断里，哪怕图像处理被卡住，无线指令的解析和状态置位也要优先执行。同时，指令不要只发一次，要连续多发几帧，车端按“最近有效指令”执行，做到天然的抗丢包。
对视觉和语音这类“非可靠通道”，一定要加超时回退机制。比如识别到手势后，车端在500毫秒内没有收到确认信号，就自动回到默认的自动驾驶状态，避免停在交互区发愣。这个超时值也要在现场反复实测：太短，选手动作慢一点就误判超时；太长，交互区等待时间拖太久。
交互可靠性的最终标准不是“识别率百分之多少”，而是“整个比赛流程能不出错地跑完”。所以我建议队伍在赛前反复做“全流程联调”，把自动行驶、交互触发、状态切换、恢复行驶这几步串起来，像排练节目一样跑几十遍，直到所有流程节点都稳定了，再去抠识别率的小幅提升。
4. 实战调参与问题排查实录
4.1 从零到完赛的调参顺序
很多队伍备赛卡丁组时最容易犯的错是一上来就想着“跑得快”。我的建议完全相反：先把“跑得对”做扎实，再一点点提速。具体调参顺序可以分成五个阶段：
第一阶段是“静态感知调试”。把车架在支架上，打开上位机看摄像头画面，调整曝光、阈值、透视变换参数，确保赛道线和核心元素在各种光照条件下都能稳定输出。这个阶段不要碰电机，不要碰舵机，把所有图像处理的参数先定下来。
第二阶段是“低速元素逻辑调试”。让车以非常低的速度，比如0.3到0.5米每秒，完整跑一圈赛道。这个阶段只调逻辑，不改速度，重点看元素识别和状态机切换是否正确，比如环岛有没有误判、停止线有没有漏检。只要逻辑有Bug，就在这段低速阶段修完，否则高速下根本没法定位问题。
第三阶段是“横向控制调参”。把速度固定在一个中等值，比如1米每秒，只调转向PID和预瞄距离。目标是做到任意弯道都能稳定通过，不振荡、不切内弯、不冲出赛道。调好后记录一组可靠的横向参数。
第四阶段是“纵向速度规划”。在横向稳定的基础上逐步提高弯道速度和直道速度，配合速度规划表和纵向PID，让圈速逐步上来。每次提速只动一个参数，记录对应效果，不要同时改好几个旋钮。
第五阶段才是“人车交互联调”。在完整速度下反复测试交互流程，持续缩小时延、提高可靠性。
这个顺序看起来保守，但实际是最省时间的。我们队伍第一年尝试“先提速再补交互”，结果交互一测试就发现底盘控制不稳，所有交互动作的执行效果都被底盘抖动带偏，最后被迫回头重新调转向，白白浪费了将近一周。
4.2 高频问题与处理方案
调车过程中遇到的问题是必然的，关键是能不能快速定位。我列一份在卡丁组里出现频率最高的排查清单：
| 问题现象 | 可能原因 | 解决思路 |
|---|---|---|
| 图像里赛道线断断续续 | 曝光过大/过小、反光 | 切换自动曝光、增加二值化回退策略、增加滤波 |
| 直道上跑着跑着画龙 | 预瞄距离过短、D项不足 | 增大预瞄距离、调高微分系数 |
| 弯道里车尾外甩 | 入弯速度过高、转向响应慢 | 提前减速、增大纵向PID的刹车项 |
| 环岛入口反复犹豫 | 环岛特征判定阈值过近 | 提前开启远处检测，或增加“预进入”状态 |
| 交互手势识别误触发 | 背景颜色干扰、曝光变化 | 增加颜色范围限制、加入运动先验、采用连续性判定 |
| 遥控指令偶发失灵 | 无线串扰、协议校验不严 | 换信道、增加重发机制、检查校验位 |
| 交互后无法恢复正常行驶 | 状态机卡死、超时未处理 | 增加状态超时自动复位、添加强制退出路径 |
| 停车压不住停止线 | 测距不准、刹车距离计算不匹配 | 做距离标定、增加刹车提前量、分两级刹车 |
其中最隐蔽、也最坑人的是“交互后无法恢复正常行驶”。很多队伍的状态机只做了“自动驾驶->交互->自动驾驶”的单向跳转，没有考虑识别失败、指令冲突、超时等异常路径。一旦中间状态卡住，车就会停在原地，直到裁判叫停。解决思路是：整个状态机必须是一个“每层都有默认出口”的有限状态机，任何一个状态停留超过设定的超时时间，就自动降级或者复位回自动驾驶模式，确保车辆永远有路面上的行为。
4.3 竞赛现场的工程经验
现场比赛和实验室调试完全是两回事。首先是电池电压问题：电池从满电到亏电会影响电机最高速度和舵机响应，导致参数在赛前和赛中出现漂移。我们当时的做法是，每一轮发车前都做一次统一的“满电起步”，并且要记录同一电压下的基准速度，保证每轮测试条件一致。
其次是无线信道干扰。赛场几十支队伍同时用2.4G模块的时候，无线信道拥挤程度会远超实验室环境。建议赛前多准备几个备用信道，并且做“现场扫频”，实际侦测一下哪些信道相对空闲。再一个细节是遥控接收天线和电机线的走线距离一定要拉开，否则电机换向时的电磁干扰会直接压低接收灵敏度，造成指令丢帧。
最后是赛前检查清单。我每次带队都会提前整理一份纸质清单，内容包括：电池电量是否充满、摄像头镜片是否擦拭干净、轮胎是否有磨损、舵机拉杆是否松动、摄像头固定螺丝是否拧紧、无线模块是否绑扎牢固、程序版本是否与赛道元素设置一致。听着都是小事，但任何一项在发车后出问题，都足以毁掉整轮比赛。
5. 人车协同时代的技术准备方向
卡丁快跑组这两年刚刚起步，不同赛区的规则细节也有微调，但“自动驾驶+人车交互”的大方向不会变。从更长远的视角看，这个赛题组的价值不在于那一张获奖证书，而在于它把所有自动驾驶领域的关键问题——感知、决策、执行、人机协同——都浓缩到了一个学期就能迭代多轮的平台上。
如果备赛时间充裕，我建议多留一点精力在上位机和数据可视化上。哪怕是简单的图像回传、参数调试图、状态量曲线回放，都能让调试效率提升一大截。很多队伍把大量时间花在反复烧录程序、看串口打印上，却迟迟做不出“回放数据、分析问题”的闭环，进度自然慢。可视化工具不复杂，就是用上位机把摄像头原图、处理结果、当前状态、PID输出叠到一起显示，每次跑完车看一遍回放，问题在哪里一目了然。
另外一个值得投入的方向是仿真环境。现在很多开源自动驾驶仿真器已经把一辆阿克曼小车放到模拟赛道里跑，可以直接验证感知、控制、交互的逻辑正确性。在仿真器里把逻辑跑通、把参数摸出规律，再搬到实体车上精调，能节省大量电池成本和场地占用时间。仿真和实车之间肯定有差异，但“先用仿真定位逻辑问题，再用实车调参数”这套工作流，即使放到真实自动驾驶公司里也是完全成立的。
最后说一个我自己带队实践后的体会：卡丁快跑组里最容易被低估的技术点是人车交互，但最值得投入的恰恰也就是人车交互。底盘控制和感知算法有大量往年资料可以参考，同理可循；而“车与人怎么配合”这件事，没有太多现成答案，需要自己从系统层面设计、从一次次实测里找手感。这部分的经验，无论以后是继续做竞赛还是转向科研和工作，都是完全迁移不过来的硬通货。备赛期间多在这个方向上花心思、踩几次坑，比赛结束后回头看，你会感谢那段天天蹲在赛道边研究交互流程的日子。
