具身智能开发实战：从硬件平台到深度估计的完整技术链路

这两年“具身智能”这个词确实被反复刷屏，但落到实地上，很多人还是搞不清楚一件事：一台机器人要真正具备在物理世界里干活的能力，到底需要什么样的硬件、什么样的视觉方案、什么样的深度估计手段。我经常在技术社区里看到有人拿着一个开发板问“能不能直接跑具身智能”，也看到不少团队对着机械臂抓取视频里的深度图一头雾水。

今天这篇，我不讲那种“概述+展望”的空话，直接把具身智能开发里最绕不开的四块内容拆开揉碎给你看：硬件平台怎么选、开发板怎么配、视觉感知怎么搭、深度估计怎么落地。文中涉及的主控板选型、传感器调试、深度图处理、数据集坑点，都是我实际动手验证过的东西。无论你是刚开始接触嵌入式的学生，还是已经在做无人机、机械臂项目的工程师，这篇文章应该能帮你把整条技术链路串起来，少走不少弯路。

1. 从“能动的机器”到“具身智能”：这到底在做什么

很多刚接触这个方向的人，第一反应是“具身智能是不是就是给机器人装个大模型”。这种理解不算错，但太粗糙了。具身智能的核心不是单一模型，而是把感知、决策、控制三大模块在物理设备上闭环起来。也就是说，机器人要能从传感器拿到数据，理解周围环境，再通过网络或者运动规划算法把决策变成真实的机械动作。

对于开发者来说，这意味着你首先要有一条完整的技术栈意识：不会只写一个Python脚本就能搞定一切，也不会只调一个电机就能做出智能动作。整个系统是分层协作的，每一层都有对应的硬件和算法。

物理环境里做AI，跟在数据集上做AI最大的区别在于三个字：不确定。你在仿真环境里训练的模型，拿到真实场景里会遇到反光、暗光、遮挡、传感器噪声、线缆松动、电机震动等各种问题。而且真实环境里所有信号都是带延迟的，图像处理要时间、深度估计要时间、路径规划要时间，任何一个环节慢了，整个系统就会表现得“卡顿”甚至“失去控制”。

所以具身智能开发者真正的工作，是在一台资源有限的硬件上，想办法把一个复杂的感知-决策-控制回路以尽可能低的延迟跑起来。这也是为什么后面要花那么大篇幅去讲硬件选型和深度估计——这两个东西决定了系统的下限。

1.1 一句话拆解具身智能系统

用一句话来概括具身智能的技术链路，就是“从传感器到执行器”。一条典型的数据流动路径长这样：

1. 传感器采集数据，比如摄像头画面、激光雷达点云、IMU姿态信息、六维力传感器反馈。
2. 感知模块处理原始数据，识别出场景里的目标物体、障碍物、可行区域，或者估计出目标的距离和位置。
3. 决策规划模块根据感知结果生成动作指令。这一步可能是传统算法，比如RRT路径规划、模型预测控制，也可能是学习类策略，比如强化学习、模仿学习，或者接一个大模型做高层任务拆解。
4. 控制模块把动作指令转成电机或舵机可执行的力矩、速度指令，最终驱动机械臂或底盘完成动作。

注意，这四个步骤之间不是单向流动的，尤其是加入了力传感器之后，控制端还会反馈状态给决策端，形成闭环迭代。开发板在这里是“中间层”角色：它要跑感知算法，可能要跑轻量级模型，要和执行器通信，还要管理各个传感器的时间同步。

我们常说的“硬件平台”，也分三个层级。最底层是电机、舵机、减速器这些执行部件；中间层是各类传感器和驱动电路；最上层才是主控计算平台，也就是我们常说的开发板。具身智能开发的关键发力点，主要在中间层和最上层。

1.2 为什么深度估计是关键一环

视觉感知最终要给机器人一个可操作的空间认知，核心问题只有一个：目标物体离我有多远、在哪里。2D图像能告诉你图像里的某个区域是什么，但没法直接告诉机械臂应该往哪个空间坐标伸手。这时候就需要深度信息介入。

深度估计的常见做法有三种：第一，用RGB-D相机直接输出深度图，比如Intel RealSense系列；第二，用双目相机做立体匹配，靠视差算出深度；第三，用单目相机配合神经网络做单目深度估计，成本最低但精度和稳定性都要打折扣。选哪种方案，取决于你的应用是室内抓取、室外无人机避障，还是野外巡检，不同场景对精度、量程、功耗、成本的要求完全不同。

