很多第一次参加智能车竞赛的同学听到“卡丁快跑”这个名字时第一反应是“把小车做成卡丁车造型跑圈”。真去看了规则之后才会意识到这组真正考验的是两件事一是让车具备踏实可靠的自动驾驶能力二是把“人”这个环节设计得足够舒服。换句话说车要自己看路、自己打方向、自己控制速度但人在调试、接管和比赛现场同样要有清晰高效的交互手段。这篇文章就围绕卡丁快跑组把自动驾驶和人车交互两个核心点拆开揉碎讲讲我在实际调车过程中用到的方案、踩过的坑以及可以直接复用的经验和代码。准备参加21届、22届智能车竞赛的同学或者对自动驾驶小车主线感兴趣的开发者都可以参考。1. 先看清卡丁快跑组在比什么任务拆解与技术选型1.1 卡丁快跑组的核心任务与难点智能车竞赛里的“卡丁快跑组”并不是单纯追求圈速的竞速组。从我接触到的规则和赛道环境来看它通常要求车辆在铺有引导线的场地中沿指定路线行驶途中要应对十字路口、急弯、环岛、坡道等常见元素有些赛题还会增加人车交互的环节比如允许选手在等待区通过按键或无线指令让车辆完成起步、停车、降速等动作。这实际上是把自动驾驶里的“感知-决策-控制”闭环压缩到一辆低成本小车上同时要求开发者在有限的算力和功耗约束下把每个环节都做扎实。这就带来三个主要难点。第一是环境感知的鲁棒性。赛场光线会随着时间、窗帘、灯光位置变化摄像头看到的灰度/颜色分布也在变如果只用固定阈值去处理图像必然会在某一轮试跑中突然“瞎掉”。第二是控制时效性。小车速度一旦提高控制周期就必须缩短转向和速度的耦合关系也变得更复杂不能简单把转向和油门分开调。第三是人车交互的可靠性。比赛现场有很多队伍、无线设备、大功率电机通信干扰很常见如果交互系统只在调试时好用上了赛场就失灵那前面所有算法努力都可能白费。所以卡丁快跑组在我看来最像一个小型“自动驾驶项目”的缩影它逼着你在真实约束下做取舍而不是在仿真里面自嗨。理解了这一点我们再看技术选型就清楚了。1.2 整体技术架构从传感器到执行器的闭环卡丁快跑车的硬件架构通常分成感知、决策、执行和交互四层。感知层以摄像头为核心有的队伍还会加装电磁传感器、编码器和陀螺仪。摄像头负责识别引导线、赛道元素和障碍物编码器用来测实时速度陀螺仪IMU用来提供转向角速度或横摆角信息帮助判断车辆是否甩尾。决策层主要由单片机STM32系列最常见或带NPU的主控板担任负责跑图像处理算法、路径规划和控制算法。执行层是转向舵机和驱动电机负责把控制信号变成真实动作。交互层则是独立于自动驾驶链路的一套系统包括板载按键、无线遥控、蓝牙/WiFi上位机等。我在选型时坚持一个原则尽可能减少传感器种类但保证每个传感器的信息都是“冗余可交叉验证”的。比如摄像头给出车距中线的横向偏差陀螺仪给出偏航角速度编码器给出速度三者联合起来就能判断车是不是在过弯时打滑。如果只依赖摄像头一旦图像因为逆光出现一两帧丢线控制器就会收到错误偏差很容易冲出赛道。传感器选型可以简单参考下面这个表传感器/模块作用选型要点摄像头OV7725/总钻风等识别引导线、元素全局快门优先避免运动模糊安装高度和俯仰角要留出可调余量编码器Mini编码器车速测量分辨率不宜过高一般300-500线/轮就够过高反而容易引入高频噪声陀螺仪IMU角速度、姿态辅助优先选数字输出、零漂小的型号控制周期内需要做低通滤波无线串口/2.4G模块上位机调试、遥控接管独立于电机电源供电天线尽量远离功率线束OLED/按键赛场现场交互用来切换模式、查看速度、重新发车越简单越可靠这套架构跑起来之后整个闭环就是摄像头采集图像 → 主控提取赛道信息 → 生成目标转向角和目标速度 → 舵机和电机执行 → 编码器和IMU反馈实际状态 → 控制算法修正输出。人车交互则在这个闭环的外部开了一个“旁路”正常情况下不干预一旦需要接管或调试交互信号可以快速覆盖自动驾驶输出。这个设计思想很重要后面第三节我会展开讲。2. 自动驾驶核心环节让车学会自己看路和走路2.1 环境感知图像预处理与赛道识别实战摄像头图像是赛道感知的主要信息来源。很多同学一开始直接拿高分辨率彩色图像在单片机上跑OpenCV发现帧率掉得一塌糊涂。其实卡丁快跑组的算力没那么宽裕最实用的做法是把图像降到大约“80×60”或“120×80”的灰度图再做二值化和行扫描这样单帧处理时间可以控制在1-3毫秒以内足够留出更多时间给控制算法。图像处理的第一步是矫正透视。摄像头安装在车头一定高度看到的是前方的俯视斜面需要把梯形视野通过逆透视变换投影成鸟瞰图。透视变换需要标定四个点通常是在赛道上摆一张棋盘格或直接利用赛道边界来取点。变换的目的是让后续计算的中线、偏差值更接近真实世界坐标否则在近处和远处算出的偏差权重不同转向会忽大忽小。这一步建议放到比赛前就做好参数固定下来后不要频繁改动。第二步是图像预处理。常见流程是灰度化 → 滤波高斯或中值 → 二值化。二值化阈值的选择非常关键固定阈值在光线变化时会出现大面积白色或黑色所以比较稳的做法是使用自适应阈值如大津法OSTU。大津法会根据图像灰度直方图自动找分割阈值在大部分室内赛道环境下都能工作。代码上可以用OpenCV的threshold函数如果使用嵌入式C库也可以自己实现一个简单的OTSU函数计算量不大。第三步是提取赛道信息。我习惯对二值图像逐行扫描从图像底部往上每一行寻找黑白的跳变点得到左右边界再取中点作为这一行的赛道中心。把所有有效行的中心点连起来就是车要跟随的参考路径。需要注意的是如果某一行只有一个边界甚至没有边界说明出现了丢线或交叉口此时需要做“补线”处理。简单做法是保存上一帧的赛道宽度和边界的斜率利用线性外推把缺失的部分补出来高级一点的做法是结合左右边界的连续性来判断是左弯还是右弯然后用车辆的IMU和编码器数据做状态估计推测当前位置应该在哪里。实际调试中我会把“二值化中线提取”的结果实时显示到上位机上同时保存原始灰度图和二值图各一帧用于离线分析。等出现“发车后第一圈没跑完就冲出赛道”这类问题时先看保存的图像判断是感知错还是控制错避免盲调PID。2.2 决策与控制路径规划与PID的取舍当车辆能稳定提取出赛道中线后下一步是决定怎么转向和加减速。我用的决策框架很简单在每一帧图像里算出当前车体相对于赛道中线的横向偏差 error_distance以及中线在近处的斜率代表的前视偏差 error_angle两者加权合成转向控制的误差。合成误差的计算方式可以写成float error kp_dis * error_distance kp_ang * error_angle; // 距离权重和角度权重这里的 kp_dis 和 kp_ang 不是固定不变的。在直道上横向偏差变化慢距离权重可以稍大在弯道上车辆会频繁修正角度权重更敏感容易引起震荡所以我会根据当前计算出的赛道曲率动态调整两个权重。转向执行器的控制我用的是PD控制公式是 output kp * error kd * (error - last_error) / dt。实际调试中先只给 kp让车在低速下能跟着中线走再逐步加大 kd 来抑制抖动。很多同学上来就把 kp 调大车头左右猛摆误以为是舵机有问题其实是因为缺少微分项或微分项过大。需要注意PID参数在弯道和直道上最优值不同。我的做法是把赛道按曲率分段曲率小于某个阈值时使用直道参数曲率较大时切换为弯道参数。切换过程要平滑否则车辆会在切换点猛地转向。速度控制更讲究前瞻性。纯粹根据当前偏差来调速度车子到弯心才会发现速度过快然后猛刹车造成甩尾。所以我采用“前方多行中线曲率估计”的方式取图像中线上距离车体不同远近的几个点分别估算曲率再用加权和决定目标速度。比如靠近车体一米的曲率权重为0.6两米处权重0.3三米处权重0.1。这样车辆还没进弯速度就已经提前降下来。速度环同样用PID但电机存在积分饱和输出限幅和积分分离要处理好。具体来说float speed_error target_speed - current_speed; integral speed_error * dt; if (fabs(speed_error) 50) integral 0; // 大误差时积分分离 float output sp_kp * speed_error sp_ki * integral sp_kd * (speed_error - last_speed_error) / dt;参数整定实例我有一辆车低速直道 kp25、ki0.05、kd5弯道切换后 kp 降到18kd 调整到8速度环输出范围限制在PWM 1500-1900之间。这些参数和你的电机特性强相关直接抄没有意义但整定顺序可以复用先调转向让车不撞墙再调速度让车不原地抖最后做联动优化。有的队伍会尝试用MPC或纯跟踪Pure Pursuit做路径跟踪算力强的板子上确实效果更好但对卡丁快跑组来说PD就足够把车稳定控制在赛道内原因在于场地尺度小、速度上限不高线性控制器已经能覆盖大部分工作点。强行上MPC反而可能因为标定不准或计算延迟导致“理论上最优、实际上失控”。选型时先想清楚约束再决定复杂度是我一直坚持的原则。2.3 从仿真到实车数据集与离线调参怎么落地“自动驾驶数据集”听起来是个很重的东西但在竞赛里完全可以轻量化落地。我的做法是用车上的摄像头录制一段绕赛道跑几百圈的视频每帧图片和当时的电机PWM、舵机PWM、编码器速度一起存下来。这些数据有两个用途一是离线复现把比赛场地录像拿回宿舍在电脑上跑同一套图像处理和控制算法逼真地复现现场问题二是做模型训练如果后面想升级到深度学习方案这些带标签/半标签的数据就是数据集雏形。最直接的价值是离线调参。比如我发现现场试跑时车辆在某个十字路口总是误判反复修改代码烧录再跑非常浪费时间。于是我写了一小段Python脚本从SD卡读回当时的图像序列用OpenCV模拟车端图像处理流程调整参数后立刻能看到中线提取效果。跑通之后再只烧录代码一次试跑基本就能通过。这种“数据回放”的方式让我把很多偶发问题定位到了感知环节而不是继续在PID上面做无用功。如果你决定走深度学习路线比如用语义分割给赛道边缘打标签那么数据集的组织方式至少要包含三类样本正常赛道、逆光、阴影/反光。标注时只需要标“赛道可行驶区域”和“背景”两类不需要精细到像素级边缘因为控制端拿到分割结果后仍然会用行扫描提取中线边缘不是越细越好。训练用轻量网络如MobileNetV2作为编码器的UNet就可以推理时用TensorRT或NCNN部署在带NPU的板子上。但说实话卡丁快跑组规则里传统视觉方案仍然是最稳的选择。深度学习更适合作为扩展方向或加分研究点不能为了“显得高级”牺牲实时性和可靠性。仿真工具方面很多队伍会用Gazebo、CARLA或AirSim做算法预研。我的建议是仿真只用来验证规划和控制算法的稳定性不要在仿真里过度调参因为仿真和实车在摄像头高度、轮胎摩擦、电机响应延迟上的差异非常大。把实车采集的数据集用在仿真回放里比直接建一个高保真场地更实用。3. 人车交互系统别让“人”成为最不稳定的环节3.1 交互场景拆解调试、接管、赛场协同人车交互在智能车竞赛里容易被忽略但它恰恰决定了开发效率和赛场稳定性。我把它拆成三个场景。调试场景你在电脑前需要实时看到车端摄像头画面、二值图、赛道中线、当前速度、当前转向误差还要能修改PID参数、切换控制模式。这时候交互的目标是“信息全面、延迟低、操作顺手”。我常用的是一个PC上位机通过串口/WiFi连接车上的主控把上面这些数据在同一个窗口里展示。调参时不想频繁改代码重新烧录所以我设计了一套简单的“在线参数”协议参数ID 参数值上位机发送后主控直接修改运行中的变量不需要重新编译。接管场景车辆正在高速跑圈但有突发情况比如前方出现障碍物或赛道元素损坏选手需要立刻让车减速、停住或进入遥控模式。这个场景对交互的“优先级”要求极高必须保证接管指令能够覆盖自动驾驶输出不管自动驾驶正在执行什么任务。具体实现上我建议在主控程序中设置一个“控制源”变量0表示自动驾驶1表示遥控2表示停止。每个控制周期先读取这个变量再接对应的输出通道。遥控信号通过无线接收模块进入主控使用独立中断或高优先级串口接收确保不会因为主程序里的计算任务被阻塞。赛场协同场景比赛时裁判可能要求在指定区域发车或者完成一圈后人工按钮记录成绩。这时候交互设备要越容易操作越好。我们用两个独立物理按键接到主控一个是“准备/发车”按下后车辆从待机状态进入自动行驶另一个是“急停”无论车在什么状态按下后立即锁死转向、切断电机动力。这两个按键的逻辑在比赛过程中不能有任何二义性所以我在代码里加了一个简单的状态机避免误触。3.2 上位机与数据交互协议设计数据交互协议是很多人车交互系统的地基。常见的坑有三个粘包、校验不严、编码对不齐。我推荐一个简单可靠的帧格式所有发送数据都按这个格式打包字节位置内容说明0帧头固定为0xAA 0x552帧长有效载荷长度3命令字0x01 图像参数0x02 控制参数0x03 遥控指令4..N数据区按命令类型定义N1校验和所有数据区字节取和低8位比如主控向上位机发送图像中线的偏差值uint8_t buf[8]; buf[0] 0xAA; buf[1] 0x55; buf[2] 4; // 帧长 buf[3] 0x02; // 控制参数 int16_t err (int16_t)(error * 100); memcpy(buf[4], err, 2); uint8_t sum 0; for (int i 2; i 6; i) sum buf[i]; buf[6] sum; uart_send(buf, 7);上位机在Python端接收时用状态机逐字节解析先找帧头再按帧长切包最后校验。这样即使一次收到多个包也能安全拆出来。上位机的代码比较长核心逻辑就是一个while循环加状态切换我不在这里贴完整工程但强烈建议把解析函数单独封装这样后面加新命令不需要改主循环。在线调参协议我做得更轻量。每个参数用一个枚举ID表示比如PARAM_PID_KP1、PARAM_SPEED_MAX2。上位机发送0xAA 0x55 0x04 0x10 (参数ID) (float二进制) (校验)。主控端解析出ID后把对应变量直接指向内存地址修改立即生效。实测下来串口波特率在115200时确认一次调参指令的往返延迟不到2毫秒完全满足实时调车需求。3.3 AR辅助调试把参数“画”在画面上很多人觉得“增强现实”只是营销概念但我在智能车调试里找到了一个非常实用的场景把控制算法算出来的中间量直接叠加在摄像头画面上等于给车加上了一层“可视化调试滤镜”。具体做法是上位机每收到一帧原始的灰度图就把同一时刻主控计算出的赛道中线、左右边界、目标转向角度、目标速度等数据一起接受然后在图像上用OpenCV的绘图函数把线条和数字画出来。比如下面这段Python代码把接收到的中线点画在图像上for (x, y) in midline_points: cv2.circle(frame, (x, y), 2, (0, 255, 0), -1) cv2.putText(frame, err%.1f spd%.1f % (err, speed), (10, 20), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (255, 0, 0), 2)这样你看到的不再是“一串看不懂的数字”而是车“眼中”的世界。如果中线画偏了说明感知或者透视变换参数有问题如果中线是对的但转向输出抖动说明控制参数有问题如果转向输出平滑但车还是跑偏说明执行机构滞后或者机械结构有虚位。AR叠加让问题的定位时间从一小时缩短到几分钟尤其适合比赛现场调试。需要提醒的是把图像和数据一起通过无线传输会增加延迟和带宽压力。我的折中方案是在调试模式下传输完整图像并且把图像分辨率降到QQVGA160×120在正常比赛模式下不再传图像只传关键状态和速度曲线。另外上位机画图要处理好双缓冲否则OpenCV的高gui窗口会频繁闪烁看得久了眼睛很累。3.4 语音和手势交互是不是必要之前有同学问我既然这个方向带“人车交互”要不要给卡丁车加语音控制或手势识别显得更智能。我的建议是除非规则明确加分否则不要做。原因很简单比赛现场环境嘈杂语音识别率低手势识别需要额外的摄像头或深度传感器计算资源和成本都会增加。真正重要的人车交互是低延迟、高可靠的按键/遥控/上位机交互而不是华而不实的语音手势。如果你有余力可以做一个“遥控器实体按键上位机图形界面”的组合已经能覆盖绝大多数场景。4. 现场最容易翻车的五个问题与排查技巧4.1 摄像头曝光变化与丢线现象上午试跑一切正常下午换了块场地或者阳光从窗户照进赛道车开始频繁冲出赛道打开上位机看二值图发现大片的黑色或白色区域。原因多半是固定曝光和固定阈值不再适应环境。解决办法分三层一是改用自适应阈值大津法二是修正摄像头增益和曝光时间优先保证赛道区域不反光三是物理加遮光罩减少侧光干扰。排查时不要只看算法先用手挡住摄像头前方光线如果二值图马上恢复清晰说明是曝光/遮光问题。4.2 电机响应滞后与过弯甩尾现象直线加速还行但进弯后速度降不下来或者出弯时车尾外甩。先看控制周期确保速度环控制周期在5-10ms以内再看编码器滤波滤波器过长会让速度反馈滞后半拍导致速度环过冲还要检查电池电压尤其大电流放电时如果电压跌落明显电机会突然没力。解决方案是给速度环加前馈把PWM输出中叠加一部分基于目标速度的开环占空比这样PID修正量只负担误差响应会快很多。过弯甩尾还可能是因为转向和速度耦合不足我在代码里加了一个简单逻辑当转向误差绝对值大于阈值时目标速度乘以一个小于1的系数也就是“转向越大、自动减速越狠”。4.3 无线遥控接管失灵现象调试间隔一两米没问题一旦车跑到远处遥控按键有延迟甚至没反应。先检查接收模块的天线是不是被电机线缠绕这是最容易被忽略的。然后把天线挪到车壳上方远离功率电路。如果仍然失灵检查协议是否有丢包保护。我实现了一个简单的超时机制主控每20ms收到一次遥控的心跳包如果超过100ms没有心跳就自动进入安全停止状态而不是停在最后一次错误的遥控值上。这个机制在赛车冲出视野时非常有用能避免车全速撞墙。4.4 数据记录卡顿导致调试困难现象上位机画面卡成PPT调参点下去半秒才有反应。原因通常是上位机那边用了阻塞式串口读取或者图像数据没有压缩。解决办法是把图像传输和参数/状态传输分成两个通道图像用UDP或者独立串口以尽量低的帧率传参数和状态用另一个高优先级通道传。如果只有一个串口就在协议里把图像数据分包发送每帧图像之间插入一个HEARTBEAT消息上位机用固定时间片处理。实测下来用115200波特率传160×120的灰度图一帧约20KB需要1.4秒左右。所以必须降低帧率一般10帧/秒足够调试用比赛时关掉图像传输。4.5 赛场电磁干扰导致主控复位现象电机一起转单片机偶发死机或重启跑圈数据全部丢失。这是非常经典的功率地与数字地耦合问题。解决办法电机电源用独立的电源模块避免和主控共用同一个电源轨电机控制端加光耦隔离PWM信号线靠近主控时加磁珠或RC滤波在主控程序里打开看门狗定时器一旦程序卡死自动复位。这些措施要做到“比赛前全部完成并连续跑满300圈验证”不要在赛前一天才想起来。我把常见问题整理成速查表方便现场对照问题可能原因排查步骤解决方案发车后直接冲向场外丢线补线没生效/转向极性反回放图像看中线是否拟合到错误方向先修正感知再检查转向PWM极性动态误差很大PID微分项太强/滤波滞后减小kd增加速度反馈滤波器带宽平衡滤波和微分项遥控无反应天线位置/通信协议无心跳查看接收模块指示灯短距离测试重放天线心跳超时停止画面卡顿图像帧率过高/串口阻塞统计接收帧率和丢包率降帧率图像和状态分通道主控复位电源干扰/看门狗未开示波器看电源纹波检查复位标志隔离功率地开启看门狗5. 关于卡丁快跑组我再多说几句如果让我给准备参加21届、22届智能车竞赛的队伍一个建议一定要把“数据回放”和“人车交互”当成开发效率的一部分而不是最后锦上添花的东西。很多队伍把精力全部花在图像算法上等到现场出了问题才意识到车上没有一个能随时查看状态、立即接管控制的“后门”导致整个调试节奏被拖垮。我个人的习惯是在比赛前一周把整个系统冻结所有参数和代码版本记录在案。到了现场只允许微调场景相关参数比如光线阈值、速度上限绝对不临时改控制结构。同时准备一个完整的“试跑检查单”检查电池电压、轮胎胎压、摄像头安装角度、无线天线位置、刹车测试、发车按键测试。流程化能大幅减少低级失误。另一个很有用的技巧是在车上配置一块小的OLED屏幕显示当前模式、速度、故障代码。裁判或队友一看到屏幕状态就能判断需要做什么不需要打开电脑连调试线。最后再分享一个小技巧把每一次跑圈的完整数据图像、控制量、速度都存到SD卡里哪怕比赛没有出问题也留一份备份。赛后复盘时你会发现很多“当时没注意到的小抖动”其实都是下一次优化的方向。自动驾驶的进步就是靠这些真实数据一点点堆积出来的人车交互的成熟则是靠每一次“能在关键时刻接手”的踏实感换来的。希望这篇实战解析能帮你在备赛路上少踩几个坑。