工创赛中国大学生工程实践与创新能力大赛里很多赛项最终拼的不是机械结构多花哨而是视觉识别稳不稳。物流小车要识别物料颜色机器人要判断目标方位飞行器要检测降落标识这些都离不开一块能实时采集画面、运行算法并输出控制信号的边缘计算板卡。K230 就是这样一类面向边缘视觉的 RISC-V 芯片近两年在大学生比赛中出现频率很高嘉立创等硬件渠道也能比较方便地获取相关开发板和元件库。本文围绕工创赛备赛场景梳理从认识 K230 到完成“采集画面-识别目标-串口输出”完整链路的实操方法适合第一次接触 K230、想在比赛中快速验证视觉方案的队伍参考。整个备赛过程其实可以拆成四个阶段先理解芯片和开发板的定位再搭好能运行代码的环境然后跑通图像采集和识别算法最后把识别结果通过串口或 GPIO 交给执行机构。只要这条链路在赛前反复跑过比赛现场的稳定性就会有明显提升。1. 先认识 K230它为什么能承担工创赛视觉任务1.1 从主控选型看 K230 的定位不少队伍在备赛初期会纠结主控选什么。传统 MCU 很擅长控制电机、读传感器、跑逻辑但遇到图像处理就吃力。树莓派能跑 Linux、能装各种视觉库却存在启动时间较长、功耗偏高、比赛现场供电要求高的问题。K230 给了一个折中思路芯片内部同时集成通用 RISC-V CPU 和用于神经网络加速的 KPU 单元开发板上又做好了摄像头接口、显示接口、串口和 GPIO相当于把“摄像头 算法盒子 控制板”压缩到了一块板卡上。从开发体验上看K230 支持两种常见路线。一种是运行官方 Linux 系统用 C/C 做完整应用开发适合最终要量产或需要深度优化的项目。另一种是使用 CanMV 这类 MicroPython 环境在命令行里直接 import 摄像头、显示屏、AI 模型等模块非常适合快速验证算法逻辑和比赛原型。工创赛备赛期间建议先用 Python 路线把视觉流程跑通再根据时间决定要不要把关键模块改成 C 版本。1.2 芯片、开发板与嘉立创生态这里需要区分两个概念K230 是一颗芯片而开发板是硬件厂商围绕芯片做出来的完整板卡。比赛现场使用的通常是开发板不是裸芯片。K230 开发板一般包含摄像头接口、LCD 或 HDMI 显示接口、USB、网口、串口以及若干 GPIO具体外设数量会因板卡厂商不同而略有差异。嘉立创在这个生态里主要扮演两个角色。第一在嘉立创商城等硬件渠道可以直接购买 K230 开发板、摄像头模组和外围扩展板省去自己画板的时间。第二在嘉立创 EDA 里可以检索 K230 相关元件库适用于自制底板、扩展板或比赛载体。这里要特别注意不同渠道提供的封装可能来自社区或第三方使用前必须对照 K230 数据手册核对引脚定义、焊盘尺寸和电气属性不能因为元件库里有就直接投板。1.3 学习环境与比赛现场的区别学习阶段可以只买一块开发板连接好 USB 串口线在桌面上反复烧录、调试、看日志。比赛现场环境则复杂很多电源可能不稳线缆可能被压到采集到的画面光照可能和实验室完全不同。建议在备赛时就把开发环境抽象成两层一层是“能跑的代码”另一层是“到现场也稳定的系统”。区分这两层的意义在于不要等到比赛前一周才考虑电源、固定、备份和异常恢复。比赛现场最宝贵的是时间提前把系统镜像、Python 脚本、模型文件、串口调试工具全部备份好并把启动流程设计成“上电自动运行主程序”能省下大量现场操作时间。2. 搭建开发环境从拿到开发板到跑通第一个程序2.1 硬件准备清单工创赛队伍在采购 K230 开发板时建议直接对照下面这张清单准备避免到货后发现缺线缺模块。硬件用途建议K230 开发板主控计算平台至少准备 2 块一块调试一块备用摄像头模组图像采集优先选板卡支持的 MIPI 摄像头显示屏本地实时预览支持 LCD 或 HDMI 的均可USB 转 TTL 串口线连接开发板终端确认驱动兼容 Windows 或 LinuxMicro SD 卡与读卡器存放系统镜像和脚本至少准备两张避免现场写坏稳压电源或充电宝现场供电输出电流要能覆盖开发板和摄像头峰值拿到硬件后先不要急着接线。对照开发板背面丝印和商家提供的引脚图确认串口位置、摄像头接口方向、电源输入范围。摄像头 FPC 排线尤其容易接反插入前观察金属触点方向插好后轻轻拉一下确认卡扣锁住。2.2 烧录镜像与连接串口开发板上电前需要先把系统镜像写入 Micro SD 卡。K230 的常见玩法是先用官方预编译镜像或 CanMV K230 镜像这类镜像一般会包含 Python 解释器和基础视觉库。烧录工具可以使用 balenaEtcher 或 win32diskimager选择 SD 卡对应设备盘符后写入。写完后 Windows 可能会提示“需要格式化”直接忽略不要点击格式化。镜像写好后将 SD 卡插入开发板连接串口线。串口接线规则是“收发交叉”开发板 TX 接串口线的 RX开发板 RX 接串口线的 TX两端 GND 必须相连。Windows 下打开设备管理器确认串口号然后使用 PuTTY 或 MobaXterm 建立串口会话波特率通常选择 115200不同镜像也可能要求 1500000以镜像文档为准。# Linux 下使用 minicom 连接串口-D 指定设备节点-b 指定波特率 sudo minicom -D /dev/ttyUSB0 -b 115200上电后终端应当滚动输出启动日志。看到登录提示符后先执行一条最简单的命令验证系统正常工作uname -a如果是 CanMV 镜像进入 MicroPython REPL 后执行print(hello k230)能打印出字符串说明系统、串口、SD 卡都正常环境搭建完成。2.3 远程传输代码的方式比赛现场不可能每改一次代码就拔一次 SD 卡。建议在开发板联网后使用 SSH 或 FTP 传输脚本。K230 开发板一般支持连接路由器或电脑热点先通过串口终端查看网络状态再用ifconfig或ip addr获取 IP。电脑与开发板处于同一局域网后就可以用浏览器、FileZilla 或 scp 上传.py文件和模型文件。# 电脑端上传 main.py 到开发板 /sdcard 目录 scp main.py k230user开发板IP:/sdcard/如果不想依赖网络也可以把脚本复制到 SD 卡的/sdcard目录通过串口终端里执行python main.py运行。无论用哪种方式都要保证脚本文件权限和编码正确建议统一使用 UTF-8 编码避免中文字符串在终端里乱码。3. 图像采集视觉任务的地基3.1 初始化摄像头并显示画面视觉任务的第一步不是跑算法而是确认摄像头能稳定输出图像。很多比赛队伍的代码最后没跑通问题并不在模型而是摄像头初始化失败或画面显示参数设置错误。下面这段代码以 CanMV K230 的 Python API 风格编写不同镜像的模块名和常量可能略有差异运行前先对照你手里的 SDK 示例。from media.sensor import Sensor from media.display import Display import time sensor Sensor() sensor.reset() sensor.set_framesize(640, 480) sensor.set_pixformat(0) # RGB565 sensor.run() Display.init(0) # 0 表示 LCD1 表示 HDMI按硬件选择 while True: img sensor.snapshot() if img is not None: Display.show_image(img)这段代码的逻辑是重置传感器设置分辨率和像素格式启动采集然后循环取帧并显示。需要解释的是set_pixformat(0)不同 SDK 中 0 的具体含义可能不同常见代表 RGB565。RGB565 的颜色信息足够用于颜色识别内存占用比 RGB888 小适合边缘设备。如果你手头没有屏幕可以改成保存图片文件用于离线观察画质和光照# 在循环外运行一次保存一帧画面 img sensor.snapshot() if img is not None: img.save(/sdcard/frame.jpg)在开发板终端里查看图片是否生成ls -lh /sdcard/frame.jpg3.2 图像参数的选择逻辑分辨率、帧率和像素格式不是越大越好而是要根据任务需要平衡。下面这张表总结了比赛场景中常见的参数选择逻辑参数数值偏低时数值偏高时比赛建议分辨率小目标可能看不清推理耗时增加内存压力大颜色识别用 320x240 足够目标检测用模型输入尺寸对应分辨率帧率小车运动时容易丢目标CPU 占用高发热明显一般 20 到 30 帧即可优先保证稳定像素格式颜色信息损失内存占用成倍增加颜色识别用 RGB565不需要灰度图时不要转灰度实际比赛中可以先在 640x480 下调试画面确认摄像头对焦和曝光再在算法阶段降到 320x240 提升帧率。不要盲目追求高分辨率视觉系统稳定运行比单帧画面漂亮更重要。3.3 图像采集阶段常见的三个坑第一个坑是摄像头打开后画面花屏或全黑。常见原因是 FPC 排线松动、方向接反或者是sensor.run()没有调用。第二个坑是程序运行到snapshot()卡死。这种情况多数是传感器初始化参数和摄像头硬件不匹配比如驱动型号选错。第三个坑是保存图片后发现曝光特别亮或特别暗。K230 摄像头通常支持自动曝光但比赛现场光线复杂可以尝试在初始化后设置曝光区域或白平衡参数具体 API 名称以 SDK 文档为准。注意不要只验证程序能启动还要验证每一帧图像内容是否符合预期。画面显示出来不等于图像质量合格要检查是否存在花屏、偏色、过曝和运动模糊。4. 实现两个比赛常用视觉功能4.1 颜色识别适合物流分拣与循迹颜色识别是工创赛里最常用的视觉功能。它的原理不复杂把图像从 RGB 空间转换到更便于区分颜色的 LAB 或 HSV 空间然后根据目标颜色的阈值范围筛选像素最后用连通域分析定位目标区域。下面以阈值筛选加矩形框显示为例from media.sensor import Sensor from media.display import Display sensor Sensor() sensor.reset() sensor.set_framesize(320, 240) sensor.set_pixformat(0) sensor.run() # 红色阈值实际数值需在目标光照下标定 red_threshold (30, 100, 15, 127, 15, 127) while True: img sensor.snapshot() blobs img.find_blobs([red_threshold]) for b in blobs: img.draw_rectangle(b.x(), b.y(), b.w(), b.h(), color(255, 0, 0)) img.draw_string(b.x(), b.y(), str(b.pixels()), color(255, 0, 0)) Display.show_image(img)阈值六元组在不同库里的含义可能不同常见顺序是(L_min, L_max, A_min, A_max, B_min, B_max)或(H_min, H_max, S_min, S_max, V_min, V_max)。不要盲目抄网上阈值而要在比赛实际光照下用上位机工具或调试脚本多次采集目标颜色再手动标定范围。判断目标是否有效时不能只看有没有找到色块还要加过滤条件。常用过滤条件包括像素数量pixels()、面积area()、宽高比w/h和中心位置。如果筛选条件太少环境里的反光、阴影、同色杂物都会被误判为有效目标。4.2 目标检测加载模型识别物体类别颜色识别能解决“颜色明显、背景简单”的任务但遇到“识别不同物体、需要区分类别”的场景就需要目标检测模型。K230 的 KPU 可以运行 YOLO 系列等常见检测网络模型文件通常经过转换得到.kmodel后缀。模型在比赛中的使用流程是先在电脑上准备或训练模型转换为 K230 可执行的 kmodel 文件再把模型放到 SD 卡在开发板代码中加载并执行推理。下面代码只展示流程不保证在所有 SDK 中直接可运行你需要结合官方 demo 调整 APIfrom media.sensor import Sensor from media.display import Display from app_ai import App_AI # 部分 SDK 封装的 AI 推理类名称以官方为准 sensor Sensor() sensor.reset() sensor.set_framesize(320, 240) sensor.set_pixformat(0) sensor.run() ai App_AI() ai.init_ai(yolov8n.kmodel) while True: img sensor.snapshot() results ai.run(img) for obj in results: img.draw_rectangle(obj.x, obj.y, obj.w, obj.h, color(0, 255, 0)) img.draw_string(obj.x, obj.y, obj.cls_name(), color(0, 255, 0)) Display.show_image(img)目标检测的关键点有两个。第一输入图像尺寸要和模型训练时的输入尺寸一致通常模型内部会做缩放但你可以通过设置set_framesize控制采集分辨率尽量接近模型输入尺寸减少缩放带来的精度损失。第二推理结果需要做置信度过滤和交并比处理很多 SDK 已经封装好了但如果你直接使用底层接口就要自己写非极大值抑制否则同一个目标会出现多个重叠框。4.3 什么时候该用哪种方案方案优点局限适用比赛场景颜色识别无需训练、调试直观、帧率高对光照敏感、无法区分同色不同类红色物料分拣、黑色循迹、色块定位目标检测能区分类别、环境适应性强需要准备数据集、转换模型、推理耗时更高识别工具、工件、障碍物、指定动作在备赛初期建议先用颜色识别跑通整条链路确认机械和控制逻辑正常再决定是否引入目标检测。如果赛题明确要求识别多类物体那就必须提前三周开始准备数据集因为模型训练和调参会占用大量时间。5. 把识别结果变成动作串口协议与 GPIO5.1 设计最小串口协议视觉识别完成后K230 通常只负责“看”和“判断”真正的底盘运动由另一块控制板负责。两块板之间最稳定的通信方式就是串口。串口通信的关键不是能不能收发字节而是收发双方是否对协议有一致理解。一个容易实现的协议是文本行协议例如T120,80,4500含义可以约定为字母 T 表示目标位置命令120是目标中心 x 坐标80是目标中心 y 坐标4500是目标面积。每条命令以换行符\n结尾接收端按行解析。K230 发送端代码示例import time from machine import UART uart UART(0, baudrate115200, bits8, parityNone, stop1) while True: img sensor.snapshot() blobs img.find_blobs([red_threshold]) if blobs: b max(blobs, keylambda x: x.pixels()) msg fT{b.cx()},{b.cy()},{b.w()*b.h()}\n uart.write(msg) time.sleep_ms(20)接收端下位机把收到的字符串按逗号切分就能得到目标位置信息。这种协议的优点是调试方便在串口助手里可以直接读出来不需要十六进制转换。缺点是有效信息密度偏低但对工创赛控制来说完全够用。如果担心数据在传输过程中出错可以在这条协议基础上增加简单的校验字段例如把 x、y、面积三个值按位异或后取低 8 位作为校验字节追加在行尾。下位机解析时先算校验不匹配就丢弃这帧数据避免错误坐标导致小车误动作。5.2 用 GPIO 直接输出开关量串口适合传数据但有些任务只需要一个开关信号比如识别到物料后触发继电器推杆或者让蜂鸣器鸣叫。这种情况下直接用 GPIO 更简洁from machine import Pin import time out_pin Pin(24, Pin.OUT) # 识别到目标时拉高电平 out_pin.value(1) time.sleep_ms(200) out_pin.value(0)使用 GPIO 前必须确认开发板引脚的电气特性。GPIO 输出电平一般不能直接驱动电机和电磁阀需要经过三极管、MOS 管或继电器隔离。直接驱动大电流负载轻则导致电压跌落重则烧毁板卡。比赛现场如果发现 K230 经常重启先检查 GPIO 是否带了不该带的负载。5.3 K230 与控制板的分工架构工创赛项目建议采用“K230 视觉板 STM32 控制板”的双板架构。K230 专注图像采集、算法推理和结果发送STM32 专注电机控制、编码器读取和运动规划。这样做的原因是职责清晰视觉算法迭代不会影响底盘逻辑底盘调试也不需要反复跑视觉代码。双板通信可以使用串口、CAN 或 USB具体由控制板支持情况决定。采用串口时要约定波特率、数据位、停止位和协议格式建议把协议定义单独放在一个头文件或常量文件中两端各保留一份修改时必须同步。注意不要直接让 K230 的 GPIO 长时间驱动舵机。舵机启动电流较大容易拉低系统电压。正确做法是外接舵机驱动板或单独供电K230 只输出 PWM 控制信号。6. 比赛现场最容易踩的坑按链路排查6.1 故障现象与原因速查表问题现象常见原因检查方式处理建议上电后串口无输出镜像未烧录成功、卡槽接触不良、波特率不对重新插拔 SD 卡确认开发板指示灯重新烧录镜像换一张 SD 卡测试摄像头打开失败FPC 排线接反、传感器驱动型号不对观察摄像头是否有输出检查日志报错断电重插排线核对驱动配置画面花屏或条纹排线松动、电磁干扰、供电不足重新固定排线更换 USB 供电使用独立稳压电源缩短排线长度颜色阈值找不到目标光照变化、曝光过强、背景反光保存现场图片检查画面在比赛现场重新标定阈值AI 推理卡顿模型输入尺寸过大、分辨率太高、未释放内存观察帧率和 CPU 占用降低采集分辨率使用更小模型串口无数据波特率不一致、TX/RX 接反、代码未执行到发送逻辑用串口助手监听打印调试信息重新确认接线加日志输出自动重启供电电流不足、GPIO 负载过大检查电流表和负载接线更换电源给执行机构单独供电6.2 排查顺序建议比赛现场时间紧张不要一上来就怀疑代码逻辑。按下面顺序排查效率最高检查电源指示灯和电压电流确认开发板供电稳定。检查串口连接和设备管理器确认终端能正常输入输出。检查 SD 卡和文件路径确认主程序和模型文件确实存在并且路径正确。检查摄像头画面确认图像内容和预期一致。检查日志输出定位异常发生在初始化阶段还是循环阶段。最后才怀疑算法参数和模型精度因为算法问题通常不会导致程序崩溃。6.3 三个容易被忽略的细节第一个细节是 FPC 排线。比赛现场震动频繁摄像头排线如果只用卡扣没有做固定很容易在搬运中出现接触不良。推荐用少量热熔胶或电工胶带把排线根部固定在开发板支架上。第二个细节是光照标定。实验室用的荧光灯和比赛场馆的LED灯光谱完全不同颜色阈值在实验室调得再好到赛场也可能失效。建议到现场后先跑一个“阈值标定模式”通过上位机或开发板屏幕实时显示当前画面的颜色分布微调阈值。第三个细节是 SD 卡可靠性。比赛现场突然断电可能导致 SD 卡文件系统损坏。除了使用质量可靠的品牌卡还要在赛前把主程序和模型文件在电脑上备份并准备一张已经写好镜像和程序、验证能启动的备用 SD 卡。7. 工程化与备赛建议从“能跑”到“稳定”7.1 赛前检查清单下面这张清单可以在出发去赛场前逐项确认避免到现场才发现缺东西开发板 2 块摄像头 2 个显示屏 1 个串口线 2 根。已烧录并验证可启动的 SD 卡 2 张备用空白卡 1 张。主程序、模型文件、阈值配置在电脑和 SD 卡里各保存一份。K230 电源、充电宝、各类转接头和电池组确认电量充足。串口助手、烧录工具、驱动安装包已经放到手机上或离线文件夹。摄像头排线、GPIO 线、串口线全部做标记便于现场快速接线。现场光照标定流程已经提前演练知道在哪个菜单启动标定程序。7.2 代码分层与配置外置比赛代码不要全部堆在一个main.py里。建议把代码拆成采集、算法、通信、控制四个模块让每部分只负责一件事。一个推荐的目录结构是project/ main.py config.py modules/ sensor_manager.py vision.py uart_sender.py models/ yolov8n.kmodelconfig.py用来集中保存串口波特率、分辨率、颜色阈值、模型路径等配置。这样到了比赛现场需要改阈值或 IP 时只需要改动一个文件不需要在几十个函数里搜索魔法数字。# config.py 示例 FRAME_SIZE (320, 240) BAUDRATE 115200 RED_THRESHOLD (30, 100, 15, 127, 15, 127) MODEL_PATH /sdcard/models/yolov8n.kmodel7.3 性能与稳定性优化性能优化的目标不是把帧率提到最高而是保证在需要做出判断的时刻视觉结果仍然可靠。常用优化手段包括适当降低采集分辨率使用与模型输入更接近的尺寸减少缩放损耗。在循环末尾增加sleep避免 CPU 长时间满负荷运行导致过热。对长时间识别不到目标的场景做超时处理比如连续 50 帧无结果时发送应急停车指令。在串口发送前判断通信状态避免缓冲区堆积导致程序卡死。增加日志轮转把运行日志写到 SD 卡时限制单个文件大小防止长时间运行耗尽存储空间。如果开发板支持看门狗可以在主循环里定期喂狗。这样当视觉算法异常阻塞时系统会自动重启而不是在赛场上静默失效。看门狗的超时时间要大于单次最慢推理时间通常设置为 3 到 5 秒。注意比赛现场的稳定性不是靠临场调参而是靠把异常分支提前写进代码。每个“如果识别不到”“如果串口断线”“如果模型加载失败”的分支都应该有明确的默认行为比如停车、重新初始化或恢复默认阈值。7.4 下一步扩展方向当“采集-识别-串口输出”最小链路稳定后可以根据赛题难度往四个方向扩展。第一是模型自训练采集赛题实际物体图像标注后训练专用 YOLO 模型提升复杂场景下的识别精度。第二是多目标跟踪在逐帧检测结果上加入位置预测提高小车运动过程中的召回率。第三是图像远程监控把 K230 的画面通过 RTSP 推流到上位机方便评委现场观看或队伍远程调试。第四是自制底板利用嘉立创 EDA 绘制 K230 最小系统底板把摄像头、串口、GPIO 按比赛需要整合到一块小板上降低整体体积和故障点。工创赛里的视觉任务看起来复杂但只要把链路拆成“采集、算法、通信、执行”四步每步设置明确的验收标准就会发现实现起来并不难。建议队伍从一块 K230 开发板和一个摄像头开始先跑通画面显示再做颜色识别最后接上串口控制底盘。每一步都确认稳定后再叠加模型和更复杂的决策逻辑。比赛最终拼的不是用了多强的模型而是整套系统在赛场环境下能不能稳定复现。