很多第一次接触智能车竞赛卡丁快跑组的队伍都会陷入一个误区以为这个赛项拼的是绝对车速谁油门踩得狠谁拿奖。我在带队跑完一届比赛之后最大的体会其实是反过来的——卡丁快跑组真正考验的是一套自动驾驶系统在低速场景下的完整性与可交互性。它模拟的是园区物流车、无人小巴这类场景赛道不长速度也不高但系统必须在连续运行中不翻车、能理解赛道、能响应人的介入。这篇文章我就围绕自动驾驶与人车交互两条主线把我们从硬件选型、感知控制、仿真验证到赛场排错的完整实践过程拆开来讲希望能给准备参加这个赛项的队伍一些能直接落地的参考。1. 卡丁快跑组比的不只是“跑得快”从竞赛规则倒推技术需求1.1 一个容易被低估的赛项它考的是“完整系统”卡丁快跑组的比赛场景通常是在一个小型场地上布置出模拟城市道路直道、弯道、环岛、停车线、障碍物有时还有模拟行人或者需要会车的区域。车要从起点出发完成一圈或多圈自动驾驶中途不能冲出赛道、不能撞到障碍物再配合规定的停车、避让动作最后停在指定区域。听起来很简单对吧但真实比赛的难度在于这不是跑一次而是可能要求连续跑多圈或者在有限时间内完成多次任务尝试。这意味着系统不能有偶发性崩溃不能有传感器随机丢帧导致的大偏差不能因为光照变化一下就把车道线弄丢。你会发现它考的其实是工程化的“可靠交付”而不是跑出一个漂亮的速度数据。1.2 评审视角下的赛事评分权重从我们的参赛经验看评委打分基本围绕这几个维度我按权重给大家排一下评分维度大致权重对应的核心技术需求任务完成度35%循迹稳定、避障可靠、停车精准系统稳定性25%连续运行不崩溃、不重启、不冲出赛道人车交互20%实时状态可视化、急停响应、人机接管技术方案与创新20%使用了什么算法架构、是否有自研模块看到这个权重就应该明白速度分占比很低完成度和稳定性才是大头。很多队伍堆了三四个激光雷达算法也很“重”结果赛场上各种超时、卡死最后成绩反而不如一辆用了单目摄像头加低端工控机的“素车”跑得稳。所以最开始做技术选型时脑子里要绷一根弦这个配置是为了“稳定跑完”服务的不是为了炫技。1.3 整车系统架构传感器—计算—执行—交互我们最终的整车架构可以归纳为四个模块感知模块一个前视RGB摄像头负责车道线和障碍物识别一个超声波/单线雷达负责近距离防撞再加上轮速编码器和IMU做状态估计。决策计算模块Jetson系列嵌入式平台跑图像处理与决策算法通过CAN/串口与底层控制板通信。执行模块底层单片机控制电机和转向舵机负责执行上层下发的速度与转角指令同时处理急停信号。人机交互模块一块触摸屏显示实时状态一个无线急停遥控器加上手机端监控页面。这套架构并不复杂但每个模块之间都是强耦合的。任何一个环节出问题——比如图像线程卡了500毫秒、急停信号被其他高优先级消息堵住了——反映到赛场上就是冲出赛道或者撞上障碍物。后面我会详细拆每一个模块的实践细节。2. 硬件平台搭建算力、感知与机械可靠性的取舍2.1 计算平台怎么选从树莓派到Jetson的取舍我们第一版用的是树莓派4B8GB内存版本。优点谁都知道便宜、生态好、Python库装起来方便。但实际用下来发现两个硬伤一是跑MobileNetV3YOLOv8n这种轻量模型时CPU推理帧率只有8-10帧左右赛道稍微复杂一点就会出现感知滞后二是USB摄像头数据传输偶尔掉帧虽然不频繁但自动驾驶系统里一次掉帧带来的决策抖动可能要好几米才能纠正回来。所以第二版直接换了Orin Nano系列平台CUDA推理的优势让YOLOv8n可以跑在25帧以上图像预处理还能用GPU加速CPU只管决策和通信。这里我的建议是如果预算允许尽量别在计算平台上省钱。卡丁快跑组不需要特别大的模型但需要稳定的推理帧率而这恰恰是树莓派做不太好的地方。同队的另一组同学也有用工业电脑比如带独立显卡的迷你主机的效果也不错但供电和散热是个麻烦事。比赛现场有时候是露天场馆太阳一晒工控机温度直奔85度降频之后推理速度大打折扣。如果你选了x86方案务必提前做好主动散热。2.2 摄像头、雷达与编码器的组合经验摄像头是整个感知的核心我们建议用全局快门摄像头而不是普通的CSI卷帘快门摄像头。卡丁车在过弯时车身会有快速转动卷帘快门会拍出“果冻效应”车道线在图像里直接是斜的边缘检测很容易出鬼影。我们第一版用的IMX219在低速直道还好一到弯道就经常把弯道内侧的白线识别成两条线后来换成全局快门的OV9281之后这个问题基本消失。焦距也要注意广角镜头视野大但远处分辨率不足窄视角能看清远处但近处盲区大。我们的选择是90度水平视场角的镜头配合摄像头安装高度30-35cm。这个高度和角度的组合在普通室内赛道场景下既能看清前方2-3米处的障碍物又能在视野底部看到车头附近1米内的路况适合大多数竞赛场地。雷达/超声波方面我们用了三个超声波模块前向、左前、右前各一个负责50cm内的近距离防撞。为什么不用单线激光雷达价格是一方面另一个原因是比赛场地里的锥桶、纸箱对激光的反射率不稳定让雷达点云产生很多杂点。超声波近距离测距的稳定性反而更好。2.3 供电、散热与线束赛前最容易翻车的地方这一节是我最想强调的因为我们的车第一版在调试时频繁重启排查了三天最后发现是电池电压问题在作怪。竞赛用电池如果满电是12.6V3S锂电但放电到11.5V以下时如果没有好的稳压模块Jetson会直接欠压关机。我们的Jetson模块标称支持5V/4A但实际峰值电流能到6-7A低压瞬间电压跌落系统就重启了。后来换成单独的8-20V输入、5V/8A输出的DC-DC稳压模块并且从电池主输出单独走一路给Jetson供电才彻底解决。这个排查链路我后面会专门复盘这里先给大家三条硬件装配的保命建议独立供电摄像头、舵机、电机驱动、Jetson、单片机至少分成两路供电避免电机大电流拉低逻辑电路电压。线束防松所有接插件涂热熔胶固定赛车振动环境下排线松动是“幽灵故障”的主要来源。散热不能省钱Jetson模块自带的被动散热片在40度环境下跑半小时就会降频最好换成带主动风扇的散热套装并在程序里实时监控核心温度。3. 感知与控制让车真正“看懂”赛道并稳定循迹3.1 车道线检测的路线选择传统视觉与深度的较量我们最早用纯传统视觉方案把图像转成HSV色彩空间根据赛道颜色设置阈值提取白线/红线再用Canny边缘检测加霍夫变换拟合直线。这套方案在光线均匀的实验室里表现很好模拟器里也能稳定循迹但到了比赛场地就暴露了问题——场地灯光明暗不均、地面反光、阴影边缘都会让阈值失效。要说“传统视觉一定不好”也不对。我们的经验是如果赛道颜色和地面颜色对比足够明显比如白线配深灰地面传统视觉加上自适应的阈值调整完全可以应付比赛需求而且CPU占用极低。真正让传统方案崩溃的是场景切换次数太多比如上午阳光斜照和下午顶光时赛道在画面里的亮度差异能达到一倍以上固定阈值必挂。后来我们换成了基于轻量语义分割模型的方案把赛道区域分割出来再取两条边界线做二次拟合。模型只有20MB左右在TensorRT加速下单帧推理时间在15毫秒内。这里我想说一个判断经验不要一上来就上U-Net或者DeepLab这种重量级模型竞赛赛道语义简单用MobileNetV3作为骨干的小分割网络就够用了。3.2 从分割结果到航向控制偏差量计算与控制参数整定感知输出的是赛道横截面的左右边界位置我们要把它转换成机器人可以执行的转角指令。具体做法把图像逆透视变换IPM成俯视图然后在固定前方距离比如1.2米的地方取一条横截线计算“目标点”与图像中心线的像素偏差。这个偏差作为纯跟踪控制器的输入转换成前轮转角。我用一个简单公式表达目标转角 arctan(2 * L * sin(alpha) / l_d)其中L是轴距alpha是目标点与当前航向的夹角l_d是前视距离。前视距离是纯跟踪控制器里最关键的参数太短车会来回摆振太长过急弯时会明显切内线。我们的整定经验是室内赛道速度1.5-2.0m/s时l_d取0.8-1.2米速度提升到3m/s以上l_d要增大到1.5米以上。底层的速度控制用到的还是PID但要注意PID参数不能照搬别人的因为底盘重心、轮胎摩擦都不一样。我们是通过让车跑直线然后施加阶跃干扰来调的先调P让车能回正再加I消除稳态误差最后加一点D抑制超调。跑了几十次直线后速度控制在±0.15m/s范围内就没问题了。这里有个反直觉的点有些队伍为了追求循迹精度把转向PID调得非常灵敏结果赛道上一有传感器噪声车就开始抖。自动控制不是越激进越好在竞赛场景里宁可过弯慢一点也要保证航向平滑。3.3 弯道、路口与停车线真正拉开差距的细节直道循迹大家都会做差距在弯道和特殊元素上。过弯策略我们采用“感知—预测—减速”三段式。在距离弯道入口大约1米时通过分割结果里的曲率突变判定弯道方向提前把目标速度从2.5m/s降到1.2m/s同时增大前视距离。弯中保持稳定通过。这样既不会冲出赛道又能比“直线速度全程一样”的策略快上不少。路口判断比赛场景里常有十字路口需要转弯。我们用了一个很土但有效的方法在分割结果里统计赛道连通域面积当面积在短时间内迅速增大到平时的2.5倍以上且两侧都检测到白色边界时判定为路口然后根据预设路点决定直行、左转或右转。这个方法比上视觉SLAM轻量得多在固定赛道场景下可靠性足够。停车线识别在图像下半部分设置一个ROI区域检测横向白色实线是否有一整条跨过赛道。我们用了两次灰度投影法避免地面破损被误判。第一次投影找到候选停车线第二次用外形校验过滤噪点。识别到停车线后让车以-0.3m/s的减速度缓慢停车停稳后保持2秒再起步。4. 数据集与仿真在“上车”之前把问题暴露出来4.1 自制数据集的采集与标注流程很多队伍在训练模型时直接下载网上的自动驾驶公开数据集比如Cityscapes、BDD100K这些数据集质量虽然高但跟比赛赛道的地面纹理、光照环境差异很大迁移过来效果并不好。我们最终选择了现场采集、现场标注的路子。采集时用ROS的rosbag工具录制摄像头话题和里程计话题车速控制在0.5m/s左右匀速行驶保证图像没有运动模糊每录制完一圈就人工过一遍数据剔除被手遮挡或模糊的帧。一个800米长的赛道往返录制4-6圈能得到约2000-3000帧有效图像。标注工作用的是开源的CVAT工具我们只标了两类目标lane_line和obstacle。 一辆车两三个人每人标1小时基本能覆盖第一版训练数据。这里有个技巧不要只标注赛道上的物体赛道外背景里的相似纹理也要框出来当负样本不然模型很容易把阴影误识别成障碍物。为了提升模型的鲁棒性我们还做了离线数据增强随机亮度调整、随机高斯噪声、随机透视畸变。这些操作直接在训练时用PyTorch的DataLoader动态做不用预先存成图片省硬盘空间。4.2 仿真环境的正确用法CARLA与CarsimVTD联合仿真很多时候学校没有足够多的场地来反复跑车或者因为天气原因没法去户外调试。这时候仿真平台是必须的。我们用了两套仿真工具各自分工不同。CARLA主要用来做感知和控制算法的原型验证。它在高精度地图里渲染出逼真的道路场景摄像头逼真度很高可以直接把我们的语义分割模型拿到CARLA里跑快速验证模型结构改动对精度的影响。因为CARLA可以自由调节光照、天气我们甚至用它来模拟比赛场上“阳光直射镜头”的最坏情况。Carsim和VTD的联合仿真则侧重车辆动力学。CARLA的车辆动力学模型还是太理想了轮胎滑移、悬挂响应都比较简化但如果把Carsim的整车模型和NI VTD的场景渲染结合就能在仿真中比较真实地感受到车辆极限操控行为尤其是在湿滑地面制动的效果。联合仿真的搭建确实有些门槛接口配置涉及多个软件需要专门的时间去调试但一旦跑通价值很大。我们实际做的是在仿真环境中跑一套完整的循迹避障代码验证逻辑正确性然后固定记录仿真时的油门、转角、速度轨迹曲线。上真车的时候把真车的实际轨迹与仿真的期望轨迹做对比一旦偏差超过阈值就说明控制参数需要重新标定。这一套流程让我们的真车调试时间从原来的2天缩短到半天。4.3 仿真到实车的“迁移鸿沟”三次最容易崩的地方仿真能解决很多问题但最后一个小时的上车实测永远必不可少。我们的经验里有三处仿真和实车差异最大相机成像差异仿真里的曝光和真实相机动态范围差别巨大白天室外场景里真实图像的高光溢出和暗部死黑是仿真相机永远不会产生的。我们的解决办法是上车前先用真实相机录一段视频把亮度直方图统计出来动态调整模型输入的归一化参数。执行器延迟仿真里给转角指令是瞬时生效的但真车的舵机从指令到实际转角有约80-120毫秒的响应延迟。这个延迟如果不补偿车会呈现出“开着开着就滞后于赛道”的奇怪现象。我们用了一个简单的Smith预估器在控制指令里叠加一个基于当前角速度的前馈项基本解决了。地面摩擦变化仿真默认用干沥青路面参数但赛道上可能是地砖或者防滑漆摩擦系数变化很大。车会出现同样P参数下仿真里很稳、实车却来回摆。应急办法是降低控制增益保留更大稳定裕度。5. 人车交互从“急停按钮”到“可评价的交互系统”5.1 人车交互不是附加题而是安全底线很多人觉得“人车交互嘛加个急停按钮就行”。这句话对了一半。急停确实是底线但比赛评审里人车交互分值占20%如果只给一个遥控器急停评委大概率只能给你一个基础分。真正的自动驾驶系统在开放场景下运行必然要面对人的介入需求操作员想了解车当前看到了什么、打算怎么走、系统是否正常、遇到异常能否接管。我们把交互系统拆成了三个层次状态可视化、远程监控、紧急接管。5.2 “它在想什么”要被看见可视化方案我们在车的中控位置装了一块7寸触摸屏实时显示前视摄像头画面叠加车道线分割结果、障碍物检测框、当前车速、转向角、决策状态正常循迹/避障/停车/急停。每一个模块的状态指示灯也有独立区域绿色表示正常红色表示异常。这样一眼扫过去就能判断系统是否健康。屏幕使用的框架是PyQt5加OpenCV的显示循环通过共享内存方式从感知进程获取图像和结构化数据显示刷新率控制在20帧以上减少操作员的视觉疲劳。这里大家可以注意一个细节可视化不能只显示原图一定要把识别结果叠加上去。比如车道线分割和障碍框叠加在原图上评委从屏幕就能直观看出你的感知算法是否有效。这是很朴素的“真实值验证”也是比赛中拿交互分的关键抓手。5.3 远程监控与无线急停不能省略的安全条车上有触摸屏还不够操作员不可能一直盯着车载屏幕看还需要一个远程监控手段。我们使用了一台旧手机和一个5.8GHz图传模块把车载计算结果和画面传到手机端同时通过一个2.4GHz的无线急停遥控器实现200米范围内的紧急停机。无线急停的优先级是最高的在单片机底层直接以硬件中断方式响应不经过Jetson的软件链路。这样可以保证即使系统死机或者通信中断急停信号也能直接切断电机使能让车瞬间刹停。这个设计在答辩时是个加分项因为评委看得出你考虑到了“系统失效模式”下的安全兜底。5.4 多模态交互语音提示与触觉反馈的尝鲜我们还在交互模块里增加了一个语音播报功能用一块小喇叭在关键节点播报“前方弯道”“停车执行”“障碍物”等信息。这算是个低成本多模态交互的尝试。好处是当操作员视线不在屏幕时也能通过听觉获取车辆状态变化。后来我们还接了一个振动马达放在遥控器手柄上。系统检测到障碍物进入1米范围时手柄会持续振动距离越近振动频率越高。这是一种触觉通道的提示实测下来操作员的紧急反应速度比只看屏幕快大概0.2-0.3秒。虽然这个提升看起来不大但在碰撞事故的临界点这就是能不能刹停的距离差距。6. 赛场高压下的故障排查三次真实故障复盘6.1 故障一跑着跑着系统突然重启 — 电源链路排查这是我们第一次试跑时遇到的最大的问题上面提到过这里把完整排查链路写出来。第一次出现时表现是“连续跑30秒左右Jetson突然掉电重启复位后又能正常工作”。一开始我们怀疑是算法线程内存泄漏导致系统崩溃于是在log里查了内核日志发现没有Kernel Panic记录重启时间是瞬间的和断电特征完全一致。既然是断电我们先用万用表测量电池输出端满电12.4V没问题但接到Jetson的5V端后电压只有在电机突然加速瞬间才会跌到4.7V左右明显是电压跌落触发了欠压保护。进一步排查发现主控和Jetson都接在同一个5V稳压模块上而电机驱动模组的电源也是从同一路5V分出来的。电机启动瞬间电流能到3A以上瞬间拉低了5V母线电压。我们修改为电池主输出分为两路一路经过一个高功率DC-DC单独给Jetson供电另一路经过另一个DC-DC给单片机和传感器供电电机驱动模块从电池主输出直接取电彻底隔离了高功率脉冲干扰。这个故障让我学到了一个原则电源问题永远是排查这类“偶发重启”时的第一嫌疑尤其当系统重启没有任何日志异常的时候。6.2 故障二逆光赛道上的“幽灵车道线”比赛场地里有一个大回环弯道下午太阳高度角较低时阳光刚好从弯道出口直射镜头整幅图像的高光部分一片白车道线几乎看不见车会直接冲出赛道。我们的第一步处理是降低曝光时间和增益先把整体亮度压下来保证高光区域不过曝。但这样会导致阴影区域的信息丢失赛道两侧阴影里的白线还是看不清。后来我们在IPM变换后增加了一个局部自适应直方图均衡CLAHE处理大幅提升局部对比度。同时给车辆配备了一个光敏传感器当检测到环境照度突变时程序自动切换第二套曝光参数。经过这一轮改造逆光下的分割精度大幅提升。但我也要说这只是“缓解”不是“根治”。最后为了保证比赛成绩我们的兜底方案是在车载代码里写了一个“感知置信度过低时自动减速至0.5m/s”的机制宁可慢也不要瞎跑。6.3 故障三调试时间不够时靠数据回放“白嫖”调试窗口赛前场地只开放了第一天下午很多队伍抢着上赛道实测排队一次要等20分钟真正能跑的时间非常有限。我们在这种高压环境下想到了一个办法提前录制了高质量的rosbag数据包场地关闭时就在酒店里回放数据直接驱动感知算法跑离线测试。具体操作是用rosbag play发布摄像头话题和编码器话题Jetson上的ROS节点链随即响应产生的控制指令不做输出只做记录。我们把新改的算法跑在旧数据上对比修改前后的输出轨迹和识别差异。这个办法让我们的调试窗口从“场地开放时间”扩展到了“全天候”比赛前一天连续发现了两个弯道感知的边界问题都在赛前修正了。这个方法成本极低但非常实用强烈建议每个队伍都在前期的场地调试时养成“每跑必录”的习惯多录数据永远不吃亏。现场调试时每圈数据都打上时间戳和备注标签收录进数据库。赛后重新复盘也能最快定位问题。回放数据调试唯一的坑是同步问题如果录制时图像帧率不均匀回放时可能跟传感器时间戳对不上。解决方法是在录制时给每一帧设置好时间戳并在回放时开启--clock参数发布/clock话题让系统里的所有节点跟着录制的模拟时钟走这样一致性就好多了。说到底卡丁快跑组的技术赛场上没有“灵光一现”的捷径。我们用的每一套方法都是基于“稳定跑完”这个核心目标反复逼出来的。传感器与算力的平衡、仿真与实车的互补、交互与安全冗余的设计、数据回放带来的调试效率每一个模块单独看都不算高深但组合在一起就成了决定比赛排名的胜负手。希望我们踩过的这些坑和积累下来的经验能帮你在这个赛项里少走一段弯路。