企业官网建设流程全解析

“进度要完蛋了。”如果你正在备赛智能车竞赛，这句话大概率不陌生。它可能是深夜调完一轮代码后的真实感叹，也可能是队友看到测试视频时的集体恐慌。说这句话的队伍，通常不是没有干活，而是不知道离“能完赛”还差多少。

从很多参赛队伍的备赛情况来看，我的判断是：绝大多数进度危机并不是技术能力不够，而是项目节奏失控。具体来说，是里程碑没有拆、调试手段无效、参数调整靠玄学。这篇文章就把这三件事逐一讲透，并给出一套可以直接照着做的备赛路线、代码示例和排查清单。

智能车竞赛和普通课程设计最大的区别在于：它不是一个“做完提交”的项目，而是一个“必须跑得快又跑得稳”的实时系统。赛场上任何一次抖动、误判、丢线、堵转，都会直接转化成脱轨或冲出赛道。正因为结果反馈极其直接，备赛过程中的进度问题会被迅速放大。如果团队还在用“感觉差不多”的方式推进，进度自然会一天比一天紧张。

不管你是哪一届、哪一级的队伍，也不管你参加的是摄像头、电磁还是其他组别，只要赛题本质仍然是“感知赛道—决策控制—执行驱动”这条链路，下面这套方法论就适用。

1. “进度要完蛋”背后的真实问题

1.1 里程碑没有拆到能检查的程度

很多队伍的计划就是“五周搞定，三周调车”。这个计划根本无法执行，因为“调车”本身不是一个验收项。真正可检查的验收项应该是“摄像头画面每天都能稳定输出中线”“舵机跟随中线没有明显滞后”“在目标速度下能连续跑完一圈”。

如果计划里全是任务，没有验收标准，你永远不知道进度是提前还是落后。更常见的情况是，队伍在硬件组装上卡了三天，又在图像采集上卡了一周，等到真正开始写控制算法时，比赛已经临近。

1.2 调试手段停留在“盲调”

智能车是一个闭环系统：传感器采集、算法处理、控制输出、机械执行，任何一个环节出问题都会表现为“车跑偏”“车抖动”“冲出赛道”。如果只盯着最终现象改参数，就会陷入“调了 KP 没用，又调 KD，还是没用”的循环。

根本问题在于你没有把链路拆开。比如车跑偏，可能是图像中线提取偏了，可能是转向舵机中位不准，也可能是左右电机转速不一致。没有中间量输出，就只能靠猜。调试手段落后的队伍，10 分钟可以加一个参数，却要花一下午猜测问题出在哪一层。

1.3 参数调优靠碰运气

PID 参数、摄像头阈值、车速规划、弯道前瞻，这些参数在智能车项目里非常多。如果每次调参都直接改代码、烧录、跑车，你会发现“上一版明明能跑，为什么改了一个参数就不行了”。

这实际上是缺少参数记录和版本管理。正确做法是让参数外部化、可配置，并记录每一组参数对应的现象。调参不是玄学，而是一个“变量隔离”的实验过程。一次只改一个变量，记录输入输出和现象，才能形成有效经验。

1.4 从“焦虑”到“可控”

解决办法不是给自己打鸡血，而是建立一张进度检查表。把整车拆成若干子系统，每个子系统都有明确的模块边界、测试方法和完成标志。进度不是“感觉还早”，而是“完成了哪几个模块，剩下哪几个模块，每个模块几天能做完”。

后面第 4 节会给出一份可以直接照着用的里程碑清单。

2. 智能车项目的技术架构与核心概念

2.1 一套完整的实时嵌入式链路

智能车是一个典型的实时嵌入式系统。按数据流向，可以拆成感知、决策、执行三层。

感知层负责获取外部信息：摄像头采集赛道图像，电磁传感器采集磁场强度，编码器反馈实时车速，陀螺仪和加速度计反馈车身姿态。

