如果你最近在关注全国大学生智能车竞赛，应该对卡丁快跑组不陌生。这个组别把自动驾驶和人车交互放在同一辆卡丁车模上考核，既要比算法稳，也要比人机配合快。说实话，第一次听到这个名字的时候，我的第一反应是：这不就是一辆缩小的卡丁车自己跑圈吗？真正带队备赛之后才发现，卡丁快跑组的难点从来不在某一个单点技术上，而在整个系统的可靠性和“人什么时候介入、怎么介入”这个竞速之外的问题。这篇文章是我从拿到车模到站上赛道的一路记录，适合准备入组的队伍、正在被调车折磨的同学，以及想透过竞赛了解自动驾驶工程化思路的朋友，希望能给你一条少走弯路的参考路径。
1. 卡丁快跑组到底比什么：从“遥控玩具”到“自动驾驶载体”
1.1 比赛环节与评分逻辑
卡丁快跑组的比赛形式这几年一直在微调，但核心逻辑大体一致：车模以卡丁车形态出现，赛道上分布着不同类型的路况元素，例如直道、S弯、十字路口、环岛、停车区，有时候还会加一个需要人工干预的接管点。整车要完成的动作通常包含自动模式下稳定跑完规定圈数、在某些特定区域切换成手动遥控，以及在不同模式之间快速切换且不出错。评分维度一般看完成时间、稳定性、接管响应速度和全程是否罚时。
这和传统四轮组的区别很明显。传统竞速组中，车辆一旦发车，全程都在自动控制下，选手几乎不能干预。卡丁快跑组则刻意保留了“人”的位置，比的是自动算法和人配合起来的整体表现。你可以把比赛想象成开车：自动驾驶系统负责大部分路况，但遇到系统不擅长或者规则要求必须人来处理的路况，驾驶员要能立刻接管。这个逻辑放在竞赛里，就很接近真实自动驾驶落地时的“人机共驾”场景。
1.2 从技术角度看，这个组别在逼你建立完整系统观
卡丁快跑组表面上是一辆车在跑，但它要求的技能栈覆盖了感知、决策、控制、通信、嵌入式开发和现场工程调试。仅仅说“会调PID”或者“会看摄像头图像”远远不够。你至少需要把这五块串成一条线：
- 感知层：用摄像头识别赛道边界、障碍物、特殊路标，或者用灰度传感器辅助判断。
- 决策层：根据感知结果判断当前处于什么路况，执行直道加速、弯道减速、路口补线、环岛识别等逻辑。
- 控制层：输出转向舵机PWM和电机PWM，让车实际执行决策，常用PID或串级PID。
- 交互层：通过遥控器、按键或上位机完成自动/手动模式切换，并把车辆状态反馈给操作者。
- 系统工程层：供电、机械结构、线束固定、散热、现场抗干扰，这些不写在评分表里，但每一样都能让你在赛场上翻车。
很多队伍在备赛初期会陷入一种错觉：图像处理得越炫、PID参数调得越激进，成绩就越好。卡丁快跑组用规则告诉你，不是这样的。如果自动模式下车辆在某些路段必翻，而人又不能及时接管，那算法再“聪明”也白搭。比赛真正考验的是，在有限时间内，你能否让所有模块稳定协同。
1.3 赛前需要先定下的三条设计原则
在我带过的队伍里，凡是开局就把目标定成“跑得最快”的，后期几乎都改成了“跑得最稳”。这不是保守，而是卡丁快跑组的赛制天然偏向可靠。在这里分享三条我反复强调的设计原则。
第一，先保证下限，再追求上限。一辆能稳定跑完一圈但速度一般的车，一定比一辆偶尔跑出最快圈速却经常冲出赛道的车更容易拿到好成绩。在自动驾驶环节，完成本身就是第一优先级。
第二，人车交互的关键是“自动为主、手动兜底”，但手动接管必须足够快。比赛不会专门等你准备好，听到指令才按键，很多时候是看到车行轨迹不对劲，就需要立刻切手动。如果接管逻辑绕了三层判断，等切换到手动时车早就冲出赛道了。
第三，模块之间尽量解耦。感知、控制、通信、状态管理要分开写，不要把所有逻辑堆在一个main函数里。现场调车时你经常需要单独看某一路数据，或者临时改一个控制参数。如果模块耦合严重，改一行代码都可能引发连锁bug，极难排查。
2. 自动驾驶部分：让卡丁车自己看懂路、找对线、稳住速度
2.1 传感器选型与安装：摄像头不是装上去就能用的
卡丁快跑组的车辆通常采用摄像头作为主要感知传感器。选择什么摄像头、安装在什么位置、俯仰角多大，直接决定后续图像处理能不能做。常见的是总钻风摄像头或者其他OV系列摄像头，经过厂家的兼容方案处理后输出灰度图像。有的队伍会额外加几个灰度传感器放在车头或车底，用来辅助检测起跑线、停车线或者十字路口，也算一种低成本冗余。
摄像头安装是个容易被忽略的细节。摄像头装得太高，看到的赛道范围大但远处目标小；装得太低，近处图像清晰但前瞻距离不够，车在弯道里根本来不及反应。一个比较通用的经验是，摄像头高度在15到20厘米之间，俯仰角在10到20度之间，具体要根据赛道尺寸和车速来调。调试时要固定摄像头支架，不能松。我带队伍时遇到过整整一个下午调PID怎么调都画龙，最后发现是摄像头支架被碰歪了，图像中线的角度已经偏了，跟控制参数一点关系都没有。
另外，赛场的环境光线和实验室差别很大。建议在代码里保留曝光和阈值的可调参数，现场用一块黑色和一块白色的板子快速标定。不要试图用一套固定参数闯天下，那样大概率在比赛现场翻车。
2.2 图像处理与道路信息提取：从像素到中线
摄像头输出的原始图像，通常要经过灰度化、二值化、边缘提取、中线计算等步骤。所说的“看线”，本质上是把赛道边界在图像中找出来，然后计算出车应该沿着哪条线走。常用工具是OpenCV，在PC上调试非常方便；但MCU端通常跑的是C语言，需要把手写的循环和图像算法精简到几毫秒内完成。
一套基础的循迹算法流程大概是这样的：采集图像 -> 从某一行的感兴趣区域开始扫描 -> 找到左右边界 -> 计算左右边界中点作为该行路径点 -> 对所有有效行的路径点做直线拟合或者取平均 -> 得到当前偏差。这个偏差就是后续转向控制的输入。
这里必须强调补线处理。赛道里如果有十字路口、环岛或者斜入元素时，图像上经常会出现“断线”的情况，如果不做补线，车就会对着断线处冲过去。卡丁快跑组里最常见的冲出赛道事故，十有八九都出在十字路口没有正确补线。补线的基本思路是，当检测到左右边界突然大面积丢失时，根据上一帧的边界趋势，在丢失区域补一条合理的线，让车先稳定通过路口，再在路口之后恢复真实边界。
2.3 转向控制：从P到PID的进化
图像处理得到偏差之后，转向控制要把它变成舵机PWM。很多新手上来直接写一个比例控制：
steer_pwm = center_pwm + Kp * error;这个写法在低速、简单赛道上能跑，但车速稍微一上去就会出现两个问题：要么转弯不够，冲出赛道；要么转向过头，车身来回摆，也就是常说的“画龙”。原因在于只考虑了当前偏差的比例关系，没有考虑偏差变化的趋势和累积量。
解决方式是在转向环引入微分项，甚至引入速度前馈和串级结构。比较通用的做法是串级PID：外环根据图像偏差计算期望横摆角速度，内环用陀螺仪或编码器反馈实现角度闭环。对于以循迹为主的卡丁车模，很多队伍用PD控制加上一些经验补偿就能跑得不错。Kp让车朝目标线靠近，Kd让车在快速变化时能“收住”，避免过冲。
下面给一组我在实车上调过的基准参数，仅供参考，不要直接照抄。模型不同、赛道不同，参数差异会很大：
| 参数 | 示例值 | 说明 |
|---|---|---|
| Kp | 0.35 | 偏差到转向角的比例系数，越大转向越猛 |
| Ki | 0.01 | 积分项，用于消除稳态误差，数值要小 |
| Kd | 0.08 | 微分项，抑制震荡，数值过大会导致高频抖动 |
| 舵机中值 | 75（归一化） | 舵机正中的PWM占空比 |
| 控制周期 | 10ms | 主循环固定频率，保证响应实时性 |
调参顺序也要注意：先把Kp从一个小值逐渐增大，直到车在直道上能稳住；再加Kd消除过弯时的摆动；最后才考虑加一点点Ki修整长直道上的细微偏差。千万不要一开始就把Kp给得很大，否则车会非常神经质。
2.4 速度规划：直道加速、弯道减速靠什么触发
转向控制解决“往哪儿拐”，速度规划解决“跑多快”。卡丁车模的电机响应比四轮车更直接，如果全程等速，要么直道太慢，要么弯道太快。简单高效的做法是分段式速度规划，根据前方赛道曲率决定目标速度。曲率可以从图像中提取，比如计算最近几行中线的平均斜率，斜率越大说明弯道越急，目标速度就要越低。
更进阶的用法是把速度规划和转向PID联动：当偏差绝对值很大时，说明车头已经偏离目标线很厉害，先减速再修正方向。这里要注意一个常见误区，速度环和转向环如果独立设计，很容易出现在弯道里一边急转弯一边猛加速的尴尬局面。我建议在代码里加一个“安全速度上限”的函数，根据当前转向角度和偏差实时限制电机输出，避免执行机构饱和。
速度规划还应该考虑前瞻距离。只盯着当前这一帧图像算曲率太短视，车到弯道入口才减速往往已经晚了。常规做法是取图像中远离车身的一行计算远距离偏差，或者对连续几帧的偏差做趋势判断。简单说，就是让车“看得远一点”，提前为前方路况做准备，这也是低成本自动驾驶里最值得花时间优化的部分。
3. 人车交互部分：手动自动无缝切换才是真正难啃的骨头
3.1 为什么人车交互是这个组别最大的分水岭
如果只看自动驾驶能力，很多队伍都能在赛道上跑完一圈。但卡丁快跑组最有意思的地方，是比赛中加入了“人”。裁判或者系统可能随时给出接管指令，也可能是赛车在某个特殊路段需要手动操作。这时候，从人手按下遥控到车辆真正响应，中间经过多少环节、每个环节有多大延迟，就成了决定成绩的关键。
人车交互的本质，是在自动控制回路中插入人为干预，同时不产生安全风险。试想一下，车正在以三米每秒的速度冲向一个自动模式处理不了的路口，你收到指令切手动，如果整个链路有500毫秒延迟，车已经冲出两米了。这个数字在比赛中足以罚掉很多时间。
所以，真正难的不是遥控器能控制车，而是遥控器和自动系统之间的协同不能有冲突。很多队伍把自动代码和手动遥控代码分开写，跑起来之后发现两个模块在抢舵机和电机的控制权，出现“切不回来”或者“切过去了车却突然加速”的诡异现象。这些问题往往不是硬件故障，而是状态管理和控制权交接的设计漏洞。
3.2 交互方式选型：遥控器、按键、上位机怎么选
卡丁快跑组的人车交互方式一般包括无线遥控器、车载按键/拨码开关、上位机软件三种。比赛规则不同，常用组合也不同。2.4G遥控器适合比赛现场快速接管，延迟低、手感直观；蓝牙或者串口数传适合把数据传给电脑做分析和调试；车载按键适合应急保护，比如一键切到急停状态。
选型时要重点关注延迟和抗干扰。实验室里很好用的蓝牙模块，到了赛场人多、无线设备多的时候，很可能会出现偶发丢包。经验做法是优先选择2.4G遥控接收机或者带跳频功能的无线数传模块，并在通信协议中加入简单校验，避免错误数据触发误动作。
我踩过的一个坑是，遥控器接收机放在车模底盘角落，被锂电池和电机线缆包围，结果一上电舵机抖、遥控距离缩短。后来把接收机天线引到车壳外，远离电机和电源线，问题立刻消失。无线模块看起来不起眼，但它能否稳定工作，直接决定人车交互环节的成败。
3.3 状态机设计：用有限状态机管理驾驶模式
人车交互最可靠的管理方式就是有限状态机。不要用一堆bool变量去判断当前该是自动还是手动，那样代码稍微复杂一点就会理不清逻辑。建议明确定义几个模式：
- IDLE：待机，电机不输出，舵机居中。
- AUTO：自动驾驶模式，感知、决策、控制全自动运行。
- MANUAL：手动遥控模式，接收遥控器指令控制转向和油门。
- EMERGENCY：急停模式，无论之前是什么状态，触发后立刻停车并锁定电机。
- FINISH：完成比赛，进入停止状态。
状态切换条件是重中之重。状态机自己在管理模式，但切换动作必须可靠、可复现。例如，从AUTO切到MANUAL时，要先将当前舵机输出保持一段时间，再逐渐过渡到遥控值，而不是瞬间跳变，这样可以避免车辆在切换瞬间猛地抖一下。从MANUAL切回AUTO前，也要先确认图像处理已经恢复并给出有效偏差，否则车可能在自动驾驶接管的第一帧就跑偏。
实际项目中，我用过一个简单的状态机切换函数：
void mode_switch(drive_mode_t new_mode) { if (new_mode == mode) return; switch (new_mode) { case MODE_AUTO: image_ready = reset_image_processing(); if (image_ready) mode = MODE_AUTO; break; case MODE_MANUAL: set_servo(center_pwm); mode = MODE_MANUAL; break; case MODE_EMERGENCY: set_motor(0); set_servo(center_pwm); mode = MODE_EMERGENCY; break; default: break; } }这段代码没有多复杂，但它保证了模式切换不是临时起意，而是有明确的前置条件和副作用管理。状态机在嵌入式环境里永远是好东西，它让现场调车时的思路非常清晰。
3.4 接管延迟这个隐藏指标
我每次带队伍，都会让学生专门测“接管延迟”：从遥控器按下到车上执行机构真正动作，到底隔了多久。这个指标在竞赛规则里可能不会直接标出分数，但它直接影响你的实际表现。
延迟通常拆成五段：无线接收模块解包延迟、串口或IO中断通知延迟、MCU状态机切换延迟、控制周期等待延迟、执行机构响应延迟。前四段可以通过代码优化压缩到20毫秒以内。比如无线接收模块数据到达后，使用DMA+空闲中断接收，而不是在主循环里轮询；状态机切换放在中断上下文里只做标记，主循环检测到标记后再执行切换动作。
执行机构响应也不可忽视。舵机PWM频率如果是50Hz，也就是20毫秒一个周期，那么即使控制逻辑再快，输出也要等下一个周期才能更新。可以考虑将舵机PWM频率提高到100Hz甚至200Hz，这样能明显降低转向响应延迟。不过要注意，舵机频率调高之后，舵机供电电流和发热会变化，要确认电源余量足够。
4. 备赛与调车的实战细节：这些坑我替你先踩了
4.1 一套适合卡丁快跑组的代码架构
卡丁快跑组的代码量不大，但逻辑分支很多。如果全堆在一个文件里，后期每改一个参数都可能编译半天，而且很容易误改。我的建议是按模块分文件：
main.c：初始化、主循环、状态机执行。sensor.c：摄像头采集、图像处理、中线提取。control.c：转向PID、速度规划、电机控制。communication.c：遥控接收、串口收发、数据解析。state_machine.c：模式管理、切换条件判断。debug.c：液晶屏显示、串口打印、日志存储。
主循环固定一个周期跑，一般10毫秒比较合适。所有模式切换、遥控数据处理可以放在中断或快速循环里先打标记，主循环只负责按状态执行对应控制逻辑。这样即使外部事件来得快，也不会打断当前的控制周期。
调试接口一定要早做。在板上接一个OLED显示当前模式、图像偏差、目标速度，再通过串口把关键变量打印到上位机。很多时候图像被压缩成二值化之后，肉眼看不太出来问题在哪，只有实时看数值变化才能定位。
4.2 从仿真到实车：先验证逻辑再解决机械问题
一些队伍喜欢在自动驾驶仿真环境里练习，比如CARLA或者其他模拟平台。仿真对算法逻辑的验证是有效的，但卡丁快跑组大量问题出在实车机械和硬件上，仿真无论如何都不能替代。我建议把仿真当成“逻辑预演”，验证状态机和图像处理思路，但最终还是要以实车为准。
实车调车要养成记录习惯。每轮测试前先记录：电池电压、赛道环境、摄像头曝光参数、速度上限、PID参数、轮胎状态、当时的风速和光线。测试后记录现象和结论。这个习惯看起来繁琐，但一次参数漂移排查就能让你感谢这份记录表。
我遇到过最典型的一种情况是：车上午跑得很好，下午怎么调都跑不好。查了半天发现是场地灯光从上午的侧光变成了下午的逆光，摄像头图像整体变暗，中线提取已经失真。如果提前有曝光参数可调，并且知道当前用的什么参数，现场就能快速修正。
4.3 备赛时间线建议：六周的节奏怎么安排
卡丁快跑组不太适合临阵磨枪。我带队常用的备赛周期是六周，大约这样分配：
| 阶段 | 时间 | 目标 |
|---|---|---|
| 第1周 | 车模组装、硬件点亮 | 电机能转、舵机能打角、串口能收发、无线遥控能控制 |
| 第2周 | 图像处理基本跑通 | 能稳定输出赛道中线，十字路口补线有雏形 |
| 第3周 | 简单PID跑圈 | 用比例控制或PD控制在低速下跑完完整赛道 |
| 第4周 | 串级PID与速度规划 | 直道能加速，弯道能减速，整体圈速稳定提高 |
| 第5周 | 人车交互专项 | 反复测试自动/手动切换、急停、故障注入，优化接管延迟 |
| 第6周 | 现场模拟与复盘 | 模拟比赛流程，记录所有可调参数，准备备件和应急预案 |
这个时间线不是死规则，但它能保证你不会在最后几天还在改PID。实际备赛中，第5周人车交互专项最容易被压缩，因为大家总觉得“遥控器能控制不就行了”。等到赛场上一紧张，切换逻辑的bug全暴露出来，后悔都来不及。
4.4 现场比赛的隐藏细节
先说电池。锂电池在电量不同阶段放电特性差异很大，满电时电机响应快，快没电时输出软绵绵。如果你的速度PID参数是根据满电状态调的，比赛后半段很可能出现直道速度上不去的情况。建议赛前把电池统一充到同一电压范围，同时准备备用电池，每轮发车前检查电压。
再说线束。小车在赛道上震动非常大，插排针、杜邦线很容易松脱。我见过队伍在检录时摄像头突然黑屏，结果发现是排线松了。所有连接器最好用热熔胶或者扎带固定，并且在备赛阶段就养成“每次上车前按一遍连接器”的习惯。
最后是比赛场地光线。大型场馆的灯光往往和实验室完全不同，特别是顶灯直射造成的反光和高光区域，会让二值化图像出现大片误判。所以到了比赛现场，第一件事不是跑速度，而是花二十分钟重新标定摄像头曝光和阈值。这一点做不到位，后面全白搭。
5. 常见问题排查与调车经验：现场最容易翻车的几个瞬间
5.1 典型症状与排查思路
把我在备赛和比赛中遇到过的问题整理成了一张速查表，方便对照排查：
| 症状 | 可能原因 | 处理办法 |
|---|---|---|
| 直道反复画龙 | Kd过小或过大、前瞻太近、机械间隙大 | 先增大Kd观察，无效时检查前轮和转向连杆虚位 |
| 十字路口冲出去 | 补线逻辑缺失或补线方向错误 | 打印路口标志和补线结果，逐帧回放图像确认 |
| 手动接管没反应 | 状态机被阻塞、串口中断丢失、无线模块掉线 | 检查状态是否停在AUTO，无线接收指示灯是否正常 |
| 环岛内乱转 | 没有识别环岛入口/出口，路径规划混乱 | 单独做环岛状态，用边界斜率判断入口出口 |
| 上电舵机抖动 | 电源干扰、PWM频率不合适、舵机中值不对 | 给舵机单独供电或加电容，调整PWM频率 |
| 跑起来越来越慢 | 电池电压下降、电机过热、速度环积分饱和 | 记录电压曲线，检查速度环输出是否长时间饱和 |
现场排查问题时有几个通用原则：先确定是机械问题还是代码问题；再确定是感知问题还是控制问题；最后确定是偶发问题还是必现问题。把问题范围一步步缩小，比随机改参数有效得多。
5.2 一个真实debug过程
有一次，我们队的车在第三个弯道必出赛道，之前几天还跑得好好的。大家第一反应是PID参数被谁改了，检查后发现参数没动。又怀疑是赛道摩擦力变了，清理场地后问题仍然存在。后来我在图像窗口里逐帧看二值化结果，发现第三个弯道处正好有一块从窗户照进来的光斑，把二值化后的赛道边界“吃”掉了一部分，导致中线计算跳变。
解决办法有两个方向：一是调整摄像头曝光，尽量让亮部和暗部都能保留；二是在图像处理里加入“区域阈值”或者边缘跟踪，减少环境光干扰。最后我们选择增加一个动态阈值的逻辑，根据图像整体亮度实时调整二值化阈值，效果立竿见影。这个案例说明，调车遇到诡异问题，不要只盯着控制参数，多看看感知层在特定场景下的表现。
5.3 独家调车心得：一些常规文档里不会写的经验
第一，摄像头曝光参数必须做成可调，而且最好有两种固定模式：一种适用于实验室暖光，一种适用于赛场冷光和强光。快速切换比现场一点点调阈值要省时间得多。
第二，赛前把轮胎用湿布擦干净，赛道上的浮灰也要清理。卡丁车模和真实赛车一样，轮胎附着力的变化会直接影响弯道极限。很多时候你感觉“车突然变滑了”，其实不是代码问题，而是轮胎和地面之间那层灰在作怪。
第三，每个版本改了什么参数、改完之后的现象是什么，一定要有人专门记录。队伍里最好安排一个人不碰代码，只负责记录和计时。这个人看起来没有参与技术工作，但实际上他是全队最重要的“数据库”。没有记录，调车就只能是靠手感摸黑。
第四，不要迷恋大Kp。新手最容易把比例系数调到很大，觉得这样车“反应快”，结果就是各种抖动和过冲。真正好的转向手感是，车在直道上几乎感觉不到修正，进入弯道时平滑地切过去，而不是每帧都在大角度修正。能用更小的误差和更温和的控制达到目标速度，才是高水平调车。
第五，人车交互的测试一定要加入“故障注入”。比如模拟自动模式在某个点突然丢失图像，看手动接管是否能在两秒内救回来。如果这个测试没做过，比赛现场一旦出状况，八成会慌。提前演练，至少能保证人在赛场上知道自己第一步该按哪个键。
卡丁快跑组带给我最大的收获，不是那张奖状，而是让我真正理解了自动驾驶落地时，最难的不是算法本身，而是算法和人之间那个交接的瞬间。如果你正准备入组，我建议先把稳压电源、串口日志和录像这三样基础工具准备好，所有可疑问题先记录下来再动手改。赛场上九成九的事故，都是平时测试里见过的小毛病，只是刚好在小概率时刻集中爆发了。祝你们跑得稳，接得准。