这些内容我放在第四大节详细展开，先记住一个结论：深度估计是把“看见”升级为“理解空间”的必经之路，也是具身智能项目里最容易被忽视、但调试起来最花时间的环节之一。

1.3 这篇文章适合谁、提供了什么

如果你是刚准备入手具身智能方向的新手，这篇文章能帮你建立起一套从硬件到算法的完整认知框架，让你在买开发板、选相机、跑模型之前，先搞清楚整条链路里每个环节是干嘛的。如果你已经是做机器人项目、无人机视觉或者嵌入式开发的工程师，可以参考我对开发板选型、视觉感知调试、深度图后处理、数据集质量控制这些实操层面的经验，尤其是那些在文档里翻不到的踩坑记录。

说到底，具身智能的门槛不在某一个单点技术上，而在于把多个技术点串成一条可靠链路的集成能力。这篇文章就是围绕“如何搭这条链路”展开的。

2. 硬件平台与开发板选型，先别急着买

很多人学嵌入式或者搞具身智能，上来就问“哪个板子最好”。这个问题本身就问错了。开发板没有绝对的好坏，只有适不适合当前的任务场景。同样是做具身智能，机械臂平台、轮式底盘、无人机平台对主控的需求差了十万八千里。

做硬件选型之前要先想清楚三件事：你要跑什么算法？你要接哪些传感器？你要控制哪几个执行器？这三个问题直接决定了你需要什么级别的处理器主频、多少内存、哪些外设接口、多大功耗、什么尺寸。我见过有人拿一块高性能GPU开发板去做一个只控制两路电机的避障小车，性能严重过剩，项目复杂度却被拉高了。也见过有人拿一块STM32去跑YOLO，那更是完全不现实，单片机的算力根本扛不住。

2.1 具身智能硬件体系的三个层级

我在实际项目里习惯把硬件平台分成三个层级来考虑，这样选型思路会清楚很多。

第一层是执行层，包括各类电机、舵机、步进电机、编码器、驱动器。这一层由MCU或者专用电机控制芯片来管，核心要求是实时性强，响应要快。比如ESP32可以干这个活儿，STM32也经常在这个位置出现。它不需要跑复杂算法，但需要稳定地执行PWM输出、读取编码器、处理急停信号。

第二层是感知层，包括摄像头、激光雷达、麦克风阵列、六维力传感器、IMU等。这些传感器有的需要USB接口，有的走MIPI-CSI，有的走CAN总线或者UART。如果你选的主控板接口不全，后面接传感器会遇到很多莫名其妙的兼容性问题。

第三层是决策层，也就是真正跑AI算法、做路径规划和任务调度的主控。这一层通常需要Linux环境，要有一定的算力来跑轻量级深度学习模型，还要有丰富的网络接口来和上层计算机通信。常见的方案包括Jetson系列、瑞芯微系列、树莓派、Radxa等ARM平台，如果有更大算力需求，会直接用x86工控机。

划分完这三层以后，你就知道为什么不能“一块板子打天下了”。主控板负责大脑，但手跟脚还得靠高效的执行层来配合。

2.2 常见开发板横向对比

我在实际项目里用过不少板子，这里挑几个有代表性的说，表格里罗列一下，方便你对照自己的需求去看。

这张表里面，ESP32-S3和STM32这类的MCU不负责感知和决策，它们更多做执行层的实时控制。IMX6ULL、T113属于典型的嵌入式Linux教学板，适合学基础。真正在具身智能项目里，使用频率最高的是RK3588和Jetson Orin这种带NPU或者GPU的平台，因为它们有一个共同点：能跑Linux、能跑Python、能调用摄像头、能连各种执行器，还能跑轻量的深度学习模型。

如果你预算有限又想快速上手，我给的建议是“先用RK3588起步，等算法稳定以后重新设计执行层”。瑞芯微的板子近几年生态进步非常明显，T113、RK3506、RK3588都有对应的开发板，价格比Jetson低一个量级，但完全能跑MobileNet、YOLO-Small、Depth Anything这类轻量模型，对很多教学项目和产品原型来说足够了。