决策层是 MCU 内部运行的逻辑：对图像进行二值化和中线提取，对电感值做差值计算，结合当前车速计算出期望的转向角度和期望速度，再通过 PID 控制器输出 PWM。

执行层包括电机驱动和舵机，它们把 PWM 信号转换成实际的转速和转角。

任何一个环节的数据异常，都会在“跑偏”“抖动”“冲出赛道”这些现象上体现出来。所以备赛的第一步，是保证这条链路的每一层都可观测、可验证。

2.2 核心概念一：赛道中线提取

大多数摄像头组算法的起点，不是“识别赛道类型”，而是“找到图像里赛道的中线位置”。因为智能车是沿赛道行驶的，只要知道中线相对车身左偏还是右偏，就能决定打多少角度。

中线提取的难点在于光照变化、反光、赛道边缘不清晰，以及十字、环岛等复杂元素的干扰。第一步通常是用二值化把图像变成“赛道是白、背景是黑”或者相反，再从每一行扫描左右边界，取中点。进阶做法包括大津法、自适应阈值、行中点拟合、基于透视关系的弯道前瞻。

2.3 核心概念二：PID 控制

PID 是智能车最基础的控制算法。转向环节常用 PD 控制，速度环节常用 PI 控制。P 决定响应的快慢，I 消除稳态误差，D 抑制超调。

新手最容易犯的错误是把 PID 当成黑盒，出现任何问题都往 PID 上猜。实际上在调 PID 之前，必须确认底层执行是可控的：电机响应正常、编码器读数准确、舵机中位正确。否则 PID 参数再准也没有意义。

2.4 不同组别的技术差异

智能车竞赛的分组名称每年可能调整，但按常见技术路线做通用对比，大致如下：

这里的核心结论是：不论哪个组别，底层控制逻辑都离不开编码器测速、PID 输出、PWM 驱动。这套基础能力越扎实，后面调整赛题专项时越从容。

3. 备赛环境与工程工具准备

3.1 开发环境

大多数队伍使用的 MCU 以 STM32 或竞赛板卡厂商提供的平台为主。Windows 下常用 Keil MDK 或 IAR 开发，也可以使用 GCC 工具链加 VS Code 的流程。具体工具和版本以你手上的板卡为准，但团队内部必须统一，避免“你代码在 Keil 能编，我这边全是红色报错”的尴尬。

建议直接从芯片厂商或板卡厂商提供的例程开始改，不要从零搭工程。原因很简单：例程已经处理好了时钟、引脚复用和下载配置，能省下一到两周的时间。

3.2 下载与调试

调试器常见的有 ST-Link、DAP-Link 等，视板卡而定。下载失败时不要急着重装驱动，先检查调试器和板卡连接、目标板供电、调试接口引脚是否被复用。

如果程序里把 SWD 引脚复用成了普通 GPIO，下一次下载就会失败。解决办法是按住复位键点击下载，或者使用带一键下载电路的开发板。

3.3 辅助工具清单

• 串口助手：查看打印日志，确认中间量。
• VOFA+ 等虚拟示波器：把变量实时画成曲线，调 PID 效率会提高很多。
• 逻辑分析仪：观察 PWM 波形、编码器脉冲、串口数据。
• 一个普通 USB 摄像头或手机：拍下跑车视频，方便回看转向时机和车身姿态。

3.4 Git 版本管理

Git 不只用来管理代码，还可以管理参数、文档、上位机配置。建议每次跑车测试后，记录对应的代码 commit 和参数标签，例如“commit f3a2c9 + speed_2m5 + light_noon”。

这样如果某次改动后性能下降，可以马上回退。智能车调试中有大量“改着改着就坏了”的情况，没有版本管理，你会连“上一版为什么能跑”都说不清。

4. 备赛里程碑拆解：把进度拉回“可控”

4.1 里程碑总览

以赛前 6 周为例，可以把备赛过程拆成六个里程碑。如果时间更紧，可以压缩前三个阶段，但不能跳过验证标准。

