企业官网建设流程全解析

每年开春，实验室地上都是新留下的轮胎印，电调烧糊的味道还没散干净——智能车竞赛的备赛就是这样。这篇文章来自我们大连海事大学同舟拾队在单车拉力组的技术报告整理，覆盖硬件选型、图像处理、控制策略、现场调试全流程。如果你正准备参加全国大学生智能车竞赛的单车拉力组，或者单纯想了解摄像头循迹车怎么把“看见的赛道”变成“打得准的方向盘”，这篇应该能给你一些直接抄作业的方案。单车拉力组的难点不只是循迹，它的机械特性和常规四轮组差别非常大，所以整条控制链比普通循迹车更长，也更讲究层次。看完你会明白，为什么调车到最后，比的往往不是某一个算法，而是整个系统的匹配度。

1. 项目概述：单车拉力组到底在比什么

1.1 为什么选单车拉力组

智能车竞赛每年组别都会变，但我们当年选择单车拉力组，核心原因是它“看着最难，也最好玩”。单车拉力组用的是摩托形态的单车模型，前后轮在一条直线上，车身宽度比四轮车窄很多，静态时候车身非常不稳，必须在运动中通过转向持续维持动态平衡。这就意味着，你写下去的每一行转向代码，不只是为了让车“对准赛道中线”，还在参与车身姿态控制。四轮车打偏一点可能只是走线差，单车打偏一点就可能直接侧倾扫飞。

从备赛角度看，单车拉力组对队伍综合能力的要求很高：机械上要会调转向机构、换轮胎、处理重心；硬件上要会设计稳压电路、电机驱动、传感器供电；软件上要同时啃图像处理、状态机、串级PID。相比纯跑速度的四轮组，单车组想拿好成绩，必须把整个链路都吃透。我们队当时的定位就是“什么都自己动手”，选单车拉力组，也是逼自己把智能车的完整技术栈过一遍。

1.2 这篇技术报告的核心脉络

整篇报告我会按照我们队的实际调车顺序来写，不是从理论到理论，而是从“车为什么跑不起来”开始，一步步解决问题。大致分成四条线：第一条是整车方案与硬件架构，回答“信号从摄像头到电机是怎么走的”；第二条是图像处理，回答“摄像头看到的透视画面怎么变成可用的赛道信息”；第三条是控制策略，回答“PID怎么输出角速度，转向环和速度环怎么配合”；第四条是调试方法与现场问题排查，回答“车跑飞了到底先查软件还是查硬件”。最后会贴一段我们经常用的排查顺序和避坑经验，这部分内容可能比前面的原理更有用。

1.3 适合谁看

如果你是大一、大二刚接触智能车，建议重点看第2章和第5章，先理解整体架构和PID控制，不要一上来就抄别人的图像处理代码，否则后面出了问题完全不知道怎么改。如果你已经有一辆能跑的车，但总是过不好环岛、十字或者频繁抖舵，可以直接跳到第4章和第7章，里面很多坑是我们用了几周时间踩出来的。如果你只是想了解智能车竞赛到底在做什么，通读一遍也能建立起一个比较完整的认知。

2. 整车方案与硬件选型：先别抄电路，先想清楚控制链路

2.1 整车信号链路

我们队的整车信号链路可以概括为“摄像头采集图像，主控提取边线，软件算出期望角速度，舵机执行转向；编码器测速，速度环输出油门，电机驱动执行”。听起来很顺，但真正写代码的时候，最难的是确定每一环的“更新频率”和“优先级”。图像处理是慢环节，摄像头帧率可能只有50到100帧，但PID控制是快环节，我们希望它至少跑到200到500赫兹。这就带来一个问题：控制周期不能等图像处理完再跑，必须把“图像结果”和“控制计算”解耦。

我们队最终的做法是：图像采集由DMA后台搬运，图像处理在主循环的一个固定时间片里做，处理完后把赛道中线和特征写入一个全局结构体；控制中断以固定频率（我们用的是5毫秒周期）读取这个结构体，计算PD和PI输出。这样即使某一帧图像处理超时，控制中断也不会停下来，最多沿用上一帧特征，车不会因为一帧图像卡顿就猛然跑偏。这一点对单车模型尤其重要，因为它的姿态控制需要连续输出，任何控制中断都可能造成车身晃动。

2.2 主控、摄像头与驱动模块怎么选

