尧图网页设计 
正文最近实验室进了一块 VisionFive 2同事的第一反应是这玩意儿能跑机器人说实话在看到这块板子之前我也觉得 RISC-V 和机器人之间至少隔着两道坎——一道是算力一道是生态。但这几个月实操下来我得出的结论是不仅能跑而且能跑得挺漂亮。这篇文章就基于我们用 VisionFive 2 驱动一台四自由度机械臂的完整工程把视觉识别、闭环控制以及最近很火的 Agent API 和 MCP 协议全部串起来的折腾记录。文章会附上核心代码但更重要的是把这些环节背后的选型逻辑和坑讲清楚。这个项目适合谁参考如果你手里刚好有一块 RISC-V 开发板想干点视觉的活或者你在做机械臂但总感觉视觉和运动控制是“两张皮”再或者你对 MCP 在嵌入式侧的应用感兴趣这篇文章的思路和代码都能直接抄作业。我尽量把每个环节的“为什么这么做”也讲透而不是简单甩一段能跑的代码。好先从我最初的那点偏见说起。1. 项目为什么选“RISC-V 视觉闭环 Agent”这个组合1.1 RISC-V 能不能跑机器人的核心疑问很多人一听 RISC-V 就跑机器人第一反应是“算力够吗”。这个担忧有道理因为机器人视觉和运动规划普遍被认为是高算力场景。但这里要先区分一个概念机器人系统的算力需求是分层的。底层关节伺服、电流环、插补运算其实是实时性敏感但算力要求并不夸张的活中层要跑视觉、路径规划确实需要较强的并行计算能力上层如果是决策和任务编排更多考验的是软件生态和内存带宽。RISC-V 目前的生态位置恰好在前两层尤其是配备向量扩展单元RVV的芯片在矩阵运算、滤波、卷积这类常见视觉任务上并不吃亏。VisionFive 2 用的 JH7110 处理器集成 IMG BXE GPU 和硬件编码单元其 2.0 TOPS 的 NPU 算力虽然比不了桌面级 GPU但对单路 YOLO 系模型的 int8 推理已经足够。实际上我们现在能在这个平台上跑 YOLOE关键不是算力跑不跑得动的问题而是工具链是否到位、驱动是否顺手的问题。1.2 为什么视觉闭环是机械臂工程的“骨架”机械臂如果只是一堆舵机或伺服电机的组合做位置示教和复现当然没问题。但一旦目标物体位置漂移、环境光照变化、或者抓取对象的形态有差异盲操就完全失效了。视觉闭环的核心不只是“看见了再动”而是把摄像头返回的像素坐标转成机器人坐标系下的位移量再通过运动规划让末端执行器动态逼近目标。这个闭环拆开看就是四个环节采集图像、目标检测、坐标变换、运动控制。恰好这四个环节在 RISC-V 平台都有可落地的路径——采集用 V4L2目标检测用 NPU 推理 YOLOE坐标变换是纯几何运算运动控制走串口或者 CAN 总线。整条链路没有哪一个环节依赖特定指令集这本身就是 RISC-V 能跑机器人的底气。1.3 Agent API 和 MCP 在这里扮演什么角色最早我们做的只是“识别——定位——抓取”的固定循环。后来遇到一个问题目标种类一变程序就得改逻辑一多代码里全是 if else。直到把 Agent API 和 MCPModel Context Protocol接进来这个系统的形态才真正变了——视觉模型 YOLOE 负责感知Agent 负责理解任务意图MCP 则把感知结果和机械臂控制接口暴露成标准化的工具供 Agent 调用。简单来说Agent API 让大模型有了“眼睛”视觉坐标和“手”控制接口MCP 则解决了“模型该以什么格式调用这些能力”的标准化问题。实际上这套组合的交互流程是用户用自然语言说“把红色方块挪到蓝色圆圈旁”Agent 解析意图后通过 MCP 工具调用 YOLOE 获取目标和容器坐标再调用机械臂控制接口执行抓放动作。整个过程用户不需要写一行运动学代码。把这三层组合起来RISC-V 开发板上的机器人就不再是一个跑死循环的模型而是一个可以被大模型“指挥”的物理实体。这个方向的想象空间很大但落地难度集中在标准协议和实时性之间的平衡上。2. 视觉方案选型从 YOLO 到 YOLOE 的部署路线2.1 为什么选 YOLOE 而不是直接上 YOLOv8YOLO 系列更新到现在大家其实已经有点审美疲劳了。但在嵌入式设备上选型不能只看精度排行榜得看几个硬指标是否支持 int8 量化、是否有官方 ONNX 导出、后处理代码是否好改、是否依赖动态维度。YOLOE 相较之前的版本最大的优势是语义和实例分割的统一性——它能同时输出检测框、实例掩码还能以文本提示的方式开放词汇检测。这对机器人抓取的意义在于同一个模型可以应对“抓红色马克杯”和“抓桌上的杯子”这类语义理解而不是把所有品类都写死在训练集里。在 RISC-V 平台上部署 YOLOE比想象中顺利但也比想象中麻烦。顺利在 ONNX Runtime 的 RISC-V 版本已经可用麻烦在 NPU 驱动对模型的算子支持不完整。最后我们的方案是双轨制开发调试阶段在板端用 CPU 跑 FP32 ONNX 模型验证算法上线阶段再转成 NPU 可加载的 int8 格式。实测下来前三层卷积在 NPU 上运算速度约为 CPU 的 4 到 5 倍但最后几层包括一些上采样算子因为驱动不支持只能回落 CPU整体推理延迟控制在 80ms 到 120ms 之间对这个用例完全可以接受。2.2 VisionFive 2 上部署 YOLOE 的环境搭建很多人在开发板上卡住其实不是代码问题而是环境问题。VisionFive 2 默认系统是 Ubuntu 22.04内核版本 5.15 左右自带的 Python 是 3.10这些版本组合在安装某些依赖时会有不少隐坑。我们的环境是这样的系统装在 TF 卡上但 Python 环境特意放到了外接 NVMe 固态硬盘。这是因为 YOLOE 预处理用到的 OpenCV 和推理时用到的 ONNX Runtime 库文件体积不小TF 卡的随机读写性能会让启动和加载总耗时拉到非常难看的程度。实测同一套模型把环境和模型文件从 TF 卡迁移到 NVMe 后冷启动时间从 48 秒降到了 11 秒推理单帧时间其实没变但体感好了很多。安装依赖时有一个关键点ONNX Runtime 的 RV64 版本不能直接从 pip 默认源拉取需要明确指定 Python 版本对应的 wheel 文件。我当时第一次不指定版本直接 pip install结果拉到的是 x86_64 架构包跑起来直接报 Illegal instruction 崩溃。这个坑让我浪费了一个工作日后来老老实实从官方带 release 页面手动下载onnxruntime-*.cp310-cp310-linux_aarch64.whl的 RV64 专用版本才解决。YOLOE 的推理预处理里有一处需要注意letterbox操作会改变图像尺寸比例如果后续需要把检测框映射回原始图像坐标必须记录原始宽高和处理宽高的比例。传统 YOLO 系列的代码里一般自带这个映射但 YOLOE 的示例程序因为面向多样任务有些版本没有默认输出原始坐标这两行代码是你必须自己补上的。我们实际用的代码是import cv2 import numpy as np import onnxruntime as ort # 加载模型时会自动选择 CPUExecutionProvider session ort.InferenceSession(yoloe_seg.onnx, providers[CPUExecutionProvider]) def preprocess(image, input_size640): orig_h, orig_w image.shape[:2] ratio min(input_size / orig_w, input_size / orig_h) new_w, new_h int(orig_w * ratio), int(orig_h * ratio) resized cv2.resize(image, (new_w, new_h)) canvas np.full((input_size, input_size, 3), 114, dtypenp.uint8) x_offset, y_offset (input_size - new_w) // 2, (input_size - new_h) // 2 canvas[y_offset:y_offset new_h, x_offset:x_offset new_w] resized return canvas, ratio, x_offset, y_offset image cv2.imread(scene.jpg) input_blob, ratio, dx, dy preprocess(image) input_blob input_blob.astype(np.float32) / 255.0 input_blob input_blob.transpose(2, 0, 1)[None, ...] outputs session.run(None, {images: input_blob}) # 后处理由官方代码裁剪而来主力是 NMS 坐标映射 boxes postprocess(outputs, ratio, dx, dy, image.shape[:2])这套代码在板子上跑 CPU 版本的推理单帧大约 200ms如果切到 NPU需要先跑一步模型转换后面会细说。2.3 模型量化和 NPU 部署的取舍NPU 部署的流程跟很多平台的流程类似从 PyTorch 导出 ONNX再用各自工具链转换成芯片私有格式。VisionFive 2 的 NPU 官方支持 ONNX、Caffe、TFLite 等格式的转换但对某些算子的限制比较严格。我们遇到最大的问题是 YOLOE 的 DFLDistribution Focal Loss解码和掩码分支的矩阵乘法在量化后精度损失明显边框位置抖动几像素对抓取影响不大但分割掩码边缘“糊”了。后来我们是绕过的把模型拆成两段检测头部分走 NPU掩码分支直接丢到 CPU 跑 ONNX。这种“混合推理”听起来高大上其实实现起来就是在 Python 里先跑一次 NPU再跑一次 CPU做一次拼接。如果你只是想复现“检测到物体并抓取”这个流程而不是非要跑出完美的分割掩码我建议直接放弃 NPU 上的掩码分支用检测框的中心点做抓取目标的依据精度完全够还能省掉大量模型转换的调参时间。毕竟机械臂的吸盘或者夹爪本身就有一定的容错范围检测框偏移三五毫米在大多数场景下毫无影响。3. 视觉闭环核心实现坐标变换与机械臂控制3.1 像素坐标到机器人坐标的映射方法视觉闭环里最难的一步往往不是识别而是把图像坐标变成机械臂能用的坐标。很多新手一开始想用标定板做完整相机-机器人标定但对于四自由度机械臂和一个俯视安装的摄像头其实可以用更朴素的方案实现单应性变换。单应性变换的本质是假设物体都在同一个平面上比如桌面通过四个已知点的像素坐标和真实坐标解出一个 3x3 的变换矩阵。这是平面视觉抓取的标准操作不需要计算相机内参不需要做畸变校正只要摄像头固定、目标平面固定效果就很好。实现也很直接def compute_homography(src_points, dst_points): # src_points 是图像像素坐标dst_points 是机械臂基座标系下的物理坐标 H, _ cv2.findHomography( np.array(src_points, dtypenp.float32), np.array(dst_points, dtypenp.float32), methodcv2.RANSAC ) return H def pixel_to_robot(u, v, H): p np.array([u, v, 1.0]) q H p q / q[2] return q[0], q[1]操作时先控制机械臂末端分别停在四个已知位置记录下像素坐标和物理坐标然后跑一遍compute_homography。这个矩阵理论上只跟相机安装姿态和桌面高度有关只要不碰相机和底座就能一直用。一定要注意的是单应性变换对相机畸变敏感。如果你用的是广角摄像头或者图像边缘有比较明显的拉长建议先做一次内参标定和畸变校正。我们用的是一颗普通 1080p USB 摄像头视场角 60 度左右畸变不明显因此直接跳过校正。如果你发现离中心越远定位偏差越大十有八九就是畸变在作怪。3.2 机械臂逆解与夹爪补偿拿到目标在机器人基座标系里的 X、Y 坐标之后还剩一个高度 Z。对于平面抓取来说Z 通常设为一个固定值对应桌面高度。四自由度机械臂的逆运动学在这个场景下可以简化成两段先通过 X、Y 算出大臂和小臂的关节角再通过目标高度算升降关节。VisionFive 2 本身做三角函数的运算没有任何压力逆解代码也是一套标准的几何法。我直接把核心代码贴出来。不过实际抓取时会遇到一个细节摄像头拍到的目标中心是物体的质心但夹爪开口方向不一定是正对着质心的。如果物体是长条的夹爪只夹边缘很容易滑脱。我们的解决办法是在逆解后加一个按姿态角旋转的偏移量import math def inverse_kinematics(x, y, z, l1120.0, l2120.0): # 输入目标位置输出大臂、小臂、升降关节的目标角度/长度 dist math.hypot(x, y) # 升降关节直接取 z lift z # 俯视图下的旋转角 base_angle math.atan2(y, x) # 平面内距离目标在机械臂基座水平面上的分量 r math.sqrt(dist * dist - (l1 - l2) * (l1 - l2)) if dist abs(l1 - l2) else 0.0 # 余弦定理求小臂相对大臂的角度 cos_angle (l1 * l1 l2 * l2 - r * r) / (2 * l1 * l2) cos_angle max(-1.0, min(1.0, cos_angle)) elbow_angle math.acos(cos_angle) return base_angle, elbow_angle, lift这段代码做的是理想化几何解没有考虑关节限位和奇异点。实际控制时我们还会加一个判断如果某个关节角超出硬件限位范围就报错并提示“目标不可达”。这是机器人最容易“咔哒”一声把齿轮打坏的地方必须提前处理。3.3 串口指令协议与执行状态机机械臂底层我们用了一块市售的四自由度舵机驱动板板子通过串口接收角度指令返回角度到位状态。RISC-V 板子跟驱动板之间的通信协议很简单帧头加 ID 加数据加校验。一个容易踩的坑是串口写数据之后立刻读返回经常读不到或者读到半包。原因是舵机驱动板的响应延迟不确定尤其是舵机在运动过程中状态查询可能被阻塞。我们改成了典型的生产者-消费者模型控制线程只负责发指令和读返回但状态判断线程会轮询“运动是否完成”标志避免在串口上做阻塞式等待。用 Python 的pyserial读写核心逻辑如下。为了稳定性串口超时设成 0.05 秒每次读写前清空缓冲区防止脏数据。import serial import struct import time class ArmSerial: def __init__(self, port/dev/ttyUSB0, baud115200): self.ser serial.Serial(port, baud, timeout0.05) self.ser.reset_input_buffer() def _checksum(self, data): return sum(data) 0xFF def send_angle(self, joint_id, angle_deg): # 把角度映射成 0~1000 的 PWM 值 pwm int((angle_deg 90) / 180 * 1000) frame bytearray([0xAA, joint_id, 0x03, (pwm 8) 0xFF, pwm 0xFF]) frame.append(self._checksum(frame)) self.ser.write(frame) def read_status(self, joint_id, timeout1.0): deadline time.time() timeout while time.time() deadline: if self.ser.in_waiting 6: raw self.ser.read(6) if raw[0] ! 0xAA or raw[1] ! joint_id: continue return raw[3] 0 # 第三个字节为运动状态位 time.sleep(0.01) return None3.4 抓取状态机的整体编排闭合回路的整体逻辑用有限状态机来编排是最清晰的。我们把任务拆成了几个状态等待目标、目标锁定、移到上空、下降抓取、抬升确认、放回指定位置。每个状态对应一个函数状态之间通过事件触发切换。这里我要强调一个经验千万不要把视觉识别和机械臂运动写在一个死循环里同步执行。因为舵机运动通常需要一秒多如果每帧都等目标检测的 100ms整个系统的响应会显得很“木”。我们把视觉识别单独放一个线程只更新最新的目标位置控制线程按自己的节奏读这个最新位置并执行动作。这样即使视觉偶尔丢帧机械臂也不会停顿。核心状态机的大致写法class GrabStateMachine: def __init__(self, arm, detector): self.arm arm self.detector detector self.state IDLE def step(self): if self.state IDLE: target self.detector.find_target(bottle) if target is not None: self.target_xy target self.state APPROACH elif self.state APPROACH: x, y pixel_to_robot(self.target_xy[0], self.target_xy[1], H) self.arm.move_to(x, y, z_ready) self.state GRASP elif self.state GRASP: self.arm.grasp() self.state LIFT elif self.state LIFT: self.arm.move_to(self.place_x, self.place_y, z_lift) self.arm.release() self.state IDLE这样写的好处是每个动作都有明确的出口后续加“检测失败重试”“夹爪空抓检测”也只需要在对应状态里加条件转移改动成本很低。4. Agent API 与 MCP 集成让大模型指挥机械臂4.1 为什么要用 Agent API 包装视觉和运动能力直接写死状态机有一个天花板任务一变程序就得改。我们希望用户能通过自然语言下达指令比如“把桌面上所有红色的东西收到左边的盒子里”这种命令如果用传统方式写要枚举颜色、形状、目标位置代码量爆炸。但通过 Agent API大模型本身具备较强的推理能力可以做任务分解、条件判断和异常规避。Agent API 在这里起的作用不是替代视觉模型而是编排视觉模型和运动控制。视觉和运动仍然是用传统代码实现只是被包装成“工具”tool大模型根据需要来调用。做法其实很简单把“识别位置”“移动到坐标”“抓取”“放置”这四件事封装成函数把函数名、参数和说明通过 JSON Schema 描述给 Agent大模型按格式返回调用请求。这里借用 OpenAI 的 Function Calling 风格的接口设计文中的 Agent API 泛指支持这类插件式调用的模型接口核心代码如下tools [ { type: function, function: { name: find_object, description: 在摄像头画面中查找指定类别的目标返回像素坐标, parameters: { type: object, properties: { class_name: {type: string, description: 目标类别如 bottle, cup} }, required: [class_name] } } }, { type: function, function: { name: grab_object, description: 抓取指定坐标处的物体, parameters: { type: object, properties: { x: {type: number}, y: {type: number} }, required: [x, y] } } } ]4.2 MCP 在其中的标准化作用Agent API 的函数调用是模型生态内部的标准但现实中我们要面对的不仅是模型自己的接口还有外部系统的资源。比如把 YOLOE 的检测服务、机械臂控制服务、甚至蓝湖设计稿上机器人的形态都暴露成独立的信息源或工具。如果没有一个标准协议每接一个服务就得写一套接口适配非常零碎。MCP 的价值就在这里——它是一种“模型与工具之间”的开放协议把资源resources、工具tools、提示词prompts统一描述Agent 不再需要硬编码调用每个服务的 SDK而是通过 MCP 客户端发现、调用。举个例子我们的机械臂控制模块实现成一个标准 MCP server 后任何兼容 MCP 的 Agent比如 Trae、Cursor 或其他支持 MCP 的框架都能直接操作这只机械臂不需要为不同的 Agent 框架各写一遍适配代码。MCP server 的 demo 做起来并不复杂。下面是一个用 Python 实现的极简 MCP 服务它暴露了“查询机械臂状态”和“执行移动”两个工具采用 JSON-RPC 风格的协议class MCPServer: def __init__(self, arm): self.arm arm self.tools { arm_move: self.arm_move, arm_status: self.arm_status } def handle_request(self, req): if req.get(method) tools/list: return {tools: [ {name: arm_move, description: 移动机械臂到目标坐标}, {name: arm_status, description: 获取机械臂当前状态} ]} elif req.get(method) tools/call: tool_name req[params][name] args req[params][arguments] return self.tools[tool_name](**args) return {error: unknown method} def arm_move(self, x, y, z): self.arm.move_to(x, y, z) return {status: ok} def arm_status(self): return {status: self.arm.get_state()}接上 MCP 之后Agent 写出来的决策代码里不再含任何硬件操作细节它只需要按 MCP 规范发请求、收结果。这就实现了“模型只负责思考工具只负责执行”的分层解耦。4.3 自然语言到机器人动作的完整链路我们做了一个简单的测试入口在板上运行一个 WebSocket 服务用户打开网页输入“找一个红色杯子然后抓起来放到左边”请求返回后依次看到 Agent 调用了 find_object、辨别像素坐标、调用 pixel_to_robot 转换、再调用 arm_move 和 grab_object。整个过程像看一个小型剧本在你眼前展开。这个链路里最核心的一环是“坐标转换由谁做”。最开始的版本让 Agent 直接读像素坐标再传回机械臂执行结果机械臂抓偏了。后来我们把坐标转换封装在 arm_move 的 MCP 工具内部Agent 传入的仍然是像素坐标但工具内部会自动做单应性变换。所以大模型不需要“知道”相机标定矩阵也不需要“理解”机械臂基座坐标系这些底层细节对模型透明。这是一个非常好的设计原则工具接口面向任务语义而不是面向实现细节。4.4 Computer Use 与 MCP 的边界理解这个话题最近讨论热度很高很多人分不清 Computer Use 和 MCP 的区别顺手讲一下我的理解。MCP 是模型与工具之间的通道协议它面向的是“工具与数据源”的连接而 Computer Use 更像是模型通过截图、鼠标键盘事件去操作整个桌面或网页。二者一个是“给模型一把扳手”一个是“让模型自己上手去拧螺丝”。在机器人场景里我们显然更需要前者——你不可能让大模型通过截图去看机械臂的物理位置它需要的是能够表达“当前执行器角度”和“目标世界坐标”的结构化接口。MCP 的好处不只是方便模型调用还有一个容易被忽略的点审计和权限控制。通过 MCP server 暴露机械臂控制接口可以让 Agent 调用前走一层校验比如“是否已经确认目标位置不为空”“夹爪当前位置是否安全”。这层保护对实体机器人来说至关重要——毕竟大模型一旦幻觉发出的指令可能是“抬到 10 米高”。5. 实操记录RISC-V 板上的完整跑通流程5.1 硬件清单与接线图VisionFive 2 开发板8GB 版本系统和环境装在 NVMe SSD 上1080p USB 摄像头固定俯视安装视角覆盖机械臂工作区域四自由度舵机机械臂 驱动板串口接口115200 波特率一块 5V/3A 稳压电源给驱动板供电跟 VisionFive 2 供电分开桌面上一张 A4 纸用笔标记了四个单应性标定点接线其实就两路USB 摄像头插板上任意 USB 口驱动板接 USB-TTL 转串口模块RX/TX 交叉连接GND 必须共地。这里特别提醒舵机驱动板和大功率舵机如果跟开发板共用一个电源极易引起电压跌落导致系统重启。我们前期调试时遇到过几次开发板莫名重启最后发现是舵机瞬间电流把 5V 拉低了。分离供电之后问题彻底消失。5.2 环境搭建和依赖清单Ubuntu 22.04SDK 自带镜像Python 3.10 virtualenvOpenCV 4.8从源码编译带 GTK 支持方便调试窗口显示onnxruntime 1.16.0RV64 专用版本pyserial 3.5websockets 12.0transformers、torch 只安装在开发机上用来导出模型板端只跑 ONNX Runtime这里让我纠结的是 OpenCV 编译时长。在 VisionFive 2 上从源码编译 OpenCV 需要大约 40 分钟CPU 全核跑满风扇呼呼的。如果你只是做推理不做 GUI可以直接 pip 装预编译版本但版本可能比较旧而且部分算子缺失。我们是编译了带 GTK 支持的版本因为调试阶段要弹窗口可视化检测框方便快速判断模型效果。架构检查的常用命令uname -m cat /proc/cpuinfo | grep isa python3 -c import onnxruntime; print(onnxruntime.get_device())如果你跑cat /proc/cpuinfo能看到rv64imafdc或者类似包含v扩展的 ISA 字符串说明芯片支持向量扩展向量扩展对矩阵类运算的性能提升很关键。如果没看到v后续做 NPU 转换时也不会有影响只是 CPU 推理会慢一些。5.3 模型转换和 NPU 加载过程模型转换的步骤说白了就是PyTorch 权重 → ONNX → 芯片定制的 NPU 格式。前两步大家都熟最后一步用的是芯片厂商提供的工具链。工具链在官方 SDK 的 tools 目录里读入 ONNX设置量化方式跑完会生成一个.nb或类似格式的文件。转换过程中需要指定输入图像尺寸这个尺寸必须是 16 的倍数一般是 640×640。如果你的部署图像不是正方形要在预处理里做 letterbox。量化校准需要准备 100 张左右的代表性图片我们直接用测试集里的 80 张。精度方面int8 之后检测框的 mAP 掉了大概 3 到 5 个点但对真实场景抓取来说这个精度损失不影响。真正耗时间的是算子兼容性排查。每次工具链报“unsupported op”你就得回 ONNX 图里找到那个算子要么在导出时用opset_version兼容版本要么在 ONNX 图里做算子替换。我们遇到过几次Resize算子和Gather算子的问题最后是通过把模型拆成两段解决的一段走 NPU一段走 CPU完全绕开了不支持算子的转换。5.4 全链路联调从识别到抓取的实时效果联调当天我们把 10 个不同形状的物件放在桌面不同位置目标是从识别到抓取完成整个过程在自然语言指令“找出所有圆柱体并把它们放到右上角”下自动执行。Agent 先调用 YOLOE 检测输出 4 个候选目标框再遍历每个目标计算坐标逆解生成关节角逐一下发指令抓取。三件物品依次抓完大约花了 12 秒。比起来我们最初用脚本写死的版本慢了 2 秒左右慢在 Agent 的接口调用和 JSON 解析上。但换来的是系统从“只能抓固定颜色”变成“听得懂语义指令”这 2 秒的代价完全值。板端 CPU 占用情况检测阶段四个核接近 90%运动控制阶段明显下降。内存占用整体 2.1GB8GB 版本很从容。板卡温度最高 72 摄氏度加了一个小风扇后稳定在 58 摄氏度左右。这块板子如果长时间跑视觉推理散热是必须考虑的否则 NPU 和 CPU 在高温下会降频导致单帧推理时间明显变长。6. 常见问题与排查技巧实录6.1 YOLOE 推理出现 NaN 或输出全零这是我们在板子上遇到的第一个头疼问题。现象是输出的检测框数组全是零或者 tensor 里有 NaN。排查思路有几个方向一是模型在转换时有算子部分损坏可以回开发机跑一遍 fp32 ONNX如果正常说明是板端推理环境或量化问题二是输入图像归一化是否做好YOLOE 系列要求输入是[0,1]范围的 float32如果直接传 0~255 的 uint8会出现输出异常这跟我们代码里的input_blob.astype(np.float32) / 255.0直接相关。还有一次我们发现是摄像头返回的图片格式是 BGR而模型预训练时用的可能是 RGB导致检测效果差到离谱。看似绝对正确的小事恰恰是视觉工程里最容易翻车的地方。我的经验是写一个简单的调试工具把送入模型前的图像保存下来可视化看一眼比自己盲猜快得多。6.2 MCP 连接超时或工具调用失败MCP 的开发和远端调试中最容易出现的问题是超时。因为 VisionFive 2 本身性能有限Agent 发起工具调用后模型推理需要 100ms机械臂动作需要 1 到 2 秒而默认的 MCP 超时往往只有 10 秒。如果任务复杂多次推理加多次运动总时长很容易超过超时阈值导致 Agent 误判为“机械臂没有反应”。解决办法也很简单把 MCP 客户端的超时时间调大。有些框架里可以直接配置有些框架是在具体调用代码里传timeout参数。如果你在调试时发现 Agent 返回“tool execution failed”但板端日志显示动作正常执行多半不是设备问题而是超时配置问题。6.3 机械臂夹取偏移这个误差到底出在哪夹取偏移是视觉抓取项目几乎绕不开的问题。如果出现系统性偏移比如总往右边偏 1cm大概率是单应性矩阵的标定点误差或者摄像头安装角度变了。如果偏移是随机的几毫米内的抖动属于正常因为舵机本身也是欠完美执行器。一个缩小误差的实用技巧在标定单应性矩阵时让标定点尽可能覆盖整个工作区域同时避免点集中在中心。四个标定点近似一个长方形边缘尽量接近机械臂可达范围的边界这样整个工作空间内的映射误差会更均匀。我们还写了一个“五点法”复核随便取第五个点输入像素坐标算出物理坐标用尺子量一下偏差通常在 3mm 以内就算标定合格。6.4 开发板存储空间不足VisionFive 2 如果系统装 32GB TF 卡光一个 Ubuntu 系统加基本工具就要占掉 8~10GB再装上 OpenCV、ONNX Runtime、YOLOE 模型空间立刻捉襟见肘。我们的解决办法是所有大型 Python 包和模型文件都移动到 NVMe 固态盘用软链接把.cache目录指到外置盘删除开发机上编译过的临时文件和 pip 缓存模型文件如果体积太大可以转成半精度或者 int8一个 NB 格式大约 20 到 60MB比 fp32 的 100 多 MB 友好很多如果空间实在太紧可以做一个环境销毁脚本把 pip 缓存、编译中间文件定时清理。不建议用 swapTF 卡上的 swap 性能差且寿命短在新版本内核上还容易出现 IO 延迟。6.5 Agent 误判指令和动作执行安全用大模型控制实体机器人最怕的不是它识别不了图片而是它对指令的理解“过于天马行空”。比如你对它说“把物体移走”它可能直接调用 arm_move 传入一个没有经过有效性检查的坐标结果机械臂撞到桌面或夹爪撞到支架。我们在 MCP 工具层做了两道防线第一道是入参范围检查x、y、z 必须在预设的合法区间内超出一律拒绝并返回错误第二道是工位操作前的“预检”比如下降抓取之前会先读取当前夹爪状态和已识别目标是否仍然有效防止空中乱抓。 提醒在实体设备上做 Agent 控制安全措施永远是最重要的部分。不要模型返回什么动作就照做工具层一定要有边界检查。这是我们在工程化阶段最重要的一个教训。7. 这台 RISC-V 机械臂还能怎么扩展这套系统目前跑通的是“平面视觉抓取”这一个简单任务。但框架的可扩展性已经体现在三个方面第一视觉模型可以换。只要你能导出 ONNX 模型并且板端 NPU 工具链支持大部分算子YOLOE、YOLOv8、SAM 这类模型理论上都能替换Agent API 的工具描述只需要改一个函数说明。第二运动控制可以接到 ROS 2 上。目前我们是直接控制舵机如果换成带 ROS 接口的机械臂可以把 MCP server 做成 ROS 2 action 的封装层大模型依然通过 MCP 工具下发任务底层动作全部交给 ROS。第三MCP server 可以部署在远端服务器上VisionFive 2 只做本地推理和运动控制大模型推理放到性能更好的机器上。这样算力解耦边端和云端各干各的活。我最近正在折腾的是把 MCP server 加一个 WebRTC 视频流接口这样 Agent 不仅能读到坐标还能实时“看到”机械臂的工作画面做更复杂的空间推理。这个方向还在实验阶段等稳定了再单独写一篇分享。回到最初的问题RISC-V 能不能跑机器人答案是可以而且比很多人想象的要好。它的价值不在于“性能碾压”而在于它提供了一条自主可控的嵌入式智能机器人路径同时用标准的接口MCP、ONNX Runtime串起了视觉模型、Agent 和运动控制。未来的嵌入式 AI 机器人未必只是高端 x86 平台的独角戏RISC-V 这条路会越走越宽。 RISC-V开发板驱动机械臂：YOLOE视觉闭环与Agent/MCP集成实践
正文最近实验室进了一块 VisionFive 2同事的第一反应是这玩意儿能跑机器人说实话在看到这块板子之前我也觉得 RISC-V 和机器人之间至少隔着两道坎——一道是算力一道是生态。但这几个月实操下来我得出的结论是不仅能跑而且能跑得挺漂亮。这篇文章就基于我们用 VisionFive 2 驱动一台四自由度机械臂的完整工程把视觉识别、闭环控制以及最近很火的 Agent API 和 MCP 协议全部串起来的折腾记录。文章会附上核心代码但更重要的是把这些环节背后的选型逻辑和坑讲清楚。这个项目适合谁参考如果你手里刚好有一块 RISC-V 开发板想干点视觉的活或者你在做机械臂但总感觉视觉和运动控制是“两张皮”再或者你对 MCP 在嵌入式侧的应用感兴趣这篇文章的思路和代码都能直接抄作业。我尽量把每个环节的“为什么这么做”也讲透而不是简单甩一段能跑的代码。好先从我最初的那点偏见说起。1. 项目为什么选“RISC-V 视觉闭环 Agent”这个组合1.1 RISC-V 能不能跑机器人的核心疑问很多人一听 RISC-V 就跑机器人第一反应是“算力够吗”。这个担忧有道理因为机器人视觉和运动规划普遍被认为是高算力场景。但这里要先区分一个概念机器人系统的算力需求是分层的。底层关节伺服、电流环、插补运算其实是实时性敏感但算力要求并不夸张的活中层要跑视觉、路径规划确实需要较强的并行计算能力上层如果是决策和任务编排更多考验的是软件生态和内存带宽。RISC-V 目前的生态位置恰好在前两层尤其是配备向量扩展单元RVV的芯片在矩阵运算、滤波、卷积这类常见视觉任务上并不吃亏。VisionFive 2 用的 JH7110 处理器集成 IMG BXE GPU 和硬件编码单元其 2.0 TOPS 的 NPU 算力虽然比不了桌面级 GPU但对单路 YOLO 系模型的 int8 推理已经足够。实际上我们现在能在这个平台上跑 YOLOE关键不是算力跑不跑得动的问题而是工具链是否到位、驱动是否顺手的问题。1.2 为什么视觉闭环是机械臂工程的“骨架”机械臂如果只是一堆舵机或伺服电机的组合做位置示教和复现当然没问题。但一旦目标物体位置漂移、环境光照变化、或者抓取对象的形态有差异盲操就完全失效了。视觉闭环的核心不只是“看见了再动”而是把摄像头返回的像素坐标转成机器人坐标系下的位移量再通过运动规划让末端执行器动态逼近目标。这个闭环拆开看就是四个环节采集图像、目标检测、坐标变换、运动控制。恰好这四个环节在 RISC-V 平台都有可落地的路径——采集用 V4L2目标检测用 NPU 推理 YOLOE坐标变换是纯几何运算运动控制走串口或者 CAN 总线。整条链路没有哪一个环节依赖特定指令集这本身就是 RISC-V 能跑机器人的底气。1.3 Agent API 和 MCP 在这里扮演什么角色最早我们做的只是“识别——定位——抓取”的固定循环。后来遇到一个问题目标种类一变程序就得改逻辑一多代码里全是 if else。直到把 Agent API 和 MCPModel Context Protocol接进来这个系统的形态才真正变了——视觉模型 YOLOE 负责感知Agent 负责理解任务意图MCP 则把感知结果和机械臂控制接口暴露成标准化的工具供 Agent 调用。简单来说Agent API 让大模型有了“眼睛”视觉坐标和“手”控制接口MCP 则解决了“模型该以什么格式调用这些能力”的标准化问题。实际上这套组合的交互流程是用户用自然语言说“把红色方块挪到蓝色圆圈旁”Agent 解析意图后通过 MCP 工具调用 YOLOE 获取目标和容器坐标再调用机械臂控制接口执行抓放动作。整个过程用户不需要写一行运动学代码。把这三层组合起来RISC-V 开发板上的机器人就不再是一个跑死循环的模型而是一个可以被大模型“指挥”的物理实体。这个方向的想象空间很大但落地难度集中在标准协议和实时性之间的平衡上。2. 视觉方案选型从 YOLO 到 YOLOE 的部署路线2.1 为什么选 YOLOE 而不是直接上 YOLOv8YOLO 系列更新到现在大家其实已经有点审美疲劳了。但在嵌入式设备上选型不能只看精度排行榜得看几个硬指标是否支持 int8 量化、是否有官方 ONNX 导出、后处理代码是否好改、是否依赖动态维度。YOLOE 相较之前的版本最大的优势是语义和实例分割的统一性——它能同时输出检测框、实例掩码还能以文本提示的方式开放词汇检测。这对机器人抓取的意义在于同一个模型可以应对“抓红色马克杯”和“抓桌上的杯子”这类语义理解而不是把所有品类都写死在训练集里。在 RISC-V 平台上部署 YOLOE比想象中顺利但也比想象中麻烦。顺利在 ONNX Runtime 的 RISC-V 版本已经可用麻烦在 NPU 驱动对模型的算子支持不完整。最后我们的方案是双轨制开发调试阶段在板端用 CPU 跑 FP32 ONNX 模型验证算法上线阶段再转成 NPU 可加载的 int8 格式。实测下来前三层卷积在 NPU 上运算速度约为 CPU 的 4 到 5 倍但最后几层包括一些上采样算子因为驱动不支持只能回落 CPU整体推理延迟控制在 80ms 到 120ms 之间对这个用例完全可以接受。2.2 VisionFive 2 上部署 YOLOE 的环境搭建很多人在开发板上卡住其实不是代码问题而是环境问题。VisionFive 2 默认系统是 Ubuntu 22.04内核版本 5.15 左右自带的 Python 是 3.10这些版本组合在安装某些依赖时会有不少隐坑。我们的环境是这样的系统装在 TF 卡上但 Python 环境特意放到了外接 NVMe 固态硬盘。这是因为 YOLOE 预处理用到的 OpenCV 和推理时用到的 ONNX Runtime 库文件体积不小TF 卡的随机读写性能会让启动和加载总耗时拉到非常难看的程度。实测同一套模型把环境和模型文件从 TF 卡迁移到 NVMe 后冷启动时间从 48 秒降到了 11 秒推理单帧时间其实没变但体感好了很多。安装依赖时有一个关键点ONNX Runtime 的 RV64 版本不能直接从 pip 默认源拉取需要明确指定 Python 版本对应的 wheel 文件。我当时第一次不指定版本直接 pip install结果拉到的是 x86_64 架构包跑起来直接报 Illegal instruction 崩溃。这个坑让我浪费了一个工作日后来老老实实从官方带 release 页面手动下载onnxruntime-*.cp310-cp310-linux_aarch64.whl的 RV64 专用版本才解决。YOLOE 的推理预处理里有一处需要注意letterbox操作会改变图像尺寸比例如果后续需要把检测框映射回原始图像坐标必须记录原始宽高和处理宽高的比例。传统 YOLO 系列的代码里一般自带这个映射但 YOLOE 的示例程序因为面向多样任务有些版本没有默认输出原始坐标这两行代码是你必须自己补上的。我们实际用的代码是import cv2 import numpy as np import onnxruntime as ort # 加载模型时会自动选择 CPUExecutionProvider session ort.InferenceSession(yoloe_seg.onnx, providers[CPUExecutionProvider]) def preprocess(image, input_size640): orig_h, orig_w image.shape[:2] ratio min(input_size / orig_w, input_size / orig_h) new_w, new_h int(orig_w * ratio), int(orig_h * ratio) resized cv2.resize(image, (new_w, new_h)) canvas np.full((input_size, input_size, 3), 114, dtypenp.uint8) x_offset, y_offset (input_size - new_w) // 2, (input_size - new_h) // 2 canvas[y_offset:y_offset new_h, x_offset:x_offset new_w] resized return canvas, ratio, x_offset, y_offset image cv2.imread(scene.jpg) input_blob, ratio, dx, dy preprocess(image) input_blob input_blob.astype(np.float32) / 255.0 input_blob input_blob.transpose(2, 0, 1)[None, ...] outputs session.run(None, {images: input_blob}) # 后处理由官方代码裁剪而来主力是 NMS 坐标映射 boxes postprocess(outputs, ratio, dx, dy, image.shape[:2])这套代码在板子上跑 CPU 版本的推理单帧大约 200ms如果切到 NPU需要先跑一步模型转换后面会细说。2.3 模型量化和 NPU 部署的取舍NPU 部署的流程跟很多平台的流程类似从 PyTorch 导出 ONNX再用各自工具链转换成芯片私有格式。VisionFive 2 的 NPU 官方支持 ONNX、Caffe、TFLite 等格式的转换但对某些算子的限制比较严格。我们遇到最大的问题是 YOLOE 的 DFLDistribution Focal Loss解码和掩码分支的矩阵乘法在量化后精度损失明显边框位置抖动几像素对抓取影响不大但分割掩码边缘“糊”了。后来我们是绕过的把模型拆成两段检测头部分走 NPU掩码分支直接丢到 CPU 跑 ONNX。这种“混合推理”听起来高大上其实实现起来就是在 Python 里先跑一次 NPU再跑一次 CPU做一次拼接。如果你只是想复现“检测到物体并抓取”这个流程而不是非要跑出完美的分割掩码我建议直接放弃 NPU 上的掩码分支用检测框的中心点做抓取目标的依据精度完全够还能省掉大量模型转换的调参时间。毕竟机械臂的吸盘或者夹爪本身就有一定的容错范围检测框偏移三五毫米在大多数场景下毫无影响。3. 视觉闭环核心实现坐标变换与机械臂控制3.1 像素坐标到机器人坐标的映射方法视觉闭环里最难的一步往往不是识别而是把图像坐标变成机械臂能用的坐标。很多新手一开始想用标定板做完整相机-机器人标定但对于四自由度机械臂和一个俯视安装的摄像头其实可以用更朴素的方案实现单应性变换。单应性变换的本质是假设物体都在同一个平面上比如桌面通过四个已知点的像素坐标和真实坐标解出一个 3x3 的变换矩阵。这是平面视觉抓取的标准操作不需要计算相机内参不需要做畸变校正只要摄像头固定、目标平面固定效果就很好。实现也很直接def compute_homography(src_points, dst_points): # src_points 是图像像素坐标dst_points 是机械臂基座标系下的物理坐标 H, _ cv2.findHomography( np.array(src_points, dtypenp.float32), np.array(dst_points, dtypenp.float32), methodcv2.RANSAC ) return H def pixel_to_robot(u, v, H): p np.array([u, v, 1.0]) q H p q / q[2] return q[0], q[1]操作时先控制机械臂末端分别停在四个已知位置记录下像素坐标和物理坐标然后跑一遍compute_homography。这个矩阵理论上只跟相机安装姿态和桌面高度有关只要不碰相机和底座就能一直用。一定要注意的是单应性变换对相机畸变敏感。如果你用的是广角摄像头或者图像边缘有比较明显的拉长建议先做一次内参标定和畸变校正。我们用的是一颗普通 1080p USB 摄像头视场角 60 度左右畸变不明显因此直接跳过校正。如果你发现离中心越远定位偏差越大十有八九就是畸变在作怪。3.2 机械臂逆解与夹爪补偿拿到目标在机器人基座标系里的 X、Y 坐标之后还剩一个高度 Z。对于平面抓取来说Z 通常设为一个固定值对应桌面高度。四自由度机械臂的逆运动学在这个场景下可以简化成两段先通过 X、Y 算出大臂和小臂的关节角再通过目标高度算升降关节。VisionFive 2 本身做三角函数的运算没有任何压力逆解代码也是一套标准的几何法。我直接把核心代码贴出来。不过实际抓取时会遇到一个细节摄像头拍到的目标中心是物体的质心但夹爪开口方向不一定是正对着质心的。如果物体是长条的夹爪只夹边缘很容易滑脱。我们的解决办法是在逆解后加一个按姿态角旋转的偏移量import math def inverse_kinematics(x, y, z, l1120.0, l2120.0): # 输入目标位置输出大臂、小臂、升降关节的目标角度/长度 dist math.hypot(x, y) # 升降关节直接取 z lift z # 俯视图下的旋转角 base_angle math.atan2(y, x) # 平面内距离目标在机械臂基座水平面上的分量 r math.sqrt(dist * dist - (l1 - l2) * (l1 - l2)) if dist abs(l1 - l2) else 0.0 # 余弦定理求小臂相对大臂的角度 cos_angle (l1 * l1 l2 * l2 - r * r) / (2 * l1 * l2) cos_angle max(-1.0, min(1.0, cos_angle)) elbow_angle math.acos(cos_angle) return base_angle, elbow_angle, lift这段代码做的是理想化几何解没有考虑关节限位和奇异点。实际控制时我们还会加一个判断如果某个关节角超出硬件限位范围就报错并提示“目标不可达”。这是机器人最容易“咔哒”一声把齿轮打坏的地方必须提前处理。3.3 串口指令协议与执行状态机机械臂底层我们用了一块市售的四自由度舵机驱动板板子通过串口接收角度指令返回角度到位状态。RISC-V 板子跟驱动板之间的通信协议很简单帧头加 ID 加数据加校验。一个容易踩的坑是串口写数据之后立刻读返回经常读不到或者读到半包。原因是舵机驱动板的响应延迟不确定尤其是舵机在运动过程中状态查询可能被阻塞。我们改成了典型的生产者-消费者模型控制线程只负责发指令和读返回但状态判断线程会轮询“运动是否完成”标志避免在串口上做阻塞式等待。用 Python 的pyserial读写核心逻辑如下。为了稳定性串口超时设成 0.05 秒每次读写前清空缓冲区防止脏数据。import serial import struct import time class ArmSerial: def __init__(self, port/dev/ttyUSB0, baud115200): self.ser serial.Serial(port, baud, timeout0.05) self.ser.reset_input_buffer() def _checksum(self, data): return sum(data) 0xFF def send_angle(self, joint_id, angle_deg): # 把角度映射成 0~1000 的 PWM 值 pwm int((angle_deg 90) / 180 * 1000) frame bytearray([0xAA, joint_id, 0x03, (pwm 8) 0xFF, pwm 0xFF]) frame.append(self._checksum(frame)) self.ser.write(frame) def read_status(self, joint_id, timeout1.0): deadline time.time() timeout while time.time() deadline: if self.ser.in_waiting 6: raw self.ser.read(6) if raw[0] ! 0xAA or raw[1] ! joint_id: continue return raw[3] 0 # 第三个字节为运动状态位 time.sleep(0.01) return None3.4 抓取状态机的整体编排闭合回路的整体逻辑用有限状态机来编排是最清晰的。我们把任务拆成了几个状态等待目标、目标锁定、移到上空、下降抓取、抬升确认、放回指定位置。每个状态对应一个函数状态之间通过事件触发切换。这里我要强调一个经验千万不要把视觉识别和机械臂运动写在一个死循环里同步执行。因为舵机运动通常需要一秒多如果每帧都等目标检测的 100ms整个系统的响应会显得很“木”。我们把视觉识别单独放一个线程只更新最新的目标位置控制线程按自己的节奏读这个最新位置并执行动作。这样即使视觉偶尔丢帧机械臂也不会停顿。核心状态机的大致写法class GrabStateMachine: def __init__(self, arm, detector): self.arm arm self.detector detector self.state IDLE def step(self): if self.state IDLE: target self.detector.find_target(bottle) if target is not None: self.target_xy target self.state APPROACH elif self.state APPROACH: x, y pixel_to_robot(self.target_xy[0], self.target_xy[1], H) self.arm.move_to(x, y, z_ready) self.state GRASP elif self.state GRASP: self.arm.grasp() self.state LIFT elif self.state LIFT: self.arm.move_to(self.place_x, self.place_y, z_lift) self.arm.release() self.state IDLE这样写的好处是每个动作都有明确的出口后续加“检测失败重试”“夹爪空抓检测”也只需要在对应状态里加条件转移改动成本很低。4. Agent API 与 MCP 集成让大模型指挥机械臂4.1 为什么要用 Agent API 包装视觉和运动能力直接写死状态机有一个天花板任务一变程序就得改。我们希望用户能通过自然语言下达指令比如“把桌面上所有红色的东西收到左边的盒子里”这种命令如果用传统方式写要枚举颜色、形状、目标位置代码量爆炸。但通过 Agent API大模型本身具备较强的推理能力可以做任务分解、条件判断和异常规避。Agent API 在这里起的作用不是替代视觉模型而是编排视觉模型和运动控制。视觉和运动仍然是用传统代码实现只是被包装成“工具”tool大模型根据需要来调用。做法其实很简单把“识别位置”“移动到坐标”“抓取”“放置”这四件事封装成函数把函数名、参数和说明通过 JSON Schema 描述给 Agent大模型按格式返回调用请求。这里借用 OpenAI 的 Function Calling 风格的接口设计文中的 Agent API 泛指支持这类插件式调用的模型接口核心代码如下tools [ { type: function, function: { name: find_object, description: 在摄像头画面中查找指定类别的目标返回像素坐标, parameters: { type: object, properties: { class_name: {type: string, description: 目标类别如 bottle, cup} }, required: [class_name] } } }, { type: function, function: { name: grab_object, description: 抓取指定坐标处的物体, parameters: { type: object, properties: { x: {type: number}, y: {type: number} }, required: [x, y] } } } ]4.2 MCP 在其中的标准化作用Agent API 的函数调用是模型生态内部的标准但现实中我们要面对的不仅是模型自己的接口还有外部系统的资源。比如把 YOLOE 的检测服务、机械臂控制服务、甚至蓝湖设计稿上机器人的形态都暴露成独立的信息源或工具。如果没有一个标准协议每接一个服务就得写一套接口适配非常零碎。MCP 的价值就在这里——它是一种“模型与工具之间”的开放协议把资源resources、工具tools、提示词prompts统一描述Agent 不再需要硬编码调用每个服务的 SDK而是通过 MCP 客户端发现、调用。举个例子我们的机械臂控制模块实现成一个标准 MCP server 后任何兼容 MCP 的 Agent比如 Trae、Cursor 或其他支持 MCP 的框架都能直接操作这只机械臂不需要为不同的 Agent 框架各写一遍适配代码。MCP server 的 demo 做起来并不复杂。下面是一个用 Python 实现的极简 MCP 服务它暴露了“查询机械臂状态”和“执行移动”两个工具采用 JSON-RPC 风格的协议class MCPServer: def __init__(self, arm): self.arm arm self.tools { arm_move: self.arm_move, arm_status: self.arm_status } def handle_request(self, req): if req.get(method) tools/list: return {tools: [ {name: arm_move, description: 移动机械臂到目标坐标}, {name: arm_status, description: 获取机械臂当前状态} ]} elif req.get(method) tools/call: tool_name req[params][name] args req[params][arguments] return self.tools[tool_name](**args) return {error: unknown method} def arm_move(self, x, y, z): self.arm.move_to(x, y, z) return {status: ok} def arm_status(self): return {status: self.arm.get_state()}接上 MCP 之后Agent 写出来的决策代码里不再含任何硬件操作细节它只需要按 MCP 规范发请求、收结果。这就实现了“模型只负责思考工具只负责执行”的分层解耦。4.3 自然语言到机器人动作的完整链路我们做了一个简单的测试入口在板上运行一个 WebSocket 服务用户打开网页输入“找一个红色杯子然后抓起来放到左边”请求返回后依次看到 Agent 调用了 find_object、辨别像素坐标、调用 pixel_to_robot 转换、再调用 arm_move 和 grab_object。整个过程像看一个小型剧本在你眼前展开。这个链路里最核心的一环是“坐标转换由谁做”。最开始的版本让 Agent 直接读像素坐标再传回机械臂执行结果机械臂抓偏了。后来我们把坐标转换封装在 arm_move 的 MCP 工具内部Agent 传入的仍然是像素坐标但工具内部会自动做单应性变换。所以大模型不需要“知道”相机标定矩阵也不需要“理解”机械臂基座坐标系这些底层细节对模型透明。这是一个非常好的设计原则工具接口面向任务语义而不是面向实现细节。4.4 Computer Use 与 MCP 的边界理解这个话题最近讨论热度很高很多人分不清 Computer Use 和 MCP 的区别顺手讲一下我的理解。MCP 是模型与工具之间的通道协议它面向的是“工具与数据源”的连接而 Computer Use 更像是模型通过截图、鼠标键盘事件去操作整个桌面或网页。二者一个是“给模型一把扳手”一个是“让模型自己上手去拧螺丝”。在机器人场景里我们显然更需要前者——你不可能让大模型通过截图去看机械臂的物理位置它需要的是能够表达“当前执行器角度”和“目标世界坐标”的结构化接口。MCP 的好处不只是方便模型调用还有一个容易被忽略的点审计和权限控制。通过 MCP server 暴露机械臂控制接口可以让 Agent 调用前走一层校验比如“是否已经确认目标位置不为空”“夹爪当前位置是否安全”。这层保护对实体机器人来说至关重要——毕竟大模型一旦幻觉发出的指令可能是“抬到 10 米高”。5. 实操记录RISC-V 板上的完整跑通流程5.1 硬件清单与接线图VisionFive 2 开发板8GB 版本系统和环境装在 NVMe SSD 上1080p USB 摄像头固定俯视安装视角覆盖机械臂工作区域四自由度舵机机械臂 驱动板串口接口115200 波特率一块 5V/3A 稳压电源给驱动板供电跟 VisionFive 2 供电分开桌面上一张 A4 纸用笔标记了四个单应性标定点接线其实就两路USB 摄像头插板上任意 USB 口驱动板接 USB-TTL 转串口模块RX/TX 交叉连接GND 必须共地。这里特别提醒舵机驱动板和大功率舵机如果跟开发板共用一个电源极易引起电压跌落导致系统重启。我们前期调试时遇到过几次开发板莫名重启最后发现是舵机瞬间电流把 5V 拉低了。分离供电之后问题彻底消失。5.2 环境搭建和依赖清单Ubuntu 22.04SDK 自带镜像Python 3.10 virtualenvOpenCV 4.8从源码编译带 GTK 支持方便调试窗口显示onnxruntime 1.16.0RV64 专用版本pyserial 3.5websockets 12.0transformers、torch 只安装在开发机上用来导出模型板端只跑 ONNX Runtime这里让我纠结的是 OpenCV 编译时长。在 VisionFive 2 上从源码编译 OpenCV 需要大约 40 分钟CPU 全核跑满风扇呼呼的。如果你只是做推理不做 GUI可以直接 pip 装预编译版本但版本可能比较旧而且部分算子缺失。我们是编译了带 GTK 支持的版本因为调试阶段要弹窗口可视化检测框方便快速判断模型效果。架构检查的常用命令uname -m cat /proc/cpuinfo | grep isa python3 -c import onnxruntime; print(onnxruntime.get_device())如果你跑cat /proc/cpuinfo能看到rv64imafdc或者类似包含v扩展的 ISA 字符串说明芯片支持向量扩展向量扩展对矩阵类运算的性能提升很关键。如果没看到v后续做 NPU 转换时也不会有影响只是 CPU 推理会慢一些。5.3 模型转换和 NPU 加载过程模型转换的步骤说白了就是PyTorch 权重 → ONNX → 芯片定制的 NPU 格式。前两步大家都熟最后一步用的是芯片厂商提供的工具链。工具链在官方 SDK 的 tools 目录里读入 ONNX设置量化方式跑完会生成一个.nb或类似格式的文件。转换过程中需要指定输入图像尺寸这个尺寸必须是 16 的倍数一般是 640×640。如果你的部署图像不是正方形要在预处理里做 letterbox。量化校准需要准备 100 张左右的代表性图片我们直接用测试集里的 80 张。精度方面int8 之后检测框的 mAP 掉了大概 3 到 5 个点但对真实场景抓取来说这个精度损失不影响。真正耗时间的是算子兼容性排查。每次工具链报“unsupported op”你就得回 ONNX 图里找到那个算子要么在导出时用opset_version兼容版本要么在 ONNX 图里做算子替换。我们遇到过几次Resize算子和Gather算子的问题最后是通过把模型拆成两段解决的一段走 NPU一段走 CPU完全绕开了不支持算子的转换。5.4 全链路联调从识别到抓取的实时效果联调当天我们把 10 个不同形状的物件放在桌面不同位置目标是从识别到抓取完成整个过程在自然语言指令“找出所有圆柱体并把它们放到右上角”下自动执行。Agent 先调用 YOLOE 检测输出 4 个候选目标框再遍历每个目标计算坐标逆解生成关节角逐一下发指令抓取。三件物品依次抓完大约花了 12 秒。比起来我们最初用脚本写死的版本慢了 2 秒左右慢在 Agent 的接口调用和 JSON 解析上。但换来的是系统从“只能抓固定颜色”变成“听得懂语义指令”这 2 秒的代价完全值。板端 CPU 占用情况检测阶段四个核接近 90%运动控制阶段明显下降。内存占用整体 2.1GB8GB 版本很从容。板卡温度最高 72 摄氏度加了一个小风扇后稳定在 58 摄氏度左右。这块板子如果长时间跑视觉推理散热是必须考虑的否则 NPU 和 CPU 在高温下会降频导致单帧推理时间明显变长。6. 常见问题与排查技巧实录6.1 YOLOE 推理出现 NaN 或输出全零这是我们在板子上遇到的第一个头疼问题。现象是输出的检测框数组全是零或者 tensor 里有 NaN。排查思路有几个方向一是模型在转换时有算子部分损坏可以回开发机跑一遍 fp32 ONNX如果正常说明是板端推理环境或量化问题二是输入图像归一化是否做好YOLOE 系列要求输入是[0,1]范围的 float32如果直接传 0~255 的 uint8会出现输出异常这跟我们代码里的input_blob.astype(np.float32) / 255.0直接相关。还有一次我们发现是摄像头返回的图片格式是 BGR而模型预训练时用的可能是 RGB导致检测效果差到离谱。看似绝对正确的小事恰恰是视觉工程里最容易翻车的地方。我的经验是写一个简单的调试工具把送入模型前的图像保存下来可视化看一眼比自己盲猜快得多。6.2 MCP 连接超时或工具调用失败MCP 的开发和远端调试中最容易出现的问题是超时。因为 VisionFive 2 本身性能有限Agent 发起工具调用后模型推理需要 100ms机械臂动作需要 1 到 2 秒而默认的 MCP 超时往往只有 10 秒。如果任务复杂多次推理加多次运动总时长很容易超过超时阈值导致 Agent 误判为“机械臂没有反应”。解决办法也很简单把 MCP 客户端的超时时间调大。有些框架里可以直接配置有些框架是在具体调用代码里传timeout参数。如果你在调试时发现 Agent 返回“tool execution failed”但板端日志显示动作正常执行多半不是设备问题而是超时配置问题。6.3 机械臂夹取偏移这个误差到底出在哪夹取偏移是视觉抓取项目几乎绕不开的问题。如果出现系统性偏移比如总往右边偏 1cm大概率是单应性矩阵的标定点误差或者摄像头安装角度变了。如果偏移是随机的几毫米内的抖动属于正常因为舵机本身也是欠完美执行器。一个缩小误差的实用技巧在标定单应性矩阵时让标定点尽可能覆盖整个工作区域同时避免点集中在中心。四个标定点近似一个长方形边缘尽量接近机械臂可达范围的边界这样整个工作空间内的映射误差会更均匀。我们还写了一个“五点法”复核随便取第五个点输入像素坐标算出物理坐标用尺子量一下偏差通常在 3mm 以内就算标定合格。6.4 开发板存储空间不足VisionFive 2 如果系统装 32GB TF 卡光一个 Ubuntu 系统加基本工具就要占掉 8~10GB再装上 OpenCV、ONNX Runtime、YOLOE 模型空间立刻捉襟见肘。我们的解决办法是所有大型 Python 包和模型文件都移动到 NVMe 固态盘用软链接把.cache目录指到外置盘删除开发机上编译过的临时文件和 pip 缓存模型文件如果体积太大可以转成半精度或者 int8一个 NB 格式大约 20 到 60MB比 fp32 的 100 多 MB 友好很多如果空间实在太紧可以做一个环境销毁脚本把 pip 缓存、编译中间文件定时清理。不建议用 swapTF 卡上的 swap 性能差且寿命短在新版本内核上还容易出现 IO 延迟。6.5 Agent 误判指令和动作执行安全用大模型控制实体机器人最怕的不是它识别不了图片而是它对指令的理解“过于天马行空”。比如你对它说“把物体移走”它可能直接调用 arm_move 传入一个没有经过有效性检查的坐标结果机械臂撞到桌面或夹爪撞到支架。我们在 MCP 工具层做了两道防线第一道是入参范围检查x、y、z 必须在预设的合法区间内超出一律拒绝并返回错误第二道是工位操作前的“预检”比如下降抓取之前会先读取当前夹爪状态和已识别目标是否仍然有效防止空中乱抓。 提醒在实体设备上做 Agent 控制安全措施永远是最重要的部分。不要模型返回什么动作就照做工具层一定要有边界检查。这是我们在工程化阶段最重要的一个教训。7. 这台 RISC-V 机械臂还能怎么扩展这套系统目前跑通的是“平面视觉抓取”这一个简单任务。但框架的可扩展性已经体现在三个方面第一视觉模型可以换。只要你能导出 ONNX 模型并且板端 NPU 工具链支持大部分算子YOLOE、YOLOv8、SAM 这类模型理论上都能替换Agent API 的工具描述只需要改一个函数说明。第二运动控制可以接到 ROS 2 上。目前我们是直接控制舵机如果换成带 ROS 接口的机械臂可以把 MCP server 做成 ROS 2 action 的封装层大模型依然通过 MCP 工具下发任务底层动作全部交给 ROS。第三MCP server 可以部署在远端服务器上VisionFive 2 只做本地推理和运动控制大模型推理放到性能更好的机器上。这样算力解耦边端和云端各干各的活。我最近正在折腾的是把 MCP server 加一个 WebRTC 视频流接口这样 Agent 不仅能读到坐标还能实时“看到”机械臂的工作画面做更复杂的空间推理。这个方向还在实验阶段等稳定了再单独写一篇分享。回到最初的问题RISC-V 能不能跑机器人答案是可以而且比很多人想象的要好。它的价值不在于“性能碾压”而在于它提供了一条自主可控的嵌入式智能机器人路径同时用标准的接口MCP、ONNX Runtime串起了视觉模型、Agent 和运动控制。未来的嵌入式 AI 机器人未必只是高端 x86 平台的独角戏RISC-V 这条路会越走越宽。