这里的“负责角色”不是固定岗位，而是强调每个里程碑必须有一个明确负责人。如果所有人都在做同一件事，大概率意味着任务没有拆开。

4.2 每个里程碑怎么验收

每个里程碑都要有明确的数据或现象作为验收标准。

比如“编码器能读数”不能只是串口有输出，还要确认读数方向和实际转向一致，数值和实际转速在合理误差范围内。“图像稳定二值化”不能只看一帧，要看连续 10 秒内没有大面积抖动。

很多队伍的问题是验收标准太模糊，“差不多了”“看起来可以”变成了口头语。把标准量化之后，你才能知道今天是否有真正进展。

4.3 紧急情况下的砍需求原则

进度真的完蛋时，要忍痛砍功能。比赛成绩首先取决于“稳定完赛”，其次才是速度。

如果环岛一直处理不好，可以先保证普通赛道不冲出；如果加减速频繁导致震荡，可以先固定速度跑。砍需求不是放弃，而是把有限的调试时间放到收益最高的模块上。毕竟，一辆稳定跑完赛道的车，永远比一辆高速冲出赛道的车更有成绩。

5. 核心代码模块实现示例

5.1 串口调试日志

先跑通串口打印，所有中间量才能被看见。下面是一个简单的日志模块。

// 文件路径：Src/debug_log.c #include "debug_log.h" #include "stdio.h" static UART_HandleTypeDef *debug_uart; void Debug_Init(UART_HandleTypeDef *huart) { debug_uart = huart; } void Debug_PrintFloat(const char *tag, float value) { char buf[64]; int len = snprintf(buf, sizeof(buf), "[%s] %.2f\r\n", tag, value); HAL_UART_Transmit(debug_uart, (uint8_t *)buf, len, 100); }

// 文件路径：Inc/debug_log.h #ifndef DEBUG_LOG_H #define DEBUG_LOG_H #include "main.h" void Debug_Init(UART_HandleTypeDef *huart); void Debug_PrintFloat(const char *tag, float value); #endif

使用方式：在主函数初始化时调用Debug_Init(&huart1)，之后在定时中断或主循环中打印目标速度、实际速度、中线位置等中间量。

注意，snprintf在某些嵌入式编译器环境下可能较大，如果工程内存紧张，可以只打印整数，或者使用更轻量的格式化函数。调试代码始终应该用宏开关包起来，比赛提交前把日志等级调低，避免影响实时性。

5.2 编码器测速

速度闭环必须依赖编码器。下面是一个定时器编码器模式的简化写法，不同芯片 API 略有差异，以你手上板卡的示例工程为准。

// 文件路径：Src/encoder.c #include "encoder.h" void Encoder_Init(TIM_HandleTypeDef *htim) { HAL_TIM_Encoder_Start(htim, TIM_CHANNEL_ALL); } int32_t Encoder_GetCount(TIM_HandleTypeDef *htim) { int32_t count = (int32_t)__HAL_TIM_GET_COUNTER(htim); __HAL_TIM_SET_COUNTER(htim, 0); return count; }

说明：每次周期性读取后清零计数器，得到的就是一个周期内的脉冲增量。

速度换算公式为：速度 = 脉冲增量 / 编码器单圈脉冲数 / 采样周期 * 轮周长。单位建议统一到 mm/s 或 m/s，方便和图像中线等数据一起调试。

真正容易踩坑的地方是方向。编码器正转和反转，计数方向由 A、B 相接法决定。如果发现速度闭环后车越跑越快，先不要怀疑 PID，先检查编码器方向是不是反了。

5.3 PID 控制器

下面的位置式 PID 适合速度环、转向环的常见场景。

// 文件路径：Inc/pid.h #ifndef PID_H #define PID_H typedef struct { float kp; float ki; float kd; float target; float integral; float last_error; float out_max; } PidController; void PID_Init(PidController *pid, float kp, float ki, float kd, float out_max); float PID_Update(PidController *pid, float measured); #endif