2.3 按场景选型：机械臂、无人机、轮式车

不同的应用场景对硬件平台的约束截然不同，这里拆开谈。

做机械臂的具身智能，重点考虑的是力控采样频率和六维力传感器接线。这类传感器通常走EtherCAT总线或者CAN总线，主控板要能适配这些通信协议。如果你只是做简单的视觉抓取，主控用RK3588就够，配合一个执行层MCU去驱动机器人臂，上层跑目标检测和深度估计。但如果你要做柔顺控制、拖拽示教这类依赖力反馈的功能，就需要一个实时性很强的实时控制核，这时候Zynq的FPGA+ARM方案会更有优势，因为FPGA可以做高速的数据采集和滤波，把延迟压到微秒级。

无人机场景最特殊。无人机对重量和功耗的限制非常苛刻，主控板每重一克、每多一瓦，都会影响续航和机动性。很多无人机视觉感知项目会用Jetson Orin Nano这种小尺寸的高算力板，配合MAVLink协议和飞控通信。避障场景需要同时处理多路图像流，做目标检测和深度估计，算力需求高，但环境是室外动态的，对模型的运行速度要求也很高，通常要牺牲精度换取帧率。

轮式车或者履带车属于最好上手的平台。底盘空间宽松，电源好布置，主控板的选择余地很大。新手入门可以先从RK3588开发板或者树莓派开始，搭配一个STM32做底层电机控制，上层用Ubuntu系统跑Python视觉算法，这是目前最主流的“树莓派/瑞芯微+STM32”双主控架构，分头调试互不干扰。

我见过不少人把主控选成了一个完全不支持某些摄像头接口协议的板子，然后硬要用USB转接，最后图像马赛克、掉帧、颜色错乱，排查了很久才发现是协议兼容性问题。所以选板子之前先统计好传感器的接口需求，这比纠结CPU跑分重要得多。

2.4 选板踩坑记录

做嵌入式开发以来，我在开发板选型上踩过的坑不少，挑几个值得说的分享。

第一坑是“只看算力，不看散热”。RK3588和Jetson这类高性能板子在跑模型的时候发热量相当可观。裸板不装散热片跑5分钟就可能过热降频，性能直线下降，直接表现为检测帧率从30掉到15甚至更低。这不是板子坏了，是温度保护触发了。所以选型的时候，要把散热方案的成本算进去，铝合金散热片、风扇、均热板都要考虑。

第二坑是“板子上电，电源功率不够”。很多开发板标称5V/3A供电，听起来不大，但接了多路舵机或者机械臂之后，峰值电流会瞬间飙得很高。电源选得不够猛，主控就会频繁重启，整个系统完全不可用。我的经验是，主控电源和舵机电源分开，或者至少留出50%以上的功率余量。

第三坑是“开发板挂载Ubuntu时踩到内核和驱动兼容性”。有用户在T113开发板上挂载Ubuntu系统后，屏幕终端中文显示乱码，但通过MobaXterm远程连的时候中文正常。这个问题不是系统安装错了，而是本地显示缺了中文字体库，控制系统只是在Ubuntu上安装fonts-wqy-zenhei这类中文字体就能解决。远程连接显示正常是因为SSH传输的是编码后的文本，字体渲染发生在你的电脑上，而不是开发板上。

第三坑其实很有代表性，它提醒我们：开发板上的系统环境跟PC上的还是有差异的，很多看起来“玄学”的问题，实际就是环境配置不完整，排查方向对了，几分钟就能解决。

3. 视觉感知：让机器人真正“看见世界”

视觉感知相当于机器人的眼睛，直接决定了它能不能理解环境、能不能找到目标。这部分我按“传感器选型→2D感知→3D感知→标定与同步”的顺序讲，因为这是一个完整的从成像到空间理解的逻辑链条。

3.1 传感器选型与感知任务拆解

先说传感器。RGB摄像头是最基础的，适合在光照稳定的环境里做目标检测和分割。如果你想在暗光或弱纹理环境里获取距离信息，就得考虑双目相机或者RGB-D相机。双目相机靠两个镜头之间的视差计算深度，成本低，但对光照敏感，暗处基本失效。RGB-D相机分两种主流技术：结构光和ToF。RealSense D435i用的是主动红外立体，在室内中近距离表现不错；ToF方案例如Azure Kinect，量程更远，适合大空间。