主控我们选了英飞凌TC264。TC264在智能车竞赛里用得非常普遍，双核200MHz，外设资源够用，ADC、DMA、PWM、编码器接口都齐全。相比更高端的TC377，TC264的开发资料和开源方案更多，遇到问题容易找到参考；相比ST的芯片，TC264的工业级稳定性更好，在比赛现场那种电磁环境复杂的场合不太容易死机。选主控不一定追求最强，要看你周围的资料生态和队友的熟悉程度。我们队之前有人用过TC264，踩坑成本低，所以延续了这个方案。

摄像头用的是灰度摄像头方案，具体型号是MT9V03X系列，圈内常叫“总钻风”。选它的理由有两个：一是全局快门，动态抓拍不容易出现运动模糊；二是灰度输出，后续做二值化和边线提取比较直接。摄像头分辨率我们没有拉满，实际采集用188乘120左右，这个分辨率对单车拉力组完全够用，分辨率太高反而会增加处理耗时，拖慢控制周期。镜头视角大概120度，能够覆盖车前比较宽的赛道区域，环岛、十字这类元素也能看清左右两侧的边线变化。

电机驱动我们用了BTN7971半桥驱动方案，两路BTN组成H桥，驱动能力足够单车模型的直流电机。舵机用的数字舵机，PWM频率设置在50Hz，转向响应比模拟舵机干脆很多。编码器装在驱动轮上，通过正交解码接口直接读取速度。这里有一个经验：编码器安装的同轴度和联轴器间隙非常影响速度环稳定性，如果编码器读数有周期性波动，先别怀疑代码，去用手转轮子看波形，十有八九是机械装配问题。

2.3 电源分配和接地的隐藏学问

电源是很多队伍最容易翻车的地方，尤其是单车拉力组，转向舵机和驱动电机同时工作瞬间电流很大，摄像头很容易被拉到黑屏或者出现雪花。我们的电源方案是：7.2V电池进来之后，先经过一级大电流稳压给电机驱动供电，再从电池或稳压后单独分一路给舵机，最后用低噪声LDO给主控和摄像头供电，模拟地和数字地单点相连。注意不要把所有负载都挂在同一个稳压输出上，舵机堵转时电流尖峰可能让摄像头供电瞬间跌落，表现出来就是“图像偶尔全黑”，很多人会以为是摄像头坏了，其实是电源问题。

摄像头排线也是一个大坑。图像数据线如果和电机线绑在一起走线，电机换向时产生的电磁干扰会让图像出现横条纹。我们最后把所有传感器线都改成屏蔽线，并且远离电机线，摄像头排线尽量短。硬件上的这些小细节，赛前不会让你明显提速，但比赛现场那种干扰环境下，稳定的图像比什么都重要。

3. 图像处理：把赛道的透视拉平，才能谈前瞻

3.1 灰度图、二值化与大津法

摄像头原始输出是灰度图，我们第一步是把它变成黑白二值图，让“赛道白色”和“背景深色”分离。最基础的做法是固定阈值：像素值大于阈值记为白色，否则记为黑色。但固定阈值非常怕光照变化——室内场地灯光稍微变一下，或者赛道上有反光，固定阈值就全线崩溃。所以我们用了大津法（OTSU）自动计算阈值。大津法的核心思想是让分割出来的前景和背景类间方差最大，本质上是找灰度直方图的一个最佳分割点，这样即使整体亮度发生变化，阈值也会跟着漂移，不至于固定死。

大津法虽然好，但遇到大面积阴影或者特别强的反光还是会有问题。我们后来在大津法基础上加了限制：阈值不能在一个小范围内剧烈跳变，如果这一帧算出来的阈值和上一帧差太多，就强制用上一帧的阈值。否则你会发现车跑着跑着，二值化结果像在闪烁，边线也跟着乱跳，最终表现就是转向疯狂抖动。这种“给算法加惯性”的思想，在智能车很多地方都用得上，比如后面要说的边线提取和中线平滑。

3.2 逆透视变换：为什么需要，怎么标定

摄像头是斜着向前下方看的，拍出来的赛道是近大远小的透视效果。最明显的问题就是：远一点的地方，赛道左右边线看起来几乎要并到一起；近一点的地方，边线又分得很开。如果你直接用原始图像的中线算误差，这个误差在不同距离上体现的权重是完全不一样的，控制参数就很难整定。所以我们要做逆透视变换，把图像映射成近似俯视图，让赛道宽度在整幅图里基本一致。

