这次我们来看一个智能车竞赛方向的项目记录第21届全国大学生智能汽车竞赛的“走马观碑”车模运行视频。标题里写得很明确——未加入视觉。也就是说当前跑起来的版本是纯传感器闭环的控制方案摄像头、视觉识别、赛道元素检测这些模块还没有接入整车控制。这个时间点切入恰好最适合分析一个问题在视觉没上的前提下车模稳定性做到什么程度后面加视觉的升级路径应该怎么规划。我先把这篇文章能提供的信息说清楚。文章的定位不是“看个热闹”而是基于这类车模运行视频拆解它的硬件架构、控制策略、运行表现、问题定位以及视觉模块加入后的改造方向。适合正在备赛21届或后续赛题的队伍尤其是摄像头组、AI视觉组、电磁组想升级视觉方案的队员。先给出核心能力速览再按部署、测试、排查、升级路径展开。1. 核心能力速览能力项说明项目名称21届“走马观碑”车模运行视频未加入视觉所属赛事第21届全国大学生智能汽车竞赛当前阶段车模基础运行调试视觉模块未接入运行载体智能车竞赛标准车模具体车模型号需按队伍配置确认当前控制方案以传感器闭环为主编码器、陀螺仪、电磁或摄像头原始数据采集视觉模块状态预留摄像头、图像处理接口但未加入控制链路主要功能直线稳定、弯道循迹、速度闭环、基础赛道元素识别推荐调试工具逐飞库、串口上位机、无线调试模块、虚拟示波器适合场景车模机械结构验证、底层控制调参、视觉模块接入前的基线测试尚未验证项视觉识别准确率、视觉与运动控制协同、赛道元素动态决策这里需要先说清楚文章里出现的硬件型号和控制参数是按智能车竞赛常见配置和视频中反映的运行表现做合理推演不是项目作者给出的完整参数表。每个队伍的具体板卡、传感器型号、PID系数都不一样实际调试要以自己车上的数据为准。2. 适用场景与使用边界“走马观碑”这个方案从名字和当前运行阶段看核心目标是“在高速运行中快速感知赛道信息”。但视频明确标注“未加入视觉”说明当前跑的不是完整方案而是地基版本。适合的场景很清晰机械结构验证。车模底盘是否平稳、轮胎抓地是否足够、重心是否合理这些在无视觉状态下最容易暴露。底层控制调试。速度环、方向环、串级PID是否收敛弯道是否侧滑直道是否抖动都是视觉介入前必须解决的问题。视觉算法开发的前置数据采集。没有视觉时可以先跑通底层通信确认摄像头安装位置、角度、曝光参数能拿到稳定图像但暂不参与控制。队员训练。让新队员先熟悉整车软硬件链路再逐步接手视觉算法。不适合的场景也要说清楚不适合直接用于完整赛道竞速。缺少视觉意味着无法识别十字、环岛、坡道、维修区等复杂元素只能靠预设逻辑或简单传感器判断。不适合作为最终方案演示。如果赛题要求视觉识别障碍物或特定标签当前版本只能算开发中间态。不适合长时间满载运行。没有视觉时如果PID没调好电机长时间震荡会导致发热影响车模寿命。使用边界主要集中在合规性上。智能车竞赛涉及摄像头、图像采集和控制算法所有测试素材应使用自己拍摄的赛道画面或官方提供的测试数据不要使用未经授权的第三方图像数据。涉及人脸、车牌等敏感信息的图像必须脱敏后再用于模型训练或算法调试。比赛场地内如遇其他队伍代码或图纸不要复制使用。3. 环境准备与前置条件智能车竞赛的调试环境不像普通深度学习项目那样依赖GPU更多的是嵌入式开发环境和串口调试工具链。如果队伍刚好是“先跑车、后加视觉”的流程环境准备可以分成两套。3.1 车模底层控制调试环境这是当前“未加入视觉”阶段最需要的微控制器STM32系列是最常见的选择例如STM32F103、STM32F407也有队伍用TC264、TC377或国产替代芯片。开发环境Keil MDK、IAR Embedded Workbench或者逐飞提供的VS Code GCC模板。下载器DAP-Link、J-Link、ST-Link均可推荐在车模震动环境下用带锁扣的下载器接口。传感器接口编码器接口、电磁运放接口、陀螺仪I2C或SPI接口、摄像头接口预留。调试手段串口打印、蓝牙/无线模块、逐飞虚拟示波器。供电电池电压、降压模块、舵机供电分开避免电机大电流拉低传感器电压。可以用一套代码模板来确认环境是否正确// 确认传感器数据能正常读取 // 以逐飞库的编码器读取为例 #include zf_common_headfile.h int16_t encoder_left 0; int16_t encoder_right 0; int main(void) { clock_init(SYSTEM_CLOCK_120M); debug_init(); encoder_init(ENCODER_LEFT_PIN, ENCODER_RIGHT_PIN); while (1) { encoder_left encoder_get_count(ENCODER_LEFT); encoder_right encoder_get_count(ENCODER_RIGHT); printf(L:%d R:%d\r\n, encoder_left, encoder_right); systick_delay_ms(10); } }如果串口能持续输出左右编码器的数据且推动车模时数值发生变化说明底层环境没有问题。3.2 视觉模块调试环境当前视频未加入视觉但后续要升级的话提前搭好这两套环境是值得的嵌入式视觉方案OpenMV、K210、MT9V034摄像头模块配合STM32串口通信。上位机视觉方案PC端跑YOLO或传统视觉算法通过无线图传获取赛道图像处理后再下发控制指令适合AI视觉组和“视觉大模型部署”方向。视觉环境依赖Python库建议用虚拟环境管理python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate pip install opencv-python numpy pyserial这里不指定具体版本因为不同摄像头、不同串口协议依赖的库版本差异较大。更稳妥的做法是先把OpenCV基础环境装好再根据自己摄像头的SDK补充依赖。4. 安装部署与启动方式“走马观碑”车模当前的运行视频本质上不是一套可以双击启动的软件而是一辆嵌入式车模在赛道上的实际运行记录。但我们可以把它拆成“启动流程”来理解。4.1 车模上电启动流程从嵌入式开发的角度一次完整的车模运行测试可以这样拆解确认电池电量充足电压稳定在允许范围内。连接下载器烧录当前控制固件。断开下载器拨动车模电源开关。观察车模自检状态蜂鸣器、LED、电机上电抱死。将车模放置在直道起点按下复位按钮或通过遥控器启动。观察车模运行轨迹同时通过无线模块记录实时数据。如果出现异常立即断开电源避免电机堵转烧毁。4.2 代码烧录命令示例如果用命令行烧录工具可以写成这样实际工具名称和参数按队伍使用的下载器调整# DAP-Link 通过 pyOCD 烧录示例 pyocd flash -t stm32f407vg ./build/racecar.hex4.3 串口数据监控车模运行过程中最重要的是实时观察车模内部的决策数据而不只是看车跑得快不快。建议把关键变量通过串口输出// 运行调试信息输出 printf(speed_L:%d speed_R:%d target:%d dir:%d\r\n, speed_left, speed_right, target_speed, direction);这样的输出配合虚拟示波器就能看到弯道中方向环是否响应及时直道中速度环是否存在震荡。5. 功能测试与效果验证当前视频展示的是“未加入视觉”的车模运行因此功能验证重点不是视觉识别精度而是基础运动控制是否可靠。建议按下面几个维度测试。5.1 直线稳定测试测试目的验证车模能否在直道上保持稳定方向不左右摆动。操作步骤将车模放置在长直道起点以较低速度例如1m/s运行记录舵机PWM输出和车模偏移量。预期结果舵机输出稳定车模无高频摆动速度环无振荡。判断标准直道全程不压线、不抖动。常见失败原因方向环P过大导致车模左右修正过头。机械前束不正确轮胎本身有跑偏趋势。传感器安装左右不对称。5.2 弯道循迹测试测试目的验证车模在弯道中的转向响应和速度控制。操作步骤从直道进入弯道观察车模是否切弯、是否侧滑、出弯是否摆正。预期结果车模在弯道中保持内侧轮减速、外侧轮加速出弯后能快速回到直道中轴线。判断标准弯道通过时间稳定多次测试轨迹一致。常见失败原因差速算法没有配合舵机转角。入弯速度过快超出轮胎抓地极限。陀螺仪数据未融合方向判断滞后。5.3 加减速测试测试目的验证速度环的动态响应。操作步骤设置目标速度从静止加速到目标速度再急停观察电机电流和车模状态。预期结果加速过程平滑无顿挫急停不跑偏。判断标准速度曲线无大幅超调电机无异常发热。5.4 基础赛道元素测试无视觉状态在没有视觉的情况下车模只能依赖电磁、编码器或陀螺仪感知部分赛道信息。以下测试可以作为参考十字路口如果当前方案用摄像头但未接入视觉十字路口可能只能靠陀螺仪积分估算测试时观察是否能稳定通过。坡道坡道会改变车模姿态影响陀螺仪数据测试时观察速度是否突变。直角弯无视觉时直角弯需要在入弯前提前减速否则容易冲出去。测试结果可以整理成表格测试项通过标准当前状态判断依据直线稳定性不抖动、不偏线从视频看基础稳定具体需实车确认运行轨迹弯道循迹无侧滑、无冲出需多次测试验证过弯时间与轨迹加减速响应无超调需结合速度曲线判断串口数据十字路口不误判未加入视觉阶段容易受限陀螺仪数据坡道运行不飞车、不后溜需要专属赛道测试加速度数据6. 接口 API 与批量任务传统智能车竞赛的单车控制一般不会直接暴露HTTP API。但如果队伍在做“视觉大模型部署”或“自动调试平台”可以把车模数据接入上位机形成一套调试API。这里给一个通用思路。6.1 车模数据上报接口设计车模通过串口或无线模块把运行数据上报给上位机上位机提供HTTP接口供调试页面查询。from flask import Flask, jsonify import serial import threading app Flask(__name__) latest_data {} def read_serial(): global latest_data ser serial.Serial(/dev/ttyUSB0, 115200, timeout0.1) while True: line ser.readline().decode(utf-8, errorsignore).strip() if line: parts dict(item.split(:) for item in line.split()) latest_data parts threading.Thread(targetread_serial, daemonTrue).start() app.route(/api/car/status) def car_status(): return jsonify(latest_data) if __name__ __main__: app.run(host0.0.0.0, port8000)这是通用模板串口协议、端口、返回格式需要按自己的车模代码调整。6.2 批量调试任务视觉加入之后批量处理通常会出现在两个地方批量采集赛道图片用于训练视觉模型。此时需要一个脚本批量保存图像并按赛道元素类型命名。批量回放运行数据用来调整PID参数。车模每次运行都会保存编码器、舵机、陀螺仪数据调试时可以批量导入虚拟示波器分析。import os import shutil source_dir ./raw_images category_map { straight: straight, curve: curve, cross: cross, ring: ring } for filename in os.listdir(source_dir): if filename.startswith(2025_): # 按文件名中的赛道元素标签分类 for keyword, category in category_map.items(): if keyword in filename: target_dir f./dataset/{category} os.makedirs(target_dir, exist_okTrue) shutil.copy( os.path.join(source_dir, filename), os.path.join(target_dir, filename) ) break同样目录结构、命名规则都需要按自己的数据集调整。7. 资源占用与性能观察“未加入视觉”的阶段资源压力主要不在GPU或大内存而在微控制器的实时性和车模的功耗管理。7.1 微控制器资源占用从运行视频中可以推断当前控制逻辑执行频率大概在几百赫兹到一千赫兹。观察重点包括控制周期是否稳定。如果主循环里有阻塞式延时或串口打印会导致方向环执行周期抖动反映到车模上就是直道抖动。中断优先级是否合理。编码器中断、陀螺仪DMA、控制定时器中断要分配好优先级避免互相打断。Flash和RAM占用。在Keil或IAR编译后可以查看MAP文件确认Flash占用不超过芯片容量RAM堆栈不溢出。7.2 显存与算力占用视频当前未加入视觉所以不存在视觉模型推理的显存占用。但如果后续升级到YOLO等视觉模型就要考虑嵌入式端K210、OpenMV这类设备显存受限适合跑轻量模型。PC端如果在PC上跑YOLO需要按实际显卡能力设置推理批次。可以先用CPU推理验证流程再切换到GPU提高帧率。算力分配视觉推理频率不需要和控制频率一致。视觉可以10到30Hz运行控制保持500Hz以上两者数据通过队列或共享内存传递。更稳妥的判断是在加入视觉前先把底层控制在低资源占用下跑稳保证再加一路视觉推理时不会因资源竞争导致控制崩溃。7.3 性能观察方法建议在车模上增加一个运行状态指示灯通过不同闪烁频率表示当前运行阶段快闪正在自检。慢闪待机。常亮正常运行。连续两闪方向环异常。连续三闪速度环异常。这样在视频记录中也能快速定位问题发生的大致时间点。8. 常见问题与排查方法视频中“未加入视觉”的车模运行最容易出现问题的地方恰恰不是算法而是底层稳定性和机械一致性。问题现象可能原因排查方式解决方案车模直道左右摆动方向环P过大、机械前束偏移查看舵机PWM输出波形降低P重新调整前束弯道冲出赛道入弯速度过快、方向环响应滞后查看弯道处舵机输出和速度曲线设置入弯减速点增大方向环D电机异常发热速度环震荡、减速器摩擦大用手转动轮胎感受阻力降低速度环P检查齿轮润滑上电后无反应电池电压不足、开关接触不良检查电压、指示灯更换电池或重新焊接串口数据乱码波特率不匹配、共地问题检查串口配置和接线统一波特率确保共地陀螺仪数据漂移未做零漂校正静止状态下观察数据启动时自动校零摄像头图像模糊曝光时间过长、焦距不对通过上位机查看画面调节曝光和镜头车模跑着跑着突然停供电电压跌落、看门狗复位查看复位标志、电压曲线增加电容优化供电布线视频中最值得关注的细节是车模在弯道中的姿态变化。如果车模在弯道中有明显侧倾说明机械重心偏高或轮胎抓地不够如果出弯后车模会继续摆动两三次才稳定说明方向环阻尼不足。这些在视觉加入之前必须解决否则视觉模块介入后车模会因为图像处理延迟而进一步放大不稳定。9. 最佳实践与使用建议从“未加入视觉”到“视觉闭环”是一个典型的增量开发过程。基于这段运行视频可以整理出一套更稳妥的推进思路。9.1 先建立运行基线没有视觉之前一定要把“纯传感器闭环运行”作为基线保存下来。记录这组PID参数、运行视频、串口日志和电池电压曲线。加入视觉后如果车模表现变差可以随时回退到这个基线判断问题出在视觉算法还是视觉与控制协同上。9.2 视觉模块分阶段接入不要一次性把视觉输出直接接到转向控制上。建议按以下阶段推进第一阶段摄像头采集图像只在上位机显示不参与控制。第二阶段视觉输出赛道中线或赛道元素类型通过串口发送到单片机但单片机只记录不执行。第三阶段选择一段直道让视觉输出参与方向控制。第四阶段完整赛道测试逐步提高目标速度。当前视频停在第一阶段之前所以接下来最优先工作是先把摄像头画面调稳定。9.3 数据记录要完整每次跑车都要记录电池电压。环境光线条件。赛道类型。目标速度。PID参数。是否发生异常。异常发生时车模位置。这些记录看起来琐碎但后期调视觉时非常关键。比如视觉识别失败可能不是算法不行而是光线变化导致图像质量下降如果没有环境记录很难快速定位。# 记录一次运行测试的元数据示例 test_metadata { date: 2025-06-01, battery_voltage: 7.8, lighting: indoor_artificial, track_type: test_track_3, target_speed: 2.5, pid_direction: [0.35, 0.00, 0.12], pid_speed: [1.20, 0.00, 0.05], visual_enabled: False, notes: 弯道2出现轻微侧滑 }9.4 合规与安全注意事项使用摄像头采集赛道图像时注意不要拍摄到其他队伍未公开的技术细节。如果测试场地有人员活动不要在未经同意的情况下记录他人面容。用于视觉模型训练的数据集只保留赛道区域避免包含个人信息。比赛规则要求的硬件限制例如电池电压、车模尺寸、传感器数量要定期检查不要把合规问题留到比赛前一天。10. 总结与下一步回到这段“走马观碑”车模运行视频本身最值得关注的是在完全没有视觉参与的情况下车模已经跑出了相对稳定的基础控制表现。这说明底层机械调整和PID框架是立得住的剩下的事情是把视觉能力平滑地加进这个框架。先验证的方法很简单摄像头采集的画面能不能在上位机稳定显示画面亮度是否均匀赛道边缘是否清晰。这一步不做任何控制只做图像链路确认。图像链路没问题之后再做视觉输出与控制指令的映射。最容易踩的坑有两个。一个是视觉处理延迟导致控制滞后车模会因此“画龙”或冲弯解决思路是降低视觉帧率而不是强行提高帧率保持控制频率稳定。另一个是视觉输出直接叠加到舵机控制上没有做平滑过渡导致车模转向突变解决思路是给视觉输出加低通滤波或限幅。后续可以继续扩展的方向很多视觉赛道中线提取、环岛与十字的视觉识别、YOLO标签检测、视觉与IMU融合的车模姿态估计甚至PC端跑“视觉大模型部署”来做赛道元素的高层决策。但无论如何扩展底层控制和车辆稳定性永远是先决条件。建议把当前无视觉版本的车模运行参数、调试日志和视频归档好后续每个视觉版本都和这个基线做对比。这次“走马观碑”方案的价值不在视觉恰恰在于它先把“车”本身调明白了。接下来就是让车真正“看”起来。建议收藏备用等项目推进到视觉阶段再回来看这篇基线分析对照排查。