选传感器前先拆解任务：你要检测什么目标，工作距离多远，环境光照条件怎样，需要多高的帧率。这几个参数定下来了，传感器基本就定了。做桌面机械臂抓取，RealSense级别的RGB-D足够了；做室外无人机避障，如果环境光线变化大，双目视觉就需要搭配IMU做视觉惯性里程计，而不是只靠双目深度。

感知任务拆解之后，你会发现过程中大量用到“读图像、做推理、输出结构化结果”的套件，跑在开发板上通常是这样的流程：

1. 采集图像，通常用GStreamer或者相机SDK，把图像帧交给推理模块。
2. 推理模块跑目标检测模型，输出带类别标签的检测框。
3. 根据检测框在图像中的位置，结合相机内参和深度图，得到目标在相机坐标系下的位置。
4. 通过变换矩阵转到机器人坐标系，交给规划模块执行后续动作。

3.2 2D感知：检测、分割与追踪

2D感知主要负责回答“物体的图像位置和类别是什么”。这个层面的技术已经很成熟了。目标检测方面，YOLO系列是目前工程落地最广泛的选择，YOLOv5、YOLOv8、YOLO11都有对应的轻量化版本，能在Jetson或者RK3588上跑出很高的帧率。分割方面，SAM系列属于大模型，直接在板子上跑比较吃力，更适合离线生成标签；实时分割更多用轻量级的语义分割模型，比如PP-LiteSeg或者BiSeNet。

追踪任务也很关键，尤其是动态场景，比如无人机需要持续跟着一个目标，或者抓取传送带上的物体。追踪算法分两类：一类是检测后接着做多目标跟踪，比如ByteTrack、DeepSORT；另一类是用孪生网络之类的方法做单目标跟踪，更轻量。在开发板上做追踪要特别注意ID Switch问题，也就是目标一被遮挡再出现，ID经常跳变，这个时候要结合深度信息和运动模型来追踪，而不是只看图像特征。

在机械臂抓取的项目里，2D感知经常做得很粗糙，只检测一个平面位置，结果目标物体一旦被遮挡或者有堆叠，识别效果立刻崩掉。2D感知的边界就在这——它只能给你看“看到的东西”，还没法给你“物体的准确空间位姿”。

3.3 3D感知：从像素到空间

当机器人需要真的伸手去抓取物体时，光有2D检测框是不够的。你需要知道物体的三维位置和姿态，也就是6D位姿。此时有两个方向：一是直接用RGB-D深度图得到三维点云，然后用点云分割加位姿估计网络输出物体的6D位姿；二是用一个端到端的视觉位姿估计模型，网络输入RGB和深度图直接输出物体坐标系到相机坐标系的变换矩阵。

工程上，我看到大多数团队采用的是前者：先配准深度图生成点云，再做点云平面分割，或者聚类分开堆叠物体，然后匹配已知CAD模型得到位姿。这样做的原因在于，端到端的6D位姿模型泛化能力有限，换一个物体或者换一个环境，效果立刻下滑，而点云方案至少每一步都可解释、可调试、可换算法。

点云处理本身也是一个容易掉坑的地方。深度相机出来的点云噪声很大，尤其在物体边缘和反光表面，会出现很多“飞点”。这些飞点会导致聚类算法把物体尺寸估计得偏大，进而影响抓取点计算。所以我一般会在点云处理之前加一个统计滤波或者半径滤波，先把离群点干掉，再做后续处理。

3.4 相机标定与多传感器时间同步

视觉感知里最“磨人”也最容易出问题的，不是模型本身，而是标定和同步。相机内参标定是基础，你用ROS或者OpenCV的标定板走一遍就行，但很多人标定完了内参就丢一边不管了，这是不对的。深度相机和RGB相机之间的外参标定、相机与机械臂基座之间的手眼标定，都必须做严格。手眼标定如果标得不准，机械臂抓取的时候误差会直接反映在末端上，而且这种误差是固定的，不是你调控制参数能解决的。