逆透视变换的数学本质是找一个单应矩阵，把图像平面映射到地平面。实操时不需要自己推导矩阵，可以在赛道上摆放一个已知大小的棋盘格或者矩形标记，标定出四个对应点，然后调用OpenCV的getPerspectiveTransform或者自己解一个线性方程组，得到3乘3的变换矩阵。赛前把摄像头固定好之后，标定一次就行。标定完之后，每次拿到原始图像，就做一次透视映射，后续找边线、算曲率都在这张“俯视图”上进行。我们队的经验是：逆透视之后，环岛和十字的特征明显稳定很多，因为远处边线的走向不再被透视压缩误导了。

有一点要注意：逆透视变换只对“地面平面”有效，坡道上赛道高度发生变化，映射关系会失真。所以我们做坡道识别时，是拿原始灰度图去做，而不是用逆透视之后的图。

3.3 边线提取与动态前瞻行

逆透视之后，我们从图像底部向上扫描，每一行从左到右找第一个白色边界和最后一个白色边界，分别记作左边线和右边线。正常直道，底部几行最容易找，因为离车近、图像清晰。越往上，图像越容易受反光、遮挡影响，所以我们的搜索顺序是从下往上，而且会在上一帧边线位置附近开一个搜索窗口，而不是全图扫描，这样既快又稳。

“动态前瞻”是另一个关键词。前瞻本质上是你打算看多远的前方来生成控制量。速度低的时候，前瞻近一点没关系，反应更灵敏；速度高的时候，如果前瞻太近，入弯时车已经来不及减速和打方向，就会直接冲出去。我们维护了一张前瞻距离和当前速度的映射表，速度每增加一点，前瞻行数就往上提一点，但会设置上限。实际效果很明显：低速发车时转向稳定，高速过弯时又能提前感知曲率变化。

3.4 中线平滑与曲率计算

有了左右边线，中线就是左右边线坐标的平均值。但直接拿原始中线做控制，会发现中线毛刺很多，毕竟每一帧的边线提取都可能有一两个像素的抖动。我们在中线上做了滑动平均滤波，窗口大小大概是5到7帧。这个滤波不能太重，否则弯道里中线会滞后，入弯转向偏晚。具体窗口大小需要现场试，我们的经验是：直道多可以稍微加大滤波，连续弯道就调小。

曲率计算我们没有用复杂的拟合，而是用中线上连续三点的夹角来估算。取车前最近点、中间点、远处三个点，向量夹角越大说明弯越急，这个量直接作为转向控制的前馈参考。虽然不如最小二乘拟合精确，但胜在计算量小，而且非常直观，适合在单片机上跑。

4. 环岛、十字与坡道：识别策略比纯图像算法更关键

4.1 用状态机管理路段元素

很多队伍把环岛识别写成一个“是不是环岛”的布尔判断，但实际赛道是一连串连续变化的画面，布尔判断很容易误触发。我们的做法是先建立一个路段状态机，枚举量有：直道、左弯、右弯、环岛入口、环岛内、环岛出口、十字、坡道。状态之间通过图像特征触发转移，并且要求“连续多帧确认”才切换状态。之所以要连续确认，是因为单帧噪声可能造成瞬间误判，而状态机一旦切错，恢复的成本很高，车会在几米内跑飞。

状态机还有一个好处，就是不同路段的控制策略可以不一样。比如直道可以给更大的前瞻和更高的速度，环岛内要强制减速并设置专门的转向角度上限，十字路口要开启补线逻辑。这些策略塞进一个统一的控制函数里，代码结构会非常清晰，排查问题时也容易定位。

4.2 环岛识别与补线策略

环岛是单车拉力组最常见的翻车点，我们的识别思路是看左右边线的长度差和走向变化。正常直道左右边线长度差不多，进入环岛入口时，环岛内侧会出现一条很长的弧线边线，而外侧边线会在某个位置突然消失或者明显向外弯。具体到图像特征，就是某一侧的行有效边线数远大于另一侧，且消失侧的底部边线斜率出现突变。

一旦判定进入环岛，我们不会直接让车跟着当前中线走，因为环岛入口处如果按正常中线走，车会切向环岛中心。我们的做法是“补线”：在环岛内侧缺线区域，人为补出一条与外侧边线平行的虚拟边线，然后重新计算中线。补线的位置不能离车太近，太近会让转向过早，也不能太远，太远会越过环岛出口。我们最终把补线起点设置在图像中部偏上的位置，这样车可以保持一个比较柔和的入环角度。