// 文件路径：Src/pid.c #include "pid.h" void PID_Init(PidController *pid, float kp, float ki, float kd, float out_max) { pid->kp = kp; pid->ki = ki; pid->kd = kd; pid->out_max = out_max; pid->target = 0.0f; pid->integral = 0.0f; pid->last_error = 0.0f; } float PID_Update(PidController *pid, float measured) { float error = pid->target - measured; pid->integral += error; if (pid->integral > pid->out_max) pid->integral = pid->out_max; if (pid->integral < -pid->out_max) pid->integral = -pid->out_max; float derivative = error - pid->last_error; pid->last_error = error; float output = pid->kp * error + pid->ki * pid->integral + pid->kd * derivative; if (output > pid->out_max) output = pid->out_max; if (output < -pid->out_max) output = -pid->out_max; return output; }

使用示例：速度环每 10ms 调用一次，目标速度来自上层速度规划。转向环每 10ms 或 20ms 调用一次，目标值来自图像中线。

新手最容易犯的错误是微分项在设定值突变时产生冲击。如果目标速度从 0 直接跳到 2m/s，微分项会瞬间变大，表现为电机猛冲一下。更稳妥的做法是让目标值斜波变化，或者在误差变化率上做低通滤波。这个细节在提速阶段尤其重要。

5.4 摄像头二值化与中线提取

摄像头图像先做二值化，再用逐行扫描提取中线。下面是一个单帧处理的最小示例。

// 文件路径：Src/image_process.c #include "image_process.h" #define IMG_W 188 #define IMG_H 120 uint8_t gray[IMG_H][IMG_W]; uint8_t bin[IMG_H][IMG_W]; void Image_Binarize(uint8_t threshold) { for (int row = 0; row < IMG_H; row++) { for (int col = 0; col < IMG_W; col++) { bin[row][col] = (gray[row][col] > threshold) ? 0xFF : 0x00; } } } float Image_GetCenterLine(int row) { int left = -1; int right = -1; for (int col = 0; col < IMG_W; col++) { if (bin[row][col] == 0xFF) { left = col; break; } } for (int col = IMG_W - 1; col >= 0; col--) { if (bin[row][col] == 0xFF) { right = col; break; } } if (left < 0 || right < 0) { return -1.0f; // 丢线 } return (left + right) / 2.0f; }

说明：这里假设白色为赛道，黑色为背景。如果你的赛道恰好相反，把比较符号换过来即可。

固定阈值简单但容易受光照影响，进阶做法是使用大津法或自适应阈值。中线提取的后续还可以根据连续几行的中点做线性拟合，得到一个更平滑的期望转角。

每帧图像处理的时间要控制在 10ms 以内，否则控制周期会被拖慢。如果发现耗时过高，优先优化循环内部的浮点运算，比如把乘法改为查表，把 float 改为 int。

6. 运行结果与效果验证

6.1 串口输出验证

先把车架起来，让后轮悬空，通过串口观察。

• 编码器数值是否随车轮转动增加。
• 速度环目标值和实际值是否接近。
• PID 输出是否在合理区间震荡。

如果编码器数值不变化，检查编码器电源和 AB 相接线。如果变化但方向不对，交换 AB 相。如果实际速度一直追不上目标，先检查电机输出电压是否饱和，再检查 PID 参数。

6.2 虚拟示波器观察

使用 VOFA+ 或类似工具，把目标速度和实际速度同时画成曲线。正常情况是实际速度曲线平滑贴近目标值，没有持续的等幅震荡。

如果震荡频率很高，多半是微分项太大或控制周期不稳定。如果响应很慢，多半是比例项太小。

转向环可以打印“期望中线偏差”和“实际舵机 PWM 输出”。先确认偏差计算正确，再确认 PWM 方向正确。所谓“方向正确”是指偏差为正时舵机打向对应一侧，而不是一边修正一边加剧错误。

