1. 从“摸鱼”到“摸清”一个智能车新手的真实心路“摸鱼”这个词在当代年轻人的语境里带着一丝自嘲和戏谑。当我把“第十五届智能车百度AI组初赛复赛摸鱼记”作为标题时很多朋友都笑了以为我又是去比赛里“划水”的。但只有真正参与过的人才知道在智能车竞赛这个硬核的领域里所谓的“摸鱼”其实是一个从茫然无措到逐渐“摸清”门道的过程。这绝不是一次轻松的旅行而是一场与代码、硬件、算法和无数个深夜的硬仗。今天我就以一个从零开始的“摸鱼”选手视角复盘一下这段在第十五届全国大学生智能车竞赛百度AI组基于飞桨PaddlePaddle中的初赛与复赛经历。这不是一份标准的技术报告更像是一份写给后来者的“避坑指南”和“心路历程”希望能给那些同样心怀忐忑、准备踏入这个领域的同学一些真实的参考。全国大学生智能车竞赛尤其是引入了百度飞桨深度学习框架的AI视觉组早已不是简单的单片机编程和循迹小车。它要求参赛者具备跨学科的知识储备从嵌入式硬件控制、传感器应用到计算机视觉模型训练、部署优化再到实时的决策与控制算法。对于我这样一个非科班出身、主要兴趣在软件的同学来说初看规则和任务书时感觉每个字都认识连起来却像天书。我的“摸鱼”之旅就是从这种“敬畏”与“无知”开始的。核心目标很明确让一辆小车通过车载摄像头“看懂”赛道元素如车道线、十字路口、环岛、坡道等并自主决策稳定快速地跑完全程。这背后是深度学习模型从数据采集、标注、训练到嵌入式端部署NVIDIA Jetson Nano或类似边缘计算设备的一整套流水线。2. 初赛“摸鱼”实录从环境搭建到第一个能跑的模型初赛阶段组委会通常会提供基础的仿真环境或简化赛道任务让队伍先跑通整个流程。这个阶段的核心目标不是追求极致性能而是“打通任督二脉”让数据流、模型训练和车体控制形成一个闭环。2.1 开发环境搭建第一个“下马威”很多人包括最初的我会低估环境搭建的难度。心想不就是装个Python、PaddlePaddle和OpenCV吗然而现实给了我们小组当头一棒。我们选择的是百度飞桨PaddlePaddle框架这本身是一个很棒的选择社区活跃中文文档友好且针对竞赛有优化。问题出在版本兼容性和依赖库上。我们一开始在Windows系统上用pip install paddlepaddle安装了最新版本。但当尝试运行官方提供的示例代码时各种奇怪的报错接踵而至有的是CUDA版本与PaddlePaddle版本不匹配有的是某个视觉处理库的依赖项冲突。整整两天我们都在和“ImportError”、“DLL load failed”作斗争。这让我深刻意识到在深度学习项目伊始锁定开发环境是最高优先级的任务。踩坑心得不要盲目追求最新版本。对于竞赛这类有明确时间窗口的项目最稳妥的做法是严格遵循官方推荐或竞赛技术交流群中大家验证过的环境配置。我们后来的解决方案是使用Docker。百度飞桨提供了预配置好的Docker镜像里面包含了匹配的Python、PaddlePaddle、CUDA、cuDNN等所有依赖。这简直是救命稻草。一条docker pull命令就让我们跳过了繁琐的环境配置直接进入代码开发阶段。如果你的设备支持强烈建议从Docker开始。2.2 数据采集与标注枯燥但决定上限的苦力活环境搞定后我们兴冲冲地开始尝试训练模型。但很快发现官方提供的基础数据集非常有限或者与我们的实际赛道场景有差异。于是数据采集成了必须自己动手的环节。我们用的是组委会指定的车模上面搭载了树莓派或Jetson Nano和摄像头。最初的做法很原始用手推着车在赛道上走同时用程序录制视频。结果发现手推的速度不均匀画面抖动严重而且视角和车子自己跑起来完全不同。这样的数据训练出的模型在实际自动运行时泛化能力极差。我们改进了方案编写一个简单的键盘控制程序让车子能以相对匀速虽然还是很慢自主运动同时录制视频。然后将视频按帧抽取成图片。这个过程是极其枯燥和耗时的。几百GB的视频文件抽帧后得到数万张图片需要人工或半自动地标注出车道线、停止线、十字路口中心等关键信息。实操技巧不要试图标注每一帧我们采用了关键帧标注插值的策略。比如在一条长直道上每隔10帧标注一次在弯道或路口处每隔2-3帧标注一次。然后利用标注工具如LabelMe、PPOCRLabel的变体或百度EasyData的线性插值功能自动生成中间帧的标注。这能节省70%以上的标注时间。另外数据增强翻转、旋转、调整亮度对比度必须在标注完成后进行否则坐标会错乱。2.3 模型选择与训练在“轻量”与“精度”间走钢丝对于嵌入式设备模型的第一要求是“轻量”。Jetson Nano的算力有限模型必须在满足实时性例如30FPS的前提下尽可能准确地输出感知结果。我们尝试了飞桨套件中的PaddleDetection和PaddleSeg。最初我们被YOLO系列的高精度吸引尝试了YOLOv3甚至v4的轻量化版本。但在Jetson Nano上即便经过TensorRT加速帧率也仅在10-15 FPS徘徊无法满足实时控制的需求。后来转向更专一的车道线分割模型如BiSeNet、Fast-SCNN。这类模型结构更简单输出的是每个像素属于车道线或背景的概率图。我们的训练过程也充满了波折。最典型的问题是过拟合模型在训练集上表现完美损失曲线一路下降但在验证集或实际赛道上却一塌糊涂。这通常是因为数据多样性不足。我们的解决方法是收集更多样化的数据在不同光照条件白天、傍晚、室内灯光、不同赛道背景深色、浅色地板下采集数据。使用更强的数据增强除了常规的翻转、旋转还加入了随机遮挡模拟阴影、颜色抖动等。调整模型容量如果模型参数过多如层数太深而数据量有限就容易过拟合。我们尝试减少了分割网络的通道数虽然理论精度会下降但实际泛化效果反而更好了。监控正确的指标不要只看损失Loss。对于分割任务要重点关注mIoU平均交并比在验证集上的变化。如果训练集mIoU持续上升而验证集mIoU停滞甚至下降就是过拟合的明确信号。3. 复赛“摸鱼”进阶从仿真到实车的鸿沟如果初赛是“纸上谈兵”那么复赛就是“真刀真枪”。我们需要将训练好的模型部署到真实的智能车上在实体赛道上进行调试。这一步才是“摸鱼”心态终结的开始无数新的坑在等着我们。3.1 模型部署与优化让模型在端侧“飞起来”在PC上训练好的.pdmodel文件直接放到Jetson Nano上推理速度慢得令人发指。模型优化是必经之路。飞桨提供了Paddle Inference和Paddle Lite两种推理引擎我们主要使用Paddle Inference并结合TensorRT进行加速。优化过程像一场精细的手术模型固化将训练得到的动态图模型含参数和计算图固化为静态图模型.pdmodel和.pdiparams。这能消除动态图带来的开销并方便进行后续的图优化。计算图优化使用PaddlePaddle的paddle.inferenceAPI开启诸如融合卷积与批归一化Conv-BN fusion、删除无用操作等优化选项。TensorRT加速这是提升最大的环节。将Paddle模型转换为TensorRT引擎利用其层融合、精度校准INT8量化等技术可以大幅提升推理速度。我们尝试了FP16半精度和INT8量化。INT8量化能带来2-3倍的速度提升但会引入精度损失。这里有个关键经验必须使用有代表性的校准数据集不能随便拿一些图片糊弄否则精度损失会非常严重导致车子在赛道上“眼瞎”。前后处理优化模型推理只是其中一环。图像预处理缩放、归一化和后处理从分割图提取车道线中心点也消耗大量时间。我们将这些操作尽可能用C实现或者使用OpenCV的优化函数并确保数据在CPU和GPU之间传输的次数最小化。经过一系列优化我们的车道线分割模型在Jetson Nano上终于能跑到25-30 FPS为后续的控制算法留出了宝贵的时间预算。3.2 感知与控制联调算法与物理世界的碰撞模型能实时输出车道线信息了但如何让车子沿着线跑这就进入了控制算法的领域。我们采用了经典的纯追踪算法Pure Pursuit作为横向控制器。原理很简单在图像中识别出的车道线上选择一个“预瞄点”Look-ahead point计算当前车体中心与该点的几何关系得出一个目标曲率再通过舵机转向电机控制前轮转角去跟踪这个曲率。听起来很美好调试起来却让人崩溃。第一个大坑坐标系转换。模型输出的是图像像素坐标系下的点u, v。而控制算法需要的是在车体坐标系下的位置x, y。这涉及相机标定获取内参和畸变系数和逆透视变换IPM。我们一开始忽略了相机标定直接用假设的理想参数做变换结果导致变换后的车道线扭曲严重计算出的曲率完全错误车子要么画龙要么直接冲出赛道。避坑指南相机标定必须做而且要做好。使用棋盘格在不同位置、不同角度拍摄至少20张照片用OpenCV的calibrateCamera函数仔细计算相机矩阵和畸变系数。这个过程不能偷懒它直接决定了你“眼睛”摄像头看到的世界是否准确。第二个大坑预瞄距离的动态调整。预瞄距离不是固定的。车速快时需要看得更远预瞄点更远以保证稳定性入弯时可能需要看得近一些预瞄点近以保证灵活性。我们实现了一个简单的速度-预瞄距离映射表并通过实际跑车反复调整参数。这个调参过程没有捷径就是“设参-跑车-观察-修改”的无限循环非常考验耐心。第三个大坑延迟补偿。从摄像头采集图像到模型推理再到控制指令发出舵机执行存在一个不可避免的延迟大约80-120毫秒。这意味着当车子根据“过去”的图像做出转向决策时它已经移动到了一个新的位置。如果不补偿这个延迟在高速过弯时车子会严重滞后导致冲出赛道。我们在控制算法中加入了简单的预测模块根据当前车速和角速度预测延迟一段时间后车子的位置并基于这个预测位置来计算控制量。虽然模型简单但效果立竿见影。4. 那些“差点弃赛”的软硬件坑除了算法智能车比赛更是一个软硬件紧密结合的系统工程。下面这些坑任何一个都足以让车队停滞数日。4.1 电源与电磁干扰玄学问题的根源我们的车在实验室地板上跑得好好的一放到比赛用的PVC赛道上就出现各种灵异现象摄像头画面偶尔出现条纹、主控板莫名重启、舵机抽搐。一开始我们疯狂检查代码怀疑是内存泄漏或多线程冲突。折腾了两天最后才发现是电源问题。车上的核心耗电大户是Jetson Nano和舵机。当舵机大力矩转动特别是打死方向时瞬间电流很大如果电池电量不足或电源线太细会导致整个系统电压被拉低造成Jetson Nano欠压重启。同时电机和舵机产生的电磁噪声会通过电源线或空间辐射干扰摄像头信号。解决方案电源隔离与滤波为Jetson Nano等核心计算单元使用独立的稳压模块如DC-DC降压模块并与电机驱动电源物理隔离。在摄像头电源线上增加磁珠和滤波电容。线材与接插件检查所有接插件是否牢固特别是电机和电池的XT60接口。电源线使用更粗的硅胶线减少内阻。接地尝试将摄像头金属外壳、Jetson Nano外壳通过导线连接到主电源地构成一个统一的接地参考点有时能显著减少画面噪声。4.2 传感器同步与数据融合为了提升鲁棒性我们后期尝试加入了IMU惯性测量单元进行数据融合。想法很美好用IMU的陀螺仪数据辅助估计车体姿态弥补视觉在剧烈震动或短暂丢失车道线时的不足。但实现起来时间同步成了噩梦。视觉帧率是30HzIMU数据是100Hz。两者时间戳如果不精确对齐融合结果就会引入误差反而让车子更不稳定。我们最初用软件时间戳误差很大。后来使用了硬件触发用Jetson Nano的GPIO在摄像头曝光瞬间发出一个脉冲同时被IMU和主控记录以此实现硬件同步。这一步对精度要求极高的队伍至关重要。4.3 代码工程化与调试技巧前期我们所有代码都写在一个巨大的Python脚本里变量乱飞调试困难。在复赛后期我们进行了重构模块化将代码分为感知、决策、控制、通信、日志等独立模块。配置化所有参数如控制器增益、预瞄距离、颜色阈值写入一个config.yaml文件修改参数无需重新编译代码。可视化调试工具我们开发了一个简单的PyQt5桌面程序通过Wi-Fi接收小车发回的实时数据包括原始图像、分割结果、检测框、控制指令曲线等。这让我们能在电脑端远程监控小车状态效率比盯着小车看和打印日志高得多。5. 心态与团队“摸鱼”背后的坚持回顾整个初赛和复赛技术上的挑战固然巨大但更大的挑战来自于心态和团队协作。长时间调试没有进展会让人沮丧队友间对技术方案的意见分歧也可能引发矛盾。我们的经验是设定阶段性小目标不要总想着“让车完美跑下来”。今天的目标可以是“让车在直道上不跑偏”明天的目标是“稳定过第一个弯道”。每完成一个小目标都是正反馈。合理分工充分信任有人擅长深度学习调参有人擅长嵌入式编程有人擅长硬件焊接。让每个人做自己最擅长的事并信任对方的专业性。定期开会同步进度但避免互相指责。拥抱失败及时记录每一次车子跑飞、每一次程序崩溃都是宝贵的数据。我们养成了写“调试日志”的习惯记录下问题现象、可能原因、尝试的解决方案和最终结果。这避免了在同一个坑里反复跌倒。善用外部资源多逛竞赛论坛如CSDN、知乎上的智能车专栏、多看优秀开源项目GitHub上有很多往届优秀代码、多在官方技术群里提问提问前先搜索并清晰地描述你的问题和已尝试的方法。站在巨人的肩膀上能省下大量摸索的时间。从对着一堆零件和代码发呆的“摸鱼”状态到最终看着小车在赛道上稳健行驶这个过程充满了痛苦但也充满了成长。智能车竞赛就像是一个微缩的科研与工程项目它逼着你去系统性地学习、去动手解决真问题、去团队协作。最后我们的车虽然没能站上最高的领奖台但这段“摸鱼”记却让我和队友们收获了远比奖项更重要的东西一套解决问题的工程方法论和一群并肩作战的伙伴。如果你也正准备踏上这条“不归路”那么请准备好你的热情、耐心和咖啡这趟旅程绝对值得。