环岛出口的判断也很有意思。出环时，原本消失的外侧边线会重新出现，而且会在图像中快速靠近，这个时候如果还按环岛内的逻辑补线，车会向着环岛中心继续拐，直接绕错方向。所以我们单独设了一个“环岛出口”状态，一旦识别到外侧边线重新出现，就立即停止补线，切换回正常中线跟踪。

4.3 十字补线怎么补

十字路口容易出问题，是因为画面中央会出现一大块白色交叉区域，左右边线像是被“吸”进十字中心一样，导致所在行找不到正常的边线。我们的十字补线逻辑很直接：如果当前行只有左边线没有右边线，且上一帧这一区域本来是有右边线的，那就认为进入十字区域，这时根据左边线的位置，向右偏移一个标准赛道宽度，虚拟出右边线；反过来也一样，用存在的一侧去推断缺失的一侧。

补线的关键参数是“标准赛道宽度”，这个值可以通过赛前统计多帧正常直道的左右边线距离得到。不要用固定像素值，因为逆透视之后赛道宽度相对稳定，但不同亮度下边线提取结果仍会有几个像素误差，用统计平均值更稳。补线过程中还要加一个状态锁存，只有连续若干帧都满足十字特征才真正启动补线，避免在S弯里也误触。

4.4 坡道识别与处理

坡道识别我们没有单独加传感器，就用摄像头图像。从逆透视图看，坡道会让远处的地面突然“翘起来”，表现为图像上部出现一大片与正常背景不同的区域，并且左右边线距离在某一高度突然变大。我们通过计算上部的赛道宽度变化率来判断，如果宽度变化率超过阈值，就进入坡道状态。坡道上不需要复杂的补线，主要工作是限速，防止冲坡后飞坡。我们把坡道状态的最高速度设置为直道的70%，同时在出坡瞬间恢复全速。这个70%的数值是现场试出来的——太快会飞，太慢会掉速度。

5. 控制核心：串级PID怎么把“角速度”跑稳

5.1 单车模型为什么要输出角速度

很多第一次做单车组的人会习惯性地把四轮车的转向代码搬过来：算出横向偏差，乘一个P，输出舵机角度。这在四轮车上没问题，但在单车上会立刻翻车。因为单车的转向不只是为了对准赛道，它还在控制车身倾斜姿态。前轮转角改变后，车辆会产生横摆角速度，车身会跟着倾斜，倾斜后又反过来影响转向需求。也就是说，转向角度和车身姿态是耦合在一起的。

我们的做法是串级控制：外环根据赛道中线的横向偏差和曲率，计算出一个期望横摆角速度，也就是期望的转向角速度；内环是一个角速度环，读取陀螺仪或者由转向机构反馈计算出来的实际横摆角速度，通过PID输出前轮转角。这样做的好处是，外环负责“看路”，内环负责“稳住姿态”，两个环分工明确，参数调整也更方便。你会发现，我们最终交给舵机的不是“打多少度”，而是经过角速度环校正后的转角——这就是题目里“PID输出角速度”的准确含义。

5.2 转向环与速度环的配合

速度环相对简单，我们用PI控制，目标速度来自状态机：直道高速、大弯中速、环岛低速、坡道限速。输出是油门PWM占空比。这里有个细节：速度环的输出不能直接当油门开环用，因为电池电压会随着电量下降而跌落，同样的占空比实际速度会变。速度环PID的好处就是能自动补偿，但积分项不能积得太狠，否则在出弯加速时会有明显迟滞。

转向环和速度环的配合，最重要的是“速度变化时转向参数不能不变”。我们用了一个简单的变参机制：根据当前滤波后的速度，在几组预设的PID参数之间线性插值。低速时转向P可以小一点，因为车慢，打方向太猛会侧倾；高速时转向P要适当加大，同时D也要加大，用来抑制高速下的振荡。这个变参机制不用搞得很复杂，实测下来线性插值就够用。

5.3 PID参数整定的实战次序

我们调参的顺序是严格从内环到外环，这个顺序绝对不能乱。第一步，先调角速度内环。给外环一个固定期望角速度，或者手动给定一个阶跃，看实际角速度能不能快速跟上去。P太小，回正慢；P太大，会振荡。加上D之后，让角速度响应干脆但不超调。内环调好之后，车在直道上已经有基本的稳定性。

