ESP32开发板做AI智能体：端云协同语音控制机械爪

1. 先交代背景ESP-Claw 是怎么冒出来的1.1 我为什么想把 AI 智能体塞进一块 30 块的芯片里先交代一下来龙去脉。我一直想做一个“能听懂话”的小东西不是手机遥控那种而是我说一句“把摄像头转过来”它就真的自己完成一系列动作。市面上有很多现成的智能音箱但它们的“智能”停留在问答和放歌上真正能动手操作的很少。所以我给自己定了个小目标用一块 ESP 开发板加一个机械爪做一个能接收自然语言指令、自行判断意图、然后控制舵机电机的 AI 智能体名字就叫 ESP-Claw。这个想法在不少朋友看来有点“标题党”因为 ESP32 系列开发板毕竟是个微控制器不是树莓派那种带 Linux 的小主机。它的 SRAM 通常只有几百 KBFlash 也就几 MB连一个像样的语言模型参数都装不下。可问题是AI 智能体是不是必须把模型跑在自己身上我当时专门查了一圈“智能体开发”的网络热词和相关资料发现大家更多在讨论框架、大模型、工作流很少有人认真对待“开发板”这个边缘端。于是我更想试一下如果智能体的大脑可以放在云端开发板只负责感知和执行那这个组合能不能成立思路理顺之后项目的定义就很清楚了ESP-Claw 不是一个离线 AI而是一个“端云协同”的智能体载体。开发板负责声音唤醒、录音、舵机控制、状态上报大模型负责语义理解、意图识别、任务拆分。开发板是四肢和嘴巴大模型是大脑两者通过网络连接在一起形成一个完整的智能体闭环。1.2 ESP-Claw 的准确定义边缘执行体 云端推理体很多初学者容易把“智能体”和“大模型”划等号这在嵌入式项目里会误导选型。我后来在自己的博客里写了一句总结智能体不是某个模型而是一个“感知-决策-执行”的循环系统。模型只是决策环节里的替身它负责把自然语言翻译成机器能理解的指令但真正面对物理世界的工具一定是这些开发板、舵机、传感器。所以我给 ESP-Claw 的定位是“边缘执行体 云端推理体”。传感器和执行器都留在开发板这一端最大程度降低响应延迟。云端只负责需要“理解”的部分比如把声音转成文字再把文字转成结构化指令。这样的好处很多开发板上的程序逻辑非常纯粹不容易因为模型更新而重刷固件更换大模型非常方便今天用在线 API明天切到局域网里的 Ollama只改一行 URL低功耗待机容易做平时只有麦克风在监听真正识别到唤醒词后才发起网络请求成本和安全性都可控机械爪只接受白名单里的指令不会因为模型抽风而乱动。也正是因为想清楚了这层关系整个项目才没有在中途失控。否则买回来一块 ESP32-S3装了个 3D 打印爪子发现跑不了大模型项目就黄了。下文我会把硬件搭建、软件链路、实测翻车过程逐一写出来给也有类似想法的朋友做个参考。2. 硬件准备的每一步都该踩的坑从舵机到麦克风2.1 材料清单与成本核算先列一下我实际用到的硬件清单方便想复刻的朋友估算预算。我选 ESP32-S3 而不是老款 ESP32主要原因是它对 I2S 音频和 ESP-SR 语音唤醒的支持更友好而且主频往上拉到了 240MHz双核跑音频任务时不容易卡顿。模块型号/规格大致价格作用主控开发板ESP32-S3-DevKitC-14MB Flash 版本45 元左右主控、WiFi/蓝牙、I2S 录音机械爪3D 打印舵机爪 连接件25 元左右实际执行“抓取”动作舵机SG90 9g 舵机 × 218 元左右驱动爪子开合和旋转麦克风INMP441 I2S 麦克风模块15 元左右采集语音信号功放喇叭MAX98357A 8Ω 小喇叭18 元左右语音播报和状态提示电源模块5V/2A 稳压模块 3.3V LDO8 元左右隔离舵机与主控供电辅助材料杜邦线、面包板、电容若干10 元左右连接和滤波合计不到 150 元比大部分带屏的智能开发板便宜。但它不能直接当“智能音箱”用因为它的工作重心在“动手”而不是“聊天”。我甚至特意去掉了屏幕目的是逼自己用语音和动作交互来验证体验。2.2 舵机供电差点让我以为板子烧了硬件里第一个要重点说的地方是舵机供电。SG90 是很便宜的小舵机很多人觉得电流不大顺手把它接到了开发板的 3.3V 引脚上。结果我的板子在爪子快速闭合时经常重启串口打印反复出现“Brownout detector was triggered”看起来特别像坏板子。原因并不复杂SG90 舵机堵转或者瞬间启动时电流可以冲到 400mA 以上而 ESP32-S3 开发板上的 3.3V LDO 本身还要给 WiFi、Flash 供电。舵机一拉电核心电压跌落超过阈值芯片就自动复位了。所以后来我专门加了一路 5V/2A 稳压模块给舵机供电主控独立用 3.3V LDO。信号线可以直接连舵机控制脚因为 3.3V 高电平对 SG90 来说已经足够触发信号。另外在舵机电源两端并联一个 470μF 的电解电容也很有用可以在爪子的瞬间启动阶段吸收一部分电流峰值避免电压塌下去。有人还会在信号线上串一个 1K 电阻隔离舵机电源噪声对 GPIO 的干扰实测下来对稳定性也有帮助。PWM 控制部分我用的是 ESP32 的 LEDC 外设输出频率设成 50Hz对应周期 20ms。SG90 的脉宽范围是 0.5ms 到 2.5ms对应角度 0° 到 180°。如果 LEDC 分辨率是 16 位那 2^16 6553650Hz 下每个周期对应的总占空比计数是 655360.5ms 脉宽大约等于 0.5ms / 20ms × 65536 ≈ 16382.5ms 脉宽就是 8192。所以从角度换算占空比的公式大致是uint32_t duty (uint32_t)((0.5 angle / 180.0 * 2.0) / 20.0 * 65535);这样写出来的代码直观也能保证爪子角度连续可调。2.3 唤醒词和语音输入ESP-SR 和麦克风模块的实际配合“智能体”听人话的第一步不是直接让开发板听懂所有台词而是做一个低功耗的关键词唤醒。我使用 ESP-SR 语音识别框架里的 WakeNet 模型唤醒词选了默认的“HiESP”。这个框架在 ESP-IDF 环境下编译通过 esp_sr 组件就能用。虽然它支持自定义唤醒词但我嫌训练模型麻烦直接用默认词反而省事。麦克风用的是 INMP441它是一款 I2S 输出的数字 MEMS 麦克风不需要额外的模拟采样电路。接线时注意它要求至少接 SCK、WS、SD 三根线并且在某些模组上还需要 L/R 引脚决定左右声道。我最初把 SD 接错了引脚结果录音出来全是重复的机械噪声后来查了引脚定义才搞定。关于编译环境我提一句热词里经常看到的 ESP-IDF 版本问题。我用的是 ESP-IDF v5.3.2ESP-SR 需要在 menuconfig 里把组件路径配置好。老版本教程里的 API 名称和默认参数有差异照抄很可能会报错。如果你准备复刻建议直接以官方 esp-skainet 示例为起点先跑通“唤醒 录音”的基础闭环再往上叠加网络和大模型部分。直接上手改例子比从头写要省很多时间。3. AI 智能体的核心软件链路怎么让板子“想”了再做3.1 五段式流水线唤醒-录音-理解-决策-执行软件部分我一开始想把所有逻辑都塞进一个循环里后来发现这思路在嵌入式上很危险。智能体本质上是个不断感知、决策、执行的状态机我应该把链路拆成清晰独立的模块。最后我按五段式流水线设计唤醒阶段ESP-SR 在后台监听检测到“HiESP”后Led 灯亮起表示准备接收指令录音阶段唤醒后录音 3 秒存成 WAV 格式并放到内存缓冲区理解阶段把录音通过 HTTP 上传到语音转文字服务拿到一行文字决策阶段把文字交给大模型 API大模型返回一个结构化 JSON 指令执行阶段解析 JSON调用舵机和播放模块完成动作和语音回复。这五个阶段不是一次性写完的。我最初只做了“唤醒→录→上传转文字→打印结果”确认语音链路没问题接着测试“文字→大模型→JSON→执行”把假文字硬编码进程序里确定动作可靠最后才把两者串起来。分阶段调试的好处是出了问题能快速定位而不是一团乱麻。3.2 给大模型写一个“嵌入式专用”的智能体提示词大模型不是万能的不给约束它就会随意发挥。如果我把“样品在桌子的左边”丢给通用模型它可能回一大段中文解释甚至反过来问我问题这对开发板来说完全没法用。所以我在系统提示词里做了非常强的格式约束。实际使用的提示词模板大概长下面这样你是一个嵌入式机械爪控制器。用户会发送一句语音识别后的指令文本。 你的任务是把指令翻译成 JSON不要输出任何解释、警告或额外文字。 动作枚举是固定的grab、release、rotate、update、standby。 target 字段只允许是 cube、screw、bottle、unknown。 如果指令不明确统一输出 unknown。 示例 输入“抓一下螺丝” 输出{intent: grab, target: screw}这个提示词的价值在于“降低解读成本”。嵌入式端解析 JSON 已是极限它没有能力去理解大模型输出的散文。而且枚举类型的动作天然能限制模型自由发挥即使模型判断错误最坏情况也只是一个动作不执行不会因为它自创动作导致程序崩溃。3.3 意图映射表从自然语言到机器动作的翻译层大模型返回 JSON 之后开发板要做的是把意图翻译成真正的物理动作。我维护了一张意图映射表代码里就一个简单的结构体数组。这样新增指令不需要改舵机控制逻辑只需加一行映射。意图典型自然语言执行动作grab拿一下、抓住、把螺丝抓起来爪子收拢夹爪闭合release放下、松开、放回原位爪子张开回到初始位置rotate左转、右转、把爪子转到左边旋转舵机转动指定角度update报告状态、你现在在哪返回当前角度和状态standby休眠、待机、保存电量关闭功放降低功耗这张表是项目的灵魂。云端的模型或许很聪明但到了物理层它也只能从有限的枚举里选择。真正干活的永远是这一张接地的指令表。我也建议所有想在开发板上做智能体的人先把动作枚举定义清楚再考虑怎么接大模型顺序反了会很难受。3.4 代码骨架一个最简可跑的指令中控为了节省篇幅我用 MicroPython 风格的代码展示核心交互逻辑。实际工程里我没用 MicroPython而是用 ESP-IDF 的原生 C 语言写因为 MicroPython 的内存分配在长时间运行下不够稳定。下面的代码相当于“路线图”通信和解析逻辑是等价的import network import urequests import ujson import time WIFI_SSID your_wifi WIFI_PWD your_password LLM_URL http://192.168.1.100:11434/api/generate STT_RESULT 抓一下螺丝 # 实际由 STT 模块输出 def connect_wifi(): wlan network.WLAN(network.STA_IF) wlan.active(True) wlan.connect(WIFI_SSID, WIFI_PWD) while not wlan.isconnected(): time.sleep(0.5) def build_prompt(text): return (f你是嵌入式机械爪控制器。将指令翻译为 JSON。 f枚举: grab, release, rotate, update, standby; ftarget: cube, screw, bottle, unknown。 f输入{text}) def ask_brain(text): payload { model: qwen2.5:3b, prompt: build_prompt(text), stream: False, format: json } res urequests.post(LLM_URL, jsonpayload, timeout10) data ujson.loads(res.text) res.close() return ujson.loads(data[response]) def execute(intent): if intent[intent] grab: claw_close() elif intent[intent] release: claw_open() connect_wifi() while True: if wake_word_detected(): audio record_audio(3) text stt(audio) decision ask_brain(text) execute(decision)你在真实项目里不需要完全照搬这一段核心是把“网络请求”和“动作执行”抽成独立函数方便后面替换成 HTTPS API、局域网模型、甚至是蓝牙中继。4. 实测结果和翻车复盘说三个让我头上冒汗的问题4.1 端到端延迟实测从“你好小爪”到爪子合拢为了验证它是不是真的能用我专门做了一组延迟测试。唤醒词检测是常驻监听这部分的模型推理在本地完成速度最快语音转文字走的是在线服务大模型决策走 API动作执行在本机。最终的数据如下链路阶段耗时说明唤醒200ms 以内ESP-SR 本地推理基本感觉不到录音和音频处理约 1s录音 3 秒 上传语音转文字约 600ms在线服务一次请求大模型决策约 2s小模型生成的 JSON舵机执行约 300ms从收到指令到爪子合拢总计约 4s不含用户说话时间说实话4 秒的响应比起智能音箱还是有点慢但作为开发板项目已经可以接受了。毕竟用户说一句话需要 2 秒听完再说一句交互节奏感尚在。真正让我无法接受的是另外三个“环境型”问题它们比延迟更影响体验。4.2 翻车现场一HTTP 请求卡死导致看门狗复位第一次把大模型接入后系统运行不到 10 分钟就自动重启串口日志显示看门狗超时。查了半天发现问题出在我用同步方式调用了 HTTP API在 WiFi 信号差、服务器响应慢的情况下整个主线程被堵在大模型请求里。ESP-SR 的音频回调拿不到 CPU导致任务长期不喂狗芯片就强制重启了。解决办法有两个方向。一是把网络请求挪到独立任务里并且给 HTTP 客户端加上合理的超时时间二是把音频处理和网络请求分核跑ESP32-S3 双核完毕后这种分工很适合。我最终选择在 ESP-IDF 里创建了http_task用队列和主循环通信即使 API 卡了 10 秒也不会影响唤醒监听。核心原则是让网络请求永远不要阻塞音频和舵机逻辑。开发板不是 PC不能让“想问题”占住“动作”的通道。另外一个细节是HTTP 请求失败时不能直接忽略。我在请求后面加了一个简单的“状态机”请求失败会回退到待机态并且用 LED 闪烁告诉用户当前不可用。同理连接 WiFi 也有必要做断线重连家用路由器的 DHCP 租约和设备休眠会导致 WiFi 偶尔断开不加重连逻辑智能体就会变成“聋子”。4.3 翻车现场二舵机电流把 3.3V 系统拉崩了这个问题我在前面电源部分已经说了但在实测中它换了种方式出现不是一启动就崩而是爪子抓住物体后堵转电流维持了 1 秒整个开发板才崩。这就是“瞬时过流没崩持续过流才崩”的典型案例。我后来做了两个改动。硬件上舵机电源独立供电之外又在 5V 电源和地之间加大电容软件上给爪子闭合设置了 60ms 的步进控制而不是一次性跳到目标角度。步进控制的逻辑是把从 0° 到 120° 的行程切成 20 小步每步走 5°中间间隔 50ms 再走下一步。这样既避免了瞬间大电流冲击也让抓取动作看起来更像真实机械臂而不像抽搐。代码角度上我建议把动作执行函数做成非阻塞的或者至少是短时间阻塞。如果一定要做大幅旋转就用定时器中断或者消息队列做分段执行别用一个大的delay把整个系统卡住。4.4 翻车现场三大模型“一本正经地胡说”输出了非法 JSON这大概是所有接大模型的嵌入式项目都会遇到的问题。我用测试文本“帮我转一下”去请求模型结果模型输出了一整段带中文解释的 JSON字段名乱了甚至连括号都不全。ESP32 上的 JSON 解析器一旦遇到格式错误直接返回异常动作根本不执行。解决办法分两路。第一路是指令词和提示词双保险系统提示词里明确要求“只输出 JSON不要 markdown不要注释”同时把输出格式设置为format: json现在很多模型 API 都支持类似的功能。第二路是开发板端的容错机制如果 JSON 解析失败不弹错误而是重新请求一次如果第二次还失败就播报“没有听懂”回到待机状态。还可以考虑在代码里做“伪 JSON 清理”。比如先把返回文本里的中文注释和换行全部删掉再把最外层大括号截出来。这不是最优雅的方案但在模型偶尔抽风时非常管用。我的项目里保留了这个 fallback因为它能让系统在异常情况下不至于完全不可用。5. 现在我可以回答标题问题了ESP 开发板到底能不能当 AI 智能体5.1 能但“能力半径”必须提前划清看着 ESP-Claw 在桌面上真的能随着一句“HiESP把螺丝拿起来”完成抓取我可以很肯定地说能。但这个“能”字有条件。它不是像 ChatGPT 那样什么都懂的全能智能体而是一个能力范围被开发者严格框定的专项智能体。它的智能来自云端它的边界来自代码里的意图映射表。只要不越界它就是一个真正能动手、能闭环的 AI 智能体。如果谁跟我说“我要在 ESP32 上本地跑一个 7B 大模型然后让它自己写诗”那我只能劝他冷静。ESP 开发板的内存和算力决定了它不是本地推理平台而是优秀的“智能体外周神经”。它负责感知世界、执行动作、保持低功耗大模型则负责语言理解、意图判断、决策输出。两者合起来才是完整的智能体系统。5.2 如果再让我做一次我会这样改设计这次项目做下来我对整个设计有了新的认识。如果重新做一遍我会做这些调整主控选带 8MB PSRAM 的 ESP32-S3 模组跑音频处理时内存会更宽裕也可以临时缓存更多录音数据从一开始就用 ESP-IDF 原生工程不用 MicroPython 做原型省去后迁移的麻烦在机械爪旁边加一个 OLED 显示屏显示当前智能体的状态和意图排查问题会轻松很多把语音回复换成离线语音合成甚至直接用蜂鸣器编码提示减少云端依赖给整个设备做一个自动网络配置入口首次使用时使用蓝牙配网而不是烧录前硬编码 WiFi 密码。这些调整不改变“边缘云端”的架构但会让整个系统更适合长期使用。尤其是配网方式家用智能设备最烦的就是第一次连接如果每次都要用串口改 WiFi 信息根本不适合作为产品原型。5.3 下一步方向多工具调用和“常驻记忆”现在的 ESP-Claw 还只能做单任务比如抓一个东西。但它已经验证了“大模型 开发板”这条路走得通。下一步我想扩展成“多工具智能体”一个主控连接多个子模块机械爪是工具一LED 灯是工具二温湿度传感器是工具三。大模型通过 JSON 返回不同工具的指令开发板再根据指令调用对应外设。这就是最早期的 Agent 工具调用概念了。另外记忆功能也值得做。大模型本身没有状态但如果我在开发板里维护一个简单的键值表把最近一次抓取的目标物体、位置、成功与否存到 NVS 闪存里下一次请求时把这段记忆合并进提示词它就能说出“你上次让我抓的是螺丝”这种带上下文的话。严格来说这不是模型自己记住的而是智能体系统把它记住了。每次看到 ESP-Claw 在桌面上一张一合地工作我都会想起最开始那个问题一块 30 块钱的芯片真的能变成 AI 智能体吗现在我可以给出一个具体答案把“智能”放在云端把“行动”放在边缘芯片负责和现实世界硬碰硬大模型负责和人类语言打交道。两者配合之下它就真的能变成一个 AI 智能体。这也是为什么我觉得嵌入式开发板会是未来各类智能体落到实体世界的重要入口。