时间同步也是个大问题。有的项目把RGB图像和深度图像分两条通路去读，没有对齐时间戳，结果深度图和RGB图像严重错位，生成的RGBD图像全是重影。这个问题在动态场景里尤其致命，物体稍微移动一下，你检测框框住的位置跟深度图对应的物体根本就不是同一个。解决方法是读帧的时候同时读取时间戳，用消息过滤器把颜色图像和深度图像按时间戳对齐，再输入给后续算法。

无人机视觉感知里的同步问题更麻烦，因为飞控的IMU数据和视觉数据频率不一致，必须做松耦合或者紧耦合的时间对齐。这个ROS里也能处理，但要求你一开始就把同步逻辑架构写好，而不是最后加补丁。

4. 深度估计：从“看见”到“知道远近”

深度估计就是把视觉信息升级为空间信息的关键一步。做具身智能，机器人要完成抓取、导航、避障这些任务，本质上都依赖可靠的深度信息。

4.1 深度估计的三种流派

深度估计技术路线可以粗分为三类。

第一类是用RGB-D深度传感器直接测量，比如RealSense、Orbbec这类设备。它们属于主动式方案，深度图质量高，但受环境光干扰影响大，室外晴天基本歇菜，适合室内中近距离场景。

第二类是用双目立体视觉。它不发射激光，纯粹靠两个摄像头同时拍到的图像计算视差，再根据双目标定参数恢复深度值。双目方案的好处是室外可用，功耗低，硬件成本低，但缺点是弱纹理环境下匹配效果差，比如白墙、纯色地板这类场景，立体匹配算法很难找到对应点。这个方向工程难点在立体匹配算法：SGBM、ELAS、实时立体网络，不同算法的耗时和精度差别很大。部署在边缘设备上，要选一个能在算力约束下跑得动的平衡点。

第三类是单目深度估计。它从单个RGB图像用深度学习模型直接预测深度值，代表模型有MiDaS和近年被广泛讨论的Depth Anything。这类方案最大的优势是只需要一个普通摄像头，成本极低，模型泛化能力也不错，训练数据的规模很大之后，很多环境都能应付。但它的精度上限明显低于前两类，无法提供度量级精确度，只能提供相对深度或者模糊的绝对深度。在一些场景里，比如只看一个大致距离来决定是否刹车，单目估计够用；但给机械臂提供抓取位姿的毫米级定位，单目就不够看了。

所以，我在实际项目里经常这样搭配：单目深度估计用来做人形机器人或者轮式机器人的成本敏感场景预判，双目或深度相机负责需要精确距离的操控级任务。两者不是替代关系，而是互补关系。

4.2 深度图到点云的计算逻辑

给新同学普及一下：深度图和点云不是两个完全不相关的数据格式，它们本质上是同一种三维信息的两种表示方式。深度图是一张灰度图像，每一格存的是一个像素距离相机的距离。点云则是一堆包含x、y、z三维坐标的点的集合。从深度图像素坐标(u, v)和深度值d，转成相机坐标系下的三维坐标的公式是：

x = (u - cx) * d / fx y = (v - cy) * d / fy z = d

其中fx和fy是相机焦距，cx和cy是主点坐标，这些参数都来自相机内参标定结果。很多人在ROS里用depth_image_proc这个节点就能完成深度图到点云的转换，但如果你是自己写推理管线，一定要把这条坐标变换关系搞清楚。

配合上一节讲的视觉感知，实际应用流程是：

1. 先用目标检测模型在RGB图像上找到目标物体的2D包围框。
2. 在对应的深度图上裁剪相同区域，计算该区域的平均深度或者中值深度，作为目标距离。注意平均深度容易受边缘飞点干扰，我通常用中值滤波之后的中值深度。
3. 把2D框的中心坐标加上深度值，用上面公式转换成相机坐标系下的三维坐标。
4. 再经过手眼标定得到的变换矩阵，转到机器人坐标系，发给机械臂执行抓取。

这套流程看起来不难，但每步都会引入误差。检测框偏了，深度取值就偏了；深度图有噪声，距离就波动；手眼标定如果没做，前面步骤再准也白搭。

4.3 实测中的精度与稳定性表现

从实际项目经验看，不同深度估计方案在精度上的差异非常明显。

我用RealSense D435i在0.5米到2米的室内环境里做过测试，误差一般在1%到2%左右，在1米距离上的误差大约在1到2厘米，对于机械臂抓取常见物体来说足够了。但要注意，如果物体表面过亮、反光或者黑色吸光，深度值会变成无效值或者乱跳。这个属于主动红外方案的物理限制，只能靠换角度或者加滤光片缓解。

