这半个月我身边不止一个准备智能车竞赛的团队都在传一段“走马观碑”车模运行视频。视频不长画面也不复杂车模在场地里沿路径跑了一段转向有动作速度不算快唯一显眼的是标题最后那行字未加入视觉。如果猜得没错很多人看到的第一反应是没视觉那这个视频有什么可看的其实对一个准备参加第21届全国大学生智能汽车竞赛、目标还是视觉相关组别的队伍来说这个视频恰恰是整个工程里最值得留着的一份记录。我的判断是还没接入视觉不等于车模状态“不完整”。相反它是从纯控制阶段进入多传感器融合阶段之前必须留下的一条基线。很多团队起步时急着往车模上堆摄像头、跑模型结果车辆本身的转向特性和速度闭环都没稳住最后出了问题也分不清是视觉模块的问题还是底层控制的问题。先让车模在没有视觉的情况下跑出可复现、可评价、可检查的结果再考虑视觉接入才是真正省时间的顺序。1. 先确认一下这段视频到底证明了什么“未加入视觉”的视频最容易给观众一种错觉车模能跑但还差一个功能模块。这个理解不能说错但它把问题看小了。一个没有视觉模块参与的运行视频真正证明的并不是“少了一块功能”而是“底层运动系统已经具备被后续功能依赖的基础”。1.1 视频里的“能跑”到底跑通了哪几层从智能车工程链路看车模能稳定运行至少要求三层成立第一层是执行层。电机驱动、舵机转向、编码器反馈、电池供电和电机驱动模块之间的电气连接必须正确。很多新手觉得这层简单实际上问题最多的是供电不稳定和信号线受干扰。视频里车模如果直道不抖动、转向不发生异响至少说明执行层没有严重的电气缺陷。第二层是控制层。车模运行需要速度闭环和方向控制。所谓闭环不是“给它一个PWM让它走”而是根据实际速度和实际位置持续修正输出。没有视觉靠的是编码器和惯性传感器这层跑稳定了才说明控制器的基础参数基本合理。第三层是逻辑层。车模的状态机、启停策略、计时策略、串口输出和日志记录这些代码在视频里是看不见的但它们直接决定了车模的行为是否符合预期。一段运行视频能够顺利录完本身就说明程序没有在中途崩溃、超时或卡死。所以这段视频证明了车模在三层链路里已经打通了一个最小闭环。别小看这个闭环后续任何视觉模块都只是在这个闭环之上增加“外部感知”而不是替换掉它。1.2 为什么视觉不能反过来决定车模基础性能很多团队在准备视觉组时会下意识地认为视觉才是核心竞争力底层控制随便调一调就行。这是一个非常容易踩的坑。视觉模块的输入是图像输出是目标位置、角度或者路径偏差而最终执行这些指令的依然是电机和舵机。如果车模本身的转向响应延迟、速度波动大那么视觉给出来的偏差再准车模依然跑不出稳定的轨迹。视觉系统可以告诉你“应该往左修正2厘米”但底层控制器如果响应有80毫秒延迟这个修正指令到达执行层时车模已经驶过了目标点。反过来一段无视觉的车模视频如果能够稳定重复等于提前把“执行”和“控制”两个变量控制住了。后面接入视觉时一旦出现轨迹抖动就可以大概率怀疑是感知或者视觉处理环节的问题而不是整车到处都可能有毛病。实际操作里我建议把无视觉运行视频作为视觉接入前的回归测试基准。以后每改一次视觉代码都必须拍一段同样路径、同样速度下的运行视频做对比。只要底层轨迹变形了先检查视觉管线再检查车辆机械和控制。2. 还没接视觉之前控制系统应该先守住几条边界视频看起来是车模在跑但真正需要关心的不是画面本身而是画面里那些容易被忽略的“边界条件”。没有视觉阶段恰恰是检查这些边界最干净的窗口期。2.1 速度闭环和转向响应不能只看跑起来我见过不少团队车模能跑就急着调视觉结果连速度反馈的稳定区间都没标定过。车模在0.5米/秒和1.5米/秒两种工况下PWM和编码器之间的关系完全不同。如果没有视觉之前就把速度环调到“给目标速度能稳定收敛”的程度后面一旦视觉需要急停或低速过弯车模就会开始振荡。在无视觉阶段至少要确认下边几项电机PWM上限和下限。油门给到多少会原地抖动给到多少会饱和。速度闭环在低、中、高三档下的超调量。目标速度从1.2米/秒降到0.6米/秒时会不会冲出目标再折返。舵机中位和中位附近的死区。视觉给到角度偏差后舵机是否有最小响应延迟。电池电压下降后的表现。满电和低电时同样的PWM是否还能维持同样的速度。这些数据不一定都体现在视频里但视频是验证这些数据是否可信的第一手资料。如果拍完视频回放时听出电机在高频抖动那就说明电流或者PWM占空比大概率没到稳定的工作点。2.2 底层参数先固化再谈感知融合“底层参数固化”的意思是在没有视觉阶段就定好一套相对稳定的参数组合之后不能因为视觉识别不准就随便改底层PID。原因很简单底层参数是多个变量共同作用的结果视觉是另外一个变量。两个变量同时抖动的时候你根本无法定位问题。我建议在无视觉阶段把下面几个参数记录下来作为团队的参数基线目标速度与PWM的映射表。正常电量下不同目标速度对应的稳定电流范围。舵机从物理中位到最大左转和最大右转的响应时间。车模从启动指令到稳定达到目标速度所需的时间。在固定路径上跑完一圈的总耗时和分段耗时。这些参数记录下来之后后续接入视觉时只要某个指标明显偏离基线就可以快速判断是视觉引入的问题还是底层硬件状态发生了变化。3. 视觉不是装上去就能用它需要先跟硬件解耦很多人以为视觉模块就是一个摄像头加一个识别模型接上线就能给车模输出角度。真实情况是视觉模块从一开始就要面对取图帧率、分辨率、曝光时间、图像传输延迟、识别模型计算耗时、输出结果的外推和滤波等一整套问题。在没有视觉的阶段先把视觉模块和车模控制“解耦”是让后续工作不那么混乱的前置条件。3.1 先把视觉跑在“离线输入”上一个便于落地的做法是视觉程序先不连车模只处理提前录好的图像或者视频流。把摄像头架在场地边采集几段真实光照和赛道条件下的图像标注好目标元素然后让视觉程序跑离线识别。这样可以确定一个最关键的问题当前算法在真实画面上到底能不能稳定识别出目标。很多团队会把视觉识别代码直接放到车模上联调结果发现画面模糊、反光严重、目标太小一套问题堆在一起。如果先离线跑就能先排除算力和实时性对结果的干扰只看模型和图像处理本身是否成立。这一步做完后再把视觉输出打印到串口或者日志里手动对比预测结果和实际目标位置的误差。等离线精度达到可接受范围再转到车模上进行实时测试。这个顺序能节省大量联调时间。3.2 图像帧率低、处理慢经常不是算力问题“视觉取图帧率低”“网口设置”“识别慢”这些是智能车视觉团队里的高频问题。但实际排查时很大一部分原因是摄像头配置、传输带宽和等待逻辑不对。在无视觉阶段车模主控和摄像头之间的数据通路往往没有建立这时候最好先把一条“虚拟视觉通路”跑通。也就是说即使摄像头还没参与实际控制也要在程序里预留一个图像输入接口用一个固定测试图像每隔固定周期喂给感知模块验证每个环节的时间戳和输出延迟。它不替代真实摄像头但能提前确认数据流、计算耗时和输出接口是否顺畅。等到真实摄像头接入时需要重点确认的就不是“算法好不好用”而是“每一帧图像到底经过了哪些环节消耗了多少时间”。如果每一帧从采集到输出平均值已经超过控制周期那再好的识别模型都难以稳定控制车模轨迹。4. 一块“未加入视觉”的车模视频应该怎么拍、怎么看车模运行视频不是单纯记录过程它其实是工程判断的重要素材。拍得好回放时能看出很多参数问题拍得随意最后只能作为纪念不能用来调试。4.1 拍摄条件要固定才有对比价值视觉接入前后的对比视频必须保证拍摄条件一致。我在实践中一般会这么做固定场地地图包括路径形状、标志物、边界线。固定出发位置和解说方向标注拍摄时间。尽量使用固定机位从车模正上方或斜上方高机位拍摄。同一次对比测试里保持光照条件基本一致避免中午强光和傍晚阴影造成误判。视频里要有计时参考建议直接在场地里放一块带秒数的电子表方便逐帧回放。这些细节看似与视觉无关但视觉接入后如果要判断“是识别不稳定还是控制不稳定”就必须有同样的拍摄基准来对照。4.2 回放时重点看四个特征每次拍完视频不要只看“有没有冲出跑道”可以按下面几个特征去观察直道上的横向摆动。如果车模在直道出现周期性蛇形运动往往是速度环和方向环的耦合没有调好。入弯前的减速点。视觉介入前车模应该根据路径判断提前减速。如果它总是在弯心里突然打舵说明路径规划或转向响应不够平滑。出弯后的恢复时长。视觉车模如果没有提前规划好出弯路径出弯后会在直道上走斜线而不是沿切线拉直。车轮是否出现间歇性打滑。这一点视频里可能不明显但听声音可以发现。如果电机在弯道中有断续啸叫一般说明转向负载超过轮胎抓地力。这些观察结果在接入视觉之后要反复对照因为视觉只是改变了“决策依据”没有改变底层执行物理特性。一个小提醒回放视频时不要用手机自带的默认倍速直接看建议用0.5倍速逐帧拖动尤其观察车轮和舵机的相对时机。很多问题只在低倍速下才看得出来。5. 从无视觉到有视觉我建议按四步走为了让“未加入视觉”的状态转换成“视觉稳定接管”的状态而不至于推倒重来我总结了一个相对稳妥的四步推进顺序。5.1 第一步先把底层的固定参考标记做好接入视觉之前先在场地里规划好参考点。比如赛道边界、起点线、特殊元素位置这些参考不做成视觉依赖而是作为物理坐标基准。车模在没有视觉时就可以根据这些基准点记录自己的运动轨迹方便后续用视觉识别结果和物理基准对照。这一步的核心目的是让视觉结果有一个“真值”可以去比较。没有真值的视觉只看着像识别准了实际误差分布完全未知。5.2 第二步离线验证视觉识别链路把摄像头接到电脑或工控机上跑一段固定路径的图像生成识别结果曲线再和真实路径对比。重点检查三件事识别准确率、识别延迟、异常帧出现频率。这个阶段不要追求极限速度先保证结果稳定可复现。如果这一步发现识别结果有时提前、有时滞后不要直接调模型先确认时间戳是否统一。视觉程序里常见的一个隐患是图像获取时间和控制指令时间不在同一个时间基准下导致车模以为看到的是当前画面实际上读到的是几十毫秒前的旧帧。5.3 第三步视觉结果先用于提示不直接参与控制别急着让视觉输出直接驱动舵机和电机。建议先把视觉结果输出为“提示信号”比如只在屏幕上画一个目标框然后让车模继续按原有路径运行。人站在旁边观察比较视觉提示和真实位置是否一致。这一步很容易被大家跳过但它能发现很多隐蔽问题视觉识别结果是否抖动、帧数是否连续、输出值是否满足控制输入的范围。这些问题如果不提前暴露等到视觉参与控制就会表现为车模忽左忽右但你在画面里又看不出是识别误差还是控制误差。5.4 第四步用安全系数建立视觉参与控制的边界开始让视觉参与控制时先设一个安全范围。比如视觉输出值如果超出合理区间就切换到底层预设路径或者强制降速。这个机制叫保护性接管是视觉车模进入稳定阶段前的必要保险。我通常会在代码里加一个条件判断视觉连续N帧输出异常时车模自动回到低速直行状态同时记录日志。因为视觉识别在真实环境中一定会遇到遮拦、反光、目标短暂消失等场景如果没有保护机制任何一次丢帧都可能让车模直接冲出场地。6. 在21届准备阶段哪些取舍最容易被忽略关于第21届全国大学生智能汽车竞赛的准备争议最大的一点通常是“要不要一开始就上视觉”。我的看法是如果你是视觉相关组别的队伍尽早接触视觉管线是对的但不要以牺牲车辆基础控制为代价。无视觉阶段不是逃避视觉而是为了让视觉有更健康的运行平台。6.1 别把大量时间花在调模型上先搞定工程链路很多队伍的视觉计划只有模型训练和推理这一步。但实际工程链路是图像采集、图像预处理、目标检测、坐标系转换、目标跟踪、结果平滑、控制指令生成、执行反馈。这中间任何一环断了视觉都跑不起来。在没有视觉的阶段重点要把这条链路的骨架提前预留出来。比如图像采集接口、数据可视化界面、日志系统、异常处理机制这些和具体模型无关但它们会决定视觉接入的顺利程度。先把这些工程骨架搭好后续慢慢替换模型和技术细节时整体风险会小很多。6.2 记录“未加入视觉”的基线是为了以后能回退我见过太多队伍陷入一种状态今天改了视觉参数车模跑得还行明天改了一个模型结构车模开始冲出去再往后改了一版底层PID结果视觉反而失灵但谁也不知道是哪一步引入的问题。如果无视觉阶段保留了清晰的基线视频和参数记录这种情况就能得到控制。每次只改一个变量改完跑一次无视觉对比测试再跑一次带视觉的测试对比差异。严格按这个流程走看起来慢实际上才是最快的问题定位方法。6.3 视频不只是给评委看的更是给团队看的智能车竞赛的作品展示视频、运行视频确实有外部展示的意义但视频更大的价值在内部。它记录的是团队调试过程中每一次有效变化也是一份低成本的状态快照。等到比赛前一周谁还能记得三周前电机的响应参数是什么样把视频和日志按日期整理好就能更快找到回归。我建议每支队伍在无视觉阶段就养成三条记录习惯每次调参后拍一段固定路径的运行视频。视频文件名里带上日期、版本、目标速度、是否带视觉。把视频和参数表、串口日志放在同一个目录下统一命名。用不了多少存储空间却能让整个调试过程变得可追溯、可复盘、可交接。回到最初那段“未加入视觉”的走马观碑视频。它最打动我的地方不是车模跑得多快而是团队愿意承认当前阶段的状态并且用视频把状态钉在时间轴上。这一步意味着他们已经理解了智能车工程的切入点先稳定再感知再决策再优化。视觉不是一段被插进代码库的魔术而是整个链条上的一环。先跑通无视觉的基线版本视觉接进来才不会变成一场碰运气的联调。希望你们在21届的备战路上也给自己留一条“未加入视觉”的基线它会比你想象的更有用。