2025全国大学生电子设计大赛K题-自动避障小车-(全网行进速度最快)

【2025电赛K题开源】基于 K230 + STM32 的视觉导航自动避障小车

这是一辆为 2025 全国大学生电子设计竞赛 K 题设计的视觉导航避障小车。

它要完成的任务并不只是“能跑”，而是要在随机摆放黑白圆柱的九宫格场地中，自己看懂赛场、生成地图、选择路线，并稳定避障到达目标区域。

项目最终采用 K230 + STM32F407 双处理器架构：K230 负责视觉识别和路径决策，STM32 负责底盘控制和状态执行。视觉端使用 YOLO11 识别黑白柱，控制端使用编码器反馈和双闭环控制，让小车从“看得见”真正走到“走得准”。

项目已完整开源
GitCode：https://gitcode.com/Embodied-AI-Workshop/Auto_Hide_Car
演示视频：
BillBill：https://www.bilibili.com/video/BV17XTu65Esx/

---

1. 项目亮点

这个项目比较有意思的地方在于，它不是单独验证某个算法，而是把视觉、规划、通信、控制和整车联调都串成了一个闭环。

亮点	说明
K230端AI识别	使用 YOLO11 识别黑柱、白柱，减少光照变化对识别的影响
九宫格地图构建	根据检测框中心点聚类，自动生成赛场地图
Route路径模板	将路径规划简化为稳定路线选择，降低底盘执行难度
STM32双闭环控制	位置 PD + 速度 PI，让小车走得更稳
状态机异常恢复	增加超时、fallback 和恢复机制，避免整车联调时卡死

一句话概括：

K230负责看懂赛场，STM32负责把路线稳稳跑出来。

---

2. 项目效果

小车上电后的完整流程如下：

摄像头采集
  -> YOLO11识别黑白柱
  -> 生成九宫格地图
  -> 路径决策
  -> UART发送运动指令
  -> STM32执行双闭环控制
  -> 自主完成避障导航

赛题场地为固定 3x3 九宫格区域，黑白圆柱随机放置。小车需要自动识别柱子位置，建立地图，规划或选择通行路线，并避开障碍物行驶至目标区域。

---

3. 系统架构

项目采用双处理器架构：

模块	主要职责
K230	摄像头采集、YOLO11推理、目标坐标提取、九宫格地图生成、路径决策
STM32F407	UART接收、状态机调度、编码器采样、PD/PI控制、电机驱动

这样分工的核心原因很直接：视觉计算量大，底盘控制又特别吃实时性。如果把所有任务都压在一个处理器上，视觉推理一旦卡顿，控制周期就会抖，小车轨迹也会跟着飘。

所以我们把系统拆成两层：

• K230 做“上层感知和决策”；
• STM32 做“底层控制和执行”。

系统主流程：

摄像头
  -> YOLO11识别
  -> 目标中心点提取
  -> 九宫格地图生成
  -> 路径决策
  -> UART通信
  -> STM32状态机
  -> PD位置环
  -> PI速度环
  -> 电机驱动
  -> 编码器反馈
  -> 回到控制闭环

---

4. 硬件组成

模块	型号 / 说明
AI视觉处理器	K230
主控	STM32F407VET6
摄像头	OV5640
电机	四驱减速电机
编码器	霍尔编码器
电源	2S锂电池

为什么选择 K230

项目初期考虑过 OpenMV 和树莓派，但最终放弃：

• OpenMV 做颜色阈值识别时，对光照、阴影和反光非常敏感；
• 树莓派性能足够，但功耗、体积和现场部署成本更高；
• K230 自带 AI 加速能力，适合部署 YOLO 类目标检测模型。

所以视觉端最终选择 K230，将黑白柱识别问题从“调阈值”转为“目标检测”。

为什么选择 STM32

底盘控制最重要的是实时性。STM32 定时器、PWM、编码器接口和中断资源成熟，适合承担运动控制和状态执行任务。视觉结果由 K230 计算，STM32 只接收明确的运动指令并稳定执行。

---

5. 视觉识别与地图构建

从颜色识别到 YOLO11

最开始我们也走过很常见的路线：HSV 阈值分割、颜色检测、简单规则判断。实验室里看起来没问题，甚至还会给人一种“这题好像不难”的错觉。

但一换到真实场地，问题立刻出现：