双目视觉的精度主要取决于基线长度和图像分辨率的匹配。基线越长，能测的距离越远；但长基线又导致近处盲区变大，需要根据场景来权衡。室内桌面场景，双目在小区域内自动曝光不一致会导致匹配错误，所以很多双目相机内部已经做了自动曝光补偿，例如Mynteye的S系列会做图像同步曝光，能用。

单目深度估计的实测情况是：Depth Anything这类模型在室内外场景下，结构感很强，边缘轮廓保留得很好，但要把它直接当测距工具用是不行的。它的输出尺度不一致，同一个物体在不同距离下给出相同深度预测的可能性不是没有，只是它给出的是一个结构化的、看起来舒适的深度图，离精确测距还有距离。真正要做绝对距离应用，还需要校正这个尺度问题，通常得配合已知尺寸的标定物或者IMU信息做一个在线尺度恢复。

4.4 深度估计在机械臂抓取和无人机避障中的应用差异

深度估计在机器人两大应用场景里的挑战不太一样。

机械臂抓取更强调精度而非量程。你需要在0.5米到1.5米的距离内获得毫米级的深度精度，同时处理反光、透明、黑色物体这些麻烦。透明物体比如矿泉水瓶，深度相机经常直接拍不到，深度图上是空洞。这种情况除了换多模态传感方案，比如双目视觉加结构光融合，另一个思路是先用图像检测框记住物体位置，再根据物体尺寸先验估算抓取位姿，不完全依赖深度图。

无人机避障更强调实时性和量程。无人机飞行速度很快，这就要求深度估计模块每秒至少要能输出15到30帧的深度图。Jetson平台上，轻量的双目立体匹配算法大概能跑到这个帧率，但单目深度估计的实时模型也能做到。另一个关键是量程，无人机在室外可能需要感知20米开外的障碍物，RealSense这种深度相机的有效距离通常在5米以内，室外强光下更差，所以很多无人机项目宁愿用双目或者激光雷达，也不依赖主动式深度相机。

这里多说一句：现在很多团队的无人机避障，用的是前置双目相机为主、单目视觉深度模型为辅的融合策略。双目在白天光照好、纹理清楚的场景下非常可靠，但一旦纹理接近或者靠近水面这种极端反光区域，双目匹配就会失效，此时单目模型的先验语义知识反而能给出一个相对合理的深度推测。两套结果做不确定性融合，整体系统的稳定性要高很多。

5. 数据集质量、学习路线与避坑建议

把硬件、感知、深度估计都讲完之后，最后一部分聚焦学习路径和开发中的现实问题。这部分内容与其说是技术补充，不如说是手记：很多坑我都在社区里看人反复踩，写出来能帮你省一两个月甚至更长时间。

5.1 具身智能数据集质量要求与评价方法

具身智能项目里，数据的重要性怎么强调都不过分。尤其是近几年大家都在做模仿学习和强化学习，模型吃的数据质量和多样性直接决定真机表现。但数据不是光堆数量就有用，质量要求和评价方法这里头有不少门道。

一条合格的数据集至少要满足四个条件。

第一，任务相关性。你采集的数据必须和部署场景高度相关。如果你想让机械臂学会抓取水杯，那么数据里就要有大量不同角度、不同光照、不同桌面纹理下的水杯抓取记录，而且还要记录失败案例，让模型知道什么样的状态不能抓。

第二，传感器一致性。训练数据里的传感器配置要和真机一致。数据如果是用RealSense拍的，部署的时候也用RealSense，能够少很多迁移问题。如果数据里的相机内参和部署相机不同，深度尺度就会有偏差，模型学到的空间映射关系也会走样。

第三，时间同步和标注质量。数据里每一帧图像、深度图、关节角度、末端位姿必须带时间戳且同步对齐。这个说起来容易做起来难，我之前有一次发现数据里的深度图像和关节状态差了500毫秒，导致模仿学习的策略在真机上动起来抽搐，查了整整两天才找到原因。标注质量同样关键，如果是人工标注的物体位姿，要建立多人交叉校验机制，减少标注误差。

