ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

开源机器人开发实战:从模型下载到本地推理与接口封装

开源机器人开发实战:从模型下载到本地推理与接口封装 开源机器人最近热度上升得非常明显。一方面大模型开源权重越来越多从对话模型到多模态模型都能在消费级硬件上运行另一方面具身智能、桌面机器人、教育机器人项目不断放出 demo把“大模型 机器人”从论文里拉到了普通开发者面前。Hugging Face 发布的 399 美元开源机器人 Microduck正是这条趋势里的一个标志性产品。本文不打算写成产品评测而是围绕“拿到一款开源机器人之后怎么把模型下载、本地推理、Web 接口、语音视觉这些能力真正接进去”展开一套完整实操方案。无论你手里是 Microduck还是树莓派加舵机搭出来的简易小车这套思路都适用用 Hugging Face 获取模型和数据集用 Ollama 把大模型跑在本地用 FastAPI 暴露成机器人可以调用的接口最后再叠加摄像头、语音等外围能力。整个过程不需要昂贵的服务器一台 16GB 内存的电脑或者一块入门级开发板就能起步。下面从概念开始逐步落到可运行的代码。1. 背景与核心概念1.1 Microduck 是什么廉价开源机器人为什么重要Microduck 是 Hugging Face 推出的一款开源机器人定价 399 美元目标很明确让更多开发者、学生和中小团队能够用低成本硬件接触“大模型 机器人”开发。在此之前移动机器人平台要么价格偏高要么软件生态封闭入门者想复现一个带对话能力、视觉能力、运动能力的机器人往往需要自己拼一堆模块。Microduck 这类产品出现的价值是把硬件成本压到“一台中端手机”的区间同时借助 Hugging Face 的模型库和社区生态把软件侧的学习曲线也拉平。需要说明的是截至本文整理时官方尚未公布完整的硬件配置清单公开信息以 Hugging Face 官方公告为准。因此本文不会凭空罗列 CPU 型号、传感器规格而是按“开源机器人平台的通用构成”来做拆解。机器人本体通常包含底盘或关节、主控板、摄像头、麦克风/扬声器、电池和扩展接口开发者要做的事情是让这些硬件与大模型能力打通。1.2 开源机器人的常见组成从软件视角看一个能对话、能感知、能行动的机器人至少包含四层。第一层是硬件抽象层负责驱动摄像头、麦克风、电机、舵机等设备第二层是感知层处理图像、音频、传感器数据第三层是决策层通常由大模型或者规则引擎来完成比如理解用户指令、规划动作、生成回复第四层是执行层把模型输出转换成电机转速、舵机角度或语音播放。Microduck 虽然具体型号未知但整体架构大概率不会跳出这个框架。对于开发者来说最重要的不是先纠结硬件而是先把“决策层”跑通。一个能运行的对话接口配上摄像头采集和简单的运动控制就已经是一个完整的机器人原型。后面的章节会按照“模型下载 → 本地推理 → API 封装 → 外围设备接入”的顺序展开。1.3 需要掌握哪些技术栈如果目标是复现一个类似 Microduck 的开源机器人学习项目建议优先掌握以下技术栈。模块技术选型作用模型管理Hugging Face Hub / huggingface_hub下载模型权重、数据集、配置文件本地推理Ollama GGUF 量化模型在本地运行对话模型资源占用低接口服务FastAPI Uvicorn把模型封装成 HTTP 接口供机器人调用视觉处理OpenCV读取摄像头画面做人脸/物体检测语音交互edge-tts / Whisper把回复转成语音把语音转成文本硬件控制GPIO / 串口 / PWM控制电机、舵机、传感器这套组合的最大优势是“每一层都可以单独替换”。今天用 Qwen 系列明天换 Llama只需要改模型名今天用 Web 接口明天接到 ROS 2也只需要在接口层做适配。学习时不要急于一次全打通按“模型 → 接口 → 硬件”的顺序推进踩坑成本最低。2. 环境准备与项目结构2.1 硬件环境建议在官方 Microduck 硬件规格没有公开之前先用一套通用配置来准备环境。如果你已经有开发板按实际设备调整如果还没有可以先在普通电脑上完成全部软件实验。最低配置建议如下CPU4 核以上 x86 或 ARM 处理器内存16GB 以上模型推理时内存占用会明显上升硬盘至少 30GB 可用空间GGUF 模型通常在 5GB 到 10GB 之间GPU可选有 NVIDIA 显卡可以显著提升推理速度没有也能运行 CPU 版本摄像头USB 摄像头或开发板自带摄像头均可麦克风/扬声器用于语音交互扩展。如果后续要做真机控制再根据开发板接口选购舵机、电机驱动板、电池和底盘。初期不建议追求昂贵硬件先把软件链路跑通再逐步加设备。2.2 软件环境清单本文所有代码基于 Python 3.10 以上版本操作系统可以使用 Ubuntu 22.04、Windows 10/11 或 macOS。下面是用到的核心软件包软件包用途huggingface_hub下载模型和数据集datasets加载 Hugging Face 数据集ollama本地运行 GGUF 量化模型fastapi / uvicorn提供 HTTP 接口requests调用 Ollama APIopencv-python摄像头与图像处理edge-tts文本转语音安装命令统一使用 pip。建议先创建虚拟环境避免依赖冲突python -m venv microduck-env source microduck-env/bin/activate pip install -U huggingface_hub datasets requests fastapi uvicorn opencv-python edge-ttsOllama 不能通过 pip 安装需要从官网下载对应的安装包。安装完成后在终端执行ollama --version检查是否成功。2.3 项目目录规划建议把项目按下面结构组织方便后续扩展microduck-project/ ├── models/ # 本地模型文件 ├── datasets/ # 下载的数据集 ├── app/ │ ├── main.py # FastAPI 入口 │ ├── brain.py # 模型调用封装 │ ├── vision.py # 摄像头/视觉模块 │ └── voice.py # 语音合成模块 ├── scripts/ │ ├── download_model.py # 下载模型脚本 │ └── download_data.py # 下载数据集脚本 ├── requirements.txt └── README.md这样做的好处是职责清晰模型下载、推理服务、视觉、语音相互独立即使未来更换机器人平台也能保留大部分代码。3. 第一步从 Hugging Face 获取模型与数据集3.1 安装 huggingface_hub 并配置镜像Hugging Face 是当前最大的开源模型和数据集社区。Microduck 作为 Hugging Face 生态的一部分天然适合通过 Hugging Face 下载模型。huggingface_hub是官方提供的 Python SDK也是后续所有模型下载操作的基础。安装方式很简单pip install -U huggingface_hub国内网络环境下直接连接 Hugging Face 可能会不稳定。可以配置镜像环境变量把下载流量指向国内镜像站export HF_ENDPOINThttps://hf-mirror.com如果你用的是 Windows PowerShell使用下面的写法$env:HF_ENDPOINThttps://hf-mirror.com设置完成后huggingface-cli和 Python SDK 都会自动使用镜像地址。这一步不是必须的但能明显提升下载成功率和速度。3.2 下载 GGUF 量化模型机器人要听懂人话需要一个能本地运行的对话模型。GGUF 是 llama.cpp 生态常用的模型格式特点是量化后体积小、CPU 也能推理。在 Hugging Face 上搜索“qwen3.5-9b-gguf”或者“Qwen GGUF”能看到大量由社区转换好的量化版本。下载时建议优先选择 Q4_K_M 或 Q5_K_M 量化文件。Q4_K_M 在体积和效果之间比较平衡大约能把 9B 模型压到 6GB 左右适合 16GB 内存的设备。下载命令如下huggingface-cli download 你的用户名/qwen3.5-9b-gguf \ --include *.gguf \ --local-dir ./models/qwen3.5-9b如果你更习惯 Python可以写一个脚本放在scripts/download_model.pyimport os from huggingface_hub import snapshot_download repo_id 你的用户名/qwen3.5-9b-gguf local_dir ./models/qwen3.5-9b snapshot_download( repo_idrepo_id, allow_patterns[*.gguf], local_dirlocal_dir, local_dir_use_symlinksFalse, ) print(f模型已下载到: {os.path.abspath(local_dir)})这里的你的用户名/qwen3.5-9b-gguf只是占位符实际操作时替换成你搜索到的真实仓库名称。allow_patterns表示只下载匹配规则的文件避免把整个仓库的 README、图片等无关内容都拉下来。3.3 下载微调数据集除了模型数据集也是开源机器人开发的重要资产。你可以用数据集做三件事评估模型效果、微调模型、或者作为机器人领域的知识库。使用datasets库加载数据集非常方便。下面以 HuggingFaceH4/ultrachat_200k 为例这个数据集包含大量多轮对话样本适合做对话模型效果评估from datasets import load_dataset ds load_dataset(HuggingFaceH4/ultrachat_200k, splittrain_sft) print(ds[0])输出会显示一条对话样本的结构包括用户输入和模型回复。如果只是想快速试一下可以只加载前几千条ds load_dataset(HuggingFaceH4/ultrachat_200k, splittrain_sft[:1000]) print(len(ds))数据集本身也是通过 Hugging Face Hub 分发的所以上一节配置的HF_ENDPOINT镜像变量同样生效。后面如果要做模型的领域微调可以在 Hugging Face 上搜索robotics、embodied等关键词找到更适合机器人场景的数据集。4. 第二步用 Ollama 在本地跑大模型4.1 安装 OllamaOllama 是目前本地运行大模型最省心的工具之一。它负责把 GGUF 模型加载到内存、管理推理过程、提供命令行和 REST API开发者基本不需要关心底层算子细节。安装完成后Ollama 默认监听11434端口。安装方式请参考 Ollama 官网支持 Linux、macOS 和 Windows。安装完成后先做一个基础验证ollama --version如果你已经下载了完整版模型也可以直接用官方仓库里的模型体验ollama run qwen2.5:7b输入你好能看到模型正常回复。这一步主要用于验证环境没有问题后续正式使用还是以自己下载的 GGUF 模型为准。4.2 导入 GGUF 模型从 Hugging Face 下载的 GGUF 文件不能直接被 Ollama 使用需要先通过Modelfile导入。进入模型目录创建Modelfilecd models/qwen3.5-9b cat Modelfile EOF FROM ./qwen3.5-9b-Q4_K_M.gguf EOF然后执行导入命令ollama create qwen3.5-9b -f Modelfile说明一下qwen3.5-9b是导入后你自己定义的模型标签后面调用时都用这个标签。Modelfile里还可以写SYSTEM指令比如设定机器人的角色FROM ./qwen3.5-9b-Q4_K_M.gguf SYSTEM 你是 Microduck 的助手回答要简洁、准确、友好。重新执行ollama create qwen3.5-9b -f Modelfile即可覆盖更新。这样机器人就有了“人设”。4.3 命令行验证模型效果导入完成后先用命令行验证模型是否能正常响应ollama run qwen3.5-9b 你好请介绍一下你自己如果模型本身支持中文会返回一段中文介绍。此时可以多试几类问题比如ollama run qwen3.5-9b 请用三句话说明如何用 Python 读取摄像头画面建议在验证阶段多测试不同风格的指令确认以下三点模型回复是否流畅、英文和中文效果是否有明显差异、生成速度是否能接受。如果生成速度很慢说明当前硬件压力较大可以考虑换更小的量化版本比如 Q3_K_M。4.4 REST API 调用Ollama 自带 HTTP API这是机器人对接模型的标准方式。默认请求地址是http://localhost:11434/api/chat。下面用 Python 调用一次import requests response requests.post( http://localhost:11434/api/chat, json{ model: qwen3.5-9b, messages: [{role: user, content: 你好}], stream: False, }, timeout120, ) print(response.json()[message][content])stream参数设置为False表示等待完整回复如果设置为True服务器会以流式方式返回多个片段适合做打字机效果。后续在 FastAPI 里我们也会用同样的接口格式。5. 第三步把模型变成机器人的“大脑”5.1 设计消息接口模型跑起来之后机器人还缺一个对外服务层。这个层负责接收用户消息、调用模型、返回回复并且可以插入日志、权限校验、多轮记忆等逻辑。接口设计建议遵循 REST 风格下面是一个最小的请求/响应格式。请求{ message: 我饿了推荐一份简单食谱 }响应{ reply: 你可以试试番茄鸡蛋面番茄炒出汁加水煮面最后倒入蛋液。 }用 FastAPI 实现这个接口很简单。FastAPI 自带接口文档启动服务后访问http://localhost:8000/docs就能看到可视化调试页面对机器人开发来说非常方便。5.2 FastAPI 聊天服务先创建一个最小可运行的 FastAPI 服务文件路径app/main.pyfrom fastapi import FastAPI from pydantic import BaseModel import requests OLLAMA_URL http://localhost:11434/api/chat MODEL_NAME qwen3.5-9b app FastAPI(titleMicroduck Brain, version0.1.0) class ChatRequest(BaseModel): message: str app.post(/chat) def chat(req: ChatRequest): payload { model: MODEL_NAME, messages: [{role: user, content: req.message}], stream: False, } resp requests.post(OLLAMA_URL, jsonpayload, timeout120) resp.raise_for_status() return {reply: resp.json()[message][content]}代码逻辑很直接收到message字段后把消息转发给 Ollama拿到模型回复后再返回。使用timeout120是因为 9B 级别模型在 CPU 上生成一段长回复可能需要几十秒不能按照普通接口的超时标准设置。启动服务uvicorn app.main:app --host 0.0.0.0 --port 8000在浏览器访问http://localhost:8000/docs点击/chat接口的Try it out按钮输入测试消息就能看到模型回复。如果机器人本体在局域网内它会通过这个地址调用你的模型服务。5.3 加入多轮记忆上面的接口每次调用都是独立的模型不记得之前聊过什么。要让机器人更像一个真实的助手必须维护对话历史。最简单的做法是把历史消息保存在服务内存里每次请求时带上最近的几轮。from typing import List from fastapi import FastAPI from pydantic import BaseModel import requests OLLAMA_URL http://localhost:11434/api/chat MODEL_NAME qwen3.5-9b app FastAPI() conversation_history: List[dict] [] class ChatRequest(BaseModel): message: str app.post(/chat) def chat(req: ChatRequest): history conversation_history[-8:] # 只保留最近 8 轮 messages history [{role: user, content: req.message}] resp requests.post( OLLAMA_URL, json{model: MODEL_NAME, messages: messages, stream: False}, timeout120, ) reply resp.json()[message][content] conversation_history.append({role: user, content: req.message}) conversation_history.append({role: assistant, content: reply}) return {reply: reply}这里把历史截断为最近 8 轮避免消息太长导致显存和内存消耗过大、模型响应变慢。注意服务重启后历史会丢失如果要做持久化可以把历史写入 SQLite 或 Redis。5.4 接入语音与摄像头可选对话接口跑通后可以给 Microduck 加上语音和视觉两个能力。语音合成推荐使用edge-tts它不需要申请 API Key使用简单import asyncio import edge_tts async def speak(text: str): tts edge_tts.Communicate(text, voicezh-CN-XiaoxiaoNeural) await tts.save(output.mp3) asyncio.run(speak(你好我是 Microduck 的语音助手))生成output.mp3后用开发板或电脑的音频播放器播放即可。如果要做语音唤醒和识别可以再接入 Whisper 或语音 ASR 服务本文先不展开。摄像头读取建议使用 OpenCVimport cv2 cap cv2.VideoCapture(0) while True: ret, frame cap.read() if not ret: print(无法读取摄像头画面) break cv2.imshow(Microduck Vision, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()cv2.VideoCapture(0)中的0是摄像头编号。笔记本自带摄像头通常是 0外接 USB 摄像头可能是 1需要根据实际设备调整。循环里持续读取画面并显示按q键退出。6. 完整实战搭建一个 Web 端问答机器人6.1 创建 FastAPI 工程现在把所有步骤整合成一个最小可复现的 Web 端问答机器人项目。先创建依赖文件requirements.txtfastapi0.110.0 uvicorn0.29.0 requests2.31.0 pydantic2.6.0 huggingface_hub0.23.0 datasets2.18.0 opencv-python4.9.0.80 edge-tts6.1.10安装依赖pip install -r requirements.txt然后创建app/main.py把对话、记忆、日志、健康检查全部写进去文件内容如下import logging from typing import List import requests from fastapi import FastAPI from pydantic import BaseModel OLLAMA_URL http://localhost:11434/api/chat MODEL_NAME qwen3.5-9b logging.basicConfig(levellogging.INFO) logger logging.getLogger(microduck) app FastAPI(titleMicroduck Web Robot, version0.1.0) conversation_history: List[dict] [] class ChatRequest(BaseModel): message: str app.get(/health) def health(): return {status: ok, model: MODEL_NAME} app.post(/chat) def chat(req: ChatRequest): history conversation_history[-8:] messages history [{role: user, content: req.message}] logger.info(user message: %s, req.message) resp requests.post( OLLAMA_URL, json{model: MODEL_NAME, messages: messages, stream: False}, timeout120, ) resp.raise_for_status() reply resp.json()[message][content] conversation_history.append({role: user, content: req.message}) conversation_history.append({role: assistant, content: reply}) logger.info(assistant reply: %s, reply[:50]) return {reply: reply}6.2 实现 /chat 接口上面代码里的/chat接口已经实现了完整逻辑。为了更贴近真实项目可以把日志输出到文件而不仅是终端。在main.py里增加FileHandlerimport logging logger logging.getLogger(microduck) handler logging.FileHandler(robot.log, encodingutf-8) formatter logging.Formatter(%(asctime)s - %(name)s - %(levelname)s - %(message)s) handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(logging.INFO)这样每次问答都会写入robot.log方便后续排查问题和分析用户输入。6.3 运行与验证启动 FastAPI 服务uvicorn app.main:app --host 0.0.0.0 --port 8000然后打开另一个终端用curl测试接口curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {message: 你好请用一句话介绍你自己}预期会返回类似下面的 JSON{ reply: 我是一个运行在 Microduck 项目上的开源问答助手。 }你也可以直接用 Python 测试import requests resp requests.post( http://localhost:8000/chat, json{message: 机器人怎么学习新技能}, timeout120, ) print(resp.json()[reply])6.4 结果说明到这一步你已经完成了一台“机器人大脑”的最小闭环用户文本 → FastAPI 接口 → Ollama 模型 → 中文回复。这个闭环可以直接跑在 Microduck 上也可以跑在普通电脑上。后续只需要把机器人的摄像头画面、传感器数据转换成文本描述再交给/chat接口就能让机器人具备环境感知和对话能力。如果开发板性能较弱建议把 Ollama 服务和 FastAPI 服务部署到一块单独的电脑上机器人本体通过网络访问接口。这也是当前很多开源机器人项目采用的“本体 服务器”分离架构。7. 常见问题与排查思路7.1 模型下载很慢或连接超时使用 Hugging Face 下载大模型时经常出现下载中断或速度慢的问题。常见原因有两个网络不稳定同一个文件被多个线程反复写入。解决方案是配置镜像环境变量并使用断点续传能力。huggingface-cli download默认支持断点续传重新执行同样的命令即可继续。如果下载速度仍然很慢可以指定--max-workers 1降低并发huggingface-cli download 你的用户名/qwen3.5-9b-gguf \ --include *.gguf \ --local-dir ./models/qwen3.5-9b \ --max-workers 1另外建议在磁盘空间充足的分区执行下载因为 GGUF 文件在下载过程中还会有临时文件占用空间。7.2 Ollama 加载模型后内存爆掉9B 模型量化后虽然体积只有几个 GB但运行时需要额外占用内存。如果 16GB 内存的设备同时运行多个程序很容易出现系统卡顿或直接被 OOM Killer 杀掉进程。解决思路是换更小的量化版本比如 Q3_K_M或者在 Ollama 中限制并发请求避免多个会话同时加载模型。还可以通过环境变量控制 Ollama 在 CPU 模式下使用的线程数OLLAMA_NUM_PARALLEL1 ollama serve如果条件允许优先给设备增加物理内存或者把模型部署到另一台有独占内存的机器上。7.3 FastAPI 无法访问如果uvicorn app.main:app --host 0.0.0.0 --port 8000启动成功但局域网内其他设备无法访问通常有三个原因防火墙拦截、端口未开放、机器人本体与服务器不在同一网段。排查顺序建议如下问题现象常见原因解决思路本机访问正常其他设备超时防火墙拦截 8000 端口临时放行端口后重试其他设备能 ping 通但无法访问接口服务只监听了 127.0.0.1确认启动命令包含--host 0.0.0.0全部设备无法访问服务未启动或端口被占用查看日志并检查端口占用检查端口是否被占用可以使用命令lsof -i :8000如果端口被其他进程占用可以换一个端口启动例如--port 8001。7.4 摄像头与麦克风权限问题在 Linux 上使用摄像头时用户必须属于video组否则cv2.VideoCapture(0)返回的ret永远是False。可以执行下面命令查看当前用户是否在组内groups如果缺少权限添加用户到对应组后重新登录sudo usermod -aG video $USER麦克风权限类似桌面系统会弹出授权窗口需要在系统设置中允许终端或 Python 进程使用麦克风。在开发板上还要检查音频设备是否被其他服务占用。7.5 机器人回复质量不稳定大模型输出具有一定随机性因此同一句话每次回复可能不同。如果回复质量波动明显可以调整采样参数。在调用 Ollama 时增加optionsresp requests.post( OLLAMA_URL, json{ model: MODEL_NAME, messages: messages, stream: False, options: { temperature: 0.3, top_p: 0.8, }, }, timeout120, )temperature越低输出越稳定top_p控制候选词范围。对于机器人对话场景建议把温度设置在 0.3 到 0.7 之间既能保持自然又不会过于发散。8. 最佳实践与工程建议8.1 模型管理与版本控制Hugging Face 的模型仓库本身就是做版本控制的每次提交都会有 hash。在项目里不要只记录“我下载了某模型”建议把模型仓库 ID、量化格式、文件 hash、下载日期写进README.md或配置文件。这样当模型更新时可以快速还原旧版本也能方便团队其他人复现环境。代码层面尽量把模型名和 Ollama 地址放到配置文件或环境变量里而不是散落在代码中。例如借助pydantic-settings读取.env文件避免每次修改都要改代码。8.2 接口幂等与超时控制机器人场景的请求经常需要重试因此接口设计要考虑幂等性。当前/chat接口每次请求都会新增对话历史如果客户端超时后重发同样的消息历史里会出现重复内容。更健壮的做法是让客户端在请求头里带一个request_id服务端根据 ID 去重避免同一指令被重复执行。超时设置也很关键。请求 Ollama 的超时时间要远大于普通数据库请求建议设置为 120 秒而 FastAPI 对外层的超时可以更短配合异步任务队列把长时间推理放到后台执行前端先返回“正在思考”的状态。8.3 安全边界给机器人开放 HTTP 接口时默认不要暴露到公网。如果确实需要通过公网访问务必在网关层加认证比如 API Key 或 JWT。机器人可以接受用户指令但不能被随意控制特别是涉及电机、舵机等执行器时要在服务端做指令白名单不允许模型输出直接驱动硬件。如果机器人带有摄像头和麦克风隐私问题更需要注意。采集的数据尽量只在本地处理不要上传到不受信任的第三方服务日志中也不要记录完整的人脸画面或敏感对话。8.4 开源合规使用开源模型和数据集时要留意各自的 License。Hugging Face 仓库页面通常会有许可证说明有的模型允许商用有的只允许研究使用。Microduck 是开源硬件项目但“开源”不代表无限制使用你在它之上开发应用时要同时遵守硬件、模型、数据集三部分的许可证要求。建议在项目里单独建立LICENSES.md把所有用到的模型、数据集、软件包的许可证列清楚避免后续商业化时踩法律风险。8.5 从仿真到真机在真机阶段起步不要直接跑复杂动作。先做好三件事验证运动控制可以紧急停止验证模型输出到执行器的通路有超时保护验证摄像头和传感器数据在低延迟下能到达主控。很多开源机器人项目失败不是因为模型效果差而是硬件安全机制没有做好。如果条件有限也可以先在 Gazebo、MuJoCo 等仿真环境里跑一遍再迁移到 Microduck 实物。仿真环境能帮你快速调试路径规划和感知算法减少真机损坏风险。9. 总结与下一步围绕 Hugging Face 开源机器人 Microduck 的方向本文完成了从模型下载、本地推理、HTTP 接口封装到语音视觉扩展的完整闭环。核心链路是 Hugging Face 获取 GGUF 模型Ollama 负责加载和推理FastAPI 对外提供/chat接口后续再按需接入 OpenCV 和 edge-tts。这套方案不依赖特定硬件Microduck、树莓派小车或者普通电脑都能跑。下一步建议优先做三件事先把/chat接口接到开发板的扬声器和麦克风上完成语音问答再把摄像头画面做简单目标检测把检测结果拼进提示词让模型能“看见”环境最后再考虑运动控制把模型输出的结构化指令映射成电机动作。每一步都尽量拆小独立验证后再组合。开源机器人最有意思的地方就是把模型、硬件和工程串起来形成真实系统这个过程比单纯跑通一个 demo 有价值得多。
返回列表