具身智能端云协同实战：树莓派小车跑通云端推理闭环

最近一段时间具身智能的热度肉眼可见地升高。无论是机器人公司还是云厂商都在强调“大模型 机器人”的组合。不过当你真的用云端的模型去驱动一台具身智能小车跑起来时会发现从云端到真机之间还有不少环节是断层的。业内常说国内云计算赛道上有“四朵云”它们近两年也都在往具身智能方向布局有的发布机器人开发套件有的开放多模态大模型 API有的推出仿真训练平台。但仔细看大部分动作都集中在“大脑上云”这一层算力、模型、通用数据平台。至于机器人本体怎么接入、真机数据怎么回流、场景怎么运营很多还停留在 Demo 阶段。用一句话概括就是走了半步具身后程还有大量硬骨头。这篇文章不打算只做产业评价而是从开发者视角把云厂商切入具身智能的“半步”拆解成具体技术能力再用一棵树莓派小车把“端云协同”的最小闭环跑通。内容会覆盖概念背景、系统架构、云端推理服务、端侧采集与决策、数据回传以及常见问题排查。无论你是刚接触具身智能的新手还是想把手里的机器人项目接入云平台的后端开发者都可以按文章步骤实际操作一遍。1. 背景与核心概念1.1 具身智能到底是什么具身智能Embodied Intelligence这个词拆开看就是“具身”加“智能”智能体不仅要像大模型那样能说会看还要有一个物理身体能在真实世界中感知、行动并根据行动结果调整下一步决策。一个完整的具身智能系统通常包含这样一个闭环感知通过摄像头、激光雷达、触觉传感器等获取环境信息。决策根据感知结果结合任务目标生成下一时刻的动作策略。执行通过电机、舵机、机械臂等执行机构把决策变成物理动作。反馈执行后观察环境变化回到感知阶段形成持续循环。这与我们熟悉的纯软件 AI 有本质区别。大语言模型存在于数字世界回答问题哪怕答错了也不会产生物理后果。而具身智能一旦动作执行错可能撞倒货架、抓碎工件甚至伤到人。所以它的问题难度更高对实时性、可靠性、安全性的要求也完全不一样。1.2 云计算在具身智能中扮演什么角色具身智能的模型通常非常大尤其是视觉语言动作模型VLAVision-Language-Action Model参数量动辄几十亿。这类模型不可能完全放在机器人本体上运行一方面成本太高另一方面端侧算力和功耗都撑不住。因此目前的工程方案普遍采用“云边端协同”云端负责复杂计算预训练大模型、海量真机数据清洗、增量训练、仿真训练。端侧负责实时响应图像采集、运动控制、低时延的轻量感知。边侧作为中间层在网络不稳定或需要低延迟时做本地预处理和局部决策。云计算在这里提供的不是单一产品而是一整套基础设施GPU 算力、对象存储、消息队列、容器服务、模型托管、仿真平台等。可以这样说没有云底座具身智能的数据收集和模型迭代会慢到几乎无法推进。1.3 什么是“四朵云”为什么说它们走了半步“四朵云”并不是一个严格的官方概念而是业内对国内市场份额靠前的几家头部云厂商的泛称。本文不特指某一家而是把它们看作一个整体讨论这些云厂商在具身智能赛道上的共同布局状态。为什么说“走了半步”用两层逻辑来看第一层是已经走好的“半步”。头部云厂商在算力基础设施、多模态大模型 API、通用数据清洗与标注、开发套件等方面能力已经比较完善。开发者想做具身智能项目确实能直接租到 GPU、调到大模型接口、用上数据平台入门门槛比两三年前低很多。第二层是还没走好的“后半步”。具身智能的灵魂在物理世界的数据闭环。云厂商自己没有机械臂、没有机器人底盘、没有产线也不容易持续获得真机操作数据。即便推出了机器人相关模型模型能否在真实光照、遮挡、材质差异下稳定工作还需要长期场景数据反哺。这一块大部分云厂商才刚刚开始布局。所以说“走了半步”并不是否定云厂商已有的成绩而是指出一个事实具身智能的真正壁垒不在云上能跑多大的模型而在于能否把物理世界的数据持续回流到云端再让模型回到物理世界中执行得更好。2. 云厂商具身智能布局的技术拆解2.1 一张表看清“半步”与“后程”为了更直观地理解云厂商在具身智能上的布局现状我把能力拆成四个层次能力层次目前相对成熟的“半步”仍在早期、短期难补齐的“后程”算力底座GPU 云服务器、分布式训练集群、AI 推理服务面向机器人场景的专用调度、异构算力统一管理模型服务多模态大模型 API、视觉识别 API、语言规划 API模型与具体机器人硬件的策略对齐、真机微调数据平台对象存储、数据清洗、数据标注、批量计算真机数据采集协议、跨机构数据孤岛打通、合规传输机器人生态开发套件、Demo 示例、仿真环境主流底盘/机械臂的标准化接入、场景化解决方案从这张表里可以看到四个层次中前三层的“地基”已经存在但真正和机器人强绑定的“后程”还没有形成行业标准。这恰恰是一个充满机会的阶段。2.2 云厂商已经能拿出来的“半步”对开发者来说云厂商目前能提供的能力非常实用。首先是算力。你可以按小时租用带 GPU 的云服务器把 YOLO、Deformable DETR、VLA 等模型部署上去按量付费不需要自己买卡、维护机房。其次是模型服务。很多云平台开放了多模态模型的 HTTP 接口直接传一张图就能拿到识别结果或文本描述省去了自建模型服务的麻烦。再有就是数据链路。对象存储可以接收设备上传的海量原始帧消息队列可以做异步削峰云数据库可以存轨迹和状态。把这些组件组合起来一个端云协同的数据管道很快就能搭起来。换句话说云厂商已经帮开发者解决了“模型从哪来、算力从哪来、数据存哪里”这三个基础问题。这是它们为具身智能做出的实质贡献。2.3 后程需要补上的关键拼图既然“半步”已经走完后程到底缺什么第一是标准化的设备接入协议。现在市面上的机器人底盘、机械臂、传感器品牌繁杂通信方式各不相同。云厂商如果希望更多机器人接入自己的平台必须定义一套端侧 SDK 和接入标准让不同厂家的设备能即插即用。目前这还远未成熟。第二是真机数据闭环。云厂商没有自己的本体很难低成本获取真实操作数据。缺乏数据模型就只能在通用数据集和仿真环境里打转无法真正解决物理世界的长尾问题。第三是场景级解决方案。仓库搬运、产线上下料、家庭服务每个场景的需求都不一样。云厂商需要和集成商、机器人公司合作把模型、硬件、业务流程打包成可交付的解决方案而不是只提供一个 API。所以判断“四朵云”后程是否有望核心不是看它们发布多少模型而是看它们能否补上“数据闭环 本体生态 场景落地”这三块拼图。3. 端云协同的具身智能系统架构3.1 云-边-端三层分工在动手写代码之前先把系统架构理清楚。一个典型的端云协同具身智能系统通常分成三层层级核心硬件/服务主要职责端侧机器人本体、摄像头、电机驱动板、MCU/树莓派图像采集、运动控制、本地轻量感知边侧边缘网关、Mini PC、工业电脑低时延预处理、局部避障、网络抖动缓冲云侧GPU 云主机、对象存储、消息队列、模型服务大模型推理、训练、数据清洗、OTA 下发边侧不是必须的。对于一台树莓派小车这种入门项目可以直接省略边侧让树莓派作为端侧直连云端。只要网络条件稳定这个简化架构也能完成一个有意义的最小闭环。3.2 数据流向上行与下行端云协同系统里存在两条核心数据链路。一条是上行链路。端侧摄像头采集图像后先在本地做压缩和关键帧筛选再通过 HTTP/MQTT 上传到云端云端把原始数据写入对象存储经过清洗、标注后进入训练集用于模型迭代。另一条是下行链路。云端部署好的模型接收端侧推理请求返回识别结果或动作指令端侧根据指令执行前进、转向、停止等动作再把执行结果反馈给云端。在真实项目中这两条链路通常是并行的而且需要做异步化。比如端侧一边持续采集图像一边用独立线程上传历史数据避免上传操作阻塞实时决策。下面实战环节会体现这个思路。4. 实战基于树莓派的具身智能小车端云协同最小闭环4.1 需求与功能拆分这一节的目标很明确做一台树莓派小车通过摄像头采集画面把图像上传到云端的推理服务识别画面中是否出现目标物体人或车辆小车根据识别结果执行“前进”或“停止”动作。整个项目拆成四个功能模块图像采集树莓派 Camera Module采集 640x480 分辨率的画面。云端推理Flask 服务接收图像调用 YOLO 模型完成目标检测。动作决策根据检测结果用简单规则决定小车是前进还是停止。数据回传把图像和检测结果异步上传到云平台为后续迭代积累数据。4.2 硬件与环境准备建议的硬件清单如下树莓派 4B 或 5内存 4GB 或 8GB 均可。树莓派 Camera Module可以是官方 CSI 摄像头或 USB 摄像头。小车底盘 直流电机 电机驱动板L298N 或 L9110S 均可。移动电源或锂电池组给树莓派和电机分别供电。一台云服务器建议带 GPU用于部署推理服务。软件环境方面树莓派端推荐使用 Raspberry Pi OS Bookworm 64 位系统Python 版本建议 3.9 以上。云端可以是任意 Linux 云主机Ubuntu 20.04/22.04 比较常见。需要注意新版 Raspberry Pi OS 默认不预装 RPi.GPIO树莓派 5 上 RPi.GPIO 兼容性也有限。后面代码中我会使用 RPi.GPIO 接口如果你的系统安装失败可以尝试安装rpi-lgpio替代大部分代码可以保持不变。依赖安装命令如下# 树莓派端 sudo apt update sudo apt install python3-picamera2 python3-opencv pip install requests RPi.GPIO # 如果树莓派 5 上 RPi.GPIO 安装失败 pip install rpi-lgpio# 云端服务器 pip install flask ultralytics opencv-python4.3 云端推理服务先实现云端推理服务。这个服务提供一个 HTTP 接口接收一张图片调用 YOLO 模型做目标检测返回识别到的物体类别、置信度和边界框坐标。我选择 YOLO 作为示例是因为它部署简单、推理速度快而且ultralytics库封装得比较完整适合作为第一版原型。# 文件路径cloud_infer.py import cv2 import numpy as np from flask import Flask, request, jsonify from ultralytics import YOLO app Flask(__name__) # 加载预训练模型第一次运行会自动下载权重 model YOLO(yolov8n.pt) app.route(/infer, methods[POST]) def infer(): if image not in request.files: return jsonify({error: no image uploaded}), 400 file request.files[image] img_bytes np.frombuffer(file.read(), np.uint8) img cv2.imdecode(img_bytes, cv2.IMREAD_COLOR) if img is None: return jsonify({error: failed to decode image}), 400 # 推理 results model(img, verboseFalse) detections [] for r in results: for box in r.boxes: cls_id int(box.cls[0]) conf float(box.conf[0]) x1, y1, x2, y2 [float(v) for v in box.xyxy[0]] detections.append({ label: model.names[cls_id], conf: conf, bbox: [x1, y1, x2, y2] }) return jsonify({detections: detections}) if __name__ __main__: app.run(host0.0.0.0, port8080)启动服务python cloud_infer.py本地测试curl -X POST -F imagetest.jpg http://127.0.0.1:8080/infer如果返回的 JSON 中包含目标类别和坐标说明云端推理服务已经跑通。这里有一个细节需要注意yolov8n.pt是 YOLOv8 的轻量级预训练权重包含 COCO 数据集上的 80 类目标其中就包括 person、car、truck 等足够我们做小车避障验证。实际项目中建议用自己场景的数据微调模型而不是直接使用通用权重。4.4 树莓派端图像采集与调用接下来是树莓派端。代码需要完成三件事采集图像、调用云端推理接口、根据结果控制电机。# 文件路径pi_robot.py import io import time import requests from picamera2 import Picamera2 from PIL import Image import RPi.GPIO as GPIO # 云端推理服务地址按实际环境修改 SERVER_URL http://云服务器IP:8080/infer # GPIO 引脚定义按实际接线修改 PIN_LEFT_FORWARD 17 PIN_RIGHT_FORWARD 18 PIN_LEFT_BACKWARD 22 PIN_RIGHT_BACKWARD 23 def setup_gpio(): GPIO.setmode(GPIO.BCM) for pin in [PIN_LEFT_FORWARD, PIN_RIGHT_FORWARD, PIN_LEFT_BACKWARD, PIN_RIGHT_BACKWARD]: GPIO.setup(pin, GPIO.OUT) GPIO.output(pin, GPIO.LOW) def stop(): for pin in [PIN_LEFT_FORWARD, PIN_RIGHT_FORWARD, PIN_LEFT_BACKWARD, PIN_RIGHT_BACKWARD]: GPIO.output(pin, GPIO.LOW) def forward(): GPIO.output(PIN_LEFT_FORWARD, GPIO.HIGH) GPIO.output(PIN_RIGHT_FORWARD, GPIO.HIGH) def turn_left(): GPIO.output(PIN_RIGHT_FORWARD, GPIO.HIGH) GPIO.output(PIN_LEFT_BACKWARD, GPIO.HIGH) def turn_right(): GPIO.output(PIN_LEFT_FORWARD, GPIO.HIGH) GPIO.output(PIN_RIGHT_BACKWARD, GPIO.HIGH) def capture_image(picam2): 采集一帧图像转成 JPEG 字节流 img picam2.capture_array() pil_img Image.fromarray(img) buf io.BytesIO() pil_img.save(buf, formatJPEG) buf.seek(0) return buf def infer(picam2): 调用云端推理服务 buf capture_image(picam2) try: resp requests.post(SERVER_URL, files{image: buf}, timeout10) resp.raise_for_status() return resp.json() except Exception as e: print(推理请求失败:, e) return None def decide(json_data): 简单决策规则检测到人/车辆就停车否则前进 if not json_data: return stop for det in json_data.get(detections, []): if det[label] in [person, car, truck, bus, bicycle]: return stop return forward def main(): setup_gpio() picam2 Picamera2() config picam2.create_still_configuration(main{size: (640, 480)}) picam2.configure(config) picam2.start() try: while True: result infer(picam2) action decide(result) print(检测结果:, result, 动作:, action) if action stop: stop() else: forward() time.sleep(1) except KeyboardInterrupt: pass finally: stop() picam2.stop() GPIO.cleanup() if __name__ __main__: main()这段代码的核心逻辑并不复杂但有几个地方值得展开说明。capture_image使用picamera2.capture_array()拿到画面数组再用 Pillow 编码成 JPEG。为什么不直接用 OpenCV因为树莓派官方摄像头在 Bookworm 系统上更推荐使用 picamera2它和 OpenCV 的 V4L2 接口共存时容易出现冲突。使用统一采集接口可以减少调试成本。infer函数把图片放入requests.post的files参数中以 multipart/form-data 格式上传这和云端request.files[image]是对应的。超时设置为 10 秒避免云端无响应时程序卡死。decide函数是决策层。这里用的是最简单规则只要检测到人、汽车、卡车、公交车、自行车中的任意一类就让小车停车。实际项目中你可以根据置信度、目标距离、任务目标做更复杂的判断如果使用四轮差速底盘还可以输出左转、右转等动作。4.5 运行与验证运行分两步。第一步在云服务器上启动推理服务并确保安全组放行 8080 端口。如果树莓派和云服务器不在同一局域网需要把SERVER_URL改成云服务器的公网地址如果在同一局域网做测试也可以改成内网 IP速度更快、更稳。第二步在树莓派上执行python pi_robot.py预期行为摄像头对准空旷区域时控制台输出动作: forward小车前进。摄像头对准行人或车辆时控制台输出动作: stop小车停止。网络异常或云端服务未启动时infer返回 None决策结果为 stop小车保持停止。这从某种程度上验证了“安全优先”的设计思路当系统不确定外界情况时默认停止而不是继续前进。4.6 网络与安全说明上面的示例为了方便阅读直接使用了明文 HTTP 和公网 IP。真实项目中尤其是设备跨网络访问云服务时不能这样做。至少要加一层接口鉴权比如在请求头中带 Token云端校验通过后才执行推理。# 端侧请求增加鉴权头 headers {Authorization: Bearer YOUR_API_TOKEN} resp requests.post(SERVER_URL, files{image: buf}, headersheaders, timeout10)# 云端校验 Token import functools API_TOKEN YOUR_API_TOKEN def require_token(func): functools.wraps(func) def wrapper(*args, **kwargs): token request.headers.get(Authorization, ) if token ! fBearer {API_TOKEN}: return {error: unauthorized}, 401 return func(*args, **kwargs) return wrapper如果条件允许更推荐直接使用 HTTPS避免图片内容在传输过程中被截获。5. 数据闭环从 Demo 到迭代5.1 为什么真机数据是后程关键前面不断强调“数据闭环”这里从技术角度解释一下原因。通用预训练模型在实验室数据集上表现不错但真实物理环境里会遇到各种长尾情况逆光、遮挡、目标被部分截断、同类别物体外观差异巨大。处理这些问题必须用真实场景的数据做增量训练。对具身智能来说数据不只是“看看这是什么”还要包含动作和结果例如“抓取这个杯子时力度大了导致杯子滑动”。这类体现物理交互的数据在公开数据集里非常少只能从真机操作中长期积累。所以谁能更高效地采集真实场景数据谁就掌握了具身智能下半场的竞争力。5.2 最小数据回传方案回到我们的树莓派小车项目。目前小车每次推理后图片只是临时使用然后就被丢弃了。现在改造一下把每次推理的图片、检测结果、时间戳一起异步上传到云端。注意“异步”两个字。上传操作如果放在决策主线程里一旦网络抖动小车反应会卡顿。更合理的做法是使用一个后台线程和队列。# 文件路径data_collector.py import threading import queue import requests class DataCollector: def __init__(self, upload_urlhttp://云服务器IP:8080/upload): self.upload_url upload_url self.queue queue.Queue(maxsize50) self.session requests.Session() self.worker threading.Thread(targetself._worker, daemonTrue) self.worker.start() def _worker(self): while True: item self.queue.get() if item is None: break try: files { image: (frame.jpg, item[image], image/jpeg), json: (meta.json, item[json], application/json), } self.session.post(self.upload_url, filesfiles, timeout20) except Exception as e: print(上传失败:, e) finally: self.queue.task_done() def push(self, image_buf, json_data): 把帧放入队列队列满时丢弃旧帧 image_bytes image_buf.getvalue() try: self.queue.put({image: image_bytes, json: json_data}, blockFalse) except queue.Full: print(上传队列已满丢弃当前帧) # 云端对应的接收接口 # app.route(/upload, methods[POST]) # def upload(): # image_file request.files.get(image) # meta_file request.files.get(json) # ...在pi_robot.py中只需要在推理后调用collector DataCollector() result infer(picam2) if result is not None: collector.push(capture_image(picam2), json.dumps(result))云端接收接口可以根据实际存储方案实现。第一版可以直接保存到本地磁盘后续再接入对象存储和数据库。5.3 从原始帧到训练集云上数据清洗思路原始上传的数据不能直接用来训练需要经过清洗才能变成高质量训练集。常见的清洗任务包括过滤模糊帧图像梯度方差过低的帧直接删除。过滤重复帧相邻帧内容高度相似时只保留一帧。过滤无效帧画面中没有任何目标、动作也未发生变化的帧。自动标注与人工复核对保留下来的帧自动打标再由人工抽检修正。这些任务如果放在单台电脑上处理效率很低。放在云上可以借助批量计算服务并行处理几百路设备上报的数据这也是云厂商数据平台的典型应用场景。经过清洗后的数据会进入增量训练流程训练好的模型再部署回云端推理服务。至此一条“采集-上传-清洗-训练-部署-再采集”的数据闭环就跑通了。到这一步一个小车项目才真正具备“越用越准”的雏形。6. 常见问题与排查思路这里把端云协同和树莓派小车开发过程中可能遇到的问题整理成一张表。问题现象常见原因解决思路树莓派开机后找不到摄像头摄像头未在系统中启用执行sudo raspi-config在 Interface Options 中启用 CameraOpenCV 读取 CSI 摄像头失败picamera2 与 V4L2 冲突统一使用 picamera2 采集不要混用两套接口云端接口请求超时网络不稳定、图片过大、模型推理慢压缩图片、降低分辨率、改用 GPU 推理、增加重试机制小车行动不灵敏决策明显滞后决策频率太低或上传操作阻塞主线程降低推理频率但不建议太低把上传操作放入异步队列上传数据过多云存储成本快速上升所有原始帧都上传做关键帧筛选只上传检测到目标或动作变化的帧树莓派 5 上 RPi.GPIO 报错RPi.GPIO 对树莓派 5 支持不完善使用rpi-lgpio代码接口基本兼容公网访问云端服务失败安全组未放行端口、IP 限制、服务未启动检查云服务器安全组确认 Flask 监听 0.0.0.0并开启防火墙端口返回结果出现中文乱码或类别名不匹配模型训练数据集与任务不一致检查模型类别映射表必要时用自有数据微调电池供电不足小车中途断电电机和树莓派共用电源分开供电电机用大电流电源树莓派用独立 5V 电源6.1 树莓派选 4GB 还是 8GB很多初学者会把树莓派的内存和 TF 卡容量搞混。4GB、8GB 指的是内存不是存储空间存储空间由 TF 卡决定一般建议至少 32GB。回到选型问题。如果树莓派只负责图像采集、网络请求和电机控制4GB 版本完全够用因为真正的模型推理在云端进行。如果你希望在小车端侧跑一个轻量级模型比如 MobileNet 或 YOLO-nano从大模型退化为端侧小模型那么 8GB 会更从容可以同时运行采集程序、推理程序和决策程序而不至于频繁触发内存交换。预算允许的情况下直接买 8GB 版本后续扩展空间更大。6.2 怎么定位“端侧决策正常但云端一直报错”的问题这个问题可以按链路逐段排查。首先看云端服务日志确认请求是否到达然后看请求头里的 Token 是否正确再看图片数据是否完整上传最后看模型推理是否报异常。推荐在端侧和云侧都打上同一个 request_id便于把端侧日志和云侧日志关联起来。7. 最佳实践与工程建议7.1 端云链路设计建议第一图像必须压缩。640x480 JPEG 大约几十到一百多 KB如果直接用 4K 原始流上传带宽和存储成本都会失控。上传前可以先缩放再提高 JPEG 压缩率。第二采集、上传和决策要解耦。采集线程只负责拿帧决策线程只负责根据状态机输出动作上传线程异步消费队列。三者互不阻塞系统才能稳定运行。第三决策逻辑建议使用有限状态机。简单 if-else 在小项目里够用但一旦加入避障、巡逻、回充等状态状态机会让逻辑清晰很多。比如class RobotState: IDLE idle FORWARD forward AVOID avoid STOP stop7.2 接口安全与最小权限给云端接口加鉴权是底线要求。Token 不要硬编码在代码里可以从环境变量或配置文件读取。云服务器的安全组只放行必要的端口不要对所有 IP 开放。云账号使用子账号授权只给这台设备访问对象存储和推理服务的权限遵循最小权限原则。7.3 成本与性能平衡按量付费的 GPU 实例适合原型验证不长期运行时要主动释放。如果希望成本稳定可以使用竞价实例或包月低配实例。模型选择上优先尝试轻量模型例如 YOLO 的 nano 版本再根据准确率决定是否换更大的模型。数据存储方面只保留关键帧并设置生命周期规则比如 30 天后自动清理临时数据。7.4 日志与可观测具身智能项目排查问题比普通 Web 项目更繁琐因为问题可能出在硬件、网络、模型任一环节。建议从