6.3 整车测试的验收标准

整车测试不能只看“能跑”这个结果，要看几个量化指标。

• 连续 5 圈内出赛道的次数是否降到 0。
• 高速入弯时是否出现明显点头或甩尾。
• 图像丢线后是否能快速恢复。
• 电量从满电到低压过程中，速度是否保持一致。

如果电量变化导致速度漂移，说明速度闭环没有真正生效，或者电机驱动已经进入低压保护区。这也是很多队伍在比赛下午突然“变慢”的常见原因。

6.4 失败时的排查顺序

整车跑飞时，按照“先传感器，再算法，再执行”的顺序排查。

第一步看图像或电磁值是否正常。第二步看中线或偏差计算是否正确。第三步看转向 PWM 是否输出正确。第四步看舵机机械结构是否有卡滞。

绝大多数“跑飞”都发生在传感器数据异常或者舵机中位偏移，而不是 PID 系数不够好。如果在这些基础项没确认之前就盲目调参，只会让问题更隐蔽。

7. 进度失控时的紧急排查清单

救援原则三句话：先跑通再优化；砍掉低收益功能；保留上一版能跑的配置。赛前一周不要大改机械结构，否则你会在“改动”和“适应”之间消耗掉最后的时间。

8. 工程化最佳实践与团队协作

8.1 用 Git 管理代码和参数

即使团队只有两个人，也要用 Git。

每次跑车前把代码状态提交一次，跑完后把现象记录到 commit message 里。参数文件单独存放，不要散落在各个源文件里。这样在赛场上临时调参，也能保证随时回到“上一版能跑”。

8.2 建立参数记录表

用表格记录每一组关键参数：日期、目标速度、PID 系数、摄像头阈值、赛道光照条件、现象、结论。

调参时一次只改一个变量。如果没有记录，你会反复调整同一组参数，浪费大量时间。很多队伍最后几天调不出来，不是因为工程能力差，而是因为同样的坑已经踩了三次。

8.3 软硬件接口约定

把软硬件之间的接口固定下来。比如电机 PWM 是低电平有效还是高电平有效，舵机中位对应的 PWM 占空比是多少，编码器方向约定是正向为 1 还是反向为 -1。

这些约定写在文档里，避免硬件换人后整个算法全部要重新标定。接口约定越早确认，后期联调越顺利。

8.4 电气与机械安全

电池供电的板子电压不低，接反很容易烧主控。建议在电源入口加防反接二极管和保险丝，主控板与电机驱动板分开供电。

机械上，轮胎悬空测试时一定要把车架固定好，防止高速转动时飞出。摄像头镜头要固定牢固，比赛前检查排线是否松动。细节问题在赛场上会被放大成致命故障。

8.5 赛前一周的收敛策略

赛前一周不是做大幅创新的时间，而是稳定收敛的时间。

每天只做一次整车测试，每次只改一个参数，跑完记录结果。把“能稳定完赛”的配置单独备份，命名为final_backup，再在这个基础上尝试小幅提速。如果提速失败，切回备份配置，不要犹豫。

9. 总结与下一步建议

智能车备赛进度紧张不是少数队伍的问题，而是竞争性项目里必然出现的压力。但进度压力能被管理，前提是把它拆成可以验收的里程碑、可观测的调试数据、可回退的版本配置。

先跑通链路，再稳定复现，最后逐步提速，是一条比“熬夜硬调”可靠得多的路径。如果你现在正处在“进度要完蛋”的状态，建议今天就把整车拆成感知、决策、执行三层，打印出每一层的中间数据，找出第一个断点。

先恢复串口日志，确认电机和传感器都正常，再谈提速和复杂元素。只要链路是通的，进度就还掌握在你们手里。等跑稳之后，可以继续深入图像自适应阈值、弯道前瞻、路径拟合、速度规划、惯性导航融合这些方向，把整车性能一步步推向极限