• 光照变化会导致阈值失效；
• 阴影会让白柱和地面混在一起；
• 反光会带来误检；
• 遮挡和视角变化会让规则方法不稳定。

也就是说，颜色识别不是完全不能用，而是太依赖现场环境。为了让系统更稳，最终改用 YOLO11 目标检测方案，只训练两个类别：

black pillar
white pillar

识别流程：

摄像头采集 -> YOLO11推理 -> NMS去重 -> 输出检测框 -> 提取中心点 -> 生成九宫格地图

最大的问题：斜视摄像头

比赛中摄像头安装在小车前方，看到的是斜视图，而不是俯视图。

这是整个项目里最容易被低估的问题之一：YOLO 的检测框明明是对的，但九宫格地图还是会错。

原因在于，斜视画面存在透视关系。远处柱子的像素距离会被压缩，近处柱子的间距会被拉大。如果直接按 X 或 Y 坐标排序，就会把真实空间里的格子顺序排乱。

最终采用自适应聚类方法，根据目标中心点的空间分布自动分组，再生成九宫格状态。这个改动之后，识别结果才真正从“检测框正确”变成“地图正确”。

九宫格生成流程：

检测结果 -> 提取中心点 -> 自适应聚类 -> 行列映射 -> 九宫格地图

示例地图输出：

white black white
black white black
black black white

这部分是整个视觉系统中最关键的工程问题之一。目标检测解决的是“看见柱子”，九宫格映射解决的是“理解柱子在赛场中的真实位置”。

---

6. 路径决策方案

项目中尝试过两类路径方案：A* 路径规划和规则 Route 模板。

A* 路径规划

A* 的思路是将九宫格建模为图结构，把黑色柱子视为不可通行节点，通过启发式函数搜索从起点到终点的路径。

A* 搜索流程：

开始 -> Open表 -> 取最小F节点 -> 扩展相邻节点 -> 到达终点 -> 生成路径

A* 的优点是泛化能力强，理论上能处理更多障碍分布。但在实际小车系统里，算出路径只是第一步，底盘能不能稳定执行才是更现实的问题。

对于固定九宫格赛题，完全动态的路径输出会让控制端面对更多变化，调试成本也会增加。

规则 Route 模板

为了提高稳定性，后续方案将路径搜索问题简化为规则决策问题：K230 根据九宫格状态直接选择预定义路线，STM32 只负责执行对应轨迹。

这个思路听起来没有 A* 那么“通用”，但非常适合电赛：场地规则固定、目标明确、稳定优先。与其追求每次都算一条理论最优路径，不如把路线模板提前调稳，让小车每次都按熟悉的轨迹走。

对比项	A*路径规划	规则Route模板
决策方式	图搜索	规则映射
输出结果	动态路径	Route编号
实时性	中等	高
控制端执行	路径变化较多	轨迹固定、易调试
适用场景	障碍分布复杂	固定九宫格任务

Route 层最终保留四类路线：

Route	作用	典型场景
Route1	左绕路线	左侧通道优先
Route2	右绕路线	右侧通道优先
Route3	直行或轻微调整	前方通畅或轻度障碍
Route4	备用绕行路线	复杂或不确定场景

四条预定义路线如下：

核心判断区域是前方三格：

front = current_map[6:9]

常见规则示例：

[0, 0, 0] -> Route3
[1, 1, 1] -> 根据左右通道选择 Route1 / Route2 / Route4
[1, 0, 0]、[0, 1, 0]、[0, 0, 1] -> 结合左右列状态选择绕行或微调

规则 Route 模板的本质，是把“路径规划问题”降维为“有限规则决策 + 稳定轨迹执行”。对于电赛这种规则明确、场地固定的任务，这比追求通用最优路径更容易稳定落地。

---

7. STM32 运动控制

视觉和路径决策只能告诉小车“往哪里走”，真正决定比赛表现的是底盘能不能稳定、准确地走到目标位置。

这一部分也是从“能跑”到“能比赛”的关键。刚开始小车能动起来会很开心，但真正联调时才会发现：能动不代表能走准，能走准不代表每次都稳定。

实际调试中遇到的主要问题包括：

• 电机非线性；
• 地面摩擦变化；
• 编码器噪声；
• 转向惯性；
• 左右轮响应不一致。

