每年备赛进入后半程实验室里最容易被拖到最后一刻的两件事一个是车还在赛道上抽风另一个就是智能车竞赛的技术报告还是一片空白。很多队伍现场跑得不错最后却在技术报告上丢掉一大截分甚至因为格式不符合细则被扣分。这篇内容就是把我这几年参与全国大学生智能车竞赛、帮学弟学妹改报告的经验连同细则里那些看似是格式、实际决定分数的条款一次性讲透。不管你是第一次参赛、连章节都不知道怎么分的新手还是已经拿过奖、想冲击更高名次的队伍都能从这里找到能直接抄作业的框架和细节。需要先说清楚一件事每年官方发布的细则都会有微调页数上限、字体字号、评分权重这些硬性数字一定要以当年发布的正式文件为准。下面讲的框架、写法、避坑点是跨届都通用的部分也是评委真正在意的东西。1. 技术报告在智能车竞赛里到底占多少分量1.1 别把它当成跑完车之后的补作业我见过太多队伍的时间线是这样的放假前两个月调车比赛前一周才开始写报告最后两天通宵排版交上去一份电路图是截图、波形是手机拍的、结论是编的的东西。这种报告交上去评委翻三页就能看出来分数自然不会好看。技术报告的本质是把你做的工程翻译成别人能验证的语言。评委不会坐在你的车旁边看你跑他只能通过报告判断三件事你知不知道自己在做什么、你的方案是不是自己想出来的、你的数据能不能支撑你的结论。现场成绩证明你的车能跑技术报告证明你的车为什么能跑。这两件事缺一件整体评价就是不完整的。从评分构成上看通常由现场竞速成绩、技术报告评分、以及部分组别的答辩或设计方案评审共同组成具体权重比例每届不同。但有一点是确定的当两支队伍现场成绩接近时技术报告往往是拉开差距的那一项。现场成绩受当天光照、赛道状况、临场心态影响很大技术报告则是你在赛前就能完全掌控的部分属于确定能拿的分。把可控的分丢掉是最不划算的事。1.2 评委翻开报告实际上在看什么很多人写报告的逻辑是我做了什么就写什么从第一块电路板写到最后一版代码。这个逻辑对作者友好对读者不友好。评委看报告的时间可能只有十几分钟他心里有一张隐形的清单你要做的是主动把答案喂给他。下面这张表是我总结的常见评分关注点不同年份和组别会有差异但大方向差不多关注维度评委想确认的事典型扣分表现方案合理性选型和参数是否有依据不是照搬只说用了某某方案不说为什么技术难度与创新有没有超出基础套路的自研部分全篇是通用教程的复述工程完整度软硬件、机械、调参是否闭环只写软件机械只字未提数据支撑结论有没有实测数据背书通篇效果良好运行平稳规范性格式、图表、公式、引用是否规范图无编号、表无单位、公式截图原创与诚信内容是否为本人工作大段与往届报告雷同看到数据支撑那一栏了吗这是最容易补、也最容易被忽略的一项。你把转向响应快改成在 3 m/s 直道末端舵机从接收到指令到角度到位耗时约 XX ms超调量约 X%评委的观感完全不同。前者是形容词后者是证据。1.3 一份合格报告的骨架长什么样不要自己发明结构细则一般会给出建议章节照着来最省事。如果细则没写死用下面这套骨架基本不会出错封面学校、队伍名称、参赛组别、队员与指导教师、日期按细则要求的字段填全缺项是硬伤。目录自动生成页码与正文一致别手工敲。引言或总体方案任务理解、整体思路、方案对比与选定理由。机械结构设计车模改装、重心、传动、悬挂、传感器安装。硬件电路设计系统框图、电源树、各功能模块、PCB 布局要点。软件系统设计程序架构、任务调度、图像处理、控制算法。赛道元素识别与策略各类元素的识别逻辑与通过策略。调试与测试测试方法、参数整定过程、实测数据与分析。结论与改进方向达成了什么、还有什么没解决。附录原理图、PCB 图、主要程序清单、元器件清单、参考文献。举个具体的篇幅分配参考假设细则允许的正文上限是 20 页左右具体以官方为准总体方案 2 页机械 2 到 3 页硬件 3 到 4 页软件与算法 5 到 6 页元素识别与策略 3 页测试与数据 3 页结论 1 页。你可以按这个比例倒推自己还剩多少页避免出现算法写了八页、机械一句话带过的失衡。注意细则里关于页数、字数、字体、装订方式的要求属于硬性条款不按要求提交轻则扣分重则不予评审。交稿前把细则当成检查清单逐条打钩比反复润色文字有用得多。2. 报告框架怎么搭从赛道元素倒推章节编排2.1 用感知—决策—执行—验证这条主线串起来新手写报告最常见的问题是章节之间没有逻辑关系硬件一章、软件一章、机械一章三章互不相干读起来像三份独立的作业拼在一起。真正好读的报告有一条贯穿始终的主线我习惯用感知—决策—执行—验证这四步。感知是传感器和图像处理解决车怎么知道自己在哪决策是元素识别和路径规划解决车接下来该往哪走执行是控制算法和电机舵机解决车怎么按想的方式动验证是测试和数据解决我怎么知道它做对了。你把这四步写清楚读者自然能看懂你的车是怎么工作的。这条主线还有个好处它天然解释了为什么机械章节不能省。传感器装在哪里、重心的位置、轮胎的处理方式全部属于感知质量和执行精度的前置条件。你把机械部分单独拎出来写读者会以为机械只是把零件装上去你把机械的作用挂到主线上读者才知道你为什么要反复调那个舵机中值和前轮倾角。2.2 篇幅该往哪里倾斜报告不是均匀铺开的你的篇幅分配应该和你的技术亮点一致。哪一块你投入最多、最有心得、最能体现技术水平哪一块就该写得更细。反过来如果某块你就是按参考设计做的老老实实写清楚参考了某某方案并做了如下适配比硬凑五页废话强。我一般建议把重心放在算法与元素识别上因为这部分最能体现你自己想出来的东西。同一条赛道直道加速谁都会真正分胜负的是环岛怎么进出、十字怎么不误判、坡道怎么不失速、斑马线怎么减速。这些策略细节写透了评委一眼就能看出你是真跑过车的。有个反例值得说说。有队伍把大量篇幅花在元器件参数对比表上列了十几个电容的品牌型号但对自己怎么解决某个赛道元素的误判只写了一句调整阈值后解决。这种篇幅分配就是典型的力气用错地方。2.3 图表和数据组织的基本逻辑报告里所有的图和表都是为结论服务的不是为了填满页面。我给学弟学妹定了一条规矩每一张图后面必须跟一句解释它说明了什么。图是车模照片、下面写整车外观这种等于白占版面。比较好的组织方式是这样系统框图放在总体方案章节帮读者建立全局认知。原理图和 PCB 三维图放硬件章节配一段布局考量说明。程序流程图放软件章节用层次结构图而不是密密麻麻的流程线。上位机波形、串口数据曲线放调试章节配参数量化的结论。赛道元素处理前后的图像对比放元素识别章节直观且信服力强。表格方面参数表、测试数据表、性能对比表是最实用的三类。测试数据表一定要带上测试条件比如光照强度、赛道摩擦情况、连续测试次数、统计的是均值还是最优值否则数据没法采信。3. 核心技术章节怎么写才不空3.1 硬件设计把电源树画出来比什么都强硬件章节最容易写成元器件大杂烩。我的建议是先画一张电源树从电池出发展开每一级转换的输入输出范围、额定电流、纹波要求都标出来。这张图一画读者立刻明白你的供电架构也知道你对功耗和噪声是真的考虑过。电机驱动部分是硬件里最讲究的。有刷直流电机在换向瞬间会产生较大的电流尖峰和反向电动势如果和信号地混在一起采集回来的传感器数据会跟着一起跳。常见的处理方式包括电机地与信号地单点汇接、驱动芯片就近布置大容量储能电容、电机两端加吸收电路具体参数以实际测试为准。传感器信号调理这块要写清楚你为什么选这个运放或比较器带宽够不够、输入失调电压是否可接受、供电轨是否匹配。电感采集类方案里选频放大器的中心频率要和赛道信号频率对应品质因数影响的是抗邻道干扰能力这些都是可以量化的。ADC 采样的设计也要落到数字上。比如图像采集用多少位、采样率多少、参考电压多少、有效分辨率能到多少 LSB这些数据评委会关心。你写出我们最终选择了 X 位 ADC、Y 位有效精度这样一句话比提升了采集精度有说服力得多。注意硬件章节里出现的每一张原理图和 PCB 图都要保证清晰可读。截图模糊、网络标号看不清、元件位号被裁掉是最常见的低级失分点。矢量图导出 PDF 后放大不糊这是一个基本要求。3.2 传感器与图像处理从原始数据到有效特征图像处理章节不能只写我们用了大津法二值化。评委想看到的是你对图像质量问题的处理链条原始图像有没有噪声、光照变化怎么补偿、阈值怎么自适应、二值化后怎么提取有效特征、特征怎么转化成控制量。自适应阈值的思路一般是在局部窗口内统计灰度分布取类间方差最大的那个灰度值作为分割点。这个方法的优点是光照变化时阈值能跟着走缺点是计算量偏大。实际用的时候通常会把统计窗口缩小或者隔行隔列采样来降低运算量。这些都是可以写进去的工程取舍。特征提取环节要讲清楚你提取的是什么。用摄像头立着装的方案常见做法是找边沿、算中心线、对中心线做加权拟合得到车体相对赛道的横向偏差和方向偏差。这两个量就是后面控制器的输入。你需要说明边沿是怎么找的从中间往两边扫、找梯度跳变最大的点、异常边沿怎么剔除连续性约束、宽度约束、丢线的时候怎么办保持上一帧、或者切到预测模式。给一段伪代码会非常直观评委也能感受到你是真的写过// 边沿搜索的简化示意仅表达思路 int left_edge center_x, right_edge center_x; for (int i center_x; i 0; i--) { if (binary[i] BLACK) { left_edge i; break; } } for (int i center_x; i WIDTH; i) { if (binary[i] BLACK) { right_edge i; break; } } // 连续性校验与上一帧的中心线偏差过大则视为误检 if (abs(left_edge - last_left) MAX_JUMP) left_edge last_left;元素识别部分建议用状态机来讲。每个赛道元素都能拆成特征触发—状态切换—状态退出三个环节。比如环岛先靠一侧的弧线和位置关系触发进入状态再靠字线和方向判断走内圈还是外圈最后靠出环的特征退出。把这套状态转移表列出来比大段文字描述清楚得多。元素触发特征状态处理退出条件十字左右边沿同时向外跳变放弃边沿按上一帧方向直行边沿重新收敛环岛单侧弧线加内切特征切换跟随目标边沿检测到出环缺口坡道图像下方大面积失线加陀螺仪俯仰突变降低速度环目标姿态恢复斑马线规律性黑白交替条纹减速通过条纹消失这张表里的每一项你都要在正文里解释你是怎么定阈值的、阈值怎么随速度自适应。速度越快允许的判断时间越短很多队伍会做低速宽容、高速保守的双阈值策略这就是可以写的亮点。3.3 控制算法把参数整定过程写出来控制部分是技术报告的重头戏。转向通常用位置式 PD 或者 PD 加前馈速度用 PI 或者 PID两者构成串级结构。你要讲清楚为什么用串级转向环的响应要求是快速度环的响应要求是平稳两者时间尺度不同分开设计更容易整定。离散化的公式一定要写出来而且要写清楚你的采样周期。比如转向环在 5 ms 周期下运行、速度环在 20 ms 周期下运行这样写评委才知道你的积分项和微分项是怎么标定的。// 位置式 PD 转向环示意 float steer_pd(float err, float gyro_z) { static float last_err 0; float d (err - last_err) / TS_STEER; // 微分项TS_STEER 为采样周期 last_err err; float out KP_STEER * err KD_STEER * d KGYRO * gyro_z; // 陀螺仪前馈 return limit(out, -MAX_STEER, MAX_STEER); // 输出限幅 }参数整定过程必须写。不要只给最终的一组参数要给怎么走到这组参数的路径。我习惯按这个顺序描述先只开 P从小到大加到出现小幅振荡记录下临界值再把 P 退回到临界值的六成左右然后加 D 抑制超调观察高频抖动抖动明显就说明 D 过大最后加陀螺仪前馈改善入弯的响应速度。每一步都配上波形或者表格。整定阶段P 取值D 取值现象结论只有 P小0入弯反应迟钝出弯跟不上增大 P只有 P中0直道出现小幅左右摆达到临界退让P D退让后小摆动被压住入弯仍偏慢加前馈P D 前馈同上同上入弯响应改善无明显抖动定稿速度环的写法类似但要提一句积分限幅和输出限幅。积分不限制长时间偏差累积会导致出弯时速度猛冲。抗积分饱和的处理方式比如积分分离、遇限削弱积分都值得展开一小段。机械方面的手感也要量化。舵机中值不是调到车能直着走这么一句而是给出具体做法把车放在长直道上低速跑通过上位机观察横线偏差的漂移方向反复微调中值直到三米内偏移小于某个范围。轮胎处理、前轮外倾、差速松紧、配重位置这些都可以用调整前 X 现象、调整后 Y 现象的方式记录下来。4. 实测数据与验证把跑通了变成证明得了4.1 测试方案要交代清楚条件数据有没有说服力一半取决于测试条件的描述。同一辆车在上午的斜射阳光和下午的顶光下图像处理效果可能差很多。你不写条件评委没法判断你的数据是在什么环境下取得的。我的习惯是每次测试都记录这几项场地位置和环境光来源、赛道清洁程度、胎面状态、电池电压区间、连续测试次数。把这些做成一张测试条件表放在测试章节开头后面所有数据都建立在这个共同前提下可读性会好很多。重复次数尤其重要。单次跑出的最快圈速没有意义你需要给出多次测试的统计结果。一般来说同一个配置至少跑 5 到 10 次记录最快值、最慢值、平均值和波动范围。波动范围小说明方案一致性高波动范围大就要分析是参数问题还是环境干扰。4.2 波形和曲线怎么放才专业上位机波形是最能体现调试功底的素材。放波形的时候注意三点坐标轴要有物理单位和量级、要有图例区分不同通道、时间轴要能看出采样密度。手机拍屏幕是绝对不行的用上位机自带的导出功能或者截图工具导出原始分辨率的图。我一般会放这几类波形转向环的输入偏差和输出舵量对比、速度环的目标与实际速度跟随、陀螺仪在过弯时的角速度、以及某一个具体元素处理过程中的关键变量。每张波形配一句从图中可以看出……把结论说出来。数据表格建议统一格式用三线表单位写在表头或者量名后面的括号里。下面是一个测试数据的示例格式测试轮次圈速 (s)最大速度 (m/s)偏差峰值 (像素)备注118.423.0524电池 8.1 V217.963.1221电池 8.0 V318.133.0826侧向光照变化平均18.173.0823.7—4.3 失败案例写进去反而加分大部分人写报告只写成功的部分其实把关键的失败和排查过程写进去能显著提升可信度。因为真实做工程一定会有反复全是顺利的过程反而不真实。写法上推荐现象—假设—验证—结论四步。举个例子现象是车进环岛后偶尔冲出赛道假设是环岛入口的弧线识别被误判成普通弯道验证是把出问题那一帧的原始图像和处理后图像导出对比发现入口处的边沿确实被十字逻辑吞掉了结论是给环岛触发增加了一个优先级判断让它在十字判断之前生效。这样一段两百字的记录比两页空泛的算法描述有价值得多。5. 排版、图表与公式的细则红线5.1 目录、页眉、页码这些小地方自动生成目录是基本要求。手工敲的目录一旦正文改动页码就对不上评委翻到目录发现页码错位印象分直接掉。用编辑器的样式功能给各级标题套用统一样式再自动生成目录和页码后期改动成本很低。页边距、行距、字体字号按细则要求设置。常见的做法是正文用宋体或仿宋小四、行距固定值或 1.5 倍标题分级加粗具体以当年细则为准。别小看这个细则里写了的格式就是硬性条款。章节编号建议让编辑器自动生成而不是手动敲3.2.1。手动编号在插入新章节后需要全篇改很容易漏掉一两处出现3.2.1 后面接 3.2.3这种低级错误。5.2 图表规范三线表、坐标轴、图注表格统一用三线表去掉竖线和多余的横线。表头写清量名和单位比如最大速度 (m/s)而不是最大速度。表格里的有效数字保持一致别一行写 3.05、一行写 3.1。图片要求是矢量图或者高分辨率位图导成 PDF 后放大不糊。图注放在图的下方表注放在表的上方这是常规做法。图注要写清图 X 什么系统的什么部分不要只写图 X 系统框图。坐标轴的刻度要合理别让曲线挤在一个角落。多条曲线一定要有图例图例里的通道名要和正文里提到的名称一致不要一会儿叫err一会儿叫偏差。5.3 公式、代码与引用公式必须用公式编辑器或者对应的排版语法输入不能截图。截图公式在缩放和打印时都会失真而且显得很随意。公式里的变量用斜体单位和函数名用正体这是通用的排版习惯。每个重要公式后面要用一段文字解释每个符号的含义。代码清单放附录正文里只在讲关键逻辑时贴短片段。代码用等宽字体保留缩进注明语言和文件名。整段粘贴几百行代码进正文会严重挤占篇幅得不偿失。引用参考文献要用统一的格式正文里出现他人方案或数据的地方要标注来源。这既是规范问题也是诚信问题。5.4 查重与原创性部分年份的细则会要求技术报告进行查重。就算没有明确要求抄袭往届报告也是绝对的红线。我见过有人把学长报告里的硬件章节直接拿来改改电路参数结果两届评委有重合一眼就认出来了。正确的做法是参考思路、重写表达、替换数据。你看往届报告是为了知道有哪些方案可选但最终的选型依据必须来自你自己的测试。数据、波形、图像这些素材一定用自己的。6. 常见问题与排查速查6.1 内容层面的高频问题内容问题往往要等到评审阶段才暴露补救成本最高所以要在动笔前就规避。问题表现根本原因处理方式通篇只讲软件机械和硬件一笔带过分工不均只写了自己负责的部分按主线补齐四个环节结论全是形容词没有数字测试记录缺失补做分段测试建立数据表算法部分和代码对不上报告是后期回填的以最终代码为准重新梳理元素策略描述含糊靠现场试出来的没复盘逐元素写出状态转移表6.2 格式层面的高频问题格式问题是最亏的失分因为它和技术水平无关纯粹是细心程度。交稿前一定要做一轮专门的格式检查目录页码是否同步、图表编号是否连续、公式是否全部为可编辑格式、页眉页脚是否正确、参考文献格式是否统一、附录是否齐全。这一轮检查最好由队里最细心的那个人来做作者本人容易看漏自己的问题。6.3 提交环节的坑提交前确认文件格式和命名要求。细则通常会规定是提交 PDF 还是同时提交源文件、命名规则是什么、是否需要压缩打包。压缩包命名写错、漏交附录、PDF 导出时字体丢失导致乱码这些都是真实发生过的翻车案例。导出 PDF 后一定要在另一台设备上打开看一遍确认字体没有替换、图片没有丢失、公式没有变成方框。这一步花五分钟能避免很多麻烦。提示把最终版 PDF 同时在两台设备上打开检查一台电脑一台手机重点看公式、特殊符号和图表是否正常渲染。7. 我实际踩过的几个坑与经验补充第一次带队的时候我把报告写成了实验记录流水账从第一版电路到最后一版全部罗列结果评委的反馈是看不出最终方案是什么。后来我改成先给最终方案再解释为什么这么选中间的迭代过程只保留关键的两三次。这个思路的转变让报告的可读性提升非常明显因为读者不需要跟着你重走一遍弯路他只需要知道你的弯路给你带来了什么判断。还有一个坑是图表编号。我们有次在最后一天临时加了两个章节手动编号的图表全乱了有几张图的编号重复最后是靠通宵重排才解决。从那以后我要求所有图表都使用自动编号和交叉引用正文里提到如图 X 所示时全部用引用字段插入新内容后编号自动更新。另外一点关于时间安排的建议技术报告的素材收集应该和调车同步进行而不是等到调完车再补。我现在的做法是在实验室放一块白板每次解决一个关键问题就写一行问题—方案—数据晚上回宿舍花二十分钟把当天内容整理成一段文字存进文档。等到正式成稿的时候测试章节和调试章节基本已经写完了剩下的只是排版和串稿。这样不仅省时间还能保证细节不被遗忘那些当时觉得肯定记得住的现场现象过两周基本就想不起来了。最后再分享一个关于数据整理的小技巧把每次测试的上位机日志按日期和配置编号存档命名格式统一成日期_赛段_配置版本比如0812_环岛_v3。这样写报告需要引用某一组数据时能立刻定位到原始文件既方便补图也方便被问到细节时快速查证。这套习惯看起来有点麻烦但真正到交稿前那几天你会感谢当时多敲了那几个字符。