简介全国大学生电子设计竞赛智能送药小车项目的K210数字识别模型及配套代码适合参赛学生和嵌入式AI开发者。压缩包共8个文件包含Python脚本boot.py、boot2.py、txt说明文件README.txt、labels.txt等、jpg图片report.jpg、startup.jpg以及kmodel神经网络模型m.kmodel总大小仅1.59MB。已有1173人学习下载。其中kmodel文件为K210可运行的神经网络模型配合脚本可实现数字识别boot.py、boot2.py等代码可帮助理解系统启动与识别流程jpg图片则提供接线示意图或运行效果参考。通过学习和二次开发读者能快速上手K210的模型部署掌握将数字识别技术融入送药小车、实现药品编号识别与自动配送的完整思路为赛题冲刺和实际项目落地打下基础。 电赛备赛那阵子我们团队在“智能送药小车”这道题上卡了最久的就是视觉识别。明明小车底盘、电机驱动、灰度循迹都能跑通了可只要识别病房数字这一环掉链子整个任务评分直接崩盘。后来换了K210方案才真正把“看得见、认得准”这件事稳定下来。K210这块芯片在电赛圈子里已经被用到烂熟双核RISC-V处理器自带KPU神经网络加速单元跑轻量级数字识别模型非常顺配上摄像头模块和MaixPy固件从模型训练到板上推理几天光景就能出活。这篇文章就把我从数据采集、模型训练、烧录部署到K210与STM32串口通信、再到整车联调的完整链路掰开揉碎讲清楚不光是贴代码每一步为什么这么做、有哪些坑全部写在下面给正在备赛的队伍一条能直接复现的路。1. 电赛送药小车任务拆解视觉部分到底在解决什么问题1.1 从评分规则倒推视觉需求送药小车这类赛题场上要跑的动作拆开看无非是小车从药房出发沿着地面引导线走走到病房门口停住把药放下再返回。关键评分点多半落在“能不能准确停在指定病房”上而病房的区分标识最常见的就是门口贴的编号数字。也就是说视觉系统的首要任务不是炫技而是把“房门口那个数字是多少、它在画面里什么位置”这两个信息稳定地交给主控。很多队伍一开始把视觉想象得很复杂又是测距又是建图实际上赛题对视野和精度的要求相对集中识别范围大概就是小车正前方几米内的门牌区域数字大小从几厘米到十几厘米不等光线条件因场地而异。把需求拆到这一步你就知道视觉模块需要输出什么了一是目标数字的类别编号比如0到9二是目标在画面中的位置坐标这样主控才能根据偏移量来调整车身姿态保证最后停车时车头正对病房门。如果识别模型只给结果不给位置后面做闭环控制会非常难受。这也是为什么我建议在视觉端直接做目标检测而不是只做个分类器来回传“我看到数字几了”。目标检测输出的边界框中心点坐标配合画面中心参考线就能算出一个横向偏移量告诉STM32该左转还是右转。这个偏移量在整车调试里比单纯一个数字值有用得多后面我会详细展开。1.2 为什么选择K210而不是OpenMV或树莓派备赛选型时大家通常纠结三个方向OpenMV、树莓派、K210。我直接说结论电赛送药小车场景下K210是性价比和稳定性最平衡的选择。OpenMV优点是好上手MicroPython语法很多教程但它的算力应对简单的色块识别还行真要跑数字检测模型帧率会掉到让人崩溃。而且OpenMV的MCU主频不高图像分辨率一大就吃力视觉识别和串口通信同时跑时经常出现CPU占用过高导致的时序抖动。树莓派算力强模型能随便跑但它的问题在电赛里很致命启动时间长、体积大、供电要求高、受静电和反接影响容易莫名重启。比赛现场是不可能给你时间等树莓派慢慢开机的很多队伍在树莓派冷启动上吃过亏。K210刚好卡在中间算力够用内置KPU硬件加速器跑一个经过量化压缩的YOLO模型实测帧率能到20到30帧这在电动车场景下完全够用启动速度快上电即用支持MicroPythonMaixPy开发效率不低裸板价格便宜烧坏了换一块不心疼。更关键的是K210的GPIO和UART、I2C接口齐全和STM32通信非常直接不需要额外的协议转换芯片。1.3 系统分工K210看STM32跑在整车架构上我的建议是让K210专注于视觉感知STM32负责运动控制和逻辑调度。这样分工清晰排查问题也方便。K210端要做的事上电初始化摄像头加载训练好的数字识别kmodel持续取帧推理把识别到的数字类别、目标框中心x坐标、目标框宽度、置信度通过串口周期性地发给STM32。STM32端要做的事接收K210的数据解析出数字和偏移量结合灰度循迹传感器的状态决定直行、转向还是停车控制电机转速和方向。这个架构能跑得稳有个隐形前提K210和STM32之间的通信协议必须定义得足够简单可靠。很多队伍栽在通信上K210发得高兴STM32收得一脸懵数据错位、丢帧、校验失败都是家常便饭。协议的设计我在第4章专门讲。2. K210数字识别模型训练与部署数据决定了识别的上限2.1 数据采集与标注别偷懒背景越杂越好很多人以为K210上跑数字识别是“模型一发就能用”其实最花时间的往往不是调模型而是准备数据。我们在备赛初期直接用网络上现成的手写数字数据集训练结果一到比赛场地上识别率惨不忍睹。原因很简单门牌数字不是MNIST里那种规整的印刷体它可能是打印体、亚克力雕刻、胶带贴的数字周围有门框、墙面纹理、光线阴影背景杂乱程度远超普通数据集。正确的做法是自己搭一个数据采集流程。把摄像头装在车模上推着车在不同距离、不同角度下拍摄印好的数字门牌模拟比赛中会出现的各种视角。建议每类数字至少拍200到300张把顺光、逆光、侧光、远一点、近一点、稍微歪斜的情况都覆盖到。拍完以后统一缩放到训练输入尺寸再用labelImg这类工具标注存成YOLO格式的txt文件。如果实在时间不够可以用翻转、亮度调整、随机裁剪做数据增强把有限的样本扩到三到五倍。记住背景越杂、样本越多样模型在赛场上的泛化能力就越强。标注的时候还有个细节容易忽略数字框尽量紧贴数字边缘不要留太多白边也不要切掉笔画。白边太多会让模型学到过多背景特征切掉笔画则会干扰数字形状的学习。我见过有队伍因为标注框太随意训练出来的模型把门框的竖向边缘当成数字1的一部分到赛场上狂出错。2.2 模型选型与训练分类器还是目标检测在K210上做数字识别有两种常见技术路线一种是用MobileNet之类的轻量分类网络先通过二值化或颜色提取找到数字区域裁剪出来再分类另一种是直接用YOLO目标检测一步到位输出数字框和类别。我强烈推荐后者。原因在于分类器依赖前一阶段能稳定地把数字区域从复杂背景里抠出来这个“抠”的过程在赛场光照变化下非常脆弱画质稍微一变裁剪区域就歪了。目标检测模型直接把“在哪里”和“是什么”一起解决场景的鲁棒性要好得多。K210的KPU跑YOLO系列轻量模型完全可行我们用的是YOLOv5n结构经过int8量化后模型体积大概2MB左右单帧推理时间在30到50毫秒完全在可接受范围内。训练时候内存充足且时间允许的话可以用Ultralytics YOLOv8在本地训练导出ONNX再转成K210能加载的格式。但比赛节奏紧的话直接在MaixHub上在线训练更省心上传标注好的数据集选YOLOv5轻量模型训练完成后平台直接给kmodel下载链接。无论哪条路训练时有个共同要点类别数就设10个数字0到9不要额外加类别减少模型负担提升精度。2.3 模型转换与烧录kmodel才是K210看得懂的格式K210芯片不能直接加载你在训练平台里用的torch或tflite模型它只认经过NNCase工具链转换出来的kmodel格式。这个转换步骤看起来不起眼实际翻车率极高。本地训练的话流程是先用Ultralytics导出tflite或ONNX权重再用K210官方的NNCase工具做量化转换指定输入尺寸、量化方式最终输出.kmodel文件。转换时最容易踩的坑是输入尺寸不一致。训练时你用的是640x640或320x320转换时如果输入尺寸写错推理阶段图像resize的宽高比就会对不上模型实际看到的画面是变形拉伸的识别率直线下降。建议统一用320x320兼顾精度和K210推理速度。烧录方面K210有两种承载方式一是把kmodel烧写到Flash里二是放在SD卡上。我建议优先放在SD卡因为比赛中需要频繁换模型测试从SD卡加载模型只要换文件就行不需要每次刷Flash。固件方面MaixPy固件版本要和模型转换工具版本匹配不然可能出现K210报错“load error”或者推理结果乱跳。烧录可以用kflash_gui这个工具选对串口、波特率、固件文件写入后复位即可。3. K210端识别代码拆解从图像到串口的一整条链路3.1 初始化摄像头并加载模型K210跑MaixPy代码风格和MicroPython基本一致熟悉OpenMV的队友上手会非常快。第一步是初始化外设、摄像头和KPU。import sensor, image, lcd, time from machine import UART from fpioa_manager import fm lcd.init() sensor.reset() sensor.set_pixformat(sensor.RGB565) sensor.set_framesize(sensor.QVGA) sensor.set_vflip(1) sensor.set_hmirror(1) sensor.run(1) import KPU as kpu task kpu.load(/sd/num_detect.kmodel) kpu.init_yolo2(task, 0.3, 0.3, 5, 3)注意set_vflip和set_hmirror这两个函数很多人刚上手会漏掉。摄像头安装角度不同画面可能是上下颠倒或者左右镜像的如果不做翻转模型输入到KPU里的图像方向就是错的。翻转方式根据你的摄像头固定方向决定调试的时候先在屏幕上画个箭头确认方向再接模型推理。3.2 推理主循环与结果解析初始化完成后就是主循环取帧、跑模型、解析检测结果、通过串口发出去。核心代码逻辑如下fm.register(10, fm.fpioa.UART1_TX, forceTrue) fm.register(11, fm.fpioa.UART1_RX, forceTrue) uart UART(UART.UART1, 115200, 8, None, 0, read_buf_len256) def send_result(detect_num, center_x, box_w, confidence): data bytearray([0xAA, 0x55, detect_num 0xFF, center_x 8, center_x 0xFF, box_w 8, box_w 0xFF, int(confidence * 100)]) checksum 0 for b in data: checksum b data.append(checksum 0xFF) uart.write(data) while True: img sensor.snapshot() objects kpu.run_yolo2(task, img) if objects: best None best_score 0 for obj in objects: if obj.value() best_score: best_score obj.value() best obj if best: x best.x() y best.y() w best.w() h best.h() cls_id best.classid() cx x w // 2 send_result(cls_id, cx, w, best_score) lcd.display(img)这段代码里有几个关键决策。第一多个检测框出现时取置信度最高的那个。场景里可能同时出现两个数字框尤其是门牌号可能是两位数我们只取最明显的那个作为主目标避免STM32执行逻辑混乱。第二发送框中心坐标而不发送左上角坐标因为后续转向控制更关心目标相对画面中心的偏移。第三坐标拆成高字节和低字节发送因为串口一帧数据最多发一个字节数值大于255就必须拆分接收端再拼回去。3.3 提高识别稳定性的几个代码技巧模型推理跑通以后接下来就是扣稳定性。有三个代码层面的优化我非常推荐。第一个是限制ROI区域。摄像头装在小车前方真正有用的画面往往是画面中下部分上半部分通常是天花板或者远处环境既浪费算力又容易带进干扰。可以在sensor.snapshot()之后、模型推理之前用image.crop或者直接设置窗口把有效识别区缩小到中下部比如取0到240行的下半段。ROI缩小后模型输入图像里的门牌面积占比变大识别率会有明显提升。第二个是延时锁存策略。比赛中小车是运动的画面里数字会出现、消失、再出现。如果每一帧都把识别结果发给STM32会出现数字来回跳变STM32一会儿觉得看到了3一会儿觉得看到了5控制逻辑直接乱掉。我在实际项目里加了一个简单的状态锁存连续5帧识别到同一个数字才认为结果有效并发送如果识别不到数字连续10帧以后才发送一个无效帧告诉STM32“视觉丢了”避免瞬时抖动干扰。第三个是跳帧推理。K210的KPU推理虽然快但每帧都推理对画面流畅度和功耗都有压力。如果只是做门牌识别不需要每一帧都跑模型可以采用每次取帧后先显示再每两帧跑一次推理的方式实际效果几乎不受影响但系统整体流畅度好了很多。4. K210与STM32的通信协议让识别结果驱动车轮4.1 为什么用UART而不是I2CK210和STM32通信有人用I2C有人用UART我排除了I2C原因很实在I2C主机从机通讯需要处理时钟同步、应答信号、总线仲裁K210的MicroPython里用I2C从机模式调试起来非常费劲尤其比赛现场没有太多时间让你慢慢抠时序。UART串口是全双工一根TX一根RX加一根共地就完事逻辑简单出错容易排查。接线方面只需要把K210的UART1_TX接到STM32的某一个串口RXK210的UART1_RX接到STM32的TX两边GND一定要连在一起否则信号没有参考电平会出现随机乱码。选引脚时要查K210的fpioa功能映射表MaixPy允许把任意GPIO绑定到UART功能我习惯用IO10和IO11代码里fm.register就干的这件事。STM32端选一个空闲的USART比如USART2配置成115200 8N1。4.2 帧协议设计不能裸发数据很多新手直接把一个整数用uart.write发过去STM32收到就解析这样短距离测试可能会通但在电机转起来以后必炸。原因有二第一电机产生的电磁干扰会污染串口信号单字节数据错位后没法纠正第二如果数据有多帧结构接收端不知道一帧从哪里开始到哪里结束解析完全靠猜。我设计了一个非常轻量的帧协议实际项目里跑了很久都没出过问题帧头0xAA 0x55两个字节用于接收端识别帧起始。有效数据区数字类别1字节、中心坐标x高字节1字节、中心坐标x低字节1字节、框宽高字节1字节、框宽低字节1字节、置信度百分比1字节。校验和前面所有字节相加后取低8位放在帧尾。接收端用状态机判断等第一个0xAA再等第二个0x55都匹配才开始接收数据区收满固定长度后计算校验和比对通过才认为这一帧有效。加上帧头和对齐校验的好处是就算串口中间丢一个字节下一帧也能通过重新寻帧头恢复同步系统不会彻底卡死。4.3 STM32端中断接收与状态机解析STM32端的代码建议用串口空闲中断加定时器超时处理或者更简单的方式串口接收中断里把每个字节塞进一个环形缓冲区主循环里跑状态机解析。下面是一个通用解析框架uint8_t rx_buffer[16]; uint8_t rx_index 0; uint8_t expect_len 8; uint8_t state 0; void ParseByte(uint8_t b) { switch (state) { case 0: if (b 0xAA) state 1; break; case 1: if (b 0x55) state 2; else state 0; break; case 2: rx_buffer[0] b; rx_index 1; state 3; break; case 3: rx_buffer[rx_index] b; if (rx_index expect_len) { uint8_t sum 0; for (int i 0; i expect_len - 1; i) sum rx_buffer[i]; if (sum rx_buffer[expect_len - 1]) { // 数据有效取 rx_buffer[0] 为数字1~2 为中心坐标3~4 为框宽 HandleVisionResult(rx_buffer[0], ((uint16_t)rx_buffer[1] 8) | rx_buffer[2], ((uint16_t)rx_buffer[3] 8) | rx_buffer[4]); } state 0; } break; } }解析出来以后在HandleVisionResult里STM32就能拿到识别到的数字类别、目标在画面中的中心x坐标、目标框宽度。有了这三个量运动控制逻辑就可以做很多事情了。5. 识别与控制的联动从“看到数字”到“停在病房”5.1 目标坐标偏移量的价值光识别到数字还不够K210传给STM32的目标中心坐标x是让小车对准病房门的关键。假设画面分辨率是320x240画面中心x坐标就是160。如果识别到目标的中心x是180说明目标目前偏右小车需要右转一点让目标回到画面中央如果目标中心x是120说明目标偏左小车需要左转修正。实际控制里我建议把偏移量归一化用(center_x - 160) / 160得到一个从-1到1的偏差值再乘一个比例系数作为转向舵机或者差速轮的速度补偿。这个P控制器看起来简单在电赛场景里比复杂的PID更实用因为目标距离近、速度慢只要方向修正连续车身姿态就不会有大幅震荡。5.2 到站判定逻辑很多队伍有个误区识别到目标数字就立刻刹车。但小车在运动中摄像头视野里第一次出现正确数字时车辆离病房可能还有几十厘米远直接刹车停在半路距离不达标。正确的做法是设定一个“识别确认窗口”当连续若干帧都识别到正确数字且识别框宽度w逐渐增大到一定阈值时才认为小车已经接近门口触发停车减速。这个思路的本质是用目标框宽度作为距离的代理值。假设模型在距离病房30厘米时识别框宽度可能超过150像素而刚看到数字时可能只有50像素。所以代码里可以这么写识别到目标数字正确同时box_w大于某个阈值比如120同时小车还在直行状态才执行停车动作。具体的阈值需要在实际场地里标定不同摄像头高度和视角下差异挺大不要照搬别人的数值一定现场测。5.3 多病房场景的决策流程当比赛要求小车在多个病房之间选择时视觉和控制的联动就要带上状态机。我的建议是STM32维护一个任务状态状态A从药房出发循迹直行等待K210上报数字。状态BK210上报数字与目标数字不匹配继续直行或切换到下一分支路线。状态CK210上报数字与目标数字匹配按照偏移量修正车身方向向门口靠拢。状态D目标框宽度达到阈值执行停车、放下药品倒车或掉头返回。这里要注意K210上报的数字可能会有瞬时误判不能一收到匹配数字就立刻从循迹状态切换到进病房状态必须连续确认几帧。我在前面代码里加的连续5帧锁存就在这里起到关键作用。另外如果目标是识别的数字超过1位比如病房号是12建议处理策略是只识别个位数字或者分时识别两个数字这取决于赛题的具体要求。最简单的做法是把门牌号设计成单个数字或者让K210同时输出两个框主控用两个框的相对位置关系决定读作“12”还是“21”但这个逻辑需要提前测试别等到比赛现场才临时加。6. 实测翻车记录与调试经验6.1 光线和反光带来的误识别比赛场地为了拍视频灯光通常很亮地面和门牌表面容易反光。有一次模拟测试模型把数字7认成了1找了半天原因发现是门牌表面有一道斜向反光刚好把7的横笔画遮住了。解决办法有三个层次一是采集数据时专门加一组带反光、高光的样本让模型自己学会忽略这种干扰二是调整摄像头曝光参数减少过曝区域三是在最终部署时选择哑光材质打印门牌而不是镜面亚克力。后两个治标第一个治本。另外如果赛题允许自己贴门牌强烈建议用大号黑体或等线体数字笔画粗、间距大的字体识别率远高于花体。比赛不是设计比赛识别稳定才是第一位。6.2 识别距离太近刹车来不及这是我们整个调试过程中遇到的最大问题。模型在最开始能识别到的最大距离只有不到20厘米小车速度稍微快一点等识别确认完已经冲过病房门口了。后来通过两件事改善了一个是把模型输入从320x320之外又增加了ROI裁剪让远处的小数字在画面里更清晰另一个是降低电机PWM限幅让小车进入识别区域前就提前减速而不是等看到数字才减速。说白了视觉识别有它的物理极限运动控制必须配合它把速度降下来。6.3 串口丢帧与供电干扰小车电机一转串口就开始乱码这是最常见的混合信号污染问题。排查步骤从硬件到软件先确认K210和STM32共地再把串口线从电机电源线和电机驱动线旁边拉开最后在串口TX线对地加一个100nF的小电容滤高频干扰。如果还不行降低波特率到9600或19200误码率会明显下降。我们最终用的是115200配硬件滤波实测稳定但不同车模情况不同不要盲目照搬。6.4 模型连续推理导致的卡顿和过热K210跑KPU推理时芯片温度会明显上升尤其是夏季赛题连续跑半小时后偶尔出现推理结果变慢甚至空跑的现象。那时候别急着怀疑模型先摸一下芯片外壳烫手的程度就说明需要加个散热片了。小铝片加硅胶垫贴在K210背面温度能降不少。同时可以在代码里适当降低推理频率避免KPU长时间满载。最后再说一点个人体会备赛的最后几天我们几乎每天都在改数据、调阈值、重烧模型。现在回头看数字识别模型本身不是什么高深的东西真正拉开队伍差距的是数据质量、协议设计、系统联动这些看起来不起眼的工程细节。如果你正准备做同类型的赛题我建议第一优先级是尽早把“识别——通信——停车”这条主线跑通把所有关键阈值预留成可配置参数不要写死在代码里这样临场调整速度会快很多。等主线稳定了再去优化帧率、识别距离这些性能指标。方向对了车就一定能把药送到。本文还有配套的精品资源点击获取