第二步，调外环横向偏差的P。把车放在赛道中线偏左一点的位置，看车能不能平滑地回到中线。如果回到中线的过程中来回过冲，就是P太大或者D不够。如果反应迟钝，就是P太小或者前瞻太远。外环不需要加I，因为中线跟踪本身没有稳态误差，加了I反而容易在弯道里产生积分饱和。

第三步，把速度环加上，先低速跑，再逐步提速。提速度的过程中如果车开始画龙，优先检查转向环的D是不是要加大，而不是一味加大P。最后再调前馈：在弯道里根据曲率提前叠加一个转向角度，可以让车的入弯更自然，减轻外环的负担。

代码方面，我们的控制中断里大致是这个逻辑：

// 5ms控制周期 float speed = encoder_get_speed(); float curvature = image_get_curvature(); float lateral_err = image_get_lateral_error(); // 外环：横向偏差和曲率 -> 期望角速度 float target_yaw_rate = LAT_P * lateral_err + CUR_FEEDFORWARD * curvature; // 内环：期望角速度与实际角速度 -> 舵机转角 float real_yaw_rate = gyro_get_yaw_rate(); float steer_out = YAW_P * (target_yaw_rate - real_yaw_rate) - YAW_D * (real_yaw_rate - last_real_yaw_rate); // 速度环：目标速度与实际速度 -> 油门 float speed_err = state_get_target_speed() - speed; float motor_out = SPEED_P * speed_err + SPEED_I * speed_integral; servo_set(steer_out); motor_set(motor_out);

这里要提醒一个老生常谈但特别常见的错误：D项不能直接用在误差的差分上，要用“实测值差分”或者“测量值差分”，否则目标值一变，微分项就会产生巨大的尖峰。很多车在切状态或者速度突变时突然猛打方向，就是这个原因。

6. 调试方法：让车把“看到的”告诉你

6.1 图像回传与阈值调试

调图像最忌讳的事情是“黑盒调试”——不知道摄像头看到什么，只能让车跑出去看结果，那效率太低了。我们队第一天就搭了一套图像回传链路：TC264通过串口把压缩后的二值图或者边线叠加图发到上位机，上位机实时显示。这样停车就能看到：这一帧二值化得干不干净、边线提取得对不对、补线补在哪个位置。

图像回传不只是赛前调试用，比赛现场也非常有用。试车时如果发现车在某个路段行为异常，立刻停车回传最近几帧图像，马上就能判断是阈值问题、边线提取问题还是状态机误判。我们甚至会在车上装一个小的无线透传模块，把关键图像和状态量发送到手机或者电脑，这样车在跑的时候就能远程监控，不用追着车跑。现场允许的情况下，这套东西能帮你省下大量试车时间。

6.2 数据记录与回放

单看实时画面还不够，有些偶发问题跑十次才出现一次，等你停下来看上位机已经来不及了。我们的办法是把关键数据按帧记录到TF卡或者通过无线模块发到电脑保存，数据包括：帧号、二值化阈值、左右边线坐标、中线偏差、曲率、状态机状态、目标角速度、舵机输出、实际速度、电机输出。每一条记录都带时间戳。

出问题之后，回放这些数据，把时间轴拖到故障前100毫秒，就能看到完整的因果关系。我们有一次环岛出弯总是偶尔失败，看回放才发现不是识别问题，而是环岛出口状态触发之后，速度环的目标速度瞬间从低速切到高速，但转向环还在用低速参数，导致车身向内侧倾斜过大，前轮失去抓地。找到原因之后，我们在状态切换时做了一小段速度斜坡，问题就消失了。这种问题不看回放，光靠跑步测试，可能一个下午都定位不到。

6.3 硬件问题优先排除

我个人的原则是：先怀疑硬件，再怀疑软件。特别是“灵异现象”——代码没改，车突然跑偏；昨天好好的，今天一开电源就抖动。这类问题大概率是接触不良、供电变差、编码器松了、舵机磨损。检查顺序可以按照下面这个流程来：

• 测电源：电池满电电压、稳压输出、舵机供电端在打方向瞬间的跌落幅度。
• 测波形：用示波器看PWM波形是否正常，舵机信号是否有毛刺，编码器A、B相是否正交。
• 看图像：确认摄像头没有断帧、没有雪花、二值化稳定。
• 查接线：所有插头重新插拔一次，重点看编码器、舵机信号线。
• 最后才怀疑代码逻辑。