第四，场景多样性。具身智能最大的敌人是过拟合到特定环境。一个只在某张桌子、某个光照、某个背景里训练过的策略，拿到别的地方马上失效。所以采数据集时要刻意增加背景、桌面颜色、物体纹理、光照方向的变化。

至于评价方法，业界目前的标准还不完全统一，但一般会关注“任务成功率”和“场景泛化效果”。任务成功率没法只看平均值，要按困难程度分层统计，比如简单摆放、遮挡摆放、光照变化三大类分别统计。场景泛化效果要单独留出训练时没见过的环境做测评，不能拿训练环境的结果充当泛化指标。

5.2 适合新手的具身智能学习路线

如果你现在完全是个新手，我的建议别一上来就买好几千块的Jetson开发板。学习的第一步是先搭Python和Linux环境，把基本数据结构、图像处理库用熟。然后在本地电脑上跑通目标检测和深度估计模型的推理，理解图像从读入到输出结果的完整流程。这个过程不需要专门硬件，用你的PC就可以。

第二步，入手一块RK3588或者树莓派，搭配一个STM32，把“主控Linux板+执行MCU”的双层架构搭起来。学习串口、I2C、SPI、CAN这些通信协议，让主控板能通过串口给单片机发指令，单片机控制电机转动。这一关过了，你就具备了搭建一套最小闭环硬件系统的能力。

第三步，加视觉模块。把一个USB摄像头接到主控板上，用OpenCV读图像，做一个深度学习目标检测，再把检测结果在图上画出来。然后加RGB-D相机，学会读深度图和点云，学会坐标转换，实现“图像检测+深度定位”的最简版抓取。

第四步，再往上走就是集成和算法优化，涉及控制理论、路径规划、强化学习、模仿学习、大模型等等。到这个阶段，你已经有足够的工程基础去理解复杂的算法论文和源码了。

很多人困在第二步，不是学不会代码，而是不懂嵌入式底层。建议先掌握串口通信和定时器中断，不要急着上RTOS，把裸机控制搞明白，再上FreeRTOS或RT-Thread。

5.3 常见开发问题速查

把几个常见开发问题整理成一个速查表，碰到问题可以对照着排查。

这里我再补充一个VSCode连接开发板的小技巧：如果网络比较弱，建议设置remote.SSH.showLoginTerminal为true，这样能看到SSH的登录过程，方便判断是密码错误、网络不通，还是服务端卡死。

5.4 几个我踩过的大坑

做具身智能项目这两年，真正让我记忆深刻的坑往往不在算法侧，而在工程侧。第一个坑是对开发板的性能预期过高。很多人以为换了Orin之后，所有模型都能实时跑，实际上一加载大模型，显存就爆了。所以我现在做视觉方案之前，会先做一次“最小可运行”验证：找一个类似的轻量模型在目标板子上跑一遍，记录帧率和延迟，再决定要不要换更重的模型。

第二个坑是力传感器的标定和滤波。虽然这篇文章主要讲视觉，但具身智能里力反馈的作用同样重要。六维力传感器数据天生带噪声和零漂，直接拿回原始值做控制，机械臂会高频抖动。处理方式是要做零点校准和低通滤波，滤波截止频率要根据机械臂的刚度来调，调不好会牺牲灵敏度。

第三个坑是战略层面的：闷头做模型，不做系统集成。我见过有的团队花了几个月调一个抓取网络，在仿真环境里成功率95%，一上真机降到30%。原因就是把所有精力放在模型精度上，没有花时间做相机标定、机械臂运动学标定、抓取策略鲁棒性分析。具身智能的项目，拼的不是单一模块的SOTA，而是整个系统在最差情况下的可靠性。

写在最后：给正在准备做具身智能的人一个具体建议

如果非要给一个执行层面的建议，我的建议是：第一次做项目，不要把目标定成“做一个通用具身智能机器人”，那是一个科研问题。把一个非常小的任务闭环打通，比如“机械臂从桌面上准确抓起一个已知的方块放到指定位置”，这里面涉及的视觉检测、深度估计、手眼标定、机械臂运动学、抓取规划、控制执行，每一环都够你折腾很久。把这条小链路做到稳定，你对整个系统的理解会比读十篇综述都深。之后再逐步增加任务难度和目标种类，模型和算法再慢慢加码，这条路才走得稳。