RISC-V驱动机械臂：VisionFive 2集成YOLOE与MCP实战

“RISC-V 能不能跑机器人能但跑法跟你习惯的 x86 工控机不是一回事。”这是我在规划这个项目时所持的真实想法。写这篇文章前我重新把整个工程链路过了一遍从 StarFive VisionFive 2 做主控到 YOLOE 负责目标检测再到视觉状态机闭环、Agent API 与 MCP 协议把自然语言指令翻译成机械臂动作最后形成一个可以反复演示的桌面级“识别—抓取—搬运”完整闭环。整个过程跑通之后最让我意外的不是 RISC-V 算得快而是只要把每一层的分工切清楚它反而比我想象中更适合做这类小体量机器人实验。这篇内容适合两类人看一类是手里有 VisionFive 2 或者类似 RISC-V 开发板却不确定能不能碰机器人方向另一类是想接入 MCP 但被各种 agent 框架绕晕的工程师。我会把硬件选型、系统调试、YOLOE 落地、坐标闭环、MCP 服务编排和核心代码全部摊开讲尽量少讲虚的。1. 为什么拿 VisionFive 2 当机械臂主控选型逻辑与整机分工1.1 RISC-V 跑机器人最容易踩的认知误区提到跑机器人多数人第一反应是“CPU 得够快”。这个说法对了一半。机器人系统里真正吃掉大量计算资源的是三块图像预处理、目标检测推理、路径规划里的频繁矩阵运算。如果所有工作都在一颗 RISC-V 处理器的 CPU 上硬算那确实会卡得很痛苦。但这个项目里我做了个非常明确的分层机械臂自身的关节伺服控制由机械臂控制器完成主板只负责发轨迹指令视觉模块只挑出最重要的物体类别和像素位置真正让机械臂稳定运动的闭环控制会在底层驱动里以几毫秒周期执行并不会因为 AI 推理慢而被拖垮。也就是说RISC-V 主控承担的是“决策与调度”的角色不是高实时性运动控制的核心。我选的板子是 VisionFive 2 的 8GB RAM 版本CPU 是四核 SiFive U74频率大约 1.5GHz指令集是 RV64GC不带 V 向量扩展。这个配置放到桌面级机器人项目里属于“够用但内存偏紧”的状态。8GB 内存让我可以同时常驻一个 Python 视觉服务、一个机械臂驱动服务和一个 MCP 服务不至于因为内存不足频繁交换进程。1.2 这套机械臂平台的硬件拓扑我用的机械臂是一台常规的 6 轴桌面协作臂控制器通过串口/USB 转接与主板连接支持最基本的笛卡尔坐标指令。夹爪是两指平行夹爪也走同一路控制器。相机方面没有用昂贵的工业相机只是一个普通的 USB 免驱摄像头固定在支架上俯拍机械臂的工作桌面。整机链路可以这样描述视觉服务常驻抓到一帧画面后跑一次 YOLOE 检测检测结果经过坐标换算得到某个目标物体在机械臂基坐标系下的三维位置机械臂驱动服务接收“去这个点抓取”的指令到达预抓取点后视觉服务再次确认物体没有移动再执行下探和夹取Agent/MCP 层在最上层把“把里面的苹果挪到左边”这类指令拆成上面这套流程有人会问为什么不让 Agent 直接写 Python 代码控制机械臂可以但那样每次请求都可能产生不稳定的提示词代码权限边界也很难控制。MCP 的价值就是把机械臂驱动能力封装成“工具”而不是“代码生成”Agent 只能根据我定义的参数调用工具。1.3 为什么不直接用一台旧电脑当主控我在实验里确实有 x86 开发机但最终选择让 VisionFive 2 当实际主控一个重要原因是功耗和体积。机械臂工作台经常需要在不同实验桌上搬动一台带 GPU 的台式机热、吵、占地而且会让人误以为机器人能力取决于主机性能。实际上桌面级机械臂的视觉抓取任务真正要求的是确定性而不是峰值算力。RISC-V 板子的另一层价值在于它的外设控制方式非常直白。GPIO、UART、USB、CSI/HDMI 这些接口都能直接在 Linux 下访问没有各种私有 SDK 绑定。对做机器人的人来说这意味着“这台机器从内核往上都受我控制”调试自由度比消费级 ARM 单板电脑更高。2. 系统底座让 RISC-V 板稳定跑感知进程的几条硬规矩2.1 系统的安装与镜像选择VisionFive 2 官方有 Debian 镜像我用的是基于 Debian 的 riscv64 版本。第一次刷机时我用了一张普通的 32GB TF 卡但后来又换成了固态硬盘加 USB 转接方案。原因是 SD 卡在长时间读写交换数据和模型文件时稳定性偏差而视觉服务和 MCP 服务都是长驻进程对存储 IO 没那么宽容。刷系统之后我做的第一件事不是装 Python 环境而是把内核升级到带较新 GPU/VPU 驱动的内核线。VisionFive 2 的显示控制器和视频解码单元其实都有驱动只是在不同内核版本上表现差异很大。跑纯无头机器人服务的话不接显示器也能工作但内核版本还是会直接影响摄像头驱动和 USB 控制器的稳定性。建议安装完系统先跑一轮烧机测试确认下面几项都正常再继续CPU 温度在空载时低于 50 度满载压测不超过 80 度USB 口在同时接摄像头和机械臂控制器时不会掉设备系统日志里没有持续的 rcu_sched stall 警告Python 3.11 以上能正常安装 venv并能编译 numpy我在初版配置里因为供电不足吃过不小的亏后面第七节会细说。先把系统这一层压稳是后续少踩坑的前提。2.2 RISC-V 上没有“标准 Python 二进制包”的应对套路在 x86 的 Ubuntu 上装 Python 包习惯用 wheel但在 riscv64 上很多包的轮子并没有发布。像 opencv-python、onnxruntime 这类大件如果直接 pip install大概率会编译很久或者直接报平台不支持。我的处理方式是给系统安装好编译工具链然后使用 venv 管理项目依赖。onnxruntime 我在这个项目里是编译出 riscv64 CPU 版本后自用的opencv 使用无 UI 依赖的精简分支能够完成图像读取、绘制和颜色转换就够了。为了不让编译过程反复失败建议单独开一个 8GB 的交换文件不然在内存吃紧时编译器会被 OOM kill。这个步骤看起来不酷却直接决定了后面能否顺利跑 YOLOE。很多人从 x86 开发环境直接复制需求文件到 RISC-V 板子结果依赖装不上就判定“RISC-V 不能跑 AI”其实问题出在发行版生态没有为这块板准备现成的轮子而不是指令集本身有什么不可逾越的障碍。2.3 固定 CPU 频率、限制桌面服务VisionFive 2 的 CPufreq 调节器默认策略在负载变化时会出现频率波动这对视觉服务的帧间隔稳定不利。我在启动脚本里把 governor 切换成 performance让 CPU 尽量稳定在高频。代价是温度和功耗上升所以必须配合主动散热不然长时间运转会触发过热降频视觉检测速度反而更不稳。另外我的系统跑在无头模式下关掉了桌面合成器和不需要的 DBus 服务。有朋友问这些能省多少资源实际测试下来内存能省出 400MB 左右对常驻视觉模型的小内存系统来说非常关键。3. YOLOE 板端部署零样本检测在 RV64 上的取舍3.1 为什么选 YOLOE而不是传统训练好的 YOLOv8传统 YOLO 系列模型检测效果不错但有一个绕不开的问题每次换检测目标就要重新准备数据集并训练。做机器人实验时我今天想让它抓螺丝刀明天想让它抓马克杯每次都重新训练是不现实的。YOLOE 的特点是不用针对每个新类别重新训练它支持文本提示和参考图像提示。也就是说我可以直接给出 “screwdriver” 这样的文字描述模型就在当前画面里把螺丝刀框出来也可以给一张目标物体的参考图来自动建立特征。这种方式对基于 RISC-V 的机器人视觉系统非常有吸引力因为板上根本没有条件做大规模训练只能做推理。YOLOE 把“换目标”的代价压到了接近零实验者只需要改提示词视觉服务不用重新起。3.2 模型导出与在 VisionFive 2 上跑的姿势我在 PC 上先把 YOLOE 模型导出成 ONNX 格式固定 batch size 为 1方便后续在 RISC-V 板子上的 CPU 推理。导出时把动态轴全部关掉这样能减少许多算子兼容性问题。有人在板端编译 PyTorch 想直接跑原模型我实测后建议放弃PyTorch 在 riscv64 上编译时间很长生成的推理图也包含大量不必要的调度开销ONNX 是更务实的中间表示。视觉服务的 Python 代码大致保持这样的结构从摄像头读取一帧缩放到模型输入尺寸做归一化后交给推理会话。YOLOE 输出包括检测框、类别与置信度。我不会试图让所有代码都在重负载下毫秒级返回而是接受它作为一个“慢但准确”的感知源用异步队列把它和机械臂运动分开。当模型输入尺寸为 640x640、模型为 YOLOE-M 级别时在 VisionFive 2 的 CPU 上实测单帧推理速度约在 1.5 秒左右。这个速度乍看很慢但经过几十次运行后发现它完全够用。原因是抓取流程并不需要每一帧都做目标检测机械臂在预抓取和下探阶段主要靠的是底层运动插补视觉只需要在关键节点确认目标是否仍然存在以及目标位置有没有明显变化。3.3 如何降低检测频率提高系统可用性既然单帧推理慢系统设计就要符合这个物理限制。我没有让检测线程以固定帧率循环而是设计成按需触发。初始时进行一次全画面扫描找到目标后机械臂以较低速度向目标靠近期间视觉线程再次触发一次确认。如果两次检测结果空间距离小于 2 厘米就继续执行抓取如果差距大就重新规划抓取位置。这里最关键的一点是要敢于降低“视觉刷新率”而不是硬着头皮优化模型。很多机器人项目的实时性焦虑本质上是把实时性放在了错误的层级。对桌面物体的抓取而言100ms 和 1500ms 的感知延迟没有本质区别只要位置误差在可接受范围内就行。真正不能省的是运动控制周期里的毫秒级刷新而那部分已经被机械臂控制器接管不需要 RISC-V CPU 去处理。4. 视觉闭环链路从二维像素到机械臂关节指令4.1 相机标定和手眼关系YOLOE 检测结果只是二维像素框要把像素坐标变成机械臂能用的三维位置需要做两件事相机内参畸变校正和相机到机械臂基座的坐标变换。我的实验场景里相机固定在支架上与机械臂基座的相对位置始终保持不变这是最简单的固定手眼构型。标定时使用棋盘格放在机械臂工作台面上先用手动模式让机械臂末端尖点触碰棋盘格上多个角点记录每个角点在机械臂基座坐标系下的实际位置。同时用相机检测同一棋盘格的像素角点建立多组像素坐标和基座坐标的对应关系。如果场景中台面比较平整用单应矩阵就足够完成映射。若物体的高度不同则需要相机标定出的外参把平面像素坐标投影到台面高度对应的三维平面上。为了减少视觉误差我所有对物体的定位都限定在固定高度平面机械臂也只有到了这个高度附近才做精确抓取。4.2 视觉闭环不只是一个坐标转换函数坐标转换做完后只算开环定位。真正形成闭环的是“视觉确认—运动—再确认”的循环。我的机械臂服务里有一个状态机每个状态下只有有限几个动作。状态包括 searching、moving_to_pre_grasp、confirming、approach、grasp、retract、transport 和 place。比如在 confirming 状态机械臂停在目标物上方约 8 厘米的位置视觉系统重新检测一次。若检测框中心与下落点的 x/y 误差小于 5mm就进入 approach若误差大则重新回到 searching 状态更新目标位置。这样可以避免一次检测位置的噪声直接传导到机械臂末端极大降低夹空概率。闭环中还有一个容易忽略的细节就是机械臂末端遮挡问题。机械臂下探后夹爪会进入相机视野如果此时继续盲目做视觉更新检测结果大概率会跳到夹爪上。因此我定义了视觉可执行区域一旦机械臂末端低于某个高度就停止视觉更新只依赖底层运动到位。控制软件里把“谁在什么时候有权操作机械臂”管清楚比优化某个算法更重要。4.3 从像素到空间的坐标系变换代码思路这段代码的核心工作是做像素坐标到机械臂基座坐标的变换。它需要保存好相机内参、畸变向量以及外参。由于棋盘格标定时目标平面高度确定这里我直接通过单应变换计算平面坐标再叠加固定高度。在实现时有一个很实际的问题像素噪声会导致目标位置在几个毫米内跳动。如果每次检测结果都直接发给机械臂机械臂会频繁做小幅修正看起来非常不自然。解决办法是加一个简单的滑动滤波只取最近几次有效检测框中心的中位值。这样既消除了抖动又不会像均值滤波那样在大偏移出现时收敛太慢。5. Agent API 与 MCP 接线层把自然语言变成设备动作5.1 为什么需要 Agent API 这一层通过 MCPAgent 能发现自己可以调用哪些工具但在一个机械臂工程里工具的参数往往是复杂的结构体。比如“把物体移到指定位置”光靠用户一句“放到左边”并不足以生成稳定轨迹。我们需要 Agent API 层把自然语言转成结构化指令再通过 MCP Server 派发给设备。我在项目里采用的方式是Agent 运行在上层的对话程序中它通过 MCP Client 与 MCP Server 通信。MCP Server 暴露了三个工具获取目标抓取位置、执行抓取计划、执行放置。这些工具的参数已经被我定义了枚举和 vector 类型Agent 只能传合法值。相比让 Agent 自己写 Python 调用机械臂库这种接线的安全边界清晰很多。5.2 MCP 的工具协议与 JSON-RPC 消息MCP 底层基于 JSON-RPC一个工具调用流程大致分为这几步客户端先发送初始化请求建立协议版本接着请求工具列表用户指令触发 Agent 决定调用某个工具时客户端向 MCP Server 发送 tools/call 请求服务器执行完实际动作把结构化结果返回。机械臂执行过程可能长达几十秒所以我在服务器端把工具调用实现成异步作业先返回“已接收”状态再通过一个查询接口让 Agent 轮询执行结果。这一点对机器人集成非常关键。如果按同步工具调用实现MCP Server 会在机械臂运动完成前一直阻塞而 Agent 的默认超时时间往往只有几十秒。一次稍长的抓取动作就容易断掉。加入任务队列后Agent 可以调用“查询任务状态”工具让执行状态与工具协议解耦。5.3 用哪些现成工具来搭 MCP要不要自己实现市面上已经有不少 MCP SDK 可以加速开发不过在这个非主流平台上我不太想多引入一个依赖层。因为这个场景本质只是实现一个基于标准输入输出的 JSON-RPC 服务完全可以手写一个几百行的 minimal MCP server然后再用 SDK 测试兼容性。这样做的好处是出了问题我能直接读协议日志定位而不是去翻框架源码。如果你想快速复制一个 demo也可以直接用官方 MCP Python SDK 里的 FastMCP 包装器它会帮你处理握手和工具注册。RISC-V 环境下只要 Python 版本达标安装这个纯 Python SDK 并不困难。5.4 Agent 编排工具的调用心得实际使用过程中我发现一个有意思的现象Agent 并不总能准确知道什么时候该调用视觉工具。比如用户说“看看桌面上有没有螺丝刀”Agent 可能会直接调用 pick 工具而不先调用检测工具。这个问题的通用解法不是写更长的提示词而是把工具命名和参数设计得有状态感。我采用的方案是引入一个视觉检测结果缓存服务。也就是说“获取目标抓取位置”这个工具的返回结果里会带有时间戳和置信度如果 Agent 拿到的位置时间戳过于陈旧pick 工具会直接拒绝执行并要求重新检测。这套“工具之间互相校验”的设计比靠大模型自觉要可靠得多。6. 核心代码串烧视觉、机械臂与 MCP 服务怎么连起来6.1 机械臂驱动服务的关键类下面的代码不是完整业务实现但覆盖了机械臂服务最重要的一层串口指令封装与执行锁定。实际项目中我使用的是简单文本指令协议每行指令包含目标坐标和运动速度。我封装了一个 ArmDriver 类内部维护锁和对机械臂状态的缓存。import threading import time import serial class ArmDriver: def __init__(self, port: str, baud: int 115200): self.ser serial.Serial(port, baud, timeout1.0) self._lock threading.Lock() self._last_response self._busy False def _send(self, cmd: str) - str: with self._lock: self.ser.reset_input_buffer() self.ser.write((cmd \n).encode(utf-8)) line self.ser.readline().decode(utf-8).strip() self._last_response line return line def set_pose(self, x, y, z, roll0.0, pitch0.0, yaw0.0, speed50.0): cmd fMOVEL {x:.4f} {y:.4f} {z:.4f} {roll:.2f} {pitch:.2f} {yaw:.2f} {speed:.1f} resp self._send(cmd) if not resp.startswith(OK): raise RuntimeError(farm command failed: {resp}) self._busy True return resp def wait_until_idle(self, timeout60.0): start time.time() while time.time() - start timeout: resp self._send(STATE) if resp.startswith(IDLE): self._busy False return True time.sleep(0.5) raise TimeoutError(arm wait timeout)为什么要单独做驱动类而不是直接在 MCP Server 里写 serial 操作因为机械臂运动期间可能会被多个来源请求打断。项目里 Agent 是请求来源之一本地的 python 脚本也是共享的 ArmDriver 用锁保证同一时刻只有一条指令在串口上飞行否则一个换行符错位就可能导致机械臂误动。6.2 视觉服务按需返回目标位置视觉服务不主动往机械臂发指令它只响应请求。一个检测函数大概是这样import cv2 import numpy as np import onnxruntime class YoloeService: def __init__(self, model_path: str, text_prompt: str): self.sess onnxruntime.InferenceSession( model_path, providers[CPUExecutionProvider] ) self.text_prompt text_prompt self.input_name self.sess.get_inputs()[0].name self.output_names [o.name for o in self.sess.get_outputs()] def detect(self, frame: np.ndarray): h, w frame.shape[:2] blob cv2.dnn.blobFromImage( frame, 1 / 255.0, (640, 640), swapRBTrue, cropFalse ) outputs self.sess.run(self.output_names, {self.input_name: blob}) boxes, labels, scores self._postprocess(outputs, w, h) return boxes, labels, scores def get_target_pose(self, frame: np.ndarray, text_prompt: str): boxes, labels, scores self.detect(frame) valid [ (box, label, score) for box, label, score in zip(boxes, labels, scores) if label.lower() text_prompt.lower() and score 0.5 ] if not valid: return None box max(valid, keylambda x: x[2])[0] cx (box[0] box[2]) / 2.0 cy (box[1] box[3]) / 2.0 return cx, cy实际部署时文本提示词可能来自 Agent 工具参数。YOLOE 的优势在这里体现得很直接你不需要重训模型只改 prompt模型就换了一个检测目标。当然提示词并不是越抽象越好像 “drink bottle” 比 “object on table” 稳定得多这需要在项目里反复调几轮。6.3 MCP Server 工具注册的例子我写的最小 MCP Server 采用标准输入输出作为传输层。核心注册函数如下它把视觉和机械臂动作封装成 Agent 可调用工具import json import sys TOOLS [ { name: get_pick_pose, description: 检测指定物体在机械臂基坐标系下的抓取坐标, inputSchema: { type: object, properties: { text_prompt: {type: string, description: 目标类别描述} }, required: [text_prompt] } }, { name: pick_and_place, description: 执行一次完整的抓取与放置动作, inputSchema: { type: object, properties: { pick_x: {type: number}, pick_y: {type: number}, pick_z: {type: number}, place_x: {type: number}, place_y: {type: number} }, required: [pick_x, pick_y, pick_z, place_x, place_y] } } ] class MinimalMcpServer: def __init__(self, vision_service, arm_driver): self.vision_service vision_service self.arm_driver arm_driver def handle_request(self, req): method req.get(method) req_id req.get(id) if method initialize: return self._ok(req_id, {protocolVersion: 2025-03-26, capabilities: {}}) if method tools/list: return self._ok(req_id, {tools: TOOLS}) if method tools/call: params req.get(params, {}) tool_name params.get(name) args params.get(arguments, {}) return self._call_tool(req_id, tool_name, args) return self._error(req_id, -32601, method not found) def _call_tool(self, req_id, tool_name, args): if tool_name get_pick_pose: prompt args.get(text_prompt, ) pose ... # 抓取视觉服务结果并做坐标转换 return self._ok(req_id, {content: [{type: text, text: json.dumps(pose)}]}) if tool_name pick_and_place: # 真正的机械臂运动在独立线程执行先返回已接收 return self._ok(req_id, {content: [{type: text, text: task accepted}]})从代码顺序上可以看到MCP Server 本身并不关心视觉算法细节也不关心机械臂的具体运动学。它的职责就是把 Agent 的语义请求映射到内部服务。未来就算换一台机械臂或者换一个检测算法MCP 层的工具协议都可以保持不变。这也是我推荐在机器人项目里引入 MCP 的根本原因协议与实现解耦。6.4 把整个系统串起来的主进程主进程需要做几件基础工作初始化摄像头、启动机械臂驱动线程、启动视觉服务、启动 MCP Server。同时还需要一个心跳线程负责在系统空闲时把机械臂回到安全初始位。实际搭建时不要把所有东西塞进一个巨大文件我分成 vision_service.py、arm_driver.py、mcp_server.py 和 main.py 四个文件。调试的时候可以单独启动 arm_driver.py 的测试入口手动输入坐标移动机械臂等机械臂动作稳定之后再接上层。这样排查问题时通常两三分钟就能定位是视觉侧、运动侧还是协议侧的问题。7. 压测两小时发现的真实状况性能、线程与硬件供电问题7.1 性能瓶颈不完全在模型推理搭建完成后我做了两小时的连续压测指令是循环搬移一个马克杯Agent 层每 30 秒向 MCP Server 发起一次抓取任务。观察到的结果是在连续运行约 20 分钟后视觉服务的检测耗时从 1.5 秒慢慢涨到了 2.3 秒。这不是模型变慢了而是内存碎片和 CPU 降频导致的累加效应。我的解决方式是给视觉服务外加了一个定时重启机制。每处理 50 次请求后视觉子进程会自动重启并重新加载模型。RISC-V 板上跑单进程时内存很容易因为反复分配 tensor 缓冲区而产生碎片与其费劲优化分配器不如用进程隔离来得干净。另一个发现是线程在很多 IO 操作上并不可靠。使用 GStreamer 读取摄像头时如果主线程里同时调用机械臂串口读取会出现偶发的键值延迟。最后我把摄像头读取单独放进一个进程用 Unix domain socket 和主服务通信彻底避免了线程争用问题。7.2 最容易被忽略的供电问题我在测试到十几分钟时遇到过几次机械臂突然复位板子没有重启但机械臂控制器丢失连接。排查很久后确认是电源问题VisionFive 2 和机械臂控制器共用一个 5V/4A 电源当机械臂启动瞬间电流尖峰很大USB 口电压跌落到阈值以下控制器就重置了。更换为机械臂单独供电并且让 VisionFive 2 使用独立的 5V/3A 电源后问题再没出现过。这里提醒一句很多人会在树莓派类板子上忽略电源质量但机器人场景里有电机这种大电流负载电源问题会被放大很多倍。上电顺序也要注意我建议先给机械臂控制器上电等待 2 秒后再给主板供电避免 I/O 引脚上的电平竞争。7.3 Agent 重复调用的防御使用 Agent API 时还遇到一个很有意思的问题模型在生成下一步操作前会把自己上一轮的调佣结果又发一次。也就是说一个抓取动作实际被执行了两次第一次已经把物体搬走了第二次自然检测不到目标。由于机械臂动作本身是安全的重复执行不会损坏设备但会白白浪费时间。解决方法有两个层面。第一层在机械臂驱动里加“非空工作台”判断放下物体后如果拿到成功状态再收到相同抓取指令时就直接回空第二层在 MCP Server 端为同一 req_id 的执行结果做缓存重试请求直接返回上次结果而不是重新操作机械臂。实际经验告诉我只做第一层不够因为 Agent 可能生成新的 req_id必须靠业务逻辑做幂等。下表总结了这段时间最值得记录的问题与对策现象根因解决方式视觉检测耗时逐渐变长内存碎片和 CPU 降频子进程定期重启每 50 次请求回收一次机械臂偶发复位电源共地供电不足机械臂与主板独立供电并调整上电顺序Agent 重复执行动作模型重复调用工具工具业务逻辑幂等MCP Server 响应缓存图像丢帧摄像头线程与串口线程争抢 GIL摄像头读取隔离到独立进程编译频繁 OOM内存不足准备 8GB 交换文件使用编译参数调低并发这些坑单独看都算不上什么高级问题但在 RISC-V 平台上同时出现时会让人觉得“这板子不行”。实际上把供电、线程划分和进程生命周期这三件事做好后整机连续跑几个小时都没有再出过状况。8. 这个项目的边界目前能做什么别期待什么聊到 RISC-V 跑机器人很容易被带进“能不能达到 x86 性能”的陷阱。如果只看 AI 推理吞吐VisionFive 2 确实远不如一块入门级 NVIDIA 显卡甚至不如某些 Arm 板。但这个项目让我对“机器人主控”有了不同的理解。最核心的收获是系统的确定性比峰值性能重要。机械臂抓取任务并不需要每秒 30 帧的检测速度它需要的是在正确的时机拿到置信度足够高的结果然后让底层运动控制精准到位。RISC-V 板把检测频率限制在每秒零点几帧反而逼着我把状态机设计得更清楚把重复决策降到最低。从扩展角度看这套架构的未来方向是把更重的感知模型放在边缘推理盒或者远端 GPU 上VisionFive 2 继续承担设备控制与 MCP 调度。这样“设备侧决定怎么做感知侧负责看到什么”的分工依然成立RISC-V 板并没有因为算力弱就被踢出系统而是处在更合适的位置。如果你也想在自己的桌面机械臂上复现这套链路我给的建议是按顺序来先让机械臂用固定坐标点完成一次纯粹的运动控制测试再接一个最简单的颜色识别再上 YOLOE最后才引入 MCP 协议层。每一层都验证稳定后再叠下一层你会发现在 RISC-V 上做机器人实验没有想象中那么玄它只是需要你更尊重硬件边界和工程顺序。