这个顺序救过我们很多次。有段时间车总是在同一个弯偶尔左右乱摆，排查半天，最后发现是摄像头排线有一根线内部接触不良，车震动到某个频率时图像会漏行，边线位置跳变。如果一开始就去调PID参数，估计调一个月也找不到根因。

7. 常见问题与排查技巧实录

7.1 高频故障速查表

7.2 偶发问题怎么定位

最让人头疼的是那种“跑十次才出一次”的问题。我们的方法分三步：第一步，让问题复现，不能复现就没法查。如果每天只在某个特定条件出现，就在那个条件下反复跑，同时用数据记录把现场抓下来。第二步，把回放数据和触发条件关联。比如发现每次出问题都跟电池电压低于某个值有关，那就重点查电源；如果每次都在切换状态之后100毫秒左右出问题，那就重点查状态切换逻辑。第三步，做“单变量验证”：一次只改一个变量，改完再去复现，不要同时改两三个参数，否则永远不知道是哪个改动起了作用。

还有一个更玄学的经验：如果某段代码逻辑上完全正确，但车表现时好时坏，可以去检查中断优先级和阻塞时间。TC264这类多核单片机，如果图像处理里有一个耗时很长的for循环，而它所在的中断优先级又高于控制中断，控制周期就会被随机拉长，表现出来就是“逻辑没变，但车偶尔发神经”。我们后来把图像处理放到低优先级任务里，控制中断保持最高优先级，这类问题就消失了。

7.3 几个值得记住的避坑细节

第一个是开机初始化顺序。舵机和电机驱动在上电瞬间会有一个非确定状态，如果主控还没初始化完就先给了舵机信号，舵机会猛打到一边，轻则损坏舵机，重则扫到旁边的车。我们在工程里加了一个延时，初始化完成之后先让舵机归中，再使能电机输出。这个习惯看起来不起眼，但能避免很多惨剧。

第二个是编码器方向与电机方向、速度环反馈符号的一致性。如果编码器方向反了，速度环会把油门越加越大，车会在原地突然冲出去。接完线先低速开环测试，确认电机正转时编码器读数为正，再闭合速度环。

第三个是备用配置。比赛现场很可能不让你重烧程序，或者烧录器刚好出问题。我们赛前会在调试SD卡里存一份稳定版本的工程备份，并且把当前参数写在车上明显位置。万一现场需要恢复，至少有一个已知能跑的配置兜底。

8. 写在最后：比赛那几天，比技术更重要的是流程

8.1 赛前最后一周该做什么

最后一周不要再去折腾大改动了，比如换摄像头、换控制架构、重新标定逆透视。我们的原则是“冻结硬件，只调参数”。每天做的事就是反复跑完整圈，记录圈速和稳定性，把出现频率最高的问题逐个修掉。同时把备用电池充满，检查所有连接线，准备一份详细的发车检查清单。清单包括：电池电压、轮胎状态、摄像头是否松动、舵机拉杆是否正常、编码器线是否插紧、程序版本号。现场时间很紧张，靠脑子记容易漏，清单是最可靠的。

8.2 试车策略小建议

试车的时候不要一上来就全力跑。先把目标速度降到80%，让车稳定跑完整张图，确认所有路段的识别和控制都正常，再逐步提速。每次提速只提一档，跑几圈看稳定性，再决定是否继续。如果提速后某个环节开始出问题，就降回上一档，记下当前速度边界。比赛比的是单圈最快，但更比的是“能不能跑完”。我们见过太多队伍预赛跑得飞快，结果最后冲刺直接飞车，连成绩都没有。

8.3 一些留给后来人的经验

做智能车这一年，我们最大的体会是：不要迷信某一个“神级算法”，真正拉开差距的是整个系统的稳定性和调试效率。同样的摄像头，有人能跑出流畅的弯道，有人却连续翻车，差别往往在于阈值稳定、边线滤波、参数匹配这些细节。把基础做扎实，环岛识别这种问题自然水到渠成。

最后分享一个小技巧：给车上的每一个可调部件都做标记，比如舵机臂角度、摄像头俯仰角、轮胎胎压。调车过程中你会频繁地拆装，没有标记的话，一旦手滑拧歪了一个螺丝，后面所有参数都会变得莫名其妙，而你根本不知道机械已经变了。做标记这件事花不了十分钟，却能帮你省下一下午的排查时间。希望这些内容对准备参加智能车竞赛的朋友有帮助，祝你们的车越跑越稳。