智能车竞赛单车拉力组技术报告：摄像头循迹与串级PID控制实战

每年开春实验室地上都是新留下的轮胎印电调烧糊的味道还没散干净——智能车竞赛的备赛就是这样。这篇文章来自我们大连海事大学同舟拾队在单车拉力组的技术报告整理覆盖硬件选型、图像处理、控制策略、现场调试全流程。如果你正准备参加全国大学生智能车竞赛的单车拉力组或者单纯想了解摄像头循迹车怎么把“看见的赛道”变成“打得准的方向盘”这篇应该能给你一些直接抄作业的方案。单车拉力组的难点不只是循迹它的机械特性和常规四轮组差别非常大所以整条控制链比普通循迹车更长也更讲究层次。看完你会明白为什么调车到最后比的往往不是某一个算法而是整个系统的匹配度。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、编码器接口都齐全。相比更高端的TC377TC264的开发资料和开源方案更多遇到问题容易找到参考相比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 高频故障速查表问题现象可能原因排查方法直道画龙转向P过大、D过小、前瞻太近、机械传动间隙大先减小外环P再增大内环D检查舵机拉杆和转向节虚位入环岛经常冲出去环岛识别触发太晚、入环速度太高、补线起点太远提高环岛入口识别灵敏度把入环目标速度降一档补线起点往下移十字路口直接切错道补线触发条件太松、进入十字前没有状态确认增加连续多帧确认补线宽度改为统计赛道宽度禁止在S弯内触发摄像头图像偶发全黑或花屏供电跌落、排线接触不良、曝光时间设置过长检查摄像头供电端波形重新插拔排线降低曝光时间电机响应滞后PWM频率太低、驱动死区未补偿、电池内阻大提高PWM频率检查驱动芯片死区时间换大放电倍率电池高速入弯车身侧倾过大速度太快、转向角速度前馈不足、内环响应慢降低入弯速度增大曲率前馈系数检查内环角速度P参数7.2 偶发问题怎么定位最让人头疼的是那种“跑十次才出一次”的问题。我们的方法分三步第一步让问题复现不能复现就没法查。如果每天只在某个特定条件出现就在那个条件下反复跑同时用数据记录把现场抓下来。第二步把回放数据和触发条件关联。比如发现每次出问题都跟电池电压低于某个值有关那就重点查电源如果每次都在切换状态之后100毫秒左右出问题那就重点查状态切换逻辑。第三步做“单变量验证”一次只改一个变量改完再去复现不要同时改两三个参数否则永远不知道是哪个改动起了作用。还有一个更玄学的经验如果某段代码逻辑上完全正确但车表现时好时坏可以去检查中断优先级和阻塞时间。TC264这类多核单片机如果图像处理里有一个耗时很长的for循环而它所在的中断优先级又高于控制中断控制周期就会被随机拉长表现出来就是“逻辑没变但车偶尔发神经”。我们后来把图像处理放到低优先级任务里控制中断保持最高优先级这类问题就消失了。7.3 几个值得记住的避坑细节第一个是开机初始化顺序。舵机和电机驱动在上电瞬间会有一个非确定状态如果主控还没初始化完就先给了舵机信号舵机会猛打到一边轻则损坏舵机重则扫到旁边的车。我们在工程里加了一个延时初始化完成之后先让舵机归中再使能电机输出。这个习惯看起来不起眼但能避免很多惨剧。第二个是编码器方向与电机方向、速度环反馈符号的一致性。如果编码器方向反了速度环会把油门越加越大车会在原地突然冲出去。接完线先低速开环测试确认电机正转时编码器读数为正再闭合速度环。第三个是备用配置。比赛现场很可能不让你重烧程序或者烧录器刚好出问题。我们赛前会在调试SD卡里存一份稳定版本的工程备份并且把当前参数写在车上明显位置。万一现场需要恢复至少有一个已知能跑的配置兜底。8. 写在最后比赛那几天比技术更重要的是流程8.1 赛前最后一周该做什么最后一周不要再去折腾大改动了比如换摄像头、换控制架构、重新标定逆透视。我们的原则是“冻结硬件只调参数”。每天做的事就是反复跑完整圈记录圈速和稳定性把出现频率最高的问题逐个修掉。同时把备用电池充满检查所有连接线准备一份详细的发车检查清单。清单包括电池电压、轮胎状态、摄像头是否松动、舵机拉杆是否正常、编码器线是否插紧、程序版本号。现场时间很紧张靠脑子记容易漏清单是最可靠的。8.2 试车策略小建议试车的时候不要一上来就全力跑。先把目标速度降到80%让车稳定跑完整张图确认所有路段的识别和控制都正常再逐步提速。每次提速只提一档跑几圈看稳定性再决定是否继续。如果提速后某个环节开始出问题就降回上一档记下当前速度边界。比赛比的是单圈最快但更比的是“能不能跑完”。我们见过太多队伍预赛跑得飞快结果最后冲刺直接飞车连成绩都没有。8.3 一些留给后来人的经验做智能车这一年我们最大的体会是不要迷信某一个“神级算法”真正拉开差距的是整个系统的稳定性和调试效率。同样的摄像头有人能跑出流畅的弯道有人却连续翻车差别往往在于阈值稳定、边线滤波、参数匹配这些细节。把基础做扎实环岛识别这种问题自然水到渠成。最后分享一个小技巧给车上的每一个可调部件都做标记比如舵机臂角度、摄像头俯仰角、轮胎胎压。调车过程中你会频繁地拆装没有标记的话一旦手滑拧歪了一个螺丝后面所有参数都会变得莫名其妙而你根本不知道机械已经变了。做标记这件事花不了十分钟却能帮你省下一下午的排查时间。希望这些内容对准备参加智能车竞赛的朋友有帮助祝你们的车越跑越稳。