这些问题会让理论路径和实际轨迹产生明显偏差。

第一版：单环 PID

最初方案是直接用位置误差控制 PWM：

目标位置 -> PID -> PWM -> 电机

这一版最大的优点是简单，小车确实能动起来；最大的问题也是简单，轨迹偏移严重，到点后容易抖动，无法稳定停车。问题在于位置误差被直接转换为电机输出，中间缺少速度约束，控制过于粗暴。

第二版：位置 PID

加入编码器位置反馈后，小车的位置控制有所改善，但仍然存在超调、回摆和 S 型修正问题。根本原因仍然是控制结构缺少速度层，位置误差一大，输出就容易过激。

第三版：位置 PD + 速度 PI 双闭环

最终稳定方案采用双闭环控制。它的思路是先由位置环算出“应该跑多快”，再由速度环把电机速度稳住：

目标位置
  -> 位置误差
  -> PD位置环输出目标速度
  -> 速度误差
  -> PI速度环输出PWM
  -> 电机执行
  -> 编码器反馈

双闭环控制流程：

目标位置
  -> PD位置环
  -> 目标速度
  -> PI速度环
  -> PWM输出
  -> 电机
  -> 编码器反馈
  -> 回到位置环和速度环

位置环负责“该往哪里走”，速度环负责“以什么速度稳定地走”。PD 位置环避免积分带来的位置振荡，PI 速度环用于消除电机速度稳态误差。这个结构比单环 PID 更容易调参，也更适合四驱小车的实际运动。

---

8. 关键踩坑总结

下面这些问题基本都是整车联调时一点点踩出来的。单看代码时不一定明显，但一上车跑，问题就会非常真实地表现出来。

问题	现象	根本原因	最终解决方案
颜色识别不稳定	光照变化后误检、漏检	HSV阈值强依赖环境	改用 YOLO11 目标检测
九宫格映射错位	检测框正确，但地图顺序错误	摄像头斜视导致坐标非线性	使用自适应聚类生成九宫格
转向严重过冲	左右来回摆动，难以对准	单环控制过激，未处理惯性	分阶段控制，降低过冲
积分项导致震荡	到点后持续抖动	积分累积和编码器噪声被放大	限幅积分、误差死区、必要时冻结积分
状态机偶发卡死	小车停止运动但无明显报错	状态切换条件不完整，异常无出口	增加超时、watchdog 和 fallback 状态

这些问题说明：机器人系统不是单个算法正确就能稳定运行。视觉、路径、通信、控制和状态机必须一起闭环，任何一个环节不稳定，最终都会体现在车辆行为上。

---

9. 开发过程复盘

项目整体经历了五个阶段：

阶段	目标	结果
颜色识别验证	快速让小车识别柱子	实验室可用，真实环境失败
引入 YOLO11	提高视觉鲁棒性	识别稳定性明显提升
地图构建 + A*	让小车自动找路	路径能算出，但执行不够稳定
Route模板 + 双闭环	提高运动稳定性	路线执行更可控
整车联调	解决通信、状态机和异常恢复	系统稳定完成任务

回头看，整个项目不是一次性设计出来的，而是被问题一步步推着改出来的。最重要的认识是：

算法正确 != 系统稳定

在真实小车上，能跑起来只是第一步。真正困难的是让系统在光照变化、摩擦变化、通信延迟和控制误差存在的情况下，仍然保持可恢复、可调试、可重复运行。

---

10. 开源资料

项目开源内容包括：

• K230 端源码；
• STM32 端源码；
• YOLO11 模型；
• 数据集；
• 原理图；
• 技术文档；
• 调试记录。

开源地址：

https://gitcode.com/Embodied-AI-Workshop/Auto_Hide_Car

---

11. 总结

这个项目把 AI 视觉、地图构建、路径决策、嵌入式控制和整车联调完整串在了一起。前期看起来只是“识别柱子并避障”，真正做起来才发现，它本质上是一套小型机器人系统。

最终方案可以概括为：

K230负责看懂赛场
STM32负责稳定执行
YOLO11解决识别鲁棒性
聚类映射解决九宫格定位
Route模板降低路径执行难度
双闭环控制保证底盘稳定

希望这份开源项目能给后续做电赛、智能车和机器人方向的同学一些参考，也欢迎交流和改进。