【DigiKey好物畅享】Arduino UNO R4 WiFi & UNO Q：AI 图像识别与 LED 矩阵可视化系统实践
1. 项目背景与目标
在嵌入式端侧智能应用中，“AI 推理”与“实时交互显示”通常存在天然矛盾：
AI 推理需要较强算力、较高灵活性（适合 Linux / 高层运行环境）
LED 点阵显示与硬件驱动强调实时性、确定性（适合 MCU）
本项目基于 Arduino 官方 App Lab 的 **Image Classification（图像分类）**示例进行二次开发，构建了一个完整的端侧 AI 应用闭环：
用户通过 WebUI 上传图片
Linux 侧调用预训练模型完成图像分类推理
将识别结果映射为简短缩写（如 CAT / DOG / HUM / CAR 等）
通过 Bridge（RPC）下发到 MCU
MCU 驱动 13×8 LED 矩阵实时显示识别结果缩写
最终实现了一个“可交互、可演示、可扩展”的 AI + 双端协同系统。
2. 系统总体方案与双端分工
2.1 系统组成
系统由以下模块组成：
1. Web UI（浏览器端）
图片上传
置信度阈值设置
显示推理结果与置信度
2. Linux 应用（Python）
接收图片数据（Base64）
图像解码与预处理
调用 ImageClassification Brick 推理
解析推理结果并生成缩写
通过 Bridge RPC 调用 MCU 服务
3. MCU 固件（Sketch）
注册 RPC 服务接口（如 set_text）
将缩写字符渲染到 13×8 LED 矩阵
保证显示实时性与稳定性
2.2 双端优势体现
本项目重点体现了开发板“双处理器/双域协同”的优势：
Linux 侧优势（AI 与应用逻辑层）
便于接入现成 AI 模型/推理服务（ImageClassification Brick）
Python 开发效率高，适合快速验证、调试和扩展
便于实现复杂逻辑（如分类结果归并、TopK 投票、阈值策略等）
MCU 侧优势（硬件实时显示层）
点阵显示属于典型实时任务，MCU 可稳定驱动
与 Linux 解耦，显示刷新不受推理延迟影响
固件逻辑可控、稳定，不易因系统负载产生卡顿
通过这种架构分工，本系统实现了：
“AI 推理灵活性” + “硬件实时性” 的兼顾。
3.软件工程结构
项目基于 Arduino App Lab 示例扩展，主要目录结构如下：
其中：
python/main.py 运行于 Linux 环境，负责推理与业务逻辑
sketch/sketch.ino 运行于 MCU，负责点阵显示与 RPC 接收
4. AI 推理与结果处理（Python 端）
4.1 图像数据获取与预处理
Web UI 上传图片后，Python 侧接收 base64 编码的数据。为了避免不同图片格式（PNG/JPEG）与色彩模式（RGB/RGBA/灰度）差异导致推理不稳定，本项目采用统一预处理策略：
Base64 解码为 bytes
PIL 打开图像
强制转换为 RGB
4.2 图像分类推理调用
项目使用 Arduino App Lab 的 Image Classification Brick 调用预训练模型完成推理。推理输出为结构化结果，一般包含：
类别名称：class_name（detected object）
置信度：confidence
4.3 推理结果返回结构与解析
调试过程中发现，Brick 的返回结构可能为字典（dict）形式，例如：
{
‘classification’: [
{‘class_name’: ‘Persian cat’, ‘confidence’: ‘95.94’}
]
}
因此 Python 侧实现了统一的解析逻辑，用于兼容不同结构并稳定提取 Top1：
从 results[‘classification’] 提取第一个候选
获取 class_name 与 confidence
作为后续映射与显示的输入
4.4 detected object 的字符化归并策略
AI 输出的 detected object 并不局限于“猫 / 狗 / 人”，可能覆盖大量类别（如车辆、食物、设备、家居物品等）。但 13×8 LED Matrix 不适合显示长文本，因此本项目采用“语义归并 + 缩写显示”策略：
对 class_name 转小写并进行关键词匹配
将类别归并到有限的“显示域”
输出 3~4 字符缩写（便于点阵显示）
示例映射如下：
识别类别示例（class_name） 显示缩写
Persian cat / Tabby cat CAT
Dog / Retriever / Husky DOG
Person / Face HUM
Car / Truck / Bus CAR
Bicycle / Motorcycle BIKE
Pizza / Coffee / Food FOOD
Phone / Laptop / Camera DEV
Chair / Table / Sofa HOME
Tree / Bird / Nature NATR
其他类别 UNK
该策略优势：
LED 显示清晰、稳定、可读性强
AI 的“多类别识别能力”可通过 Web UI 展示完整 class_name 与 Top-K
MCU 端无需承载复杂分类逻辑，只负责显示，系统更可靠
4.5 Bridge RPC 下发机制
Python 端通过 Bridge 调用 MCU 端注册的服务接口，将缩写字符串下发：
服务名：set_text
参数：缩写字符串（建议 3~4 字符）
5. LED Matrix 显示设计（MCU 端）
5.1 13×8 LED Matrix 显示限制分析
开发板集成 LED Matrix 分辨率为 13×8（宽×高），显示能力受限：
宽度 13 列：传统 5×7 字体无法显示 3~4 字符
高度 8 行：可容纳 5 行字体并留出上下边距
若直接显示长文本，会出现截断或可读性差的问题
因此显示端需要面向硬件特性进行字体与排版优化。
5.2 3×5 字体方案
为实现 3~4 字符缩写在 13×8 上完整显示，本项目采用 3×5 字体：
每字符 3 列、5 行
最多 4 字符占用 12 列，适配 13 列宽度
字体在 8 行高度内垂直居中显示
5.3 三字符间距优化（+1 列空隙）
实践中发现：三字符缩写（CAT/DOG/HUM）若无间距，字符粘连影响可读性。
因此在 MCU 渲染逻辑中加入规则：
当字符数 = 3：字符间距 = 1 列
其他情况：间距 = 0（保证 4 字符仍能放下）
该策略计算验证：
三字符宽度 = 3×3 + 2×1 = 11 列
在 13 列上可居中显示并保留边距，清晰度显著提升
5.4 MCU 端 RPC 服务与显示流程
MCU 端主要流程：
初始化 LED Matrix
默认显示状态文本（如 WAIT）
注册 Bridge 服务：set_text
接收 Linux 侧发送的缩写字符串
调用 draw_text() 使用 3×5 字体写入帧缓冲
刷新点阵显示
6. 调试过程与问题定位
6.1 推理返回 None：runner 容器未启动
现象：Web UI 提示 “No results returned”。
日志显示 DNS 解析失败：无法解析 ei-classification-runner。
结论：推理 runner 容器未随 App 启动。
解决方法：在 App 中按正确方式添加/启用 Image Classification Brick，使 ei-classification-runner 容器启动并加入网络，推理恢复。
6.2 推理结果正确但 LED 无变化：结果结构解析不一致
现象：推理成功返回字典结构，但 LED 不变化。
原因：初版逻辑按 list 解析 results，未正确从 dict 中提取 class_name，导致显示逻辑一直走默认值。
解决方法：实现统一 _extract_top1() 解析函数，兼容 dict/list，提取 Top1 类别与置信度，并生成缩写后下发。
6.3 字符显示不完整：字体选型不匹配 13×8 分辨率
现象：使用 5×7 字体时，3~4 字符显示截断。
解决：改用 3×5 字体；针对 3 字符加入 1 列间距提高可读性，问题彻底解决。
7. 实验效果与展示
系统运行效果如下：
Web UI 可上传图片并显示推理结果（类别名称与置信度）
LED Matrix 能实时显示识别缩写（CAT/DOG/HUM/BIKE/FOOD/DEV/HOME/NATR/UNK 等）
识别结果与显示同步，系统运行稳定
8. 可扩展方向
在当前版本基础上可进一步扩展：
Top-K 轮播显示：将 Top3 缩写依次轮播，最后停留 Top1
置信度条显示：在点阵右侧用列条显示置信度等级
识别记录与导出：将识别类别与时间戳记录到存储介质，便于追溯
场景化联动：结合语音播报、蜂鸣器、提示灯实现多模态交互
归并策略增强：引入同义词表、TopK 投票、置信度门控等提升鲁棒性
9. 总结
本文基于 Arduino 双端架构完成了一套端侧 AI 图像识别与 LED 矩阵字符化显示系统的设计与实现。系统通过 Linux 侧完成 AI 推理与语义归并，MCU 侧完成实时点阵显示，并通过 Bridge RPC 进行低耦合通信，最终实现：
AI 推理能力（Image Classification）
可交互 Web UI 上传与结果展示
13×8 LED Matrix 清晰显示识别缩写
双端分工明确、系统稳定、便于扩展
该实践验证了双端协同在端侧 AI 场景中的工程价值，为后续更复杂的智能终端设计提供了可复用的参